Supposedly, the industry is trending toward hiring fewer separate front-end and back-end engineers and instead hiring more full-stack engineers. The idea is that a full-stack engineer can deliver an entire application (front-end, back-end, database, ops, etc) instead of specializing in one of those areas. Is this trend real? I am not yet convinced, but let’s assume it is real in this post.
Why it makes sense
I would argue that whether this trend is true or not, there are reasons for it that make sense. The tooling available to full-stack engineers has never been better. For instance, a full-stack engineer can use tools like React Native or Google Flutter to build applications that be deployed to every major platform using the same code base. Furthermore, the server side code can be written using TypeScript and deployed on Node. Coupled with React Native, this means that the full-stack engineer need only master a single language.
Where it falls apart
Writing non-trivial front-end applications targeted for many platforms is tricky and time-consuming. Furthermore, designing complex backend applications for modern applications is also tricky and time-consuming for different reasons. With that in mind, it makes sense to keep the disciplines separate. However, this same logic applied to development and operations. Many companies have found success combining development and operations into a single role. They likely see the same opportunity with front-end and back-end work.
My advice
If you’re a backend engineer, you’d serve yourself well to begin delving into front-end tools using a framework like React or React Native. There are numerous available resources to begin learning.
If you’re a frontend engineer, learning backend design is less straightforward (imo) since it is less about jumping into code and more about developing “systems thinking”. With front-end code, you tend to have a single user using a given instance of the application at a time. With back-end, a single application instance should serve thousands of concurrent users. The database and app must gracefully handle concurrent writes. To learn more, start watching systems design videos on YouTube.
Versatility a driving factor?
Companies and leaders (even smart ones) are obsessed with treating every engineer as equivalent. They want to create an environment where skillset need not be considered when reassigning engineers to other teams and projects. Of course, this sounds crazy to any sane engineer. However, requiring that every engineer be a full-stack engineer drives reality closer to this management utopia.
Full-stack might make most sense for established teams
If your application or application component is mature, then full-stack engineers might make a lot of sense. When is your application mature? Let’s just say that once you are at the point where new features require some modifications to a mostly complete back-end codebase and an established front-end codebase that deploy to a running app, then we’ll consider it mature within the context of this post.
My target when building a team of 8-10 engineers that is delivering a full stack experience has been to have 2 engineers that are frontend focused and another 2-3 that are “full stack aware” (meaning they could move up and down the stack if they needed to but mostly stay toward the backend). I certainly agree that backend engineers have a bit of an easier time moving forward.