You know if it's a small company looking for a "full stack" engineer, they want a unicorn to come into their office and turn their shit into gold.

I've gotten it too often where clients want an overly ambitious MVP made from scratch on a shoe string budget.

You lose value once you cram all those services into a single position (from server architecture to backend engineering to front-end design). These cheapskates don't even consider the cost of things like branding -- how do I make this site without a logo, colors, or a design system?

It takes the magic of accomplishing such a monumental task and diminishes it immensely. What should be a rockstar position for the amount of skill required to orchestrate everything, ends up being a catch-all that companies try to abuse for cheaper labor.

Full stack provides something that silo'd positions don't: variety. I am a full stack developer. My title may be Director of IS, but that's just a title. I'm the primary designer, architect and implementer of every feature in our system. Back end, front end, middle tier. You name it, my hands are on it. The problem is, I'm the only developer in our company who can do that. We have two other developers, but their skills are narrow, and they're just as busy as me in their respective areas. So, while it provides lots of variety, it also means I'm the person everyone runs to when things aren't working right. Sadly, the company cannot quite afford to hire another developer who is more well-rounded. (Full stack developers tend to be significantly more expensive.)

As someone in a management position, I can tell you this: I'd rather have one full-stack developer on my team than 5 silo'd developers.

Now, you mention burnout. Yes, that is very real, especially if you're the go-to person all the time. I have not figured out how to avoid this. It's completely cyclic in nature with no break in between. Here's an example of the cyclic routine of a full-stack developer:

1. Feature needs to be done by X date (sometimes date is set by external means, e.g. unbending clients or regulations)
2. Get to work developing while at the same time fixing bugs or just normal maintenance tasks and administrivia (everything non-development, but still has to happen, such as meetings, time reports, emails, etc.)
3. Deadline approaching, so get ready for deployment
4. New feature request. But wait! I haven't even finished the last one!!!! Too bad. So sad.
5. Finish deploying.
6. Deal with after effects for the next few day... training (meaning, explaining to people why things are different now, because they didn't get the same memo you got... why am I even involved in training in the first place???, possible bug fixes, last minute changes (no, we didn't mean "this", we meant "that"!!)
7. Remember that new feature request that came in before this was even done? See #1.

No break. No time for vacation. Repeat ad nauseum. This is the life of a solo full-stack developer. When you are a solo full-stack developer, often, things really do fall on your shoulders. It gets really old after a while.

I really like working for small companies because it give the opportunity to be all over the code base, and even into hardware stuff. And, full-stack has its rewards. But being the ONLY full-stack developer in a small company can make one burn out very quickly.

I definitely would not say steer clear. Instead, I would say, set ground rules with your employer. They give you paid vacation? Take it. And tell them you're refusing to get caught in the cycle I described above. I need to take my own advice here. I'm terrible at this. But if you want to be full-stack AND avoid burnout, you need breaks to regroup.

Two things: there’s no such thing as full stack developer, and that’s definitely not the reason of the burnout.

I have already written in detail what full stack means in my opinion.

Burnout is a tricky thing; lots of psychologists tried to solve it, without much advancement. I think it’s simply when you loose interest in your job. You loose motivation. No reason to go on. So let’s switch careers.

Now if you truly are full stack, this will come much later. The fact you can do every type of job in a project means you won’t get bored for a while. Well, unless you have to do a lot of one specific type of task, which will eventually come in every project.

There’s a point when adding new features to a product is a bad idea. It works as intended, it brings in money, so you don’t have to touch it. There might be occasional bugfixes, there might be operational annoyances, but that product is essentially finished. That’s when most full stack devs will feel the burnout.

Also, during development, the main point is to add new features. It might be more diverse, but feature grinding can create lots of technical debt. That, again, can lead to the burnout feeling, as you have to work with the same pile of ugly code, which slowly becomes a burden.

I can probably go on with all the cases, but I will definitely not say “so you burn out because you are oble to do too many things.” Just find the balance between the tasks you like, and make tasks you don’t like enjoyable.

Happy coding!