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.
I’ve had a wildly successful career in tech where I’ve gotten to do, what to me are crazy impressive things (I don’t want to brag about here but you may have benefited from some of it, certainly all of you have done more impressive things than me, and thank you for that) and I don’t regret it a day, but as someone that’s worked in those " normal jobs", other than factory work I found the jobs themselves WILDLY more satisfying than anything I’m doing today.
Tech work did used to be a lot better and I still love learning new things but if I could make a few hundred grand a year and never do another OKR and garden I would take that so quickly you can’t even imagine (actually I’d take it for a 100 grand year).
Now I’m old and I have people that depend on me, so I do the OKR shuffle and play all the politics, and even lead on new tech that I think is being misapplied in the org but hell if I can get anyone to believe me and just use SQLite. But if I was single and had no kids, I’d gladly give up the 6 figure lifestyle to get my hands in the dirt again or even get through a hard rush in the kitchen with the team, there was so much more worthwhile about the jobs I had before, it was just the benefits sucked and couldn’t support a family in the USA without a lot of luck and sacrifice.
I think maybe it is possible that most of you that think these other jobs are so hard just didn’t come from a family where they were normal, but for me they were, and I don’t see anything wrong with them other than the pay and the benefits. They’re honest work.
That said I’d be ok if technology companies just let us do our jobs without all the bizarre AMA, self help talk and bizarre behavior from management.
The thing is, it's a job that needs creativity, spontaneous decision making as well as personal responsibility for those decisions. It's a real easy job if you don't need to take this responsibility (e.g. those who come after me when I am long gone have to deal with the consequences). It becomes a hard job the instant that you have some passion or ethical concerns that drive you to create software that holds up to your own high standards and requirements.
I think that's what makes it so hard for many. We are incredibly passionate (why would we be on this forum in our free time otherwise) but we constantly have to betray our own principles to make it work or stay employed.
I loved it and got hired internally the second try. If I tell you we were called 'flight dispatch officers' you might be able to figure out which airline that was.
In about 12 years the airlines headquarter and ops center moved to the Midwest so I opted to stay in NY and go to school for retraining. I choose WAN admin because there were no coding schools. Here I got my A+, MCSE, MCSD,CCNA,CCNP,CCIE. But in the meantime I got heavily involved in scripting and coding. So my first job was perl, PHP and SQL developer and I've been doing it for quite some time now. I must say this is the most liberal and appreciative career I've seen. As long as your work is done, you can be anywhere. Besides the great salaries, benefits, (,ok no travel) these jobs are fun. Good choice.
I do get pleasure when building software, but like many others I also dream about starting a farm to diversify my income and get some physical work regularly.
I worked on a farm and I find this romanticising outright ridiculous because I don't think a lot of you understand just how hard is it to actually make a living from the land.
Financially it is great, no doubt about that. Take away the money and it’s a terrible job - despite loving programming, design, and engineering. And I mean, I love design, programming, ambiguity, and the constant learning required.
My largest source of sanity in this career is to spend extra time at work doing the things that I love in my position. Ironically, I get high performance ratings because of this - but have to fight to spend my time on it.
Modern tech companies and culture suck, even the best ones that I praise. I can’t even blame anyone at this point because it is hard and I have not started a company that tries to be better. I'm not even sure I would do better, to be honest.
As someone who only delivered newspapers and worked in a video store as a kid, before landing my first developer job, I’ve always had this impression.
And I could never convince myself to go work on a farm, or in a nursery, or at a gas station, because working on my computer, often from home, always paid better.
I feel like most computer problems are made up, and so many real-world problems draw in your emotions and senses.
Now before you get out your tiny violin, I'm not saying other people don't have it worse, or that anyone should direct their sympathy towards us at all. I guess it feels more like a golden handcuffs situation.
I think you just described most people who aren't SE's. The only difference is that they can't land better paying jobs.
Are you sure?
Compare working in big law to big tech, and it will be plain as day. And I am not even getting into the baseline requirements to get there (undergrad from a good school with great GPA, LSAT, a top law school that is gonna cost you a pretty penny, hustling for internships, BAR, etc.), which SWE as a career has pretty much none of. The overall work-life balance difference alone is crazy.
Not everyone works in big tech. A lot of devs worldwide work in mom and pop shops, legacy businesses, or various consultancy/body shops. Big-tech workers are the exception, not the rule, except maybe for the US workers.
But most jobs are tough - in some way.
Software Engineering is one of the most information-volatile industries in history that I can think of.
You have to aggressively keep pace with potentially, and I’m guessing here, the fastest shifting industry in history in terms of practices and knowledge and improvements.
Not only that, it is constant failure and obstacles - bugs, frameworks, features, platforms, what have you - and constant layers of abstraction. A lot of the time you cannot visualise any outputs.
Software Engineering is a highly skilled industry, and probably the most competitive industry in the world, with a very high rate of uncertainty and layoffs and change. We are working with some of the most complex systems created by man in history.
I don’t think you can make a broad generalisation that we are coddled lol. Software Engineers in the USA in certain population centres earn a large salary, sure, but look overseas and comparatively that is not the case.
Seriously, by what metric is Software Engineering one of the easiest careers? I’d like to hear your viewpoint because I think it’s so off-base that I must be missing something.
It has its definite perks like work from home.
But Software is up there as one of the toughest knowledge-worker industries there is.
There are much tougher careers like anything Electrical Engineering, but by no yardstick is Software easy
It may be fair to say that it wants to work its way towards that as the industry matures, but that hasn't been the case. People have been able to make insane amounts of money in software. You cannot make money in a competitive industry.
One friend had just finished a 3 month program to certify to fly a certain type of airliner. They probably had more intense study and testing in 3 months than most people do in a 4 year undergraduate program, SWE included.
-Those tests are no joke, but saying they are more intense than a 4 year CS degree is ridiculous. Also the major airlines you can compare to FAANG, and many people study for 6+ months to pass those interviews - Airlines are union jobs. If you get them you aren't getting fired unless you try to do something really stupid. - There isn't any wondering if you are doing a good job or not , and you don't take any work home. - Regulations change or you can switch planes, but the career is leaps and bounds more static then SWE.
Net net is that they are very different jobs. SWE is a great gig overall but I take issues with people saying how much harder or easier it is than other jobs. "It depends" is the answer.
An airline pilot is "grey collar".
https://en.m.wikipedia.org/wiki/Grey-collar
https://www.forbes.com/sites/jackkelly/2024/02/01/gray-colla...
Out of 10 people off the top of my head, most of them have been laid off in the past 5 years. For the ones that found new jobs (that I know) they are not satisfied with their pay.
I've talked my pay vs theirs and am shocked. Almost a decade worth of experience, making what I was making 4 years into engineering, in non management positions, and worse job security.
I could be mixing up programmer vs SWE. I just call them techies.
Industries with difficult certifications tend to protect those when awarded. It’s a grind to get in but then the employment is easy and lucrative.
This is the promise of a career as a pilot or doctor. (Inb4 doctors do hard things)
In contrast, industries that are lucrative but have a low barrier to entry (sales, real estate, etc) tend to have direct performance competition.
In software by the time you finish your 3 months course the tech is considered obsolete.
Not just Frontend. Backend can change on a dime.
Elastic/MySQL/CockroachDB is using different license that's incompatible to AWS. We have to switch our stack!
Kafka is out. It's all about Iggy! What do you mean it's different language? Learn it!
Things can be hard in different ways. After coding for whole week doing garden work can almost come as a relief.
30 minute walk before work, gym after work, outdoor/physical hobbies, intentional healthy eating, etc...
These, to me, aren't difficult and end up providing a net benefit on your life far outweighing the effort required to implement them.
I never had to work free overtime as a postal clerk until 1AM because of a production bug in deployment
I never had to figure out how to fix a fry machine on-the-spot at McDonald's because the person who normally fixes it is on vacation in the mountains
I also never had to learn brand new ways of driving cars every few months as a valet driver.
Maybe your software engineering job is easy but, this is the most stressful job I've had. And i'm not your average HN'er that's only ever known being a code slinger
I've worked construction when I was younger and wouldn't want to be still doing it at my age, it was physically harder but I wouldn't say it was tough work and at the end of the day I'd leave and not think about it again until I showed up the next day.
Have you ever heard of a modern software engineer who landed in jail because their error was part of an incident thst costed others their lives? Typically software errors are shrugged away as if they are extreme wheather events thst nobody can change.
Creating usable elegant, efficient, reliable, testable and maintainable software isn't trivial, but it is doable and the consequences to not getting it 100% right are usually comparably mild.
If I fuck up a part of code I usually produce a crash, patch it and I am good to go, if I select the wrong cables and put them into a building, I either cause a fire or I have to tear the whole building open to replace them, and let's not talk about civil engineering..
I remember sitting in a class of 30 people where people had over 30 different solutions to a complex load calculation of the kind that could kill people if it was realized.
Especially love the classic “Well, that’s not normal, only what I am familiar with is normal, because everybody thinks like me”-flavored responses. Obviously it’s not normal to work overtime or crunch because I’ve never done it. (Just ignore https://en.m.wikipedia.org/wiki/Crunch_(video_games) and go back to shittalking SWE.)
Viewer: “Streaming is so easy, you’re basically not even working, streamers are so privileged.”
Streamer: “Can you act?”
Viewer: “No, but what -“
Streamer: “Ok so you can’t act. Have you ever tried acting out a play, but it’s 6 hours long and also hundreds of people get to shout obscenities at you, and also you’re sometimes obligated to respond to their disturbing comments completely ad-lib without breaking character, and also you have to be juggling at the same time?”
Viewer: “… well I still think <INSERT JOB> is harder”
It doesn’t take a genius to realize there a different dimensions of difficulty and yet somehow many people can’t
A developer, programmer, software engineer, call this category of work however you like, it uses the brain at such relentless limits, implicitly or explicitly depending on the problem a person it's currently working on, it takes an incredible amount of effort to relax your mind at the end of the day.
I remember working on a very difficult project for a customer and I would sleep for 4-5 hours per day until I deliver it, and by the end of the project I was so exhausted that I had to take a whole week to cool down my brain and relax my body.
It took me a whole month to fully recover!
I have worked as a construction worker with my father and I know how to grow my own fruits and veggies; I know the struggles with those things...but trust me, you cannot compare the two by any means!
Using your body exclusively it can be tiring indeed, but at the end of the day, you will have a nice shower, eat and rest well, and the next day you will be good to go; whereas with using your mind exclusively can be so dangerous in so many ways!
At least, that's my case.
But if it paid well enough and had better job security, I’d much rather be building houses all day.
I worked in retail for a while and made it to supervisor. It was much easier than being a software engineer, the pay was just crappy.
Software engineering is definitely up there in terms of mentally demanding jobs, it just pays well.
They are all easy and hard in their own dimensions.
Software engineering can bring immense joy, but it is often a hard job to do. While it may not be physically demanding like some trades, it is often intellectually demanding and stressful, especially with tight deadlines and evolving technologies.
You know that intellectual tasks, such as those found in software engineering, can require significant mental effort and may burn more calories than some physical jobs due to constant cognitive engagement and stress?
Even children could make it to the top of the world in this activity of intense sitting.
Clearly, being a truck driver, construction worker, farmer, fast food employee is easier for them, and software engineering is harder, otherwise they would have switched to the easier and better paying job.
They can't do my job.
I won't do theirs.
Just because the stress is mental and not physical, doesn't mean it doesn't exist. Ever heard of burnout?
Yes, it is. Tough is relative.
There is no "we" to be coddled, only your flawed perception of a difficult-to-grasp, heterogeneous whole.
There is no "we" to form a single impression of what is described in the post.
Rhetoric isn't evidence.
A doctor can’t give you aspirin without 2+ layers of administration to do the medical coding. I can only guess what bullshit liability insurance and licensure entails.
Knowledge work is usually paid because it isn’t trivial.
True that the other jobs are usually treated very poorly, though.
Yes it is. I can name a number of careers that are easier. Start with accounting or tax prep or mechanic or welder or barber or nail salon anything, on and on. Ridiculous.
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.
Would you expand on this please? Especially how it differs to agile. Very keen to learn alternative approaches, as a tech lead struggling struggling with the company's half-baked attempts to go agile.
When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform.
So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded.
And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team:
We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing).
I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions).
I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it.
For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own".
And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code.
For many engineers (and me of course) this can be the most rewarding way to work.
The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?"
They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)
Have you read product thinking, the lean startup, agile estimating and planning ?
How do you expect to leverage a methodology if you don’t do a deep dive and become an expert.
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.
Browsers do have this component, but that's not the reason they exist.
Some subset of added complexity is justified as the problems we’ve tried to solve have gotten more complex.
Another subset is added complexity for the reasons I listed (no good feedback loops to prevent it), which is imo not good. I also feel that this subset is larger than the first subset.
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.
Whilst I somewhat agree with the op I think it’s as much a hiring / resourcing issue. Hiring managers often want experts in the tech stack and domain and overlook mastery of similarly complex topics as a good proxy for ability to pick up whatever their specifics are. And the expectation of that person also having enough generalist knowledge to do gui, qa & infra as well as the rest of the engineering process.
In that regard as cto are you part of the problem or aiming to be part of the solution ?
Managers of humans build artificial empires to climb the ladder.
Managers of machines build artificial complexity to climb the ladder.
Bad for the parent org, but necessary to pad the CV.
Yet doing everything from first-principles is not viable, nor is focusing only on non-functional requirements. The solution is engineering leadership that values code not written, dependencies not added. They wince at a big commit. Every component must pull its weight. They use every part of every component and dwell in the community of it. If they don't have time for a new community, they hire a new person who does, and they may represent a new specialization on your team.
A solid team needs 5 people. CSS and Figma ('designer'). SPA ('front-end eng'). The appservers, database and outward api calls ('backend eng'). Infrastructure and CI/CD ('devops'). Finally, you need a person who owns goals, measuring past and articulating future, and take point on user and business comms ('product'). Project management can be a part-time role of anyone on the team, but fits well with product. I do not think a single human mind can be a designer/front-end/back-end/devops role and do a good job. They just don't have time to learn and stay up-to-date with all of that, and it requires an untenable amount of context switching.
I was going to add that the engineers themselves do (or should, in a healthy organisation) have the mandate to knowingly choose not to bring in artifical complexity where it's not useful or required.
But then I thought that in a lot of situtations perhaps the engineers aren't really 'Knowingly choosing not to' but 'Unknowingly choosing to' bring in that complexity, because the volume of content and mindshare that goes into proposing new and alternate ways of working and tools that aren't actually different seems to dwarf the amount of information around fundamentals and things that don't change as often.
So perhaps any accountability really should go as much to CTOs, open source developers trying to make their mark, influencers.
It seems like what we need is a sort of an integrated virtual machine for each application. The OS provides a virtual CPU+memory machine, but that needs to extend to virtual filesystem, peripherals, displays (which the OS would draw into a window), network with user-limitable urls, etc. This would prevent apps from misusing the filesystem, enable users to limit surveillance network requests, and simplify graphics.
I think there is both an inherent complexity and artificial (or 'introduced') complexity in software.
Inherent complexity comes from increasing expectations over what kinds of software we want to write (the evolution of the web and browser 'features' since its initial inception, the kinds of interaction on mobile, tablet and desktop devices) and _how_ we want to write that.
Some amount of higher-level tooling is almost a necessity because the absolute amount of lower-level things needed to make the more powerful abstractions work is too high to deal with practical. Want to write a cross-platform fully-featured-with-animation UI toolkit with just the raw hardware in your desktop? Fantastic exercise for learning, but you're almost guaranteed to start reaching for higher-level tools at some point in the journey.
The growth in artificial complexity, however, comes from so many places (including all the ones you listed).
Sometimes it's from processes and ways of working that are introduced (I sure hope you do fully automated releasable builds including management of the computers that do those).
Sometimes it's from socio-technical problems (working in a single shared code base and having to coordinate changes and releases? Surely it would be easier for teams to never have to talk to each other and just release small things independently...).
Sometimes it's from an approach to building software that is perceived as better, easier and faster (shipping a desktop application? Wouldn't it be so much easier to just bundle a full UI layout engine, scripting language interpreter, hierarchical appearance control syntax, portable bytecode interpreter and some application code that was itself compiled from a _different_ language so it could be interpreted by the interpreter you actually shipped...)
Sometimes it's from system design approaches that are pushed as 'best practice' and introduced without necessarily understanding whether you ever had the problem they were intended to solve (please, tell me more about how your relatively small ecommerce application needed to be event based in order to 'scale up').
Sometime it's because the handful of companies shipping acceleration hardware have practically zero commercial incentive to standardise on an API for writing programs that can run on said hardware, giving us a world with four (at least) slightly different syntaxes that all sort-of-mostly accomplish the same thing while being awkwardly different.
I could go on...
Not that some of the artifical introduced complexity doesn't sometimes solve actual problems or be an overall-useful thing to have. No criticism here on introducing software-based processes to formalise things, improve software quality, and so on.
But it's useful to keep in mind how much of the complexity is introduced to improve overall processes versus 'solving' for some local maxima by adding more tech without the overall software quality improving, with the end result being we've made our own lives worse in some way, without measurably improving the resulting application.
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.
It reminded me of that KotH skit "- So, are you Chinese or Japanese? - Huh, I come from Laos and... - Chinese, or Japanese?".
Compared to "programmer" or "developer", it just sounds like gluing bits of CRUD together and making it seem more advanced than it really is by way of fancy title. "Prompt engineer" being the natural next step.
Sorry if you're called/call yourself a SE, (probably) nothing against you personally :D
I've never touch JS in my daily work, or html, or php, or anything like that. Also no golang or whatever the cool kids are using. When i said i'm developer, people always assume i'm some web developer lol. Lady i know how tcp/ip work, but anything higher is a strange land to me.
I've worked at companies where everyone, all the way up to the SVP (who reports to the CEO) is still very sharp technically. Meaning, the SVP and everyone below them could legitimately pass the Senior Software Engineer interview, or at the very least speak intelligently about the sw architecture, the reasoning behind the technical and design decisions made, performance trade-offs, security, and so on. If you've never worked for a place like that, it's almost hard to believe what it's like.
I've also worked at a (fortunately only one) company, where as a leaf-node employee, my first level manager was effectively tech illiterate. Those kinds of places need their individual engineers to all 1. have good tech skills, and 2. have those rare communication/translation skills that translate tech concepts/problems into business-speek.
At most companies, the point at which a technically literate employee reports to a tech-illiterate employee is somewhere up the management hierarchy--usually around "Director" level. Wherever that point on the org chart is, that person's direct reports are the ones who need to have those tech-to-non-tech translation skills.
I don't mind an illiterate Executive when it comes to basic manufacturing, cosmetics and so on - but when it comes to STEM subjects it becomes a dangerous gamble - especially when it comes to recognize a strong vs weak player.
Too many times I've seen weaker players get bumped up as the executive in charge is somewhat incompetent...
I've been lucky as my family forged my communication skills at a young age - but these days this is rare and I see extremely competent young players get sidelined quite rapidly... Hope is a mystery, but can be found.
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"
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.
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
- 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!)
Not always easy, but that is the first thing that comes to mind, no matter the context.
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 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.
Are they? I just saw a job ad for a YC start-up that proudly explained that "We don't do PRs. We push straight to main multiple times a day." and that "We work onsite, 7 days a week"...all for a company that works in a heavily regulated industry.
That's how you get them pyramids built! Onsite weeklong lashings!
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.
Until rendering on the client was cool. But then search engines hate that, so maybe we'd better render on the server after all but then also re-render everything on the client ('reconciliation'). Ah wait, what's this? Now you can opt for 'partial pre-rendering', because it wasn't enough to send HTML from the server and make more HTML in the client, now we can mix client-only HTML rendering with reconciled server-rendered-client-re-rendered HTML.
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.
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.
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.
Lots of knowledge. It’s moving. And you don’t know it all. You learn and muddle through.
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.
Gave me a chuckle. I don’t think it was a cash strapped company but yea that’s pretty much what happened.
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.
The world has had the means to globally end poverty and hunger for decades, but we haven't. We know exactly and quantitatively what is needed to meet climate goals, but we won't do it. Groups of people who have been murdering each other for generations could choose to stop tomorrow and live in peace forever after, but they refuse. These are as far from technological problems as one can get.
But also think that is what makes dev work so difficult, because our "build times" are so short. Because we aren't limited by the real world, we can build our entire system often in seconds and then test them, which allows us to move fast and generate enormous amounts of complexity. While with physical sciences, during an experiment, the "build time" for their tests is typically much slower, often taking hours or days, so they can only deal with a limited number of variables and information at once.
Also think that is what makes software engineers often good at working in other technical domains, we have a lot techniques and hands on experience in dealing with large complex systems, much of which carries over to non-software problems...
(... but my saying this is admittedly half theoretical, because personally, haven't actually applied this to an actual science field, only to things like small construction projects and to the field of music theory, and yeah, super helpful)
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.
Personally, I don't understand how people get by in web without knowing SQL and JS + some other language.
The idea that you don't understand the flaws that SQL can introduce into a system, and have little ability to debug them is baffling. How can you actually be productive when you only control a tiny fraction of your application.
I love the simplicity and clarity of software engineering sometimes, because here many of the problems are by our own making.
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.
> 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.
You are no longer masters of your own destinies.
You have been sold out, and what ever is left of you is a sell out.
You will be broken. Only in the darkness of minds eye, where no one will hear your screams, they will break you and remake you, your thought controlls, for their games. For they are as god over you and they are the voices in your mind. The world will scorn you and turn upon you in your desperate hour, and in time it will happen to all of them.
We are thought controlled.
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.
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.
My wife is a pediatric ER doctor. She makes about the same as I do as a staff engineer at a big tech company, but she works 11-12 shifts a month (8-9 hour shifts).
The kicker is that her hours are terrible and she has to deal with distressed parents, and sick kids, and the occasional very bad outcome. It also took her 14 years of training and $200k in debt to start making real money.
But the social status of being a doctor really shouldn’t be underestimated. She has so much more autonomy than I do. Her job is as secure as a job can possibly be.
And interviewing. Interviews are basically a hospital flying her out and wining and dining her to try to convince her to take the job.
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.
Your clients don't change the specs half way through and expect you to provide an accurate estimate and at the same time, don't intend to pay you extra. You can forecast the cost of building to a very accurate degree because all bridges are more of the same, unlike software which by definition,is new every time because each time the requirement is different.
And so on.
I know because I work in civil engineering software field.
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.
I'm not so sure about that. "Easy" isn't usually an attractive trait in employment. People by and large seem to need some kind of feeling of fulfillment to compel them to show up day in, day out. It might seem difficult to the neurodivergent who are disproportionately attracted to software engineering, but to most people it is simply uninteresting work.
