Alternatives to becoming a Full Stack Developer

Starting out
When you're starting out your career as a software developer, you'll typically get a first role as either a backend or frontend dev, and after a couple of years, gain some experience on the other side to become a full stack developer.

Company specific lock in
Since every organisation has its own tech stack, a full stack developer in Company A will have a different set of skills than one in Company B. Those additional skills you learn are still useful to boost your knowledge - it can include: specific cloud services, CI/CD, containerization, DevOps processes, a domain specific library or framework, and the company's SDLC process. 

At this point many developers stay committed to their company's tech stack and remain working as a full stack developer for several more years. My advice - don't just coast as a full stack developer, limiting yourself to web apps. Branch out as soon as you get the chance, by getting experience with any of these. Do it in your own time if there is no opportunity at work.

• Native mobile app development (Swift or Kotlin)
• Cross platform mobile app development (Flutter or React Native)
• Desktop app development
• A newer backend programming language (Golang, Rust or Elixir)
• AI & ML
• IoT (Arduino or Raspberry Pi)

Become a generalist
Your aim is to become a "generalist" - someone who has deep knowledge in two or more areas and maintains a broad knowledge across many platforms, languages and frameworks.

After becoming a generalist, you'll be able to switch up your job roles, stretching your capabilities a bit each time you move. You'll find that you can apply for a larger set of roles, increasing the possibility to land your dream job. 

Career progression
Your varied knowledge will make it easier to apply your skills in new and unfamiliar areas, building up after some years to become a senior developer. Once there, its possible to remain at the senior level for an extended period - as long as you still enjoy it and are still learning, why not.

Eventually you might try for a tech team lead or software architect role. Software architects often started out as generalist developers who gained enough varied experience to be able to apply their software design skills into any domain. Tech leads can have a similar background, but they maintain more of a hands on development focus as part of their role, getting involved especially with creating proof of concepts. 

More reading
Generalist vs Specialist - the difference
Bill Gates on the book "Range: Why Generalists Triumph in a Specialized World", by David Epstein 
"The Polymath: Unlocking the Power of Human Versatility", by Waqas Ahmed
"Polymath: Master Multiple Disciplines", by Peter Hollins

Thanks to reddit user -NewYork- for this meme

Which .NET ORM - Dapper or Entity Framework?

Within the .NET ecosystem, two ORMs dominate, the lightweight Dapper (open source) and the fully featured Entity Framework (EF) by Microsoft. 

Depending on your project's size and requirements, either of these should work well for you, but there are definitely some known cases where each is a better fit. That's what we're discussing in this post.

When to use Dapper?

• Small to medium size projects. It has low overhead in terms of setup and configuration.
• The database tables are in place already and you're calling existing stored procedures. This is known as a data first approach.
• You prefer to hand code the SQL for speed, optimization or fine tuning.

When to use Entity Framework?

• Its a large and/or enterprise type project.
• The database hasn't been created yet and you'd like to use a code first approach. The framework will create the database for you after you code the data models.
• You want the ORM to handle transactions for you in the background.
• You need to use the power of C# LINQ (Language Integrated Query), whereby SQL joins and other queries are generated for you based on your C# code.

Other important factors

• Is your project likely to change frameworks, or need to be adapted to other databases? If yes I'd favour Dapper, because there's just less to migrate and configure. Dapper tries to not get in the way. There are no  additional abstractions and class models that happens with EF.
• Are you using .NET Core? Its probably a controversial opinion but I feel that .NET Core as a framework is still quite unstable compared to the original .NET Framework. So when a new version comes out, there's normally breaking changes within EF Core. For that reason I'd also favour Dapper over EF for .NET Core projects.

What's not a factor?

• Speed and performance. There's no longer any significant performance difference between Dapper and EF. Issues with performance are more likely to be something else that's not being done correctly at the SQL level, such as a lack of indexing, or an incorrect query.
• The origin of the framework. The first release EF for .NET which came out in the 2000s had terrible performance. Since that time, all the performance issues have been fixed.