Hacker News new | past | comments | ask | show | jobs | submit login
Full-stack developers are in fact stuck at mid-level. Don’t go down that path (habr.com)
69 points by atomlib 17 days ago | hide | past | web | favorite | 90 comments



I consider myself "full-stack" because my average work week nowadays seems to include a constant mix of four kinds of development: back-end performance-intensive rendering services (C++ inner loop kind of stuff), back-end "devops light" service design work and glue scripts, back-end automation work (random shit like PHP/Hack scripts to wrangle data), and plain old front-end (SPA React nowadays).

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 write the other code because I'm basically the domain expert

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.


That is a load of rubbish. I've been coding for various platforms and languages for over 20 years. My understanding of how software is built surpasses any language specifics, however I'm very proficient at a senior level with both front (JavaScript) and backend (Python) development and I can jump into Go, Java or PHP when I need to and set up complex server infrastructures. What I do, absolutely requires me to fully understand all sides of the software product. Not just for my clients, but for my own businesses which I could build because of this understanding. I'm not special here. Many full stack devs are very good (to a senior level) on both ends of the stack. This article is the writer's projection of his own failure to progress while dancing in both weddings. There should be an ethical disclaimer on "advice" given in authoritative tone that are purely based on one's own bad experience.


I had the same takeaway: the author is simply projecting. I consider my own knowledge to be both wide and deep, and I know others who have the same talent and experience. There; I countered the author's anecdote with my anecdote.


When you say

> 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?


As someone correctly understood - I consider myself an expert in 2 languages, and good enough in a bunch of others to various degrees (mostly because of not using for a long while), and confident enough that should I need to I can pick up where i left off with those. I also make a point to learn a new language with a mini project to go with it every couple of years. And yes, to use your examples, I am very aware of SQL variants between mySql, Postgres, Oracle and MSSql, I work with React daily and well, the same with Python, and I handle all of what is called devops these days on my own projects. I've been around the block a few times. But all this I don't consider special. These are tools I use daily across 3 major projects (another story). And I am absolutely sure there are many many like me and those with a much higher mastery of those tools than me. I am still learning every day and when that stops, I will too. Doing full stack does not have to mean you sacrifice proficiency. I actually love the context switching and sometimes will flip between front and backend just as a head-cleaner exercise.

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.


Not the parent, but I believe he says he considers himself an expert of two languages, and reasonbly proficient in five, not that he's an expert of all of it.

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.


What does being "senior" mean? I think it can entail many different things, from understanding the business, to work relationships with your stakeholders, to architectural expertise, and on and on. Compared to these, knowing the latest and greatest updates to any given programming language is fairly minor, especially when it's not the one you're working with at that given moment. You can catch up JIT when you approach a given problem on a given language instead.

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.


When I hire, I never say "senior" or "junior". I don't care for those titles. They mean nothing. I meant "senior" in the "conventional" sense to match the language to that of the original post.


Likewise. Is it not still worth defining the inherent characteristics, even if it's not a job title?


Characteristics yes. As in what will one be doing during working hours, or what one delivers. However, I've seen "seniors" who really had no business being in software development. No idea how they claimed the "title". While at the same time I see what the industry labels as "Juniors" due to number of years in the job market, being so amazingly good at what they do that they put said seniors to shame. Yet the "business" needs those labels to justify a pay-grade of sorts. This is wrong in my opinion. Compensation should match the ability, not the number of years someone had the fortune of being employed at this or that capacity or how good they can blag through an interview.


You don't need to know all the details behind the types of SQL indexes. It is more important to know when to use an index.

You can look up the details then.


That's arguably true. But if it's what the parent comment meant, then it's illogical for him to deride another programmer as a failure for a post where he admits that working full-stack has led to him not internalising things like the details behind types of SQL indexes.


Sounds like the author is blaming his shortcomings on full-stack development and is making a poorly thought out generalization of what full-stack development entails. Thinking that he can best people who boast many years of experience puts him right where he belongs in terms of experience and being a laughing stock.

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.


> I once cranked out a design based on abstract classes in TypeScript, and got ridiculed because apparently nobody does it this way in TypeScript. I certainly pretended that my colleagues were hopeless idiots. It used to help before, but that time it left me with a bad aftertaste.

seems like both he and his coworkers would need some help in humility.


Are you suggesting that abstract classes are a good idea in TypeScript? Because to me, abstract classes suggest that you're doing a lot of inheritance, which is the opposite of a good idea in JS.


I'm not judging if the author did something right or wrong, but that he got "ridiculed" for doing something his coworkers judged wrong, and that he insults them back.


Why? Old-school pre-ES6 explicit prototype wrangling was confusing, but what's wrong with using inheritance if you're writing in TypeScript (or, for that matter, a JavaScript version with classes)?


Too much abstraction can be bad as well, many times I’ve written a nice class diagram to discover no one really needed to reuse certain functionality, a function would have sufficed :P


This article captures a few good reasons as to why composition is much preferred over inheritance:

https://medium.com/javascript-scene/a-simple-challenge-to-cl...


No, but "got ridiculed because apparently nobody does it this way" reflects poorly on the coworkers (or on the author's perception of the world), while "I certainly pretended that my colleagues were hopeless idiots" is also rather immature.

tl;dr: it sounds like a toxic work environment where everybody loses.


Author may have left out the part where his co-workers said, "no one does it this way [because it's usually a bad approach using this technology, and your particular use-case isn't some special case where over-engineered and brittle inheritance is actually a good idea.]"


I'm sure he got feedback. It may have been harsh. There may have been laughter. And yet, it's the author's choice to characterize it as ridicule, and the choice is not a helpful one to his own career. His attitude is a millstone, not his "broad experience".


In the industry there is generally no mercy for a programmer who fails due to his own hubris.


There is generally no mercy period.

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.


I'm assuming this is aimed at people wanting to be hired by companies with large teams as a developer where you can focus mostly on a single area?

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.


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.

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..."


"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?"

Well said. Looks like no one else is expressing this; I completely agree.


I'm a full stack developer. I thought I was going to agree with the article, at least for some parts, but I actually disagree completely.

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.


Don't listen much to this guy. Full stack developers aren't doomed to fail, the only thing that happened here is that this guy failed miserably. He failed because he focused on the wrong things.

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.


This is a good technical approach but if you get this far, your salary won't match the value delivered by your actual skillset.

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.


That is true. Your salary will most likely not reflect your actual value, but will be way below what you should actually earn.

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.


This is the direction that my career is taking. Definitely the benefit is you eventually get to work on the good projects that you want to because people trust you to deliver a level of work they don't seem to get very often.

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.


I really appreciated this comment, I've been going through a period of doubt over my skillset being so broad, I'm glad to see others follow a similar path. I can't really seem to help it, designing and building an entire system brings me the most enjoyment.


Having a broad skillset will always bring valuable perspective to projects, but be aware that this doesn't mean that value will be recognized or that perspective valued. There's not much can be done about unwise cultures. So if your only goal is advancing your career and making a lot of money, then a broad skillset might not be the optimal path.


agreed. the guy failed and wants to pin the blame on 'full stack development' as a role, which is a rather stupid conclusion.


>Stop using fucking ORMs for your SQL

Or just learn more SQL so you feel comfortable using ORMs again. Just saying.


It is the opposite. The more SQL you use the less you will want to use ORMs. Many ORMs are basically a black box and you're never really sure if they are doing exactly what you want to do or adding some unnecessary crap, especially if you have very complex queries.

No good developer uses ORMs for anything significant.


You got it man. Actually build systems. End to end.


The author doesn't understand the actual value of a full-stack developer.

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.


That sort of generalist, big picture thinking also puts good full-stack developers in a position to enter management or more systems analysis roles later in their career. The "senior" level full-stack developer of the future may indeed commonly be a CTO in waiting.


Yep, this is exactly how I feel. Sometimes people often fail to perceive the big picture, as well as being so uncomfortable to leave their silos that they won't even venture into the backend / frontend code to debug an issue that has implications through the whole stack.


"Full-stack" is the jack-of-all-trades. Ergo master of none.


In truth it’s more like jack of all trades, master of one or some. 20 something years ago you didn’t hear the term full stack, you did everything — database to UI — because that’s just what you did.

These days as a consultant, I tell people I’m full stack with more emphasis on the back end.


I like to say "some parts of the stack are fuller than others"


You don't always need masters. A full stack engineer will build your a rails app that might work perfectly for the whole life of your business.

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.


Interesting point, the complete saying was originally "A jack of all trades is a master of none, but oftentimes better than a master of one."


That is only half the quote though, the full quote is

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...


Makes sense. And no one can really be an expert in something without having a broad jack of all trades perspective on everything else.


Being jack-of-all-trades and master of one aren't mutually exclusive.

Becoming senior or lead has nothing to do with how deeply you specialize, and everything to do with having an impact and delivering value.


The master of creating a product. i.e. the most valuable thing in an early stage startup in terms of tech.


> say Django for the backend and Vue for the frontend, maybe Swagger in the middle, and PSQL for the database

But this is a typical non-junior web developer, not a full stack developer.


The comments here are (predictably) negative, but it takes a lot of self-awareness and courage to not only say, “I used to think X, but now I think that was a mistake” but also to publish it publicly and invite feedback and ridicule.


He’s not wrong, but it’s situational.

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.


Though the author seems to be laser focused on career progression and $$$ (I suspect due to cultural bias's)

"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.


Not really?

It typically just means front-end, back-end, database. Not networking? I know it says "full" but it's not that full.


They also have to build their own computer and a small generator that creates electricty, and probably their own wifi router. otherwise they're mediocre and don't understand how stuff REALLY works.


Well we joke about it but I do have the concept of "deep stack" which are the devs who were Rockstar Ninjas when they were younger and are now 20 years deep and really do just know bloody everything. Rare, wonderful individuals.

The other is the "Octopus". An octopus has reasonable skills at fullstack dev, customer development, business development, business analysis, marketing, sales and accounting.


I do seem to recall as a child making a small generator Dad got me a kit designed for kids for Christmas on year.

Though I think Layer one assumes power and the pys media exists :-)


Power is assumed, yes, but it deals with physical media directly. That's what 1 is. You make or design the RF level hardware. Layer 2 is where PHY is a separate entity - driver stack starts at the lowest point of this. (Used to be higher but now more things are offloaded to firmware or hardware.)


“If you want to make an apple pie…”


Not to me as an ex OSI guy :-)


I think on one level the author has a point. Fullstack developers make sense for early startups who can only hire 1 or 2 developers, or who only are 1 or 2 developers. However once you start growing and probably need to rebuild your app, it's time to hire multiple specialized developers.

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.


This guy is painful. What a junior attitude. And please never "retrain for management". Just don't. Please don't. You are exactly the wrong kind of person for it.


If you expect to be a generalist by somewhat half heartedly knowing how to use a number of technologies you're doing it wrong. What makes you a generalist is not just being able to use tools, but rather understanding how they work. That means for web frontend work you should rather step towards understanding how the dom and v8 works instead of jumping on the newest hyped framework or instead of just learning react's api maybe also understand how and why they are building their own virtual dom. If you do backend work you eventually want to look into compilers and understand the difference between interpreting, compiling and jit-ing code. If you do database things you may want to start thinking about how you would implement your own and touch on things like transactions, consistency, how a query optimizer works or what structures data is stored in. Not that you will ever be tasked with building your own frontend library, language, compiler or database; but all that helps you immensely to understand and evaluate the tradeoff space and also quickly jump on the newest hyped thing if it actually is a good idea.


The codebase at my job is usually complex - Python, Ruby and Go, along with JavaScript/Typescript and a little bit of Java and R. I used to be in the "all programming languages are basically the same" camp but jumping back and forth between technologies has given me more appreciation for the details. Some knowledge I've wished I had at my fingertips: semantics of Go channels including all the edge cases, the scoping semantics of Ruby blocks, anything in the JavaScript standard library, the ecosystem of Java build tool and helper libraries. Having to stop and look up things lowers my development velocity compared to a specialist. In the other hand, as a generalist I can trace a request across component boundaries and go as deep as needed into a system to diagnose issues. So I think it depends on what kind of projects you are working on. A "serial generalist" that goes from one tech to the next is always going to be behind the curve, but that isn't really what I would think of as a full stack developer, either.


Another side of this is that there's demand for full stack competency. Even if it isn't perfect comprehensive knowledge, it's enough to get difficult jobs done. I think this person was striving for perfection where it's not really feasible for most people, or even necessary for most jobs.

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.


Once my architect wanted everything on python so I obliged, because of the size of the data I went with spark, but since we were using python I had to interface with it using pyspark, which still uses python 2, after a few months we start having all this problems with the py4j bridge in spark collapsing and us having to restart the service every few hours.

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)


hi, when did all this happen? isn't pyspark almost on par with scala implementation now ?

As a fellow full stack developer, I can relate. I have been called out for using Optional too broadly in Java because I was trying to treat it like Rust, and I too need to research specific syntax and API on a daily basis. On the other hand, when our company was bought out and I had to change technologies fast I think it was an asset. A year and a half in and I am clearly a senior dev again. Not the owner of any domain anymore, but like the article says, someone they come to to bounce ideas off of, and someone who can identify the cross domain architecture deficiencies with a concept of how to fix them. Also because I have to research constantly, once in a rare while I stumble across an elegant solution the domain experts weren't aware of.


At my last startup, we tried full stack development in conjunction with pair programming. Fullstack dev is hard essentially have to be great at both back and front end and some UX. Pairing helped. In the end many didn't want to continue preferring to specialize. That was a shame because like pairing, full stack is a nonstop dev flow, no pauses for talking to other 'end' nor code review delay.

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.


> What full stack means in the market is front end with a little back end

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.


Unless one literally does not care about computers AT ALL, and is content with front-end development, having no hobbies involving any OTHER kind of development etc, one will end up being a bit of a "full stack developer".

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, frankly, don't trust career coders who don't have an active interest in the broader activities around coding

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.


I think OP was saying he would be suspicious of a coder who was not interested in at least one area outside their professional domain, not any given area. If that's the case then I have to say I agree with them.


Feels like this is something a person who expects me to work on weekends would think. Don't get me wrong, I used to agree with you, I know however believe otherwise.

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.


Well you forget about the other direction. I’ve spent so much of my time getting computers to talk to each other I’ve missed the last 15 years or so of web GUI work.

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.


One problem is that people think about seniority as expert level in something.

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.


I would class your definition as expert rather than senior. It's a level above what I'd expect.

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.


Here's some additional unsolicited advice: Work on your own skills instead of dishing out advice on how to approach systems you appear to only superficially understand :)


I also have the same question about how to improve my technical skills. I don't think it is related to full stack or not. I found that most of the companies require developers with mid-level skills only. I don't have enough chance to improve because there are no difficult problems in my job. I would say if you think you are not good enough, simply move to companies which give chances to solve difficult problems.


The thing with programming, contrary to pretty most other fields, you have any possibility to do something diffcult in your free time!


Personally, I'd prefer to have a broader albeit less competitive set of knowledges as a full stack (this should be defined, though) developer. I do not see it as a flaw.

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 agree with the first part of the title, the only thing I've read.

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".


I see no reason why a backend web developer wouldn't know html/css and pure js to an acceptable level. You don't have to be a Node.JS ninja on the frontend but definitely have a good grasp of what's going on on the frontend. People who can only do one thing will have a harder time leading teams or going to management.


I have a feeling that all developers working on product would become full-stack developers eventually. Probably the dichtomy of backend v.s. frontend would become product v.s. infrastructure. Product developers support business units while infrastructure developers support product developers.


One take away, from the article and comments here. There is no industry agreement as to what a junior or senior role is. Everyone seems to place importance on a different set of skills.


I suspect the author really wants to quit management and roam the world on two-week niche contracts, but is too afraid to do so? </s>


Is a snarky, jpeg code snippet at the beginning of an opinionated tech article the new snarky, pop-culture gif?


this is nonsense




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: