IMHO: The Mythical Fullstack Engineer

This is the first in an ongoing series from developers expressing their opinions on various topics in the software engineering and computer science world. The opinions expressed here are solely those of the author. If you disagree, drop a comment and let us know your take—respectfully, of course.


I suspect that a lot of people will interpret this article as “gatekeeping.”  Although I can understand that perspective, I’ve strived to provide an honest outlook that reflects my experience over the last few years (mostly startups). I also want to explicitly disclaim that I will be focusing on fullstack in a web development context. I fully support the notion of a fullstack engineer who has never written a line of HTML or CSS, they are simply not the focus of this article. Without further ado: 

If there’s one thing that nobody in the developer ecosystem can agree on, it’s what constitutes a fullstack engineer. Over the last year of teaching myself webdev, I’ve encountered many myths and learned a lot of things about fullstack development.

What’s a Fullstack?

Let’s start with a generic, definitely-not-controversial definition of a fullstack engineer:

“Individual responsible for engineering the end-to-end features of a system. From initial user experience to backend code running on distributed servers.”

If you have criticisms about this definition, good. That’s because, fullstack engineering isn’t a real thing. There is no scientific model that describes what fullstack is. There’s no way to measure if one person is more of a fullstack engineer than someone else.The only consensus regarding fullstack is that nobody agrees what it is. This should also make it clear that anything else you read in this article is inherently opinion.

Why is Fullstack so Romanticized?

Even though there isn’t consensus regarding what a fullstack is, everyone seems to agree it’s something they want. In their defense, the notion of fullstack is very enticing, and it has nothing to do with programming. Fullstack is exciting because it addresses one of the most unavoidable problems when building complex things:

“No matter how well you can separately build parts for something, the overhead of integration is almost always non-zero.”

Integration can mean a lot of things, but at a minimum it includes the communication required by the components to fit together. In theory, a fullstack engineer reduces integration overhead to nearly 0, as they control the separate components and therefore only need to communicate with themselves. While communication isn’t the only aspect of integration, in my experience, communication tends to be the bottleneck. With this understanding of fullstack engineering, a single person can potentially be more productive than two, three, or even four people (assuming the integration overhead is non-negligible). Especially from a business perspective, the potential to pay one person slightly more to do a job that previously took four is captivating.

Popular Opinion

I wanted to create a simple model for a fullstack engineer based on the popular (moreso average) opinion. After reading over a lot of different opinions online, I arrived at the following generalized definition of a fullstack engineer. A fullstack engineer is any engineer capable of executing the entire process of building an end-to-end web experience. I’ve created a model below, which formalizes my interpretation of popular opinion:

A Minimum Viable Fullstack Engineer (MVFE):

  • Uses version control
  • Knows HTML
  • Knows CSS
  • Has a strong grasp of programming fundamentals
  • Is comfortable with JavaScript frontend development (other languages are a plus, JS is non-negotiable)
  • Understands distributed systems
  • Knows at least one primary backend language (probably NodeJS, PHP, or Java)
  • Is skilled with at least one datastore/database

This definition immediately raises some questions such as: 

  • Does it include testing?
  • Does it include design? 
  • Does it include ops? 

At first it may seem like these skills are not necessary for daily life as a fullstack engineer. But remember, the value of fullstack comes from expected reduction in integration overhead. Even though ops isn’t the same as development, there is shared surface area where the two are required to be aware of each other. A fullstack engineer might be able to get by without understanding infrastructure and cloud architecture at the level of the devops team, but if they can’t speak a common language, their potential value begins to diminish. If it isn’t already clear, this notion extends far beyond ops. It includes any aspect of the system (or product process)  which the fullstack engineer is responsible for and that needs to be integrated.

Where Popular Opinion Falls Short

It’s my experience that the above MVFE is pretty uncommon. The profile describes a person with skills requiring thousands of hours to master, but who doesn’t take part in the holistic decision making process. By nature, the value of a fullstack engineer stems from their ability to make competent unilateral decisions (decisions without asking anyone for permission). I’m sure there are people who mostly fit the MVFE, but I wager that they are few and far between. You could probably summarize my view about the MVFE as: 

It’s very impractical to become a fullstack engineer without understanding the big picture.

In my mind, a fullstack engineer’s value is mostly derived from their ability to single-handedly design, architect, execute, and operate an entire end-to-end system. Assuming this is possible, it almost completely eliminates integration overhead.

The Reality of Fullstack Engineering

In many ways, fullstack engineering gets harder with each and every passing day. By nature, a fullstack engineer has to stay versed in a laundry list of independent yet highly interrelated technologies. These technologies (CSS, HTML, and JavaScript, for example) are developed in semi-isolation, resulting in redundant concepts and terminology you’re required to learn. Another factor contributing to the complexity of fullstack, is the widespread adoption of third party package management systems such as npm. Before platforms such as npm existed, best practices and standards evolved more slowly, meaning it was a lot easier to keep up. Now it seems like a new “best” framework is released everyday, and while the benefits of switching are usually minimal, the community tends to be polarized and judgemental about those not using the latest and greatest. npm packages have also had the effect of making your dependencies far less unified. In the past, things may not have been as up to date and modern, but the interfaces were often far more uniform. Nowadays, you end up needing ten packages instead of one, and they all use their own syntax and domain specific terminology. 

Just to be clear, npm enabled the webdev ecosystem to flourish and grow in a way that few technologies have. That doesn’t mean we should be ignorant to its cost, and there is a cost.

A Practical Profile of a Fullstack Engineer

Now that we’re on the same page regarding the goals and implications of fullstack engineering, it’s time to propose a profile for a more realistic fullstack engineer. The goal of this model is to address the concerns I had with the “Popular Opinion” profile, specifically in regards to area of potential integration.

Realistically Viable Fullstack Engineer (RVFE):

All things listed in the “Minimum Viable (MVFE)” profile.

Rationale: All of the items listed in the MVFE are basic requirements for building a modern web application. It may be possible to build websites if you’re lacking skills in the MVFE, but definitely not web applications.

Understands business and customer needs.

Rationale: In a traditional team, understanding needs and subsequently translating those into deliverables usually falls on the product org. While it’s possible to build something you don’t personally understand the value of, it directly impacts your ability to make quick judgement calls and decisions about that thing. On the other hand, if you’re building something that you do genuinely identify with, or at least understand, you’ll be equipped to make empathetic and pragmatic decisions. In my fullstack model, every place where you have to integrate externally reduces your effectiveness. If you don’t understand the customer needs and business value, you will need to be integrating all the time.

Understands role of marketing and how it co-exists with engineering.

Rationale: There are a few aspects of this specific item. I’m not alleging that you need to be a marketing guru to do fullstack, just that you need to understand how engineering and marketing co-exist. Specifically, you should understand the importance and role of analytics and be familiar with the process of integrating services like Google Analytics into the frontend of your site. There’s countless places where marketing and engineering are required to play nice Here’s just a few:

Implementing and reporting on A/B and Canary testing

Integrating sales funnel concepts such as conversions, impressions, call to action (CTA), etc. into the product

Understanding how page design, layout, and responsiveness impacts the above concepts

Has strong project and time management.

Rationale: If it wasn’t already clear, self sufficiency is a fundamental aspect of fullstack engineering. Although the potential benefit of self sufficiency is huge, it also comes with some unfortunate realities. One of those realities is that  the more you’re responsible for, the harder it will be for others to manage your time for you. This one especially rings true for me, as I know quite a few people who would be really brilliant fullstack engineers. But because they lack the self-discipline and time management skills, it’s probably not something that would work out for them. 

Project management is crucial because it’s one of the most clear and concise ways of communicating with your team. It makes you accountable and gives your managers, partners, and other interested parties visibility into your progress. Last but obviously not least, it forces you to plan and structure your work. Even if you don’t follow a development methodology, you should still be planning everything ahead of time. 

Has a solid grasp of design (at least enough to work with designers)

Rationale: Design is so integral to the fullstack process that I could almost argue that fullstack engineers should at least be mediocre designers. At a minimum, a fullstack engineer should be comfortable with modern design practices and tooling. The less you know about design as a fullstack developer, the better you should be at translating design requirements/specs into the exact specified outcome. This is why I actually think it’s easier to just learn design as a fullstack developer, as it gives you a lot more leeway during development to make compromises. Remember, you don’t need to be an artist to learn design. Even just understanding the basics of typography, color theory, and spacing will go a LONG way.

Can design, architect and implement end-to-end software systems.

Rationale: If there’s any aspect of fullstack that people can agree on, it’s that fullstack engineers write software. I would argue that every developer (fullstack or otherwise) should strive to understand the logic they are implementing and not just going through the motions.

Furthermore, many fullstack engineers will struggle with visibility. If you adopt a proper architecture process, it will make it much easier for others to see your intentions without reading the source code. It’s ties directly into time/project management as proper architecting is also explicit planning.

Is familiar with CSS best practices, modern additions, and libraries.

Rationale: This goes hand in hand with the design requirement. At a minimum, you should be comfortable enough with CSS to deterministically translate any practical design mockup into a scalable and functioning representation. The more familiar you are with CSS, the easier your life will be.

For the most part, learning CSS is just memorizing a bunch of keywords. There are a few concepts, such as flexbox and grid, which you should become incredibly familiar with. Basically any website (a responsive one at that) in the world can be built with either flex or grid. I’d also recommend being comfortable with Bootstrap and Material design libraries. They can often increase development velocity, and many employers give you points for knowing them.

Knows at least one single-page application framework (SPA)(and if only one, it has to be React)

Rationale: “Commenters on this post”:

What about Vanilla JS man? Frameworks are just a conspiracy by “Big JavaScript” to control everything.

I too, wish I could live on a commune where we grow all of our own food and provide our own resources. Unfortunately, I live in the Bay Area and rent is expensive. While communes might be okay throwing out frameworks, if you plan/need to work at a company doing frontend/fullstack or anything in between, you’ll probably be using React. Even if you aren’t going to be using React, the person interviewing you knows React and that’s more than enough to get you the job.

There are obviously a ton of problems with the current JS ecosystem, especially around frameworks and dependencies. That being said, I’m not going to cut off my nose to spite my face. Problems with the ecosystem aside, I don’t even want to go back to writing vanilla HTML (for the same reason I don’t want to write web apps in ASM). Also, I’d love to hear someone explain why server-side templating is any better than a SPA? Other than performance (because it’s almost a non-issue in 2019 with modern devices), I feel that people just like server-side templating because it’s what they’re used to. As someone who came into this space recently, the SPA route is way friendlier.

Familiar with domain specific frontend concepts (HTTP, CORS, etc.)

Rationale: This is true for fullstack and frontend engineers. I guess you could theoretically write frontends that never communicate to a server, but that would be a pretty boring life. Aside from request/responses, there’s a bunch of other domain specific cruft you should know. It’s honestly silly that modern implementations haven’t abstracted this nonsense away, most of the time you don’t need to touch it. 

Has strong SQL and NoSQL skills.

Rationale: After building a reasonable number of fullstack apps, you will assuredly encounter situations where a single data storage model is simply not enough. Although I’ve been thoroughly impressed to see how much some engineers will abuse NoSQL databases to avoid using a relational alternative. In nearly all of those cases, it ended up being more work for the engineers and far more complex than the relational alternative. There are a lot of dogmatic opinions on SQL vs. NoSQL, and the honest reality is that they are both important and have their place. Don’t let not understanding get in the way of making the right decision for your circumstances.

Comfortable with devops.

Rationale: With the majority of modern applications, where and how the application runs can have a huge impact on the way the app is architected. I’ve met with quite a few fullstack engineers who believed they should be completely disconnected from ops. Although this is a nice fantasy, in reality, engineering and ops are inherently intertwined. More than that, not being able to bridge the two either limits what you can potentially build or makes what you build a potential mess. 

Depending on what type of fullstack application is being built, knowing the ops might be as simple as understanding the implications that running on Firebase has on your code. For example, in Firebase you might use firebase.config() instead of process.env. I would classify this level of understanding as ‘ops aware’, which basically means you might not be able to do the ops yourself, but you understand the implications of the choices that are made. At a minimum, a fullstack dev should be ops aware. Although, I would argue that it’s very difficult to be a reliable fullstack engineer and not be at least at a junior devops level. It would be very difficult to correctly architect a distributed application if you don’t know what the scaling policies are for the server it will be running on. 

Experienced with testing at all levels (unit, integration, end-to-end, UI, stress, A/B, Blue-Green, Canary)

Rationale: If a fullstack engineer is expected to own the application software, they either need to be involved in the testing, or there won’t be testing. Even if you have the most amazing testing team alive, there is no way they can quickly and effectively test an application that nobody explains to them. For this reason, fullstack engineers should at least be comfortable explaining the behavior of the system in a context relevant to the testing team. Practically speaking, if the fullstack engineer isn’t at least writing the unit tests, you probably already lost a lot of value from the fullstack engineer anyway. If they aren’t writing them, it either means other engineers had to spend the time to understand the code and then write tests (thereby reducing the value of the fullstack engineer) or there weren’t any tests at all. Obviously both options are bad.

Conclusion

At the end of the day, each and every person is going to have a slightly different definition of fullstack engineering. Even if we could get the whole world to agree, there would be a new term just as ambiguous the next day. The profile proposed above is a product of my personal experiences and what I’ve learned from others. I would love to hear criticism about aspects that people disagree with so I can continue to improve my understanding.

We have something fun for ya. Our latest podcast episode is out! You can check out all our episodes here.

Author

Ryland Goldstein
Product Guy
After becoming interested in programming at an early age, Ryland fell in love with complex system design. His first experiments in programming concerned game design, which lead to the eventual creation of his own game engine. His primary strengths are distributed architecture and scale out machine learning. Before coming to Binaris, he lead teams responsible for implementing deep and classical learning algorithms on an in-house high-performance compute runtime. Today, Ryland is now a driving force behind Binaris's newest product, Reshuffle, which he partially incepted.

Related Articles

Comments

  1. So, in essence, you’re talking about an engineer that doesn’t really exist or if they do, they cost about as much as 4 competent engineers cost.

    1. >they cost about as much as 4 competent engineers cost.

      no, they cost pretty much nothing, because employers expect fresh college grads to be full stack capable

      1. Well said!

        I will go one-step further! Employers – in a large number of cases – have zero idea of what a full-stack development involves!
        This is not a rant against young entrants in the industry. I mentor a number of them, as a part of my job but I wish them to see things, in the way they are.

    2. Depends on what you mean by competent engineers. A minimally competent single-language developer with a year or two of real world experience and no domain expertise? Sure, but you’ll also easily get 4x the value from the hypothetical full stack dev described in the post.

      A developer with a similar amount of skills and experience but who has specialized more narrowly will/should be equally expensive. And depending on your needs may be equally or more valuable.

      IMO the value of generalists is higher the smaller the team.

      When you have 10+ developers in a single project, you will have integration and communication friction anyway, so you will not benefit much from having guys who could do it all if they only could work 400-hour weeks. But if the project has only enough work for one, splitting it between several specialists will be much less efficient than having someone who can take care of it all.

  2. “With this understanding of fullstack engineering, a single person can potentially be more productive than two, three, or even four people…”

    That seems to be the theory, but in a business setting it’s actually more productive to have specific people dedicated to specific tasks that they do repeatedly, which is one of the things Henry Ford did to make his assembly line process more efficient.

    Your article seems to allude to this, mentioning that there are thousands of hours required to actually master the various skills needed to be “full stack” (among other things), which is why I agree with you.

    That being said, I think the push towards full stack also has a lot to do with companies struggling to find not only qualified but competent developers. There’s a gap between the work that needs to get done and the work that is getting done, so ideally you’d like to hire someone who can do it all if you can’t find two people who can do one or the other.

    My two cents.

    1. 0xC0000022L says:

      The comparison with Henry Ford’s approach to streamline blue collar work is … suboptimal. Blue collar work != white collar work. And I think we can agree that the topic of this blog post is the latter, not the former.

  3. “The Reality of Fullstack Engineering”

    You forgot the copy/paste programming. The trial & error. The introduction of architectural paradigms into the code base that don’t follow best practices and make front/back end engineers think “Oh my god, I have to maintain this now!”

    As always, greed (wanting people who can do virtually everything) leads to disaster.

    And it’s understandable that most full stack engineers would struggle so much. There is no time when you try to keep up to speed with multiple languages, dozens of libraries and lots of tooling.

    This trend absolutely has to die. Encourage people to specialize and give them the chance to learn and actually understand what they’re doing, for crying out loud.

  4. Employers think that hiring a “full stack” developer gets them three developers for the price of one. The reality is that our industry rewards deep specialization, and can easily support it both in supply and demand.

  5. TheOneWhoSighs says:

    “Also, I’d love to hear someone explain why server-side templating is any better than a SPA?”

    There’s at least 1 aspect I can think of. And that’s not maintaining 2 separate instances of MVC that have to interoperate.

    SPA’s typically have routing and MVC concerns on the front-end, and then the back-end tends to have more of the same.

    If you’re a fullstack developer, that can be a pretty big pain point.

    It also doesn’t help that, honestly, most websites don’t have the complex state management requirements that would really call for an SPA and all the baggage it brings.

    I don’t think server side templates are better than SPAs, I just think it’s more of the same and it’s completely reasonable to stick to vanilla javascript in times where you don’t need react.

    Not everyone needs react. Not everyone needs kubernetes.

  6. I was really confused for a few paragraphs before I realized you didn’t actually mean “disclaim” in the literal sense of “deny” and that you were indeed talking about web development.

  7. Henrique Erzinger says:

    “With this understanding of fullstack engineering, a single person can potentially be more productive than two, three, or even four people…”

    …just like how nine women can give birth to a baby in one month.

    As someone who worked as a “fullstack” for years, until I decided to specialize somewhat (I still do both front-end, project management and design), this is not actually feasible in the real world. You end up with someone who can bullshit most of it (I can), instead of being really able to do it all.

  8. Andre Calil says:

    I don’t understand all the hate with full stack web devs. I’m one, my entire teams is composed of full stacks, we’ve been working together for over 6 years, we have a very solid product and codebase, we don’t have problem adding more developers to the team.
    “This trend has to die”, “this is so employers can hire 1 instead of 3”, this is just FUD.
    Front/back is one approach to develop web apps, full stack is another. With each comes a proper tech stack and expertises.
    It’s not about what’s right or wrong, it’s about what’s needed for the end goal.

    1. I support this point. What about devops (fullstack + IT for dev) ?

  9. Yep, it took 10 years, and most of the concerns apply. It mostly makes sense with startups, and will never “die” there simply because there is occasionally a choice between having one overstretched fullstack, or half a product.
    * It’s hard to keep multiple tech positions filled using just equity, when plenty of more established companies will reward the specialists better.
    * A new, frequently changing product gets less benefit from the structure imposed by frameworks. A/B and stress make more sense at a larger scale.
    * “Integrating sales funnel concepts” is most critical for public-facing web stores. For enterprise systems, marketing can run the funnel and the number of potentially paying customers is initially small enough to handle manually.

  10. Grzegorz Pietrzak says:

    You should try working in a proper cross-functional team actually delivering end to end functionality. Then you can be a full stack developer without stressing about mastering every single area. Being great at one thing, decent at some and have a vague idea about the rest is quite common and gives you great opportunities (ever heard the term ‘T-shaped people’?
    Having full stack developers is not a matter of hiring less people. Is a matter of hiring people who can efficiently deliver products as a high performing teams. And having uber-specialized people, subteams and siloses gets in the way of forming high performing teams.

  11. Bah. I won’t even.

  12. Aaron Cicali says:

    Question. If a person is competent in design, HTML, CSS, JavaScript, server-side languages, database technologies, linux, security, domains, HTTPS, CORS, and both written & verbal communication… why you hatin’?

  13. I go a step further and say that a any VFE is a jack of all trades and master of none – in a world which gets crazier by the day about quality and security. Just because the buzzword is trending, it does not eliminate the fact that for example to be a decent ops guy or gal, you have to have years of experience to do it _properly_. Can a Frontend dev get a DB running? Sure -some stuff is easy to learn. But the task at hand is hard to master. What about system hardening? Monitoring? Calculating thresholds? Incident Management? Escalation Management? On the other hand, can an ops guy do decent programming? Maybe. But what about proper testing? Architecture? Security awareness (keyword: SQL injection)? Just because there is a buzzword, you still need years to master one role of a VFE properly. From my experience: whenyou are about to become one, you are either falling up the ladder or are let off into retirement.

  14. Steffan perry says:

    Seems like a pretty easy answer to me. A developer who can implement clean and good code and design principals across the whole stack from front end to backend to architecture.

  15. John Hascall says:

    “ Not everyone needs react. Not everyone needs kubernetes. “

    Amen.

    In my experience, a templating approach makes it easier to separate data from display. And since somebody is going to constantly want to twiddle with the display as sure as the sun comes up—that’s a huge win in my book.

  16. One good thing about full-stack web devs (or at least a full-stack mentality) is they tend not to be wedded to a lone specialty. As projects develop, and tech evolves, FSD’s are more likely to put the work in the most appropriate place, wherever in the stack that is. A big-picture approach is, or should be, their defining feature.

  17. Chris Goodman says:

    The trade off for knowing all this stuff, is you are always a little bit slower and behind the bleeding edge on everything compared to the specialists. But its worth it.

  18. “Other than performance (because it’s almost a non-issue in 2019 with modern devices)…”

    My user experience says otherwise. Front end heavy sites are slow as molasses, and it’s annoying. Maybe it’s because I use Firefox and sites are optimized for Chrome, but that doesn’t change the fact it’s a reality. My current computer also isn’t particularly performant (despite having 8 GB of RAM and a quad core) because I recently had to buy a cheap one quickly and haven’t had the opportunity to replace or repair my better one; the result is that front end websites consume a LOT of processor power on this machine and gum up my entire system. (Maybe my graphics hardware is bad? Not completely sure.)

    They’re also just incredibly poor UX. Scrolling in them is difficult. Ordinary browser keyboard functionality is often hijacked. Finding things is a much bigger pain. Clicking has unexpected effects (like in blank areas). And so on. Maybe to sum it up, you could say that they rarely do a good job of following the norms for website behavior.

    Whenever I encounter a site that’s lightweight on the front end, I am always pleasantly surprised and grateful.

  19. To my mind, a full-stack engineer is one whose skills **also** extend to the non-functional requirements space (https://en.wikipedia.org/wiki/Non-functional_requirement). I know such engineers exist (e.g. yours truly) and for them I am ready to concede that a certain layer, say UI, in the stack may not be their strong suit (e.g. yours truly).

    I cringe every time I see a brilliant engineer struggle to answer questions such as, what will be the operational expenditure for a customer if this software is deployed on-premise, cloud, etc. Or, how will we deliver software to the customer in an USB because they do not have internet connection at their factory, warehouse, etc.? “Sorry, but, we are a strictly Windows shop.” “We are already invested in a _insert obscure name_ database; so, please do not recommend _big company name_ database.” Such questions have a _serious_ implication on the design of the software and also the choice of tools for development.

  20. So much fuss about “Full Stack”, still they are (if they really exist) not even in the top 5 as far as salary goes https://insights.stackoverflow.com/survey/2019?utm_source=so-owned&utm_medium=announcement-banner&utm_campaign=dev-survey-2019#salary

  21. Michael Berry says:

    “everyone seems to agree it’s something they want”

    I’m not so sure about that. I think most *employers* might agree it’s something they want (why wouldn’t you want a dev that can do everything right?), but most *developers* wouldn’t be so keen. I’m not keen on frontend work, I generally find it time consuming and boring. Others I know feel the same way about backend work. I know very few real developers that really want to do both in equal measure.

  22. stojakovic dobrivoj says:

    i believe such individuals exist and, by requirements, are rare. it is called polymath. isaac asimov was one. milutin milankovic was another. there are many examples of them and yet we value more specialists then all-around experts that excel in several fields.
    but, problem is expectation of employer. they want their all employees to be polymaths. it is an exception that you cannot turn into a rule. they should feel lucky if they can get their hands on one and pay them accordingly…
    if you can use your skills they should be payed, all, not just one.

  23. So, I’m not full stack because I don’t use javascript. Despite handling tasks from UI to database to communication, to interfacing with external systems.

  24. There is no such thing as a Full Stack Engineer. The term needs to be replaced with “Jack of All” master of none.

    I just do not see it as possible to be a master of front to back tech. There will of course be a handful of individuals with photographic memories.

  25. Fullstack destroy performanceneer…

  26. You are wrong in so many points, that I don’t even know how to start.

    There is not many full stack developers, but those which I know can do frontend (JS, TS, HTML, CSS) , backend, whole architecture, devops, server management, testing automation mostly much better and much faster than many single purpose developers. They know many frameworks, languages, many technologies.

    It’s much cheaper for small and medium projects to hire one person to handle everything, so there is need for such role.

  27. A full stack engineer for a web site should also understand a good deal about user experience and SEO. It isn’t enough to build something pretty and put it out there. You also have to know how to test how users react to it and make sure that search engines can index it.

    Which is why server side templates are better than SPA for a site containing content that needs to be indexed in search engines. Despite recent advances in technology from Googlebot, SPA sites are hard for SEO. To get them indexed you have to make them look like they are static sites. You have to divide it into pages with a URL per page. You have to use pushState to change the URL as the content changes. You have to use normal links that Googlebot can digest but intercept them for users with AJAX.

    Even if you do all that, Googlebot takes months to run the JavaScript. (Literally, it has a queue that is months long.) It will take months to initially get your site indexed and it will take months before Google sees the smallest change in your website. Other search engines such as Bing, Baidu and Yandex won’t be able to index your site at all.

  28. Teemu Leisti says:

    I found this article very clear and informative.

  29. Change the title to “Random thoughts after I wake up”

  30. > […] in a business setting it’s actually more productive to have specific people dedicated to specific tasks that they do repeatedly

    @logos_164 I don’t see a reason why those specific tasks can’t take a full-stack approach. I’m a full-stacker pushing a junior dev in the same direction. The time and effort I spend getting him up to speed in full-stack is paying off quickly since he can (independently) focus on feature implementation across multiple repos thus reducing the integration overhead in having to coordinate with me or other devs. So, I suppose we are headed in the direction of Andre’s team.

    By my estimates, I’m roughly as productive as a front-ender & back-ender at my skill level coordinating, and a part-time junior designer working a few days a month.

    As a dev in the job market, I see full-stack is a great asset.

  31. I think the key element is here quality. Anyone can be a fullstack dev, but more often than not, this will lead to ‘cowboy’ learning – what you need to know to get the job done. Rarely will a fullstack reach the specialist levels of a DBA, developer, front-end dev, etc. I’d be worried about the ignorance if any claimed they are as good as.

  32. Gods I hate that phrase.

    Really the term seems to mean ‘Reasonably well rounded software engineer probably doing mostly web things at the top of a whole pile of abstraction’, and is a short hand for a wish list of things that any given applicant may or may not have (But that all can bluff having well enough).

    Using the phrase in a job advert, never mind an interview is just plain lazy hiring, you got to be way more specific then that. I find the phrase a real turn off in a job advert as it signals that someone has not really thought thru what they need, never a good look in a potential employer.

    Also, “Full stack”? Really? Someone claims something that broad that in an interview here I will expect them to be able to discuss the cache effects of data locality in SKBs and replacement strategies in a resource constrained ARP cache…

  33. Leaders need to realize that full-stack developers are not magically productive. Any human being has a limited amount of time and mental energy, which can be spent developing deep expertise in a limited scope, or limited expertise in a broad scope. Nobody can be an expert in everything. You can probably find a true “full stack” engineer if you are willing to accept a lower level of proficiency in each area. “Lower proficiency” is not an insult; there’s no point in having more expertise than you actually need for a particular task. I’m a generalist, and I readily admit that I know less than any of my team members about their particular area of expertise. However, because I understand the core principals of many domains and I’m not “heads down” in a particular role, I’m often able to see broader patterns that others miss, and help solve cross-domain problems.

    Also, leaders need to realize that there is a productivity cost associated with context and task switching, just as there is a cost associated with having different team members working on the front-end vs back-end.

  34. Nikko Pisciotti says:

    Good article here, very authentic share. Why stress about keeping up with so many disjointed trends?

    Being able to specialize or adapt to new technology is invaluable, but staying sharp on every bit of tech or latest trend is detrimental to good dev IMHO – lol.

    I guess an example would be, you don’t see a General Physician for a very specialized neuro-surgery eh?

    The article provides some great thoughts – thanks!

  35. It’s pretty funny seeing this on Stack Overflow when almost all of their engineers have been titled “Full-Stack Engineers” and they still have that as a category in their salary calculator: https://stackoverflow.com/jobs/salary

  36. Apoorv kapil says:

    This is interesting one ,however as my career in IT I have seen people with those skills.

    I tell you what you need to be a full stack developer:

    Strong Understanding of Computer Fundamentals (non negotiable)
    Good understanding of algorithm and Data structure ( non negotiable)
    Database modeling ( non negotiable )
    Basic HTML ( negotiable as non steep learning curve)
    Styling CSS ( negotiable as non steep learning curve )
    Good understanding of any programming language JavaScript, Java, php ( non negotiable )
    Good understanding of Linux and networking ( non negotiable to handle production systems )
    Basic understanding of Operations and process

    Good understanding means you worked on this part for 2-4 years to get a grasp on the concept.
    Strong understanding means 3-6 years of experience working on those.

    Last but least the Attitude to Learn , adapt and Grow.

    This makes a full stack developer.

    Note : I am a full stack developer 😉

    1. Me too. It is nice because I can from scratch make an entire web application and manage it’s hosting. But it takes a lot of experience, and as an older developer, it just comes naturally as in the past the backend and the front end were more wedded together. Today it is far easier to specialize.

  37. In an interview I was asked if I were, “A renaissance man”. I laughed and said that my mother would hope so, but I fell short. I was a good generalist and had expertise in my discipline.

    There is an old saying, “jack of all trades and master of none”.

  38. The problem is that the notion of what Fullstack Engineering ends up being too specific and covering too much ground. The real, sustainable version of this idea would be someone who is an expert in deployment, integration, and creating glueware across multiple disciplines. Writing every part of every layer and staying up to date with technologies is only even possible in areas with very specific patterns like web development.

  39. There is a deal of breadth at every layer of development, and any given system doesn’t need a full understanding of all concepts to build.

    After a few years in the industry and a couple major projects behind your belt, I think most people can be a half decent engineer across the spectrum. “Back-End” and “Front-End” aren’t even really specializations, those are broad categories in themselves.

    Generally people have their strengths and weaknesses based on their background and interests.

    If your point is that nobody is a master of everything, well yeah. Most people who specialize aren’t even a master at their supposed specialization.

  40. michael durrant says:

    I am actually simply confused by this article.
    First is says Popular opinion of a full stack is the MVFE given.
    Then it says Popular Opinion Falls Short and those with MVFE are pretty uncommon
    Then it says it’s time to propose a profile for a more realistic fullstack engineer. The goal of this model is to address the concerns I had with the “Popular Opinion” profile, specifically in regards to area of potential integration.
    Then it says Realistically Viable Fullstack Engineer (RVFE):
    All things listed in the “Minimum Viable (MVFE)” profile.
    Now I’m confused. I thought the MVFE had shortcomings and you were going to address them. Instead this adds a whole slew of other concerns. They are all great and valid but I am confused because the article starts up with the popular profile being unrealistic and then proceeds to include it and add a bunch more stuff. I am very confused by this.

  41. Not to throw the age card in here but it seems to me that this constant griping about full stack engineers being mythical is always bantered about by those with little time in the industry. Most newer devs I work with expect that after 5 years they get to call themselves senior devs. While that may be the case for one aspect of the “Full Stack” I can tell you it takes far more than a few years to be really competent across the entire stack.

    I’ve been at this for almost 20 years. Everyday I learn something new and the trends keep outpacing my ability to keep up. But I can honestly say that many of my colleagues in the 20 year crowd competently call ourselves Full Stack simply by the accumulation of that hard earned knowledge over time.

    Unless you specifically choose the route of specializing everyone will reach a point in their career where the title Full Stack Engineer absolutely applies. So don’t stress the term. Enjoy the journey, this is a hell of a fun career path to be on.

  42. Most developers I’ve worked with during my career had the profile described above. This is a pretty common profile in Europe and people graduating from an engineering school and choosing the software engineering path usually ends up at a “fullstack” position. Their title is Software Engineer usually, not Fullstack Engineer.

  43. I agree with this article more than I initially thought that I would when I clicked on it. (I especially like the phrase “DevOps Aware” – and I plan to steal it). I will also freely admit that I’ve seen a lot of “fullstack” engineers who are really backend engineers but they wrote a little bit of jQuery back in the day – or they are really frontend engineers but they made a little toy project in Node and deployed it in Heroku. But I’ve also worked with plenty of good fullstacks over the years, and I consider myself to be at least a competent one.

    I think we agree on what constitutes a Minimum Viable Fullstack (although I wouldn’t bother to include source control in that list, because _everybody_ should know how to use source control. Similarly, all professional programmers would ideally have a strong grasp of programming fundamentals). I also agree, more or less, with all the requirements of the “Practical Profile” for a fullstack engineer. But it does seem that the author is somewhat confusing “fullstack developer” with “only employee in your entire company”. Yes, a developer should have an understanding of the business and customer needs (notice here I say a “developer”, not a “fullstack developer” – as with source control, this is a requirement for everyone). But we also have Product Managers, people whose specific job is to understand the business and customer needs and convey them to the developers. Engineers should also be writing unit tests (again, notice I said “engineers” not “fullstack engineers”), but there is also room in the org for a QA Engineer who focuses on integration or functional testing, so if a full stack doesn’t have deep knowledge of Selenium or other types of tools, I wouldn’t consider that a problem. (Although, if you pick yourself up a copy of [Test-Driven Development in Python](https://www.obeythetestinggoat.com/), you may discover writing selenium tests is a lot easier than you thought). The same goes for UX Designers, DevOps Engineers, etc.

    I think the main issue is the idea that you can just replace 4 people with 1 person if they are full stack. This seems like the mythical man-month problem. At best, you will pick up some velocity on pipelining (front-end guys aren’t “blocked” waiting on backend tickets and so forth). There’s also the higher level systems-thinking that comes with working across the whole stack – the author states “It’s very impractical to become a fullstack engineer without understanding the big picture.” – this isn’t a bug its a feature. A deeper understanding of the whole system leads to better architecture and design. Another issue I think is the idea that you have to be 100% expert at _everything_ in order to be fullstack – I think realistically, most fullstack developers are fairly [T-shaped](https://medium.com/mop-developers/we-need-t-shaped-full-stack-developers-4c62c9d757a0) – but thats also not necessarily a bad thing as long as there is enough overlap on the team to cover the workload and avoid provincialism.

    One last thing I would add is that you definitely don’t need to be up to speed on all the newest npm libraries- Rich Hickey makes a strong argument in his classic talk [Simple Made Easy](https://www.youtube.com/watch?v=rI8tNMsozo0) that you shouldn’t always just “gem install hairball” (replace with “npm install hairball” or “pip install hairball” or whatever you use)

  44. I would label myself a fullstack engineer and I don’t agree with your opinion on why it is romanticized, though maybe it is partly that because I have never worried about “integration overhead” once in my life. The true reason you want a full stack engineer is you want someone that can work on any part of the system instead of hiring 5 specialists. Such a person is great at working for small businesses where bankroll is smaller, or startups where productivity needs to be high and teams small, or big corps if they have a new venture and need someone to build the ground work. They are also good at debugging an entire system to find out what is wrong because they know how all the parts work.

    Think of it like a car. You go to the general mechanic, and he can usually fix your car. Maybe they specialize in your brand of car, but they can work on the entire thing. They could also, the best of them, perhaps design a new car.

    Sometimes you need a specialist or team of specialists working together to fix a car, or design a new one. This usually works better when the size of the project is simply too huge or it is in later stages of development.

    Full stack engineers save a company money because they are able to have a birds eye view of an entire system and work on any piece of it. Of course, with breadth you will miss out on some tricks of a specialist. However, I have also noticed specialists tend to overengineer something (think of a kid with a homework assignment over doing it because they literally have nothing else to do and the end result doesn’t even net them a better grade, and often worse because they stuck a bunch of unrelated stuff in).

    I’d certainly like 4x the price of a typical engineer. If you have a job opening please email me.

  45. The whole concept of “Full Stack” can be compared to turning the “T” of the https://en.wikipedia.org/wiki/T-shaped_skills into a big “-“.

    One opinion (that seems to be shared widely) is that “full stack” is just manager jargon for someone who is capable of quickly assembling a prototypical web application by copying-and-pasting snippets from “Hello World”- blog posts and stack overflow answers. While this may sound overly critical, it’s indicative that the whole blog post above did not contain words like “maintain”, “quality”, or “sustainable”. But that doesn’t seem to matter (c.f. https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/). The approach of generating a churn of mediocre code and infrastructures keeps people busy, and conveys a feeling of progress (“Yes boss, I got the latest and greatest framework running!”).

    Someone who is overspecialized (having “I-shaped skills” – like “I”…) will probably always see this with scrutiny. Each and every aspect that was mentioned in the blog post is one where you could spend several years for just learning the basics. So what can somebody who claims to be a full stack engineer, according to these definitions, *really* know about each of them?

  46. How much experience does it take to call yourself a dev? I’ve met both front and back end devs who have claimed that title in less than a year. If you can be either a front or a back dev in a couple of months, then how can you argue that a full stack dev doesn’t exist because it takes too much time?

    I was part of the stackoverflow beta, back when there was only one dev. So which was Jeff: front or back?

  47. I have to admit it that finding someone who can do the full stack is like finding a needle in a haystack.

    Just to give you an idea…

    * I set up Azure Devops to do continuous integration and delivery.
    * I set up JUnit tests for unit testing and HtmlUnit for integartion testing with testcontainers.
    * I write Cordova code that works with Vue and have it do automatic tests (via the Vue tooling, just had to change it a bit for Cordova) https://github.com/trajano/vue-cordova
    * I develop my own container images to satisfy certain needs for my projects including multistage container builds and stacks https://hub.docker.com/u/trajano/
    * I develop Terraform modules https://registry.terraform.io/modules/trajano/swarm-aws/docker/
    * I document using PlantUML and mermaid but mostly plantuml because it has a richer pallete
    * I have set up ELK stacks on Docker.https://github.com/trajano/elk-swarm
    * I have set up Traefik with Mutual TLS https://github.com/trajano/trajano-swarm
    * I am partially color blind and other vision problems that makes me test for some accessibility automatically.
    * I’ve actually played with multple UI stacks https://github.com/trajano/reactjs-admin , https://github.com/trajano/angular-bootstrap-validator I still prefer VueJS over all of them just because I find it easiest to knowledge transfer.
    * I’ve built kernel extensions https://github.com/trajano/InsomniaT
    * and even played with RenPy https://github.com/trajano/renpy-portrait-mode-ui
    * and Unity https://github.com/trajano/ScaryShooter

    As far as things go, I just don’t have good k8s skills because I still like the simplicity and knowledge transferability of Docker Swarm, but I used to have a minikube setup at home.

    I don’t have strong gitlab skills because I am more of a github kinda guy and I prefer the managed devops of Azure Devops with their TFS tool which is free for small private projects like my home docker swarm.

    So I do think the mythical full-stack developers do exist. They’re just hard to find.

    However, if you do find one make sure they are good at the following:

    * Helping others get to their level (not necessarily writing documentation, but to actually be able to work with their peers).
    * Continuously learn.

  48. I agree, It goes even harder to be a full stack if you must have knowledge in the backend necessary technologies from frameworks, testing frameworks, e2e, code qualities, working on microservice components, and then devops basics a full stack must know about continuous integration/ deliveries, jenkins, containerization, git, webhooks and many other terminologies…
    So in my opinon, yes It may needs many many years of work in nowadays technologies to become a real full stack developer!

  49. George M Jempty says:

    I’m pretty bloody sure I’ve been a full stack engineer for over half of my 20 years, definitely the first half of that when that’s all ANY web developer worth his salt was, and sometimes in the meantime though I’ve been focused more on the front-end. As far as I’m concerned this is nothing but click-bait.

  50. So if I am handling interactions with clients on needs/wants and sales, manage the project, timelines and milestones/expectations, front/back end design and planning, infrastructure planning/purchasing/maintenance, front/back end development, database architecture and infrastructure and implementing/maintaining automated tests I really feel like it doesn’t get much more “fullstack” than that, unless I’m missing something. And from the sounds of it, I am severly underpaid…. Now taking job offers LOL

  51. On small projects it makes sense to hire one experienced fullstack-developer than f.e a designer, a programmer and another thirdparty for hosting etc. But thats depending on the workload, the more it is, the less it will be helpfull to let fullstack-guy do everything, In such case a fullstack-dev gets more to the guy who sets up the technical-infrastructure and work-patterns for each individual discipline and rather keeps an eye on first-aid for support the other devs and working collaboration like a CTO.

  52. I guess it feels like I am in the minority. I’ve known a decent number of what I would call “full stack” engineers, and they really can perform at or above the average performance of specialists in many areas. They’re unifying characteristics are the ability to consume and understand new technologies and to quickly see patterns, and anti-patterns, in order to create more stable systems.

    The added benefit is that when analyzing issues and troubleshooting, you have someone who understands the flow from top to bottom.

    Now, they are by no means “10x”, nor could they replace 4-6 people, but their understanding of the big picture often leads them to become great leads and architects as well, which should truly lead to gains within your organization.

    Where I am seeing this trend start to slow is with dev ops (K8s, containers, docker, etc). I’ve not seen one of these “full stack” developers successfully add infrastructure and deployment to their daily responsibilities unless the project is very young. Over time adding deployment and reliability to an already full plate will tend to have these developers fraying at the edges.

  53. How about fullstack polyglot, including deep knowledge on machine code and microprocessors. Hopefully not asking for too much

  54. NodeJS is not a language.

  55. The minimal full stack list has some superfluous stuff. Most notably javascript. You can easily be fullstack without ever touching anything related to browsers, just have to be fullstack with some other kind of frontend. An easy example would be smartphone apps (ex. android or ios). Or why dont I go with a silly example, and claim that it is still very much valid to implement your own hardware, OS, a browser that supports some other language than javascript, and go fullstack in that ecosystem instead?

  56. Great article, the truth is that it is difficult to find a full-stack engineer and even when hiring graduates many have a pre-set idea of which “side” (back/front/ops/test) that they would like to work in before even starting their first jobs.

    I have been a full stack developer working for a relatively small company for quite some time and have been in the fortunate situation where I am able to build / maintain my skill-set to a standard where I can (among other things):
    – liaise directly with a client
    – design and implement a detailed front-end interface accounting for UX and design principles
    – architect an application (using either SPA or server-side templating)
    – build a logical data-model
    – write integrations between third-party systems
    – manage ops and CI/CD pipelines
    – design / implement automated deployment scripts
    – and even on occasion perform functional testing (although I prefer not to and avoid testing my own code)

    It can take a lot of time and effort but the ability to switch between any given project keeps my work interesting and makes me a valuable asset. I do not feel that I am “missing out” by not specialising in a single technology / area / skill or overworked for knowing too many.

  57. Define a full stack engineer any way you want. The fact is, at my last job, they needed a new website to be built. Before I was hired, they had two older systems, one written years ago solely for desktops, and another newer one for mobile devices. When I left, they had a completely new system that worked on all devices, written in Angular 5, with a C# backend for implementation of business logic including DB operations. I also wrote the stored procedures. I did not design the DB. Otherwise, I wrote the whole thing. The only thing I didn’t do was deploy it.

    So tell me, am I a full stack engineer, or not?

    Anyhow, thanks for an interesting article.

  58. One more thing: Am I the only who certainly recognizes the importance having all parts of a system work perfectly together, to design for this from the start, etc., but also says that in the end, most websites don’t require “rocket science” knowledge? That the true rocket scientists of the web development world are the ones who for example, come up with things such as Angular, React, Entity Framework (which I hate, btw), npm, jQuery (just to throw in a plug for this game-changer), etc, etc, etc? Those of us who learn to use these tools to build the websites are the brick masons, welders, and the like: skilled at what we do, but who would be nowhere without the architects and designers?

  59. I have a friend who I believe fits the bill and I don’t think it’s so incredible that he exists. An entrepreneur CTO in a tiny company will naturally build out all the these skills to make their system work end to end.

    He freelances ops (far back of stack), I worked with him when he was the master of our backend (middle) and he’s working on a business that’s some kind of engine for generating yourself a suite of React components (front).

  60. the only place I seen such disdain to generalists is among developers…

    Does everyone here really work for a fortune 5000 us based company who hires specialized DBAs, DevOps , Es6 and java engineers???

    as long as there are small businesses and small demands within larger businesses there will be generalists…

    I can’t fathom the idea of a Oncologist and a Nephrologist chatting about how much of an impossibility being a General Practitioner is… or someone in mechatronics being called incompetent by electrical and mechanical engineers

    1. It’s not that everyone works for big companies. It’s that (statistically), most developers don’t work for startups.

      Also the oncologist, nephrologist and GP comparison has some serious holes.

      1. Comparing across fields (I understand the intended mapping between specialization) is of little value.
      2. I think what you said is true, but the inverse. Specialized fields are generally considered far more demanding compared to a GP. I know specifically that anything related to the human eye is considered incredibly demanding.
      3. The barrier of entry to be a developer is…. nothing (other than convincing someone you’re good enough to be hired). Any doctor (even podiatrist’s 😂) require the full 8+ years of education.
      4. This is purely anecdotal, but most people aren’t great at context switching.

      Obviously I appreciate what you added to the discussion. It’s a bit funny that all of these comments assume that I wrote this article as a non-fullstack developer.

  61. Pierz Newton-John says:

    At my last job I: wrote 70% of the server code in Go (the other 30% came from the developer before me); wrote 90% of the two front end apps in AngularJS and the Ionic framework (don’t judge, this was the bleeding edge when we started :); did the UX design on many features; wrote various utilities and microservices in Node and Python; created and deployed docker containers for these microservices; debugged performance issues and optimised queries in Postgres and Elasticsearch…. I’d call that full stack, wouldn’t you? Mind you, this was a small startup. I agree that the generalist is of more value and relevance the smaller the team – which is why I like small teams. As for whether this range of skills is common or realistic to expect, in my experience the unusual thing to have is the combination of visual design with strong technical/CS chops. Those seem to be birds that don’t tend to flock together.

  62. Slow Internet says:

    “Other than performance (because it’s almost a non-issue in 2019 with modern devices)”

    I’m stuck in a 3G zone at the moment, and since opening an article on your website I’ve been able to.
    1). Open a new tab
    2). Find this article again
    3). Find the bit about how performance doesn’t matter
    4). Type this message

    And your article finished loading while I was writing point 4.

  63. I don’t understand how a fullstack developer can keep up with the pace of all these technological advancement. I am a frontend Developer for 11 years and still everyday I learn something new and I have a long list of things to learn. Although I want to learn fullstack for my own benefit plus probably I can fulfill the demand of some employer but I will still be good in one thing more than the other one.

  64. Your “MVFE” seems very frontend-focused. Strong in the frontend with some backend knowledge. The opposite also exists.

    But it’s a strange discussion. We are _software developers_. A career might span fourty or fifty years. We should not let ourselves be defined by Web technology only, let alone specific bits of it. It’ll all disappear and be replaced several times during our careers.

    Why only a single full stack?

  65. Alan Bourke says:

    So … you can’t be a full stack engineer in anything other than a web development paradigm?

    There are other worlds of software development, y’know.

  66. Christian Rau says:

    So In your opinion if you don´t master JS and other technoligies that you are comfortable with, you are not a fullstack developer?
    I must add that its actually possible to avoid JS entirely, and still make perfectly working applications.

    Or did you mean AllStackDeveloper?

  67. Actually, the only traits needed in order to be a successful fullstack developer are:

    – A high enough intelligence; to quickly learn things, analyse problems,…

    – A talent for language; to be able to clearly, politely, unambiguously communicate to all stakeholders, and write clear and structure documentation where needed.

    – A talent for design; to understand what good UX is, and just ‘feel’ what looks good and what doesn’t, to create actually beautiful software.

    – Exceptional willpower; which, combined with the above talents, will allow you to learn and do anything that’s necessary to get the job done, until it’s done, correctly. This includes learning other important traits, like non-violent communication, etc.

    Unfortunately, as you’ll notice, all four are innate talents which you’re pretty much born with and/or have to develop at a young age. And you really do need all 4 of them if you want to be the kind of exceptionally good full stack developer who can replace a team of 5-10 ‘regular’ developers/analysts/testers/devops guys and the pm’s to manage all of them and executives to structure the organisation.

    It’s those guys who are hired at the Big Tech companies; guys like that who start and maintain the most widely used frameworks and libraries throughout the world for many consecutive years, guys like that who create and work at the most successful startups (or, like me, just work as freelancer for ridiculous amounts of money for the highest corporate bidder -_-).

  68. Well, first of all cudos to the author of this article. It’s a topic that heats much debate and where opinions often differ to the religious. So it takes some guts to post an article like this. 🙂

    Personally I like the concept of understanding the full stack that I am working on, both from the front- and backend perspective. If I can get into the devops part even better. My degree of understanding on these various topics is probably what makes me a good or bad fullstack developer. Depending on what particular stack I am working on and my experience with the involved technologies.

    I think everyone with a bit of understanding on the involved technologies can call themselves a “fullstack developer”, so its a lot of fuzz and a really buzzy word. I think it all comes down to experience, if one has mastered one topic, e.g. PHP as a backend language, PostgreSql as a database or anything else, it could be wise to broaden ones perspective and learn about frontend development, be it using React or Vue as an example, CSS and so on. Would that make me a better backend developer? You bet! And the other way around.

    Ok, so the argument that employers would look for 3 persons in one, is probably void in most cases. Even though someone is not techy, does not make them complete idiots, so I dont think managers generally think this way. While it actually may be that way, my better guess is, that its not more common than general stupidity amongst our populations. I think its more a matter of having someone employed that can be assigned to tasks in a broader spectrum, if that means that they are not that hardcore at an specific aspect of a stack, so be it. A lot of us OCDlers, like to put people into a specific box. But sometimes box thinking leads to bad decisions. It all depends, and its all good but I dont think one “fullstack” can replace a team of 2 good frontenders and 2 good backenders, although they might have a different take one the problems to be solved.

  69. It’s the mindset that matters. One should have a team of mostly people that seeks to understand the entire technology stack. This leads to success (if other things are in place of course)

    The opposite is completely siloed responsibilites. This leads to an extreme amount of beautiful documents that no-one understands, a messy architecture, messy code, poor performance, etc.

    I’m not sure where exactly fullstack falls on this spectrum, but does it really matter?

  70. I guess it was a bit of a throwaway comment, but performance very much still matters. One word — smartphones. Don’t be surprised if you see a web site take half a minute to render on one of those.

  71. I find it interesting, how many engineers decry the concept of a full stack engineer. IMO that’s what all engineers should aspire to be.

    Most engineers I’ve met who claim to be fullstack aren’t. And most engineers who truly are fullstack don’t call themselves that.

    As for the value, I would gladly pay more for a real full stack engineer than a specialist… any day of the week. I worked with a Java specialist a while back who couldn’t even make changes to an HTML email template.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.