I'm not sure there is anything like it.
Over the course of my three-decade career I worked on apps, system frameworks (none of this web stuff, backend stuff) and nonetheless I too had to learn all manner of new (to me) languages, API, frameworks, tools, etc. And that doesn't really cover the changes in how software is created/delivered: agile development, tech-lead driven, QA then no QA, unit tests, code reviews, etc. Always a moving target.
(To add some examples.
Some languages I have known: Pascal, C, 6502 assembly, (introduction of the PPC and with it a whole suite of new callbacks), C++, Objective-C, (introduction of Intel hardware and now endianness issues), Javascript, Swift.
When I started my career, being good about managing memory, keeping things small and fast, was a sought after skill. Somewhere about halfway through my career you had to be an expert in concurrency — you had to be able to hold in your head multiple processes running where one can complete before another, where several threads might read or write to shared variables, and UI is being updated on the main thread, etc.)
And it was unevenly distributed as well. At Apple (and likely other big companies) there were "good" and "bad" teams. And I use the quotes because I think it is often relative for the specific engineer. That is, a team I dislike — perhaps it's a highly competitive team, or one under the company spotlight — another may thrive in.
After working for a few years on a particularly "bad" team, I, strangely, developed serious gastrointestinal issues that required surgery and the removal of part of my intestinal tract. Coincidence? I have no idea. But I tell people still in the field to take stress seriously.
Also anecdotal: as someone who still writes checks to pay many of my bills, I can tell you that I noticed my signature was shit during periods of stress, only got relaxed and smooth again when I was also able to relax. I watch my signature now for signs that I am tense.
> Software gets more complicated. All of this complexity is there for a reason.
Not any good reason, imo. There used to be incentives for efficiency in various aspects of the field. Scarcity of talent, scarcity of bandwidth and compute power, scarcity of budgets.
Twenty years of “let’s all be programmers”, unhinged amounts of money, and design by committee, have rendered it a very complex world.
>All of this complexity is there for a reason
Having gone from junior Web designer/developer to CTO/CPO and then into startups over the last 25 years, I'm absolutely convinced that the reasons for complexity in what we do day to day now is for no good reason other than CV building for FAANG type job hunting, job niche building and job security self-indulgence, and a fundamental disregard for maturing the industry.
> But what happened to specializing? When a house is being built, tons of people are involved: architects, civil engineers, plumbers, electricians, bricklayers, interior designers, roofers, surveyors, pavers, you name it. You don’t expect a single person, or even a whole single company, to be able to do all of those.
You would be surprised. While it stays more or less true for low-education job, I find that any job that require more than a high-school diploma suffer from the same problem. We are asked to be more and more polyvalent, and every job offer has a laundry list of skills that we are supposed to master.
When you think about it, it makes a lot of sense: Why pay two expert when one person with just enough knowledge can wing it ? Unless the job/task is highly regulated (you don't wing accounting) or the output quality really matter, a half-ass job is often 99% enough.
Taking about building a house, you can kind of see it actually. A lot of building company are doing the bare minimum, which is why inspection is critical.
I was a developer for about forty years, retired last year. First seven years or so I worked in MUMPS on mostly DEC VAX midframes. Then in the early 90s I learned Visual Basic to break into the Windows world, worked in that for almost a decade until .NET came out in about 2000; I learned VB.NET, programmed in that for about six or seven years. Then I taught myself C# which is what I used for the next 13 years or so. I did lots of SQL Server programming account the way, but outside of that, those were really the only languages/frameworks that I needed to have a consistent career for almost four decades.
This should be called "The Insanity of Being a Web Developer". You can be an SE without ever touching JS.
Learning a couple of programming languages and frameworks you maybe don't like conceptually is more what I would describe as "mildly annoying" rather than tough.
Could be - But for me the hardest part of the job is now mostly dealing with illiteracy in tech from mid managers and up - I don't blame them as most go up the ladder mostly because they're not really decent at anything else [sorry] - but all this to say - The pain of seeing blank eyes when you have a very simple conversation let's say on input validation just kills me - A decade ago these conversations took 5 minutes - now people want to talk about it for hours as they don't get it - basically lack of core knowledge...
> You do a good job. You’re promoted to manager. You need to learn a whole other job
Relevant: https://nebula.tv/videos/coldfusion-why-are-managers-so-bad-... (or https://www.youtube.com/watch?v=m7-UdDg5uIw if Nebula won't show it to you)
The tl;dw is that quite obviously the years and years spent learning one skillset absolutely does not translate into the ability to "debug humans"
It is unusual as a comparison to other careers, esp with respect to specialization, but that is the system. Some people revel in learning new things. Software is unsatisfying compared to other jobs because when you close your laptop and you look around you think: "Did I change anything in the world?" Compare that with doing masonry, where at the end of the day you can look at a wall of bricks that you have laid, and mortared with your own hands. Tomorrow, that wall will be there. Next year, that wall will be there. Can you say the same of your code?
If you have a computer science degree you see the commonality as well as the differences between languages and systems. You pick up new things extremely fast. For all of the negatives against university, that is the benefit.
Maybe we need a memento mori for coders: What code of yours is still running today?
Ask yourself that, one week, one year, five years, ten years after.
Specialization hasn't occurred because everything keeps changing and specialists become either stagnant, bored or unemployable.
The size of a brick was standardized in 1840, then 1970 for metric. Let's get that kind of stability in software before we start specializing
Over my years of hiring and working with other software engineers, I’d say they fall into two key categories:
- Engineers who know how to build apps with a specific set of tools or frameworks and focus on applying this knowledge
- Engineers who know how to model their work in terms of data structures and the algorithms or pipelines being applied to them
The first category can be effective and efficient at applying their knowlege, particularly because of experience and practice with the tools. These are the specialists - the front-ends, the Rails devs, the embedded engineers and so on. They know more about the constraints of their environments.
The second category think more about what they are doing rather than how they are doing it. They are the generalists. They think about React as a functional-ish way to convert state into a DOM tree; they recognise the value and reasons behind various different approaches to development and don’t box themselves in.
I find the second category almost always more effective. That doesn’t mean specialists are without value - you need your embedded engineers to understand that space in depth, for example.
Especially when hiring I like to probe for this during a system design exercise: ask a question and walk through the design of a simple system or pipeline of some kind. If the engineer answers in terms of specific technologies (“I would use Kafka to send gRPC to MongoDB”), they’re usually inflexible. If they answer in terms of techniques and data flows (“I would use a work queue to distribute payloads over the network to backing store databases”) they usually get it.
I reckon changing your mindset a bit can help with the fatigue described in the article. Though I admit I’m as frustrated as anyone else the first time I bring up a new project after a whole an app the tooling has broken and the industry has moved on (looking at you, frontend!)
I call the first three paragraphs the “molecule problem.”
In construction, most components are standardized, bolts, nuts, screws, roof shingles, etc. Even when dimensions vary, there’s usually a standard way to interact with materials. For example, rebar has a defined role and behavior when used with concrete.
Programming hasn’t developed that kind of standardization. Instead, we build software at the molecule level: if statements, loops, data structures, or the atomic level (machine code). Each company or project effectively invents its own “materials and standards” for how things are built.
Imagine if every house being built didn't have standard length screws or standardized threading on bolts, it would collapse in years or take 5x longer to build.
Even when we do adopt standard tools like ORMs or frameworks, it still feels like working with molecules instead of nuts and bolts. Best practices exist, but because ORMs and frameworks are so diverse, even knowing one doesn't make switching jobs fast. Again and equivalent would be that someone putting shingles on a roof in Florida can likely pick up the nail gun and put shingles on a roof in Georgia.
I don’t know what a future where we have our "nuts and bolts" standarized looks like, but I know LLMs are making it infinitely worse because the amount of code being written is beyond exponential at this point.
One of my pet theories about the software industry is that nobody really knows how to manage mature tech companies (YC and the startup world are pretty good at running young companies).
One obvious and disastrous phenomenon in the tech world is resume-driven development: some engineers are highly motivated to put the next shiny tech buzzword on their resume, so they make sure to push that technology at their company. 9 times out of 10 the project and company would be better off by just using the standard, boring tech that everyone else uses. Tech managers should be able to detect this pattern and squash it, but they don't seem able to do so.
Especially since web pages today don't really do all that much more than web pages did a decade ago. Yet the machinery is far more complex, the download size of pages is much larger, and pages are less responsive.
> Just tell your boss that you’re available to teach the new hires — who’ve only ever heard of React — about the joys of server-side rendering.
Everything old is, apparently, new again. Last time I worked on webapps, Javascript was, at most, a minor cosmetic sprinkling, maybe with a bit of AJAX if you were daring. Everything was rendered on the server.
I tend to think all jobs are exactly as hard as the people doing them can handle.
It plays well to the myth of the hard worker. We're all rugged individualists.
It means companies soak as much work as possible from labor. We're all exploited.
And we all accept that without question because it's the status quo.
Another Problem i see with this trend of "everyone is fullstack now" is that no one knows what they are doing.
Basically, you and your team spent a year or so architecting and building something that you know, it's your domain, you know the in and outs of the system. Then your manager comes and says that team X needs a feature that needs a change on your system, but instead of working with them to implement it, we should work on something else and they will do the changes on our system.
Clearly team X has no experience on the stack or the system itself, and they start to create nonsensical PRs that don't even compile, you spent a lot of time reviewing those, explaining them the issues until it becomes a political/ego driven discussion and... congratulations you are a blocker now.
You experience the same working on your own feature, messing with code that you don't like or even understand, creating yamls that you don't have a clue on what they actually do, just replacing string where you see it fit, learning on production.
Of course, you have no time to actually understand what you are doing, is expected to be done by yesterday.
Suddenly, in name of productivity, everyone is working in the less efficient way possible, taking months what could be weeks, weeks what could be days, and days what could be hours.
I know almost none of those things. I've done great as an ML engineer. Sure I have to learn new things sometimes, but curiosity is why I got inti this in the first place
As a software engineer myself, I agree that there are certain aspects of the job that are annoying or mentally fatiguing.
That said, unfortunately I had to learn much more than I had wanted about the work of neurosurgeons and ICU units three years ago.
This made me completely rethink the difficulties I face at work so I no longer complain.
That just sounds like a knowledge work job.
Lots of knowledge. It’s moving. And you don’t know it all. You learn and muddle through.
I really liked your article; it expresses more or less my own personal concerns around technology.
I am certain that whenever the opportunity arises to change my professional direction, I will do it immediately.
To me personally, as a profession, technology is not worth it anymore; it has lost its meaning.
I just use it as my leisure, nothing more.
> Then came DevOps. Some cash-strapped company somewhere decided that now all of this would be handled by the engineers and everyone agreed.
Gave me a chuckle. I don’t think it was a cash strapped company but yea that’s pretty much what happened.
Considering that software is entirely artificial, I would argue that disciplines in the physical sciences are likely much more difficult when it comes to breaking new ground or discovering novel technologies and solutions to longstanding problems.
Just think about how little progress has been made in solving complex issues like climate change, curing diseases or securing sustainable food supplies. These are incredibly challenging, real-world problems.
In contrast, software engineering often comes down to rearranging data—it’s powerful, but not always as fundamentally complex as tackling the physical world's hardest issues.
It's not that all of this is hard. Staying afloat is actually easy by mimicking whatever you see around. I guess it's akin to blissfully selling CDOs all around, right before the 2008 market crash.
It's just that it's impossible to master the tools. We lie to ourselves thinking that we do, but when shit hits the fan, we're as powerless as anyone in the madhouse to figure out what is actually going on. We're all emperors with no clothes.
Individually we know we're naked, but somehow, we think that someone out there isn't. Someone knows what they're doing. No they don't.
Throwing LLMs into the mix will only supercharge the madness.
This whole thing is a collective suicide pact.
Lost track of the webdevhell long time ago. Total insanity changing at the speed of light, so much so that keeping up with it is a stress per-se. SE is harder from inside than it looks from the outside, but that’s also true for most jobs. So the truth is in between like most of the time. I don’t like who says that SE is a comfort job, but I also don’t agree with who says that it’s harder than any other job. But mentally yes, I’ve seen strong people pivoting to SE and dropping like flies 1-2 years later.. but IMO it’s not the job, it’s the environment that gets you
It's not insanity. The specialists are the people building platforms, libraries, and tools. The idea of understanding multiple platforms is not a crazy idea like the author tries to convey.
Not to be that guy, but other jobs are equally crazy. I had to prepare for my electrical engineering certification and I had to learn all european norms, including the ones that were valid when the places one encounters were built. Thar means I need to know which kind of circuit breaker, cable, cabling, etc. was okay to be used in any specific year in the past 100 years. The whole collection of materials amounted to over 240 GB in compressed PDFs and it took me weeks to even skim the surface. Norms are highly interdependent, a bit like hypertext without clickable links. And the best thing is that some things they just don't specify. We had a nuclear physicist in the team and he was complaining about the complexity.
I love the simplicity and clarity of software engineering sometimes, because here many of the problems are by our own making.
Being full stack used to be more exciting to me but with the front end still changing after what felt like we had reached some stability, I have decided I can’t do it anymore. It really caters to a particular type of early startup engineer who is constantly doing greenfield and creating new repos. The issue there is that means you’re constantly poor because you’re always at early stages of funding - and in this market and the market for the next few years… good luck seeing any of those options become liquid.
It’s just not a sustainable path for someone who has to pay a $3m mortgage in Silicon Valley. It’s for the already rich to tinker and the young who can live in a room in a 6bd house.
My career is entirely built around full stack and it’s no shock that I’m back to being penniless. Worked so hard for nothing. Specialize and join big tech. These early stage startups suck and aren’t worth it.
The majority of companies don't want "engineers", but settle for the necessary evil of who they believe are totally fungible "resources". Given how many programmers get into software development for reasons that go against human fungibility, they have to be tricked by the propaganda of being referred to as engineers.
Related: https://www.stilldrinking.org/programming-sucks
> Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro,1 you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”
> They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.
Depending on your role, company, and tech stack there is a lot to learn in software engineering. It can get pretty complex, confusing, etc. This is partly why I like to. I like a challenge. A puzzle. I like to learn new things. But sometimes it’s also very frustrating.
I've met (maybe) 3 other developers, in my life, who have used all the listed technologies. Most will either use ssh or use react; seldom ever work w both.
Other then all the frameworks you need learn, if you are not an expert in a specific field, in my experience, you are completely disposable as well.
The insanity of modernity, progress and change.
Very much a case of “grass is always greener”. I work in pre-sales at $FAANG and would do everything to take a 20% pay cut and go work a low pressure SWE role flinging golang around.
My lord… the lack of political maneuvering, fiefdom building and defending, workaholics chasing deals and responses through the weekend or first thing at 5:30am when they wake up…
I did a short stint as part of a pro services team at a SaaS once. Some of the most fun I’ve had, moderate to low pressure, interesting but not overly challenging problems, mostly a creativity challenge not “configure systemd” challenges.
Now I know whT you’re thinking: “oh but here in SWE land we have all the problems you mentioned too!”
Yep that’s my point.
not many professions allow me to work from home in my underwear for good sums of money
Article completely forgot what's really important: software is supposed to provide value to users so SWEs need to understand the domain and design a system that does so. Some might say that it's the job of the business analyst but the BA doesn't design the system or feature.
So happy humans will be able to stop using their brains soon due to AI !
Hot take: I see many comments hint at a pessimistic attitude in the essay. I think this is unjust because it felt for me like the author is passionate about the profession. Otherwise the humor wouldn't be there or the author wouldn't have stuck around long enough to see the evolution of the field up to the point of this vibe coding era.
I mean, my job title is currently "Full Stack Software Engineer" and I manage to get by only writing Typescript. Yes I have to do all of the things mentioned in the article: React, CSS, AWS, Docker, Databases, etc. We do a lot of greenfield so I'm the one setting these things up.
But it's basically all in the web paradigm. I don't have to work on mobile apps or drivers or something. So I think "Full stack" isn't really a good descriptor. I'm more so a "Web developer" than anything. Which is complicated, yes, but if you were a mobile developer your world would be completely different and have its own software ecosystem.
This is why we pay experts a lot of money.
For a profession that has improved the world so much, we are a pessimistic lot aren’t we?
I mean, my friend's wife is an eye surgeon. My husband's cousin is a pediatrician, with neonatal specialty. I'll take software engineering.
Yeah, turns out you need to provide value in exchange for your salary. So since there is 0 physical strain, you get mental strain.
This is like writing an article about "The Insanity of Being an Adult in Modern Society" because you have to think about insurance, dishwashing, clothes, food, taking car of your car, your hair, your health, your finances, etc... Yeah. No shit.
All this is still way simpler than designing and building bridges, for example.
This was a fun read.
We’ll keep raising the amount of knowledge needed to be employed until it’s no longer sustainable. This is just the nature of capitalism: extracting as much value from someone’s salary as possible.
uhh just use vite
This entire post is just complaining how this incredibly easy career that requires no credentials, pays incredibly well, and is trivial to enter sucks because you need to deal with uncomfortable things every once in a while.
> Being a software engineer is tough.
No, it isn't. Software engineering is one of the easiest careers. We are so coddled that we think what is described in this post is tough, that alone is evidence of how not tough our career is.