full-stack engineering is one third as good | Jobs Vox

It’s a beautiful fantasy. One developer for it all—The Magical Fullstackcorn.

Hiring for Your Startup or Tech-Forward Company? A full-stack engineer will give you 2x or more than a regular developer.

Starting or advancing your career as a software engineer? Full-stack engineering puts you on the fast track to senior positions twice as fast.

Full-stack engineering is a tempting myth, but in many cases it’s a misguided compromise that can produce a lower quality product in exchange for making one more stressed.

If you’re a developer just starting out in your career, be wary of any job postings looking for a Full-Stack Engineer. You will be expected to do two jobs for one salary in half the time.

If you’re hiring developers, don’t ask specifically for full-stack engineers. The estimated upfront savings will cost you a malformed database, a bucket of technical debt, and/or inefficient user journeys.

There are a few exceptions: specialized tools for specific use cases where full-stack engineers can provide fully functional code. (I’ll say more about these later.) And full-stack specialization can reasonably be an end game for very senior engineers with many years of experience. But in most cases, full-stack may be the choice to settle for less optimal solutions, while setting engineers up to fail.

Does full-stack engineering provide a third the value? one fourth? Whatever the math, the conclusion is clear: You’ll get enormous value from a high-performing and experienced team of specialized engineers.

our brains are not multithreaded

For all our many talents, human brains do not scale fast, and we are terrible at parallel processing under heavy cognitive load.

People who believe they multitask well turn out to be the worst at it, and full-stack engineering is just a gold wrapper around the old context switching. Design a Boyce-Codd normal form database schema with appropriate indexes and implement a highly scalable RESTful call while building an intuitive user interface that interacts with the associated object model? Then support and maintain your full implementation along with the problem you were solving? Looks a bit overwhelming.

Front-end and back-end engineering are equally complex subjects, each with its own priorities and practices. Either one takes years to master, and neither is constant. Learning never stops.

Full-stack engineering asks people to learn too much at once, a cognitive load that unnecessarily strains our brain’s capacity. These overloads slow down development and result in more mistakes that can lead to additional technical debt down the road. This is not a problem unique to less experienced developers. As long as the field continues to move at such a rapid pace, even experienced engineers will struggle to keep up.

Imagine trying simultaneously to learn a new (human) language from an unrelated language group and a new non-Euclidean geometry, applying both to solve an interesting engineering problem… while the rules of grammar and The fundamental axioms keep changing as you go.

Rising up to such a challenge may sound heroic, but engineering organizations are actually better served by a team that can divide and conquer challenges while working together on the best solution. Accepting our limitations leads to better results.

land of fullstackcorn

There is a limited land where Fullstackicorn can roam freely.

As I said above, proficient full-stack engineering is a perfectly achievable goal in a senior developer’s career, although such a distinguished engineer usually creates more value as part of a high-performing team. In which experts are involved.

For a piece of software engineering problems, any full-stack engineer working on his own can produce a viable solution. There are two use cases for this:

1. Server-side rendered monolith.
2. Hacked together MVP (minimum viable product) or prototype (sometimes a special case of #1).

Some problems are familiar and simple to solve with server-side provided monoliths. Ruby on Rails, Django, Laravel … If the required solution fits comfortably within the patterns of thought provided by these frameworks, an experienced team of full-stack developers skilled in those frameworks will be able to build it efficiently .

But remember that, while a monolith may meet your short-term needs, there is an upper limit to their complexity and feasibility under scale. You are committed to a limited number of options designed for a set of well-known problems. A monolith is not the best choice for all engineering challenges. You can rebuild your codebase later to move to right-sized services or to implement a more innovative approach to a novel problem.

Similarly, early-stage startups are sometimes content to create a “loose” MVP as they are seeking funding. (It may well be built on one of the server-side provided frameworks.) Full-stack engineers can do this, but they shouldn’t be exploited or put under undue pressure because the startup is a deep Can’t rent the team.

The key here is to go into it open-eyed that you may end up rewriting the code from scratch when you have enough money. It won’t be a matter of reactivating or expanding a malnourished MVP. You’ll likely tear it down and build it back more sturdily with a qualified team of specialized engineers.

If everyone is okay with the limitations of full-stack engineering and is willing to accept the consequences without penalizing the team for codebase deficiencies later, then let that fullstackcorn roam freely.

But if you don’t want to risk these limitations, there is another way to get a more optimized solution.

Full-Way Engineering Team

For many problems and opportunities in software engineering, collaborative teams of front-end and back-end engineers can be far more effective than full-stack soloists.

The back-end developer can focus on the data layer, well-designed RESTful endpoints, threading, scalability issues, avoiding the n+1 problem for queries, and so on.

The front-end developer can focus on enjoyable and seamless interactions between the user and the application, efficient UI bundled downloads, and well-designed and reusable components.

Much of their work, each can do alone, completely focused on their own specialty and oblivious to the other’s concerns. But where their areas of responsibility come together — where the circles in the Venn diagram overlap — team members collaborate to decide the best solution.

What data will users need to access or edit? How will the UI call the API? What does the data contract look like? The team coordinates around these questions together, then each goes off to handle his or her part of the solution.

By bringing the team together for these conversations, you slow the process down to half speed for a while, but when they split up again, you go back to full speed, faster with context. Own silo to move forward and implement features correctly. (Meanwhile, the full-stack engineer brings the entire project to a crawl at half the speed, at best, with multitasking and context switching.)

As you might expect, given these overlaps of responsibility, it is important for each team member to have some understanding of the other’s area of ​​expertise. But it’s okay if this specialization doesn’t go too deep, especially for engineers who are still early in their careers.

Careers are built through collaboration

There is a tendency early in a software engineer’s career – perhaps in other careers as well – to try to learn everything at once. But this impatience actually slows down your progress.

Imagine trying to get PhDs in maths and biology together to tackle some important problems in protein folding. With the division of your attention and time, it will likely be several years before you complete even one of those doctorates. Assuming the problem hasn’t been developed or solved before you get there, it will take many more years before you make any meaningful contribution to the field.

What if you decided to choose just one. Let’s say a mathematician, with a specialization in statistical mechanics. Along the way, you reach out to your peers in molecular and cell biology. you combine. You assemble cross-disciplinary teams.

You progress very quickly in your understanding of mathematics while your colleagues do the same in biology. You learn from each other, not enough to earn a PhD in each other’s field, but enough to collaborate on some interesting problems. You also learn how to work well together: its the process, the humanity, the social structure of a good team.

Even after graduation, each of you will remain on top of the latest developments in your respective fields. And you start making really meaningful contributions to the problems of protein folding, much sooner and with greater stability than you could have alone.

And yes, you understand molecular and cell biology better than most mathematicians, although less thoroughly than most biologists. This gives you an edge in your career and your ability to make a meaningful impact in your field.

The same is true in software engineering. You’ll progress quickly if you decide to focus on front-end or back-end engineering, then learn to collaborate well in a team comprised of people who choose a different specialty. Throughout the years, you will learn a lot through collaboration, and this cross-disciplinary knowledge will help you do more.

fuller than full-stack

The end position of this career path may be a full-stack engineer, although by that point you are positioned for much more. You are a software architect, maybe an engineering manager. You are someone with a strong grasp of fundamental principles, some specialized knowledge in one area of ​​the field, a familiarity with areas outside your expertise, and a great sense of how it all comes together to solve the most interesting problems. Picture understanding.

It’s a real two-for-one promise, sometimes five- or 10-for-one. The full-stack engineer is not overburdened to do the work of two in twice the time and with half the quality. Rather, someone who has taken the path of an expert and through cross-disciplinary collaboration has developed a refined understanding of what makes good software.

Full-stack engineering is the worst kind of math that can lead to sub-optimal implementation. Real value—for customers, companies, and individual engineers—comes from collaboration in high-performing teams.