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 gotta say I worked as a farmhand, waiter, fast food manager, line cook, grounds crew (by far my favorite job, it was at a university and I got to do everything), plumber, electrician, day laborer, delivery driver for many things and I did a couple stints in factories all before I ever owned a computer (didn’t come from a background where you had one, I got my first one and it clicked, within a year, I was working at an ISP configuring Qmail and Bind, everyone just assuming I had been living with a computer since I was born).
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.
I agree completely, but I always struggle with how to characterize this. Software engineers are generally pretty privileged, and even relatively mediocre ones can pretty easily break $100k per year. But, work in this field is incredibly unsatisfying and frustrating. For sure, none of us would drop what we're doing to go work in retail. It's not as if we're suffering in any strict sense; no one is really allowed to abuse us, our jobs aren't ruining our bodies compared to something like construction. But, many of us kind of hate it and only stay because of the money, and would work anywhere else if the other jobs paid well enough.
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.
Agreed. We don’t even need to reach for the apples to oranges comparisons with manual labor jobs, just gotta look at anyone working another highly paid white collar job.
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.
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
I was talking with friends at a party last night about their white collar jobs, and yeah, SWE was the easiest and cushiest job in the room by a mile.
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.
How old are you? You get to your forties as a software engineer, and you'd realize how taxing this occupation is. Your eyesight may deteriorate; your neck and spine may experience chronic pain; you could develop digestive and kidney problems from prolonged immobility; you might get hemorrhoids and carpal tunnel syndrome; your immune system could weaken from constant stress and may cause depression. The number of different "solutions" for solving ergonomics alone is evidence of how difficult a career as a software engineer is, both - mentally and physically.
Thank you. If I complained for one second about my short houred, high paying, long vacationing, low-education requiring job around any of my family I'd get laughed out of the house.
I don't agree at all that it's the easiest of careers.
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
Being a software engineer is a piece of cake compared to other engineering disciplines. Sure wrangling complexity and a shitton of knowledge is a lot of work, but most other engineering disciplines have much higher stakes, require you to put yourself out there and can land you in jail if you don't do your craft as you should.
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.
It irks me to no end how much software engineers love to self-flagellate. If I had never met a software engineer before and just read HN my takeaway would be that all software engineers are privileged assholes who live in a bubble, get paid way too much, on top of that cheat on their hours, and provide functionally no value to society. In real life this is obviously not true.
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.)
“Appreciate how good you have it” doesn’t help the exploited be any less exploited. Instead it serves to nudge the comparatively-less-exploited to feel guilty enough to stay quiet.
I've had quite a few jobs. I've been a computer engineer now I'm a software engineer. These are the only jobs I've had where I felt I could be fired for performance.
That's not true at all because an eight hour shift of real coding work easily wears out the brain, making the entire evening useless. It is a sedentary job requiring excessive caffeine, with the result being that health deteriorates slowly but surely due to the job.
A bridge engineer would need to know how to design a structure based on first principles of physics, nationally recognized reference documents, state agency published standards, state agency unpublished standards, agency project manager preferences, internal management preferences, and do so within a complicated project delivery protocol. These don’t all agree. Oh, and you can be sued and lose license to practice if you’re wrong.
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.
I think there is something to be said to how many people dislike doing what we do as software engineers. Forget about the people who like this job, there are so many looking at me sideways every time I describe what I do.
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.
> 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.
I disagree. We add complexity largely (but not exclusively) because they fix problems. The entire point of a web browser exists to solve the very complex problem "How do we run arbitrary code on client hardware in a way that's safe for all parties?"
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.
There’s definitely plenty of self indulgent gold plating engineers out there. And cv driven development and mortgage driven development.
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 ?
No, job security is why the code base is poorly written and uncommented. Pile of technology growth (POTG) is caused by a legitimate desire to avoid future pitfalls. Above all, application devs do NOT want to be in a situation where they must use first principles to keep the app alive. What they ignore is that the benefit of an added component is 1 but the cost scales as N^2. Call it "the integrator's dilemma". POTG via the integrator's dilemma is exascerbated by easy, fast dependency managers, FOMO and willful ignorance of managers to any concern other than "ship on that date".
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.
That's a terrible take to blame the engineers for the complexity, not the ever changing specs, headcount inflating and managers that have no idea what software engineering is. I would blame the CTOs.
> CV building for FAANG type job hunting, job niche building and job security self-indulgence, and a fundamental disregard for maturing the industry
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.
> 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.
I noticed that for web developers "developers" is a synonym of "web developer". Being a non-web developer, I find this at the same time mildly amusing and offensive.
No kidding! But "software engineer" also makes me think web dev.
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
this, i'm FW engineer, most of my time is spent writting code, so i can classify myself as SWE i guess.
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.
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...
When interviewing, one of the ways I try to discover how good a particular tech job is: How far up the management totem pole does the "tech illiteracy" start?
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.
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.
Facts. I worked on a retail system that was nearly 1M loc and the company went bankrupt. Poof all that work gone. That was a real epiphany for me, and also the start of keeping a healthy distance between me and my work. Although software can be very rewarding, it is just a job.
I think specialization still occurs in our field but it’s more domain driven than tech driven. I know folks that have built their careers in banking, auth, crypto, billing and healthcare. In each of those cases your language will differ but there are always similarities in that domain.
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.
The nuts and bolts will be embeddable DSL’s, they are the only code which does not rot. Put them in a hierarchy with one compiling down into another or several and you have your building.
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.
> YC and the startup world are pretty good at running young companies
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.
Resume driven development is the flip-side to stagnating compensation that falls below market rates over time. If an engineer knows they will have to look for a job every so often they will try to bolster their resume in an attempt to differentiate themselves from all of the other applicants.
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.
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.
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
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.
Technologically speaking, climate change, world hunger, poverty, peace, etc are all solved problems already. Unfortunately these aren't technical problems. They are social, political, and economic in nature.
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.
Agree that physical sciences, on one aspect, are inherently more difficult, Especially in research, the problems are more difficult to solve because they are limited by the physical world.
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 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.
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.
I agree, I've met a few engineers in my career who believe working in more than one language is a bad thing.
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.
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.
> 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.
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.
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!”
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.
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.
Ophthalmology is one of the cushiest and best paid specialties.
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.
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.
No, building bridges is a lot simpler because we have a set of coding practices to follow ( eurocode, ACI, British standards and whatnot). The performance of the buildings follow the deterministic Newton's laws, and you even have software packages written for that.
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.
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.
It's not an "incredibly easy career", otherwise everyone would do it. There are always some people who find themselves in positions where they can continue to get paid for doing basically nothing and software is not excepted. But many of us had to work hard to get here and continue to do so.
abxyz|11 months ago
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.
trchek|11 months ago
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.
everdrive|11 months ago
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.
filoleg|11 months ago
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.
purple-leafy|10 months ago
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
dharmab|11 months ago
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.
iLemming|10 months ago
tiberriver256|11 months ago
batty_alex|11 months ago
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
atoav|10 months ago
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.
subjectsigma|10 months ago
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.)
grafmax|10 months ago
chrsw|11 months ago
smackeyacky|11 months ago
OutOfHere|11 months ago
unknown|11 months ago
[deleted]
coldtea|10 months ago
Just because the stress is mental and not physical, doesn't mean it doesn't exist. Ever heard of burnout?
mpalmer|10 months ago
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.
dughnut|10 months ago
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.
Fire-Dragon-DoL|11 months ago
True that the other jobs are usually treated very poorly, though.
NL807|11 months ago
Supermancho|10 months ago
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.
unknown|11 months ago
[deleted]
grahar64|11 months ago
unknown|11 months ago
[deleted]
unknown|11 months ago
[deleted]
JKCalhoun|11 months ago
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.
n4r9|11 months ago
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.
travisgriggs|10 months ago
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.
hx8|10 months ago
weego|11 months ago
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.
bdbcbc|11 months ago
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 ?
intelVISA|10 months ago
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.
simpaticoder|11 months ago
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.
owebmaster|11 months ago
sunrunner|11 months ago
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.
maeln|10 months ago
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.
richforman|10 months ago
taway1874|10 months ago
ginko|11 months ago
sebtron|11 months ago
kilpikaarna|10 months ago
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
mrheosuper|10 months ago
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.
gundamdoubleO|11 months ago
SebFender|11 months ago
ryandrake|11 months ago
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.
mdaniel|10 months ago
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"
ninju|10 months ago
https://en.wikipedia.org/wiki/Peter_principle
anarticle|10 months ago
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.
le-mark|10 months ago
grahar64|11 months ago
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
_fat_santa|10 months ago
matthewmacleod|11 months ago
- 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!)
smitty1e|11 months ago
Not always easy, but that is the first thing that comes to mind, no matter the context.
bearjaws|11 months ago
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.
atmavatar|11 months ago
hdkdicnsnjes|11 months ago
d_burfoot|10 months ago
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.
phonon|10 months ago
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.
jack_h|10 months ago
kevinventullo|10 months ago
Animats|10 months ago
rsynnott|11 months ago
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.
sunrunner|11 months ago
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.
drewcoo|11 months ago
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.
basfo|10 months ago
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.
orzig|11 months ago
dondraper36|11 months ago
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.
Havoc|10 months ago
Lots of knowledge. It’s moving. And you don’t know it all. You learn and muddle through.
stefanos82|11 months ago
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.
arealaccount|10 months ago
Gave me a chuckle. I don’t think it was a cash strapped company but yea that’s pretty much what happened.
zikduruqe|10 months ago
chiffre01|10 months ago
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.
yummypaint|10 months ago
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.
computerdork|10 months ago
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)
unknown|10 months ago
[deleted]
vdupras|11 months ago
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.
moktonar|11 months ago
charcircuit|11 months ago
bearjaws|11 months ago
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.
unknown|11 months ago
[deleted]
atoav|10 months ago
I love the simplicity and clarity of software engineering sometimes, because here many of the problems are by our own making.
bradlys|11 months ago
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.
ravenstine|10 months ago
Terr_|10 months ago
> 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.
koinedad|10 months ago
unknown|11 months ago
[deleted]
karpatic|10 months ago
TriangleEdge|10 months ago
nwhnwh|10 months ago
overu589|10 months ago
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.
holografix|10 months ago
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.
cornhole|10 months ago
layer8|10 months ago
hasbot|11 months ago
zadler|11 months ago
theutopian|10 months ago
65|10 months ago
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.
ldng|10 months ago
singpolyma3|11 months ago
rektomatic|10 months ago
hzay|11 months ago
sarchertech|11 months ago
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.
Jean-Papoulos|10 months ago
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.
regularjack|10 months ago
nsoonhui|10 months ago
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.
m2has|10 months ago
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.
dmvjs|10 months ago
edwardoelliott6|11 months ago
[deleted]
clircle|10 months ago
[deleted]
theutopian|10 months ago
[deleted]
ramdemo90210|11 months ago
[deleted]
rdx90210|11 months ago
[deleted]
rdxdem90210|11 months ago
[deleted]
tekla|10 months ago
globular-toast|10 months ago