Full-stack developers are in fact stuck at mid-level. Don’t go down that path
habr.com
habr.com
> My understanding of how software is built surpasses any language specifics
do you mean that sure, you don't understand all the language specifics, but that's unimportant because you understand the high level? Or do you mean that you keep track in detail of developments in each of the five languages you've listed (to the level of detail of reading all their release notes and testing every new feature, knowing about the characteristics of all different flavours of index in SQL databases, and knowing best practices for managing state in React components, as suggested in the article)?
If the latter - if you truly have an encyclopaedic knowledge of every tool you use - then, well, congratulations, but I hope you realise that nearly all of us who work with a diverse array of technologies never achieve that mastery.
But if, on the other hand, you're casually conceding that you also don't have the low-level mastery of the tools you use that you would if you worked with only one of them every day, then... maybe you shouldn't be disdaining the author as a failure for failings that you also have?
It's hard to know what people mean by expert without a defined benchmark of what an expert is. I would have previously considered myself an expert of one server side programming language, but actually I rarely read the C code, and never really cared about how the functions conformed to Big O notation; I have profilers and metrics and can worry about specifics as and when they present themselves as problems.
I can bootstrap a linux system, docker, kubernetes, CI/CD, secret store, provide monitoring and metrics solutions, and have guided several such systems through fairly strenuous security conformance. I've also did delivered some front end JS work previously. Knowing more than one area definetly has benefits but it doesn't preclude you from delving deeper into one of the areas.
Today I act as a consultant. I go big corps and teach them how modern dev works, and how to achieve this in a security concious and cost effective way. I get paid pretty well and I doubt I could do this if I was simply an expert in Java for example.
Edit: We live in a where most devs over 25 expect to be "senior" and can actually achieve this because most orgs are unwilling to pay for experience. Personally, I wouldn't sweat the labels too much.
You can look up the details then.
There's no reason to think you came be senior in multiple languages. Even if they were unrelated and separate, you could do it, it would just take multiples of time. But the fact is, they are related. Concepts apply, and actually enhance when you apply them, across different paradigms. It doesn't work in a way that easily conveyed in passing comments (otherwise being a senior might be way easier!), but as you progress, your pattern matching brain will start to see and expect certain things from the languages you work with. That's what makes you am effective programmer in a language. The sense that "there has to be a better way to do this". Not knowing immediately what that way is.
As a side note: we're currently renovating our house and I love watching the builders work. They seem to be full stack in their abilities as well. Electrics, plumbing, structural work, plastering, decorating, building our kitchen, opening walls. It is amazing to watch them work. I asked the guy the same thing - where did you learn to do all this? how can you handle so much? His answer was the same as mine now - He's been doing it for many many years, and over those years those skills across all disciplines get stronger and fine tuned. This is just how it is I guess.
The post author seems oddly upset that someone corrected his TypeScript design choices. If you want to do full stack, you can't take feedback personally. I regularly get code reviews where I've done something that's standard practice in one language but a no-no in another, and I just didn't remember. (PHP/Hack is like ground zero for these gotchas.) That's absolutely ok — that's why we do code reviews after all!
My real expertise is the C/C++ level stuff, but I write the other code because I'm basically the domain expert. The value of that code is that it's doing something useful and nobody else had to be assigned to write it; not that it's "ideal PHP" or "beautiful React" right off the bat. That can always be tweaked and refactored in code review.
Summary: in "full stack", you can't afford ego about your code, but you need conviction about the value of your contributions. That often means you need to spend time understanding stakeholders or user needs rather than e.g. reading TypeScript release notes.
I think this is a key point. In my experience there are two paths for engineers to senior level positions: (1) management, which is usually easier (more openings available, engineers may find it unattractive) but slowly moves one away from technology development, or (2) domain expertise which is technically harder to achieve (need to be recognized as expert) but often provides more freedom and allows staying science / technology focused.
Each path requires some (different) soft skills which are more important than maintaining either a super broad or a super focused "stack". My 2c.
More likely than not, he is stuck at mid-level because of his lack of humility and arrogant approach to seniors, traits that would make a terrible technical manager.
seems like both he and his coworkers would need some help in humility.
It is good that the guy in the article experienced a bout of self-reflection. I hope he has learned some lessons and can move on and become more empathetic to others regardless of experience level.
FWIW, I think having a beginner mindset is a kind of "super-power" as long as one is also able to be humble, patient and cooperative at a level that many people can't achieve.
tl;dr: it sounds like a toxic work environment where everybody loses.
https://medium.com/javascript-scene/a-simple-challenge-to-cl...
If you're working freelance, as a consultant or building a product, people are paying you to spare them the technical details. They don't care what language you claim to be a guru in and you shouldn't shoe horn in your preferred tech stack when something else is more appropriate. Also, if you frame yourself as just "an expert in language X", you're only setting yourself up as a replaceable commodity.
I think having the skills to understand business goals combined with the ability to design and develop solutions where you're flexible about what tech stack is used is much more valuable to businesses.
Also, I don't understand the false dilemma of having to choose between being a "jack of all trades and master of none!!!" vs "super guru in one area". It's very practical to get to expert level in several languages and frameworks, especially given the similarities between many of them. If you spend all your time on one language/framework, you're going to quickly reach diminishing returns in terms of what you're learning vs how useful in general it is.
How much better are you really going to get at Python after spending 1 year, 5 years and 10 years with it? Surely at some point you're just learning obscure tricks or the ins and outs of libraries that are going to be outdated in a year or two anyway? Why is that valuable compared to being more well rounded and learning transferable skills?
If someone has been programming for a long time and they only list they're highly proficient at one language, that's a red flag to me they lack perspective and are unlikely to be able to architect solutions that require the bigger picture.
Very well-said, and needs to be repeated here every time someone posts on HN "What language, framework, shiny-new-object should I learn to get the best job..."
Well said. Looks like no one else is expressing this; I completely agree.
What the article says is true, but you could replace fullstack with any other role, name the article "You'll never be the best" and the article would still be true.
Even if you specialise in something, there will still be others that are better (and if they ridicule you, they are just assholes) and more things to learn anyway.
The author is mentioning a lot of specific technologies (react, databases, python) that, even as a pure "backend engineer" or even a "database specialist" would still face the issues mentioned in the article.
Specialising and going deep is great, as staying broad and doing more stuff. You just need to understand where you stand and what your strengths and weaknesses are. You can always specialise more, and more, and more. Specialise in backend, or actually .NET development, or actually databases, no I mean SQL, actually I mean scaling SQL databases, etc.
If you want to be a full stack developer, the quickest way to get there is to build an entire application all through it's layers by yourself. Front end, backend, and databases. And the more complicated and demanding that application is the faster you will learn. Learn how to do migrations and backups, learn security concepts and how to harden your application, learn about the intricacies of UX and UI design. Know the seven layers of OSI and get your hands dirty with them. Learn actual system programming. Stop using fucking ORMs for your SQL.
Don't do what this guy did and master languages deeply and then think that's what makes you full stack. You could actually get away with lesser understanding of languages and technologies if you are very skilled in knowing how they fit together.
Companies know this. There's not appropriate compensation for people who can get comfortable with this breadth of stuff. Fullstack is currently "exploited" because of this IMO.
But - if you do it right (and with a bit of luck), you can work yourself into a position in which you've got a lot of freedom to choose what you want to work on, and that freedom is worth a lot in itself. Because you're the one guy that can "get everything to work smoothly together" and that is able to deliver entire working solutions, while practically all the others may be able to get a single part into good condition, but they stumble when it comes to getting to something working in a greater context. Their solutions will inevitably be less polished than yours.
People are not indifferent to this. It takes a while, but they notice it. And you will be in high demand because your solutions have this really nice tendency to "just work". And nobody will really understand why it is that way. Which means you'll be able to largely direct what you're going to work on next, because since nobody has a real clue why your stuff "just works" all the time, they are doomed to rely on your opinion when it comes to where your specific skill set is most valuably used next.
I've always felt relatively underpaid compared to what I wind up bringing to the table, but I would say there have been subtle but noticable perks in other ways and it's definitely translated to comp over time too.
It clicked for me a while back that the vast majority of devs just working on line of business applications have never and will never put together an entire enterprise grade system end to end by themselves in their career. So all you really have to do is (a) have a relatively good head on your shoulders and (b) just hack away at building out a fully fledged system end to end in your own time. A sort of reference architecture of your own. Then when you need to implement stuff at work, you've already solved the problem once before so instead of taking a day to wrap your head around how a particular part of it works, you just whizz through it relatively quickly. It looks like magic from the outside, but it's nothing more than being prepared ahead of time.
Or just learn more SQL so you feel comfortable using ORMs again. Just saying.
No good developer uses ORMs for anything significant.
A full-stack developer is not a 10x ninja developer in every language/technology in the "stack". A full-stack developer is a developer that has good enough understanding of a stack of technologies (say Django for the backend and Vue for the frontend, maybe Swagger in the middle, and PSQL for the database) to help the team fix integration issues between each layer of the stack.
Becoming senior or lead has nothing to do with how deeply you specialize, and everything to do with having an impact and delivering value.
These days as a consultant, I tell people I’m full stack with more emphasis on the back end.
Only when your business scales (a lot) that you need people that are more and more specialised. And trust me, the first backend engineer you hire to optimise the backend build by your full stack engineer will probably not be the backend engineer that will be able to scale and shard your database once you reach more and more scale.
Nothing is black and white.
A jack of all trades is a master of none, but oftentimes better than a master of one.
https://en.wiktionary.org/wiki/jack_of_all_trades,_master_of...
But this is a typical non-junior web developer, not a full stack developer.
At a large company, people specialize. At smaller companies people do everything and get to work with a lot more moving parts to the bigger system.
I’ve always seen full stack as a path to management because at some point you can no longer do all of the things you’ve had your hands on over time, but you can delegate and coordinate while you actually understand what’s going on.
There are a lot of interesting paths in a field as broad as this.
"I had practical skills in all aspects of professional software engineering." I don't see any layer 1-3 skills there.
I would expect a full stack ie layers 1-7 developer to be able to design and get implemented a small network.
It typically just means front-end, back-end, database. Not networking? I know it says "full" but it's not that full.
The other is the "Octopus". An octopus has reasonable skills at fullstack dev, customer development, business development, business analysis, marketing, sales and accounting.
Though I think Layer one assumes power and the pys media exists :-)
If an established company is recruiting fullstack developers it could be because there is a manager who thinks, "Why hire two developers when I can hire one?" Which is magical thinking as there is always a trade-off.
I've tried several times in my career to focus on a skill but because I was able to do many other things, I was asked to by my employer. I rarely say no. My last job was originally supposed to be 'make these products faster' with a focus on the backend, but it turned out the frontend and anything in between the two was as much a part of the problem. Not only did I fix issues on the server, but I re-architected the frontend to a degree, moved all assets to a CDN, significantly improved the js code's tree shaking, code splitting, and lazy loading, tackled minutiae like compressing images better, using a faster and more secure alpine image, and the list goes on.
I didn't really want to do that stuff, but I could and it needed to be done. And the reality is that even though I'm not a master of anything I do, no one else at that company had done those things despite having the opportunities (indicating they didn't know how or didn't even know it needed to be done), and the main application I worked on was sped up a ridiculous amount. I remember we had accounts that took an actual honest to dog minute or more to perform an action, and when I was done it did the same thing in a few seconds. It was a game changer.
The people I worked with were awesome at what they did, and in a sense I was only standing on their shoulders. But they don't understand the entire stack well enough to connect the dots like I did. So that's where full stackers really shine, I think. Sometimes I think I get too much credit on teams for my contributions because all I do is make sense of things and break it out into tasks that most of the team is already able to do. But I suppose there is real value in bringing the bigger picture together for your team.
Fed up with the situation I rewrote the thing in Java/Scala and we haven’t touched the service ever since.
My point here is that using the right tool for the task can mitigate a myriad of issues, all the python knowledge in the world was not good when working with a java tool.
What is needed is balance, not every language is good for everything, not every framework can do it all and certainly not one engineer knows it’s all (either the individual contributor or the manager)
Because it's hard to build that culture it's ew rely done and so there's no market for it. What full stack means in the market is front end with a little back end and doesn't pay specialty rates. Actual full stack is a specialty just so rare it's not even 'a thing' in the minds of employers.
So much this. I believe in full stack development skills, that someone can have them, but I don’t believe in the job role of full stack developer.
At small medium scale, there’s just so much more front end work on a lot of apps. Let’s say 70%. My experience with full stack as a job role is that it turns into “what backend change can I quickly make in order to get back to the front end work which is most of the work.” Which then means no ones manning the ship / design / scope creep / perf risks etc of the backend. I think separate roles lead to more even evaluation of best feature implementations.
I, frankly, don't trust career coders who don't have an active interest in the broader activities around coding, software, hardware, maybe HDL's and FPGA's, or low-level stuff with microcontrollers etc.
as it appears that a career coder who specializes and then expresses no further interest in branching out is merely milking a perceived cash cow and not going to show an interest in how even the specialized piece they are building inter-relates with the other pieces of the puzzle.
I think that's unfair and ends up feeling a lot like signaling to me.
Some of those things I'm very interested in, but there are tons of development things I'm just not excited about. I don't care about containerization trends, about kernels, not all that interested in chasing the new shiny front-end stuff. I am curious about FPGAs but don't have enough reason to go farther than that. I know devs who do not care about machine learning, about databases, whatever, but are very adept at their areas of interest. If I talk about my hobby work with robotics and microcontrollers and another dev isn't interested at all, I'm not going to judge their general skills.
Expecting people to be excited about anything related to computers, hardware, general engineering isn't very realistic. It's such an amazingly broad cross-section of fields and interests.
Some stuff has happened in that time...
Last time I tried to sit down and learn some front end tech I ran screaming as the technology was do splintered, opinionated and nothing was obviously long term stable.
There is more to life than coding and computing. We have to have time for families and other hobbies. There is only so much time to do it all.
Work + trying to stay up to date already takes the main chunk of it.
In my terminology, when you are a senior you need to be a near expert in whatever you call yourself a senior within.
If that's .NET/C# like the author refers to, you must know how all (the esoteric) features of the language (e.g C#) behaves, you must know IL, WinDBG for advanced debugging and the things along those lines.
So many developers claim something that they are absolutely not, which is experts or senior in a technology.
It's IMO much harder to become an expert in something than to learn a subset of a set of technologies. Much harder actually.
Then again seniority has many dimensions. I often see a lot of senior devs who have mid level skills or mindset but they have become domain experts or experts in the product and seniority is conferred that way. I don't necessarily think that is wrong or undeserving either. I guess if we are talking absent any business/domain knowledge then seniority is judged more closely off raw technical familiarity. For me it's about system design/architecture. Having a strong set of principles that guide your decisions etc.
Back to my backend days I was on the brink of the burnout but switching to frontend gave me breath of fresh air. When I found a modern frontend as a total mess I started to dig into devops and it surely improved my competencies as a backend either.
I completely disagre with the second part: full stack developers are not stuck because full-stack is bad per se, they have chosen to not master one single skill, preferring instead to learn many of them, with a varying level of confidence, from master to "I can learn it, if needed".