What I Learned Working Across Multiple Technology Stacks
Seven years across .NET, PHP, React, Angular and Flutter. The frameworks differ far less than they appear to — and what transfers is more valuable than what does not.
Starter draft. Adjust the framing to match how you want to present your breadth.
Working across several stacks is sometimes treated as a lack of focus. In practice it has been the most useful thing about my experience, because it makes the boundary obvious between what is genuinely a concept and what is just a convention.
The frameworks are more similar than they advertise#
ASP.NET Core, Laravel, Express and Spring solve the same problems in a slightly different vocabulary:
| Concept | ASP.NET Core | Laravel |
|---|---|---|
| Request pipeline | Middleware | Middleware |
| Wiring dependencies | Built-in DI container | Service container |
| Data access | Entity Framework | Eloquent |
| Templating | Razor | Blade |
| Input validation | Data annotations / FluentValidation | Form requests |
| Background work | Hosted services | Queues |
Once you have learned the concept in one, the second framework is mostly a naming exercise. The same is true on the front end: components, props, state and lifecycle exist in React and Angular alike, with different syntax and different opinions about how much the framework should do for you.
What transfers, and what does not#
Transfers between stacks:
- HTTP: methods, status codes, caching, content negotiation
- Relational modelling, indexing and reading an execution plan
- Authentication and authorisation concepts
- Debugging method — narrow, reproduce, fix at the right layer
- Judging trade-offs and sequencing work
Does not transfer:
- Syntax and idiom
- Ecosystem knowledge: which library is the sensible default, which is abandoned
- Tooling and build systems
- Community conventions about project layout
The first list is where the professional value sits. The second is learnable in weeks; the first takes years.
Depth still matters#
Breadth without depth is a real failure mode — knowing enough of five stacks to produce something that runs, and not enough of any to know why it breaks.
What has worked for me is going deep where it pays back across stacks. SQL and query performance apply everywhere data is stored. HTTP and API design apply everywhere systems talk. Debugging method applies everywhere. Deep knowledge of one framework's configuration system expires with the framework; deep knowledge of indexing does not.
You become useful at the seams#
The genuine advantage of breadth is at the boundaries — where a React front end meets a .NET API meets SQL Server, where a Flutter app meets a PHP backend. Problems there are often invisible from either side alone: a date serialised in one time zone and parsed in another, a null the API permits and the client does not expect, pagination the UI implements differently from the endpoint.
If you have worked on both sides, you look at the boundary first. That is frequently where the bug is.
What I would tell someone starting out#
- Learn one stack properly first. Breadth built on no depth is fragile.
- Learn concepts, not APIs. Ask what problem a feature solves before memorising its syntax.
- Learn SQL seriously. It outlasts every framework you will use.
- Read existing code. Most professional work is modifying software that already exists.
- Keep notes. You will meet the same problem in a different language in three years.