For me, the notion of being a full-stack developer is the minimum required to be a senior developer. Before you can be a good developer you need to understand the underlying stack. This is to some degree dependent on domain but lets assume you mean “web” when you talk about full-stack.
Then you should have a good grasp of the following:
“Ops”
Deploying, running, maintaining and trouble-shooting an Operating System (or at least your deployment target) in production. How to troubleshoot OS performance problems, run services, check logs, backup systems. This is the base of everything and being proficient in this makes the other steps much easier.
Database OPS. Installing, configuring, running a database. This includes things like picking the right file-system and disk layout for your domain, trouble-shooting poorly performing databases (which could be disk, memory, configuration, poorly written sequel, missing indexes, etc)
Running and maintaining other services on a a server. Message Queues, Web Servers, Key/Value Databases. Well, if you know the first point this pretty straight-forward.
I believe this is the most important for any developer. Really understand the platform you are deploying to. Without it you cannot properly design your software and you can’t trouble-shoot it if something goes wrong.
The “software” you write is not just the one component. It is the entire system together.
“Development”
Database development. Know how to properly model a SQL database. Know when SQL is appropriate and where other databases (key/value, document, etc) are more appropriate
Have a good knowledge of your chosen language stack. If you are senior you are likely to have good knowledge of at least 2.
Know your protocols. TCP/IP, HTTP at least but other protocols as well depending on domain, REST/Soap or other similar.
Know the browser. DOM, events, HTML, CSS, Javascript, cookies, other storage.
Basically, a senior full stack developer should have enough knowledge to be able to implement the different components used in a web framework on his own (excluding databases, message queues, operating systems of course but including things like authentication, MVC frameworks, session and cookie handling, routing handlers, “javascript frameworks”).
Yes, badly formulated. I am talking in the context of web development.
Being a senior developer in other domains obviously doesn’t require you to be full stack.
My point was more like if you are going to be a senior web developer you are almost automatically fullstack are you not? Or is it common with 10-15 years of experience with just one small part of the entire web stack?
Your version is the cross-functional team in a single person. Cross-functional teams resulted from the realization that functional teams will tend to “fix things” in areas they have access to rather than being delayed by issuing a request to another team (in charge of the functional area where the logic actually belongs) - usually ending up with business logic in all the wrong places. However members within cross-functional teams need to communicate effectively with one another so a certain amount overlap is required and each member often needs to wear multiple hats so that absences can be covered - leading up to the notion of a team of “full stack” developers.
Now it makes sense that one should understand all these areas - but how many years will it take to become competent, much less proficient in this laundry list of skills? Also there still seems to be the notion that “leveling up” is moving into management - not to become a senior developer.
Furthermore the full stack skill set seems to focus on solution-oriented skills - what about the problem-oriented, non-technological skills like domain knowledge, domain-analysis and related methodologies?
(Aside: AWS, Azure, and Google cloud present themselves with serverless as requiring a much reduced Ops skillset).
Lately I’ve even heard the term of “full stack designer”. Apparently some “web designers” simply delivered design mockups; HTML and CSS was purely part of the “web developer’s” job. So a designer also delivering HTML and CSS (and a smattering of JavaScript) is now a “full stack designer”.
So the “full stack” terminology is about as useful as “component”.
It’s pretty common for people to not be doing much or any FE work. As anecdotal example on my team of 60+ people there are 3 devs doing mostly FE work others might help out from time to time but are pretty much doing BE dev. Also I doubt more than a few could stand up a production env. on their own in any reasonable amount of time without using preconfigured “playbooks”. I think the larger the company the more specialization people often have.
It may be true. I guess there are a number of different definitions of full-stack and I am aware that it has been quite watered down lately. I hadn’t quite thought of it from a management point of view but what you say makes sense.
It takes a lot of time, and you’d have to be in a position to get experience with these layers. 10-15 years sounds like a reasonable time to me. And obviously there will always be a varying degree of proficiency in different skills but to me they are the foundation for which you can make the correct design decisions developing software.
To be a complete developer you should have good knowledge of these as well. I am a strong believer in one-man-teams Or rather I should say the most important thing is “ownership”. You need to have a team who feels they are responsible for the entire stack.
Too often I find teams not picking up a problem because they only see their own small little component and are stuck in their corridors. Software bugs and features often touches the entire stack.
It is a generalist vs specialist argument I guess. In health care for example, you better have a condition which is diagnosed and served by one department only. In more complex cases where you need help from many different kinds of specialist you easily get handed around with no-one taking responsibility.
The same happens in software and this is where the full-stack developer comes in. They are the bridge between the compartments, they take ownership of the product and in the cases where their general skills are not deep enough they can take help of a specialist.
Ok, so agreed. full stack developer may be a meaningless word today. But is there a better word for the role I describe? Someone willing to take ownership of the product and able to make changes to any layer of the stack?
And I still don’t know why you think full-stack is unfortunate and mythical?
Also there are infinite permutations of “full stacks” given that there are any number of products that can serve in each layer. The “full stacks” that made the most sense to me were .NET or Java Enterprise because that automatically constrained the compatible products. And even then a .NET full stack developer wouldn’t necessarily know both ASP.NET and ASP.NET MVC, just like a JE developer wouldn’t know all the available Java web server frameworks (and the browser-based frontend skills were usually deemphasized anyway).
So beyond that the composition of the “full stack” is dictated by where you work. If you stay in the same place you simply keep up with the product changes. But the tech industry also has a high turnover rate. While moving from one snowflake full stack to another is possible, you need to maximize the overlap to reduce the ramp up time needed to become productive after changing opportunities.
So from that perspective full stack developers don’t exactly grow on trees and have a perceived short shelf life.
You are supposed to have T-shaped skills. The mythical full stack developer needs to have enough "T"s to make a good size comb.
I think there are multiple factors by the time the “agism” kicks in people generally have a network that will allow them to find the next job should there be a need. Also the compensation level is beyond what “startups” are willing to pay (they need young people that they can mainly compensate with “options” which have a close to 0 probability of ever being worth anything)
What you describe here are people with narrow responsibilities and/or skills. That’s not a bad thing per se. I know a heavily specialized DB developer who can rewrite any stored procedure to work 50x faster compared to what an average non-DB developer would compose. I also knew a data scientist 10 years ago who coded pretty decently but was mostly able to analyze 300+ GB of data in several days with very interesting and productive results. Many other examples exist.
From the people with narrow skills to the mythical full stack dev you are describing there’s a huge spectrum you are not including in your comments. Don’t make it so black and white. I can give you an example with myself:
I have 16.5 years of experience, 38 years old.
I worked with C, C++, Java, PHP, Javascript, Ruby, Go, Elixir. Learned MySQL and PostgreSQL, also Redis and a few others. Learned Linux sysadmin skills pretty well, too.
I knew jQuery inside and out, and dozens of others – this was a few months before the React era.
Eventually I started losing jobs, several, one after another. Was it because I was lazy? Hell no. I was just burned out and couldn’t keep up and unsurprisingly started to under-deliver. Example of what I mean: to do Javascript nowadays, you only have to do Javascript. Even catching up with the framework of the month drained me enough that I started falling behind on the backend skills I wanted to develop. (I managed to learn React on a decent level before giving up.)
So what happened? I dropped the frontend. One afternoon I sat down at a sunny cafe outside, evaluated where I am and where my career prospects are, and where are my own ambitions, and decided to cut my losses before I became a jack of all trades that’s not really good at anything.
So I guess in your eyes I’d be a “former full stack dev” but today I define myself as “a hardcore backender with an excellent understanding of the full stack” and I think this is sort of what @peerreynders was getting at (correct me if I am wrong, please).
Truth is, there are way too many technologies to be able to keep up with, ever. And I am not willing to spend all my free time just so I can keep up. Even though I code for fun ever since I was 12 – namely 26 years now – I am still human and would like to go to a SPA hotel with my wife every once in a while, to watch a movie, read a book, make love, take walks, and a load of other human leisure activities.
In my eyes you’re asking for too much, especially when you repeat several times that you “need people to take ownership”. What does that even mean? If I am paid $4500 a month (a pretty average salary for a senior dev) I really want to know what am I being paid for exactly; I can do tasks quicker than many and with much better quality… but having to also manage the product’s feature roadmap would definitely immediately make me ask 20% more because, you know, more responsibilities == bigger salary.
So I think you are conflating “senior programmer” with a “jack of all trades and good at none” and “a project manager” here. Apologies if I misunderstood.
Furthermore, I again agree with @peerreynders – age discrimination awaits us all eventually. We do indeed have to have several T-shaped skills to be valuable and be sought after – so that a bias which would interfere otherwise be deemed the lesser concern (as it should be anyway). The undeniable truth is, even if you are 65, nobody would care as long as you have rare and valuable skills. So from certain age and on we should start investing in that.
In that regard, striving to be a “full stack” nowadays is the surest way to end up burned out and generally worthless for any employer just at 35-40 years old.
Are you doing contracting? If so I can understand that you can’t keep up with all the permutations of a stack and be able to join in with short notice on any team.
I am not saying a full-stack developer = must know all of the possible stacks out there. I think full-stack is something you grow into into your current job. I feel lots of skills you accumulate during your career makes transitioning between various stacks much easier. I’ve had the pleasure to work with many different stacks, both within web development and others. I often have no problems diving into very different stacks and solving problems, even with technology I’ve never worked with before if it is is in the same domain as a product I’ve worked with. For example, ruby on rails if you have worked with another MVC web framework. I don’t think it is so much about the technology but rather what it is trying to solve. Many times I’ve ended up fixing customers software which are integrated with us faster than their “specialists”, even if I have never seen their code base, worked with the framework or even in the same language. I’m sure they are much better than me in their specific specialization, but features transfers over boundaries, in many cases between different companies and it seems that if you are not somewhat specialized in a number of these compartments you don’t even see the problem to start with.
To me you sound like the full-stack definition I have in mind.
I think @peerreynders’ link about “Generalizing Specialist” is a more suitable definition than full-stack. It also mentions your “jack of all trade” as just being a general generalist as opposed to generalized specialist.
From my point of view, taking ownership is feeling personally responsible for the application as a whole. I think when job is done in specialized compartments people don’t feel they have anything to do with the quality of work of other parts of the application. This is a big problem in larger organizations. The turn-around time for fixing things is just way to long. If you include integration points of customer/partners stack it is even worse. You have people writing documentation which is not technically skilled.
In our company, before we were acquired by bigger fish we had a small team consisting of a number of “broad-stacked” people (senior developers). We had no-one to lean on so each took “ownership” of the product. It meant the same persons wrote code and documentation, saw instant feedback directly from customers. Fast bug fixes, fast support, excellent knowledge of the entire domain and stack. Once we were acquired and pushed into a more corporate environment, the work got divided up into many teams. QA, documentation, different levels of support. For political reasons different teams started fighting over having their “component” get the resources even if it was only part of the stack. Many of these teams were specialized in what they do, but even with their specialization (which on paper should be superior) the work they did is of lower quality then the less qualified “full-stack”. Over time you lose motivation, the quality of work slips and you don’t feel empowered to make a difference.
It is about being proud of the work you do. And also being allowed to get the time needed to be able to do work you are proud of. This also ties into the ownership and responsibility. If you take pride in the work you do, you will not have a “whatever” approach you will “own” it (for lack of a better word).
Pay in itself should not be the problem if you are given the time to do your work. If you are getting rushed and not able to do the work that is up to your own standard you end up feeling rushed, or forced to cut corners, working overtime. And then it is very understandable if you ask: “What am I being paid for. I should get more”.
Not quite. I am just saying that if you have been working as a “web developer” (and I use this term from went it actually meant back-end and front-end not just javascript+html) and you have transitioned into a senior position (10 years?) you must have likely accumulated a number of the skills on my list. I don’t know if “senior” is the right word as it usually refers to rank which may actually have nothing to do with skills.
I am not saying this apply to all developers out there and that all developers can be in a position to be allowed to develop these skills. But I don’t think it is a mythical thing I and meet a number of these developers.
Agism is of course a problem. Also that you are not payed to develop your skills by your work. Perhaps this makes it harder to achieve a high level of skills in multiple areas but I don’t think it makes it “mythical”
Thanks! Yes, this is a much better term for what I am advocating. I should have read it in 2003
I think fundamental skills are transferable between stacks. If you understand the underlying principle between many of these technologies then it is quick to learn how it is done between the different components implementing these technologies. The biggest jump is if you have to jump between different paradigms.
For example with databases: If you know relational modelling, what different types of storage engines, types of indexes, different transactional isolation levels, log shipping. SQL then your skills travel nicely between MySQL / Postgres / Oracle / SQL Server.
I’m not saying you can just jump into the stack and be instantly super productive, but with a foundational understanding you’ll be able to pick it up quickly enough (if you are given the time by the employer).
Both you and @dimitarvp have similar definition of a full-stack developer. That they should already have very specialized knowledge of each component of a stack and be able to start a new job being productive on all stack being presented. In that case my definition is not accurate.
I agree. So many factors are at play and honestly I think the ageism issue is a bit overhyped. I think part of the issue for some people is they’re not interested in continuing to invest in new skills. I also think ageism is more of a factor in start-ups and contracting. Just my two cents.
So it seems I did misunderstand you. Sorry about that.
And yes, transferable skills is definitely one of the very key abilities that make you a senior / full stack.
What you speak about is now clearer – bigger organization where everybody wants to have smaller responsibilities because nobody really cares and, as you described it, getting even one feature out the door incurs a big managerial overhead.
To make people take ownership of parts of the product however, they need to have some executive power IMO. Otherwise you get greeted with “don’t take over my job” by a 150kg manager looking at you menacingly (experienced that several times in my career). So while in general I agree with the notion, I (1) would call it “taking the initiative” and “wanting to see things through to the end” and (2) would still ask for clarification which team member has how much managerial powers.
As for the organization you describe, it seems like they have the very classic growth problems – hiring people just for the heck of it, basically.
…In order to achieve transferable skills, we must avoid niche and badly done technologies. The Java and C# (.NET) worlds are full of these. C++ too. In these languages, you can legit have 20 years of experience and still have zero clue on WTF is happening when onboarded to a new project. That’s one of the reasons Ruby on Rails and Laravel got so popular: you can onboard almost anyone in a few days. And that’s why languages like Elixir and Clojure gain traction as well today: they don’t have 20 ways of doing the same thing (in this case web development) and even if their paradigma is different (functional programming vs. imperative) they are still picked up relatively easy because they bet on the principle of the least surprise and are religiously avoiding API duplication – in my opinion anyway.
Lately I am not even sure what I do. Used to work in organizations full time, lately I am hired per project, and even got offers to coach people. Also several smaller jobs with 10-20h a week. So yes, I’d say mostly contracting nowadays.
RE: being proud of what you do, I always have that, even when I screw up – because the whole thing is a process and you grow together with the project. I so wish we were allowed the time to actually show real productivity and creativity but alas, that’s rarely the case. Agreed on your points about the payment.
As for the number and quality of skills acquired, yes I do believe I have them (basically everything from your list only I am not so fluent with JS nowadays). However, the “mythical” full-stack developers as per your previous definition definitely are unicorns; I’ve met people who are able to catch up all the time but unsupririsngly, they were miserable and lacked personal lives – which is quite normal because the time investment needed is a lot. So I stand with @peerreynders here still: these people exit programming basically 2-3 years after they quality for “true full stack”.
However, as per the revised definition – “being a hardcore expert in N skills and has excellent understanding of the full stack” – I know a number of these people as well. I even dare including myself in the group.
So I’d say we are exactly on the same page here, with some variations of the definitions – but once we cleared those up we are on the same opinion.
Again though, to have people own [parts of the] product they do need some executive powers. I tried and failed many times to take the initiative – many people don’t like it if they can’t control the rhythm of your breaths and these personal flaws in managerial staff are a fact of life. So in the last few years I always include a question in the interview process: “How much freedom do I have to make decisions and to progress the project without a blessing at every step?”
Turned out this is a fantastic filter for bad workplaces by the way.
Or rather I should say the most important thing is “ownership”. You need to have a team who feels they are responsible for the entire stack.
