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 think the answer is that it depends. Software engineering is incredibly hard if you are a perfectionist who wants to make efficient, secure and maintainable software. But most probably it is not even possible to be that perfectionist and stay within any given budget. And the requirements are most often not your own.
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.
> 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.
This is the hardest lesson to learn for a lot of software engineers. By nature, computers are unforgiving, so a lot(most?) of us are wired to do things 'right'. The apparent fundamental incompatibility of that mindset with modern corporate environments is a pretty painful lesson to learn.
This is not to say that any one of the approaches is the one true approach. To a company software is a means to its ultimate goal of more profits.
To an engineer though it's often both, a means of livelihood and a source of joy. Reconciling the second with the first is easy in theory and hard in practice.
couldn't agree more! these people who are not that passionate and build software for a living tend to care less, and when we care less we do more. also rarely they come up with crappy solutions, that might not be good but work. making things even harder for the passionate perfectionists.
I started it as a dance instructor (after competing since I was 13 years old) then I saw that the dance studio director still shared a room (!!) with somebody else in a really crappy part of New York City, so I got a job on the airport from a classified ad my husband clipped from NY Times and I got really interested and passionate about aviation. Took a few lessons and went through a course for my dispatcher license.
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.
In my long carrier I've seen many devs. Those who came for money really suffer the whole life. I started programming as a kid and can't stop even now ;)
I’ll be honest I would have left by now if I could have, but I don’t regret my career in the slightest. I still code for fun, but our jobs are rarely about just coding, and the money has brought in a lot of toxicity.
Yes, in big projects you don't see the result. it becomes a boring routine. But when your hobby robot makes first steps it's a completely different feeling.
Upvotes for you. I have also worked a ton of odd jobs out of necessity. Many doing things that would frankly disgust most people, or people would say is a worker’s right violation, or is a safety violation. I enjoyed these jobs more despite the conditions.
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.
Thanks I appreciate it, re safety violations, yeah some of it was those laws were just badly applied across the board, and it was hard to find a place without some degree of violating the letter of the law, so I think they just got flippant.
Re “source of sanity” I’ve caught myself doing the same with extra work, but sometimes it backfires when the little fun tool you wrote solves the purpose so well that it becomes the company standard and then the politics comes in, I don’t mean the “oh we need this feature super badly that breaks a bunch of other things can you do it for us” that’s just having a successful project. I mean when it starts figuring into political finger pointing and you’re forced to be involved in it all since you are the creator of a tool tangentially involved in some inter office politics. I’ve not figured out how to avoid that yet.
>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.
Why do you have to fight if it's extra time? And couldn't you avoid the fighting by just doing it on regular time?
I wonder if that conviction would actually survive you being dependent on the income of that garden (and the ability for crops to survive, grow and be sold at a good price to sustain you) or if you're just dreaming of vacation where you poke at the land a bit.
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.
Yes was talking about the grounds crew, no one was harvesting trees for money, it was my favorite job and would happily do it again if I didn’t have family obligations (I had mentioned this in the post).
That said the farm I worked I knew the farmer and his dad pretty well and I worked there year round for a couple of years with breaks in the summer. Harvest time was insane and not all the years were good, but the family were comfortable and most of the time the workload was reasonable. It maybe different now but I lived in farm states then and I personally knew several well to do farmers that were living very well with more assets than I currently have. So I’m not sure I’m fully on board with your view of farming. It depends a lot on time and place I’m sure though, I’ll fully admit that I’m no expert.
I’m sorry this caused such a negative reaction but I think you stopped reading too soon, we agree more than disagree. Listen, I’ve paid my taxes on those jobs that I miss, so I know what it is I’m saying.
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.
> I feel like most computer problems are made up, and so many real-world problems draw in your emotions and senses.
It’s funny, I feel the same but come to the opposite conclusion. I don’t want to look back on my life thinking that I spent all my time chasing fake problems. The calculus is different for everyone though.
>I don’t want to look back on my life thinking that I spent all my time chasing fake problems
Neo-liberal capitalist economies are full of fake problems.
Take flash trading for example. I know why it exists, and I know why it works. I don't fault people for getting involved in it, because they (and we) exist in the system we have.
Yet, think of all the money that has gotten both pumped into that industry and the industry has made in profits, and all for...being able to algorithmically trade penny differences in value at a profit due to volume.
Is that a problem that is worth solving? Well, in our current economic system, it is, but should it be?
I don't know whats better per se (I'm not arguing for communism or some other clearly failed economic political system) but I sure feel like I can identify problems that could quite easily fall into the made up category.
Doesn’t flash trading basically contribute compute to force prices to settle at equilibrium faster thereby improving pricing efficiency?
I’m not sure it’s worth the required effort input at a system level vs other places the effort could be applied, but there is at least some abstract benefit to it, I think.
Very inspiring comment. I suppose that software development was a much more impactful job back in the days.
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 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.
I find it super satisfying, and would probably be some sort of computer programmer even if it paid a lot less and was generally looked down upon as mundane clerical work by most people. I am thankful to live in a time where it is a high paying job.
Writing software underneath MBAs who are clueless about engineering, driven by sales and marketing teams who are clueless about engineering, constantly "sprinting" to get stuff out the door...
There's a lot of stuff in the industry to suck any joy out of writing software
Software engineering can also be incredibly satisfying regardless of money. It depends on what you're working on and who you're working with. There's a great feeling when you get into flow while writing interesting software or tackling a puzzling problem.
In America. If you work in other markets the salary is much lower. The only engineers I know who make above 100k euro are either lead or founder level.
It is possibly to earn over £100k as a software engineer employee in the UK, however those tend to be very specialised fields. (Not all of them are finance related).
I do recall a software manager (OK apples to oranges) grumbling about 10 years ago about him exceeding that level, and having to play games to avoid being bit by the tax impact which cuts in between £100k and £125k.
That said, I do know engineers who indicate they earn in excess of £100k, and they're not lead nor founder level - just experienced in the appropriate area.
100k USD is about 90k EUR (and 77k GBP), which you may say doesn't change your point materially, but I'm not splitting hairs, that's more than a 10% difference.
I think people often put the goalposts further away than they truly are by comparing numbers cross-currency directly like this or just round numbers in general.
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.
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.
Nope, so called 'dark matter' developers are the majority in the US too. HN is such a small sliver of the developer community, those who work for big tech even more so
That’s a fair point, but I am not sure how it is relevant, unless devs at mom&pop shops/legacy businesses/etc. and those outside of the US work more than the US lawyers (or any other highly-paid white collar job) or have barriers to entry similar to those. From those I know working at those places (and from working at a legacy business myself at one point, a big bank), that didn’t seem to be the case at all. At startups, sure, but that’s just a high risk/high reward type of a deal, and they still don’t have almost any barriers to entry either.
Is it the case outside of the US? Genuine question, because I am not super familiar with close reality dev jobs outside of the US. But from what I saw, it didn’t strike me as an obvious thing that they get ground to the bone or have high barriers to entry (as opposed to other highly-paid white collar jobs).
> they're good jobs for sure, pay-wise it would be around plumber range?
This has been my observation, software developer pays about the same as a plumber or electrician in places like England, outside of select industries
like high finance in London etc
>but yeah, in general devs have nothing to complain about.
I respectfully disagree. I think there's alot of room for improvement in our industry, even in regards to pay we could do better. Think of the value delivered per engineer vs what they're paid, the ratio is typically very high, meaning engineers are paid a fraction of what value they provide.
Interesting sidenote, given you mentioned plumbers: being a plumber in the US has higher barriers to entry than being a dev (gotta have your apprenticeship program completed under a licensed master plumber and pass the journeyman plumber exam). On the flip side, they get paid pretty decently well.
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 mean, everyone's trying. I've noticed a marked increase in the number of people in software engineering who are there first and foremost for the paycheck. Some of them don't even like writing software!
This doesn't necessarily correlate to skill at writing software, but I've also encountered a higher ratio of poor performers from this growing demographic, as well. The end result is that the median skill level seems to go down over time.
Which isn't necessarily a bad thing, and seems like it should be expected as the pool of people working in software development grows.
But as time goes on, there are definitely more and more people who are trying (and succeeding!) at doing it.
> and probably the most competitive industry in the world
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.
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.
Maybe we should agree that all jobs can't be compared apples to apples. I have 3 good friends that fly for major airlines. I'm pretty familiar with the jobs.
-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.
Yep. OP fell into the classic trap of making generalizations across two COMPLETELY different fields despite only having knowledge in one of them. I got my PPL nearly a decade ago (obv a far cry from ATP but still) and it's ludicrous to try to compare the skill sets of computer science to piloting.
That's it. Piloting isn't easy, and you do have to study a lot, but it is rote memorization for the most part.
That is a completely different kind of thing than the kind of thinking that we do in programming. One isn't better or easier than the other, just different.
> I was talking with friends at a party last night about their white collar jobs, .... One friend had just finished a 3 month program to certify to fly a certain type of airliner.
Frankly, trying to claim their jobs, which all require more education and have much higher pressure and consequences for error than mine, aren't white collar would have been rude and insulting to everyone.
I find your definition of "insulting" really confusing, as pretty much all "white collar jobs" are "I sit on my butt all day and think lazily about things with very little pressure" jobs. They push paper and write reports on things, maybe doing some annoying math at times, but the entire concept of a "high pressure" job with "consequences for error" seems entirely at odds with white collar, and I'd personally have expected people who actually do something important on a daily basis (unlike, for example, me) might would find being categorized as "white collar" insulting?
It's equally insulting to insinuate that some blue collar jobs don't also require more education and have much higher pressure and consequences for error than many white collar jobs.
There are many blue collar jobs that require a lot of education and the consequences of errors is loss of life.
Most of the people in that room had worked blue collar jobs, worked through school, and retrained in white collar professions.
I would have been incredibly rude to tell them "No, your job isn't _really_ white collar, and you haven't changed your social standing as much as you thought."
White/Blue collar, while correlated with income, has nothing to do with social standing.
A friend of mine is a construction foreman. He lives in a mansion in a suburb of a suburb, is a member of a highly regarded country club and makes more money than me. He’s blue collar.
A person cannot be proud of their individual achievements, self improvements, working at a job they wanted, or providing for their families? Simply because many others have done the same?
Did you read the Wikipedia article? Grey collar is work that takes both intellectual and physical skill. It even includes surgery as grey collar. Thinking white collar indicates more education and pressure is the issue. There's white collar jobs that can be done by high school graduates, and blue collar jobs where life and death are literally a split second away most of the time.
I get that people want to Categorize All The Things, but this doesn't seem like a particularly useful category. If you look at the list in the Wikipedia article, it includes "skilled tradespeople/technicians". That alone represents a pretty big chunk of work traditionally considered "blue collar."
The Wikipedia article that comment linked to in a later edit says it's a controversial definition and says that such professions are typically described as white collar. That seems to support my statement?
I feel like I've experienced the opposite honestly. I'm a mechanical engineer, and my wife's old college friends consist of a bunch of silicon valley techies.
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.
> by the time you finish your 3 months course the tech is considered obsolete.
This is a meme that’s just not true. Nobody outside of the most junior applicant or most transient contractor is paid for the skills they learned this year.
The most important skills last forever. Getting a good CS or EE degree is still the best way to get started.
Exactly. In the past ten years the main differences in my professional tech stack are that I write Go instead of Java and my software runs in containers on Kubernetes instead of JAR files on CentOS. My friends have all had much more significant changes and retraining in their careers.
Yep even within internet technology this is ridiculous. Imagine we time machined a Perl old-head from 1995 only knowing http, Unix, networking, etc. They could be invaluable at any company in a month.
>They could be invaluable at any company in a month.
That's a made up fantasy. They wouldn't get hired at all in real life. Ask me how I know. Where I live recruiters only check that your recent experience and stack match the ones on the job, otherwise your resume goes in the bin.
Like Ygg2 said below, employers don't want generalists with generic CS knowledge, they want people they can immediately slot in and start crushing Jira tickets.
Do you want the list of things that haven't changed since I started programming as a kid?
I still write a lot of Python and shell. I still use Linux, mostly systemd. (I did have to use initscripts early on and do not miss them at all. systemd's way easier.) The entire networking stack has changed only minimally, with only early versions of SSL/TLS becoming obsolete. All the software I use to do my job is the same (A terminal, Vim, Firefox, GNU coreutils, and a smattering of other tools). I still use the same cloud services and databases. The skills I learned in school are equally as useful today as they were then, especially math and CS theory.
The only major shift during my career has been migrating from Linux VMs to containers on clusters (first on Mesos, then Kubernetes). Having administered both at scale, Kubernetes is a lot easier.
> I still write a lot of Python and shell. I still use Linux
All of those listed things have changed. Python went from 2 to 3, number of shells has multiplied like rabbits. Linux changed in leaps and bounds. It got async, BPF, different tech stacks, and window environments.
> Do you want the list of things that haven't changed since I started programming as a kid?
Sure basic principles have remained the same, but huge chunks of ecosystem have been transformed. Perhaps we are looking at it from different perspectives.
It's kinda like ecosystems. Amazon tropical rainforest looks the same now as it did 1000 years ago from birds eye view. But on the ground entire species came and went, and the species living there changed dramatically, in quality and quantity.
My issue is, employers don't want general knowledge, they want an easily slottable asset. You need to know their tech stack. Even if it changes. Hence why LLMs are so in demand.
Python 3 is not that different from Python 2. Yes, if you're a mindless interpreter designed to specifically parse and evaluate Python 2 code, you're going to have a hard time with Python 3. Thankfully, software developers are humans and should not have this issue.
The number of shells that are relevant to any workplace I have worked in have been two, possibly three if you're working somewhere heavily Apple-based. All three of these shells are POSIX-compatible. Other shells exist, but are entirely optional and rarely used (I say this as someone using one of those other shells).
Linux has changed more, and is probably the biggest source of change in the list that the previous poster described, but as they point out, most of these changes make managing Linux systems simpler, and shouldn't really cause significant problems.
I think you're strongly exaggerating the scale of changes here.
> My issue is, employers don't want general knowledge, they want an easily slottable asset. You need to know their tech stack. Even if it changes. Hence why LLMs are so in demand.
I'm a frontend developer. Every job I've had, I was not familiar with the specific framework they were using when I went in for that job. In every case, that's not been a problem at all, because I've been able to clearly demonstrate that I understand the foundation of frontend development, which is far more important than the precise technologies used in the company's framework of choice. My experiences in general are the complete opposite of what you describe here: every single employer that I've worked for has wanted primarily deeper general knowledge rather than specific knowledge of their specific stack.
Maybe this is a market thing — maybe things really are that different here in Europe — but your descriptions do not ring true at all for me.
> Kafka is out. It's all about Iggy! What do you mean it's different language? Learn it!
Are people really using Iggy/hyping it already? TIL it's now an Apache project[0], that's awesome, it looks impressive!
Sure, most reasonable people are definitely not ripping out Kafka for Iggy yet, but I'm certainly happy to hear it getting more usage/at least being considered.
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.
Realistically, 30 minutes of walking a day is not enough to offset the long hours of sitting (no matter how great the chair is); standing desks aren't necessarily a better solution here either. Gym and healthy eating are a must, but not everyone can afford them (in terms of time).
Anyhow, unlike my non-programmer friends, I can never leave my work - whenever I'm walking my dog, working out, cooking dinner, or taking a shower - I still keep thinking about the things I need to solve, the failing tests, the PR comments, my open-source projects, etc.
Yes, I still love my job and wouldn't trade it for anything else. Sure, I'm very happy that I don't have to leave the house at 2AM to risk my life, but still, it isn't really one of "the easiest careers" - I am easily disposable, I don't ever receive a pension, whenever I need to find another gig - I have to go through seven circles of hell, and it never is the same hell to go through, I have too many bosses, I constantly have to keep learning new skills, routinely prove my worth, and defend my opinions, because even after twenty years of building expertise in various areas, in our field of work, one can never confidently call themselves an expert.
I've been battling RSI and stuff for the past two years and am starting to make progress although it's required me to get both of my wrists fixed and potentially both of my elbows in the future.
It's easy to just say "Oh, do this workout" but it can be very difficult to do that if you either lack the time or have other health issues that prevent you from doing them.
For me, I have rods in my legs and fused ankles so even though I try to hit the treadmill regularly, doing so means I wind up in a lot of pain.
None of this has got in the way of my passion for building software, although for me there is a distinction between what I do (or want to do) in my own time vs. what I have to do for work.
It's a good day when I can really apply myself to a problem at work.
It's less great when for whatever reason, I'm prevented from being able to do a good job.
And the sad thing is that often, you're not prevented from doing a good job because of any technical or time constraint, it's usually all political.
My comment wasn't self-referential, I'm not complaining, I do exercise. Have you noticed the use of terms of possibility and not certainty in my prior comment? I'm just stating the general facts on long-term career of a software engineer.
Dont listen to those kids. Ive seen a lot of youngsters coming as Software Engineers. They have no skill, no motivation to learn, they just spend a lot of time in coffe talks and get nice paycheck. If they fail, they are being pet and said: no worry, we will find you easier task to do. And then they come to some "oldfart" engineer and ask him to do the thing.
I have first hand story where my colegue had a cow-worker like this and wanted to get rid of him.. Took whole year to do so, but NO.. he wasnt fired.. he was promoted!!! But my colegue said: At least, we get rid of him :)
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
That does not sound like normal work for a software engineer. That sounds more like you have found an unusually bad workplace. Why are you changing out tools every few months? Why are you working overtime for free? Why is there only one person who knows how to fix things when they break (especially if that happens so regularly that you have one person who "normally" fixes it)?
Ah, if that's the case I can understand the argument a bit better, but maybe the article should then be titled "the insanity of being in one of the best-paid professions in one of the richest countries in the world, and still having poor working conditions".
Apparently this is an EU/US thing, because here overtime and on-call is always paid extra (as is essentially anything beyond your usual 40 hrs/week, or whatever you've got in your contract).
That said, I also see very few jobs that involve on-call. Maybe that's because companies know they have to pay extra for it and therefore don't hand it out willy-nilly, but typically there'll be an ops team who do have on-call, and whose job is to triage and fix anything they can, otherwise just minimise the damage, and then maybe the most business-relevant couple of teams will also have an on-call rotation in case the problem can't be solved by ops alone.
This. I've worked plenty of places that have awful work/life balances, friends that work in the trades are getting 1.5x to 2x on overtime while I'm working 12-16 hour days and weekends for nothing extra except the possibility of getting fired for performance if I didn't.
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.
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.
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!
Don't say that to a truck driver, construction worker, farmer, or fast food employee.
> 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!
Going home at the end of the day and not having to think about work is sure great, except that fast food employee is probably doing their second job. As for that farmer, in one respect or other they're almost certainly operating their own business. Not managing. Operating. They're going to have trouble setting aside the stress of the job at night as well. Construction workers, well, they will be all over the map. Some will be like farmers, operating their own business. Some may be doing heavy or dangerous labor. Day to day, their job may rank as tiring. Over extended periods, they are expending their body. Short of switching to a trade, their career is on a clock. Truck drivers have their own issues to deal with. Again, a lot of them are operating their own business (even when the work arrangements make it feel like they're employed by someone else). If they're working within an urban area, they're typically driving in less than ideal circumstances for hours on end and dealing with a system that tries to make the system's problems the trucker's problems. Some long-haul drivers may earn a decent paycheck, at the cost of being on the road for days on end and being pushed outside of the safety envelope.
So yeah, everyone has something to complain about. But if you want those people to think that SWE's are arrogant jerks, then just go on saying how much worse your job is than yours.
hmm, kind of feel like you're cherry-picking the most difficult versions of those jobs. No need to to into too much depth, but for instance, yeah, not all fast-food employees are working two jobs (many seem to be high-schoolers?). Not all farmers own their own business and are employees. I had a roommate who was a truck driver. He was simply an employee and worked a 9-5 and didn't own his own truck (many of them do, but this is becoming less common).
Although, I agree, there is a lot of blue-collar work that is tough, especially on the body - have done a few weeks of construction work myself, it can destroy your body quickly if you don't learn how to pace yourself and use your body correctly (it's not something I personally would ever want to do long term). But there is also a ton of cushy blue-collar work that are easy - my roommate works at an Amazon warehouse, and she says that her role is mindless work that anyone can do sorting items in boxes.
Yeah, I am probably somewhat biased, but saying that the average fast-food employee's job is more difficult that an average SWE's job (with its deadlines, stress and politics, not to mention all the years of studying), that seems like a stretch. I'm all for the blue-collar worker, but let's be reasonable. Yeah, at least from what I've seen, often, it's not their jobs that are tough, it's the circumstances of their life (many of course are low paying, which makes everything difficult) and lack of advantages they had growing up...
... although, I do admit there are a lot of devs that once they get over the learning curve just coast at their jobs, learning little that is new and working on the same system year after years. Hmm, interesting...
It's actually quite common and typical for freelancers.
Unfortunately when you evaluate a project, initially everything looks and feel just right, that you wouldn't have any problem delivering the end result as soon as possible.
But..! We know how customers ask for small "favors" of "tiny" changes that won't affect the whole project, or so they think(!), which eventually end up delaying the whole development as they become painful hurdles, only to find yourself struggling to deliver the project so you can get paid in time.
think this is more about that there is a variety of types of work in tech. As you probably have experienced yourself, if you join a fast moving startup, they'll work you to the bone, whereas a large, a wealthy corporation will let you just go to meetings 50% of the time.
Hmm, i guess in my opinion, think most devs would agree that startups in general are more work than the average corporate job. Maybe we don't have a basis to have a discussion if we don't hold common beliefs in our field. No worries I guess (shrug)
Just want to echo the person who already replied, but contracting is a different world. One might argue that when you're a contractor you're also an independent businessman — and thus you own the responsibility of win or die.
> A developer, programmer, software engineer, call this category of work however you like, it uses the brain at such relentless limits,
Its so weird that development that pays well over $200K uses about 5% of the brainpower I used for college, when I got paid about $9 an hour to clean plates for 40 hours a week.
Maybe it's time to switch to a new role/project?? :)
But, agree, many tech jobs require you to initially mount a difficult learning curve, then coast, doing the same thing over and over (although, for better and for worse, this was rarely what my jobs in tech were like. Was always jumping around having to learn new things).
Both construction and mowing lawns are two jobs I can say felt much more rewarding than programming. Each day you walked away with a sense of having "built" something (or, er, tidied up in the case of mowing lawns).
And accomplishing anything with your hands and manual labor is instantly gratifying.
There are a lot of programming jobs where people never get to build anything, only fix things that other people didn't do well enough. Many people have never seen greenfield. Other people work jobs where they're pumping out new creative works. So when people talk about how spiritually satisfying programming is we're gonna hear this discordance.
> And accomplishing anything with your hands and manual labor is instantly gratifying.
May I add that Agile (which appears to be the currently prevalent work methodology in SE) takes away much of the gratification of software engineering?
I think you're conflating job satisfaction and the difficulty of doing it.
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?
How about this: tell a truck driver, construction worker, farmer, fast food employee: software engineering is so easy, you should go do it.
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.
Winning in software is as easy as winning in chess. Often times you're making ripples with just the flick of a wrist. You make a few clicks and suddenly you're matched against someone from across the world. Other times you're just staring at the monitor, looking intently but doing nothing.
Even children could make it to the top of the world in this activity of intense sitting.
Actually when I was gutting salmon in Alaska, making pizzas at Godfather's, mowing lawns, working as dishwasher in the dorms to pay tuition ... these all were much less stressful jobs that I look back on almost fondly. (Well, maybe not the cannery.)
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.
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.
At least software engineers can do something to not make a mess or change it. Once you get to real physical world that might not even be realistically done...
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.
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.
> 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?"
What’s about sharing documents which is still it’s primary purpose. And most of the current complexity stems from the sprawling JS API surface. We know how to sandbox software (VM and malware analysis,…), browser’s complexity is mostly corporate driven.
I had forgotten the original purpose of web browsers was to view hyperlinked documents. It seems like we abandoned that as the primary use case over 20 years ago, with technology such as Flash, Silverlight, and Java Weblets.
I don’t think that has been its primary purpose for a long time. If you want to share a document for the most part you email it. It has long since moved from documents to applications.
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.
VMS was a sandbox-based OS released in the 70s that solved "how do we run arbitrary code on client hardware in a way that's safe for all parties?" Browsers are not that.
Browsers do have this component, but that's not the reason they exist.
I wonder how productive it is to mention that though. Sure, that may not be the reason they exist and came to be (something about exchanging documents) but it may be how they are mostly used today.
You are insisting on justifying all of the complexity of browsers by claiming the same functionality that people got in the 70's with a small OS that was hand-written in assembly.
Sorry, but you don't seem to want a productive discussion. You just have a preconceived idea that turns out to be wrong.
I am not insisting anything. I wanted to point out that the "reason why browsers exist/came to exist" can be relevant in this discussion but is not a direct logical contradiction to their current complexity.
If I say, the pdf came to be in order to be a simple way to digitally represent printed/printable documents that may be correct but wouldn't actually express anything about the current complexity of the pdf format. Admittedly perhaps a bad example due to how similar it is.
It's possible I misunderstood though. If so, I apologize.
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.
It's maybe a bit orthogonal? (Or maybe misleading.) I'll fill in with anecdotes and try to make more sense:
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. ;-)
> For many engineers (and me of course) this can be the most rewarding way to work.
Agreed, this is also the world I grew up in. Nothing is as rewarding as working on something where you have ownership to set the direction and deliver.
For most of my career I had never heard of "product managers" and it was bliss. Somehwere along the line software engineer transformed from being the intellectual lead of the business, to simply a ticket-taker writing code for things some completely non-technical "product managers" decided should be done this week. And the inability to be allowed to think or plan for anything beyond a two week sprint window is mentally crushing.
I've moved to different roles now since software engineering became such a miserable job. I'd jump back in a heartbeat though if there was a company operating like we did in the 80s and 90s where engineers owned engineering.
Similar to the other reply, I don't manage people or drive the methodology changes.
I'm dev lead on a small (3 dev) sub-team within the larger platform team. We generally follow the same methodology as the rest of dev. They're reportedly following agile but it has the classic hallmarks of being driven by senior management: little/no training or education in agile (even in product), devs don't speak to clients, retros are consistently cancelled for lack of time, process changes are dictated by the product team (which is managed by the company's MD), etc... . I'm actually not convinced that the company can pull off agile. Partly because management don't understand it, and partly because our major business client are rigid about roadmaps and deadlines. Also partly because my own sub-team engages in research-heavy, long-term features. A lot of our work consists of thinking up blue-skies algorithm changes, trying them out, and going back to the drawing board if it doesn't pan out. Month-long iterations of work with potentially no viable changes after each one. When I read about agile it tends to describe stuff where you can muster up an MVP for a feature within a week or two at most, so it has been tricky to interpret how to apply it.
So basically, it's not working great and I have limited influence to change things. What I can do is fight my team's corner with well-backed arguments. E.g. there was recently a period of a few months where the entire platform team (~25 people) took part in a daily standup lasting 30 mins on average, on top of their own squad catchups. This was obviously wasteful but the engineering manager liked feeling ontop of things. After I repeatedly raised the issue, the frequency got dropped to weekly for my team and twice-weekly for the wider team. So I'm keen to learn more about agile vs alternative systems so I can continue to fight effectively my team's corner in this way. The ideal end-goal would be to extricate my team entirely from this half-baked agile mess, whether that means following agile more "correctly" or switching to something more bespoke. I appreciate the references and have started glancing through "Agile Estimations and Planning", it's okay so far but nothing revelatory. I don't have a lot of time to devote to this so I'm naturally skeptical of "just put in lots of hours of reading and I'm sure you'll see the benefit".
> 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.
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.
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.
Nope, engineers are engineers because they push back on bad decisions. I don't consider web devs engineers because they refuse to take responsibility for their actions
> 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.
That was one of the main topics of the video, yes, but the rest of it looked at some research into how to address it. One study showed that just promoting people at random had better outcomes, and a separate study showed that "up or out" was also effective. I would guess that the choice between them is mostly about the culture of the organization
I'd like to read that random promotion paper. I wonder how high up they actually implemented this strategy, because the idea of the CEO just being the person that chosen at random more than anyone else is hilarious to me.
My mental model is that "promotion" is something that only happens to middle managers; board relevant seats are either appointed by the board or come from the good ole' boy network (which I do recognize is almost certainly worse than promoting a bad manager from within, who at least has existing relationships and business context)
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.
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.
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.
This, some people recently forwarded a "tech pay" survey to all dev teams (ours does C++/Qt desktop software), and there was only (basically) "Frontend dev", "Backend dev" and "AI/ML dev" in the job list.
It reminded me of that KotH skit "- So, are you Chinese or Japanese? - Huh, I come from Laos and... - Chinese, or Japanese?".
This is an extremely mild version of what it feels like to be a minority. Web developers are the most common type of developer. It is simply natural for them to equate "developers" and "software developers". Out of sight, out of mind. It's not a hostile thing, it's not something people necessarily want to do. But it still happens. It's a human thing.
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.
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.
Absolutely & very well said - my contention lies in the fact that certain skills are just that - technical. Especially when it comes to architecture, code, complex systems and so on.
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.
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 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.
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.
> 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.
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)
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.
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.
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!”
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
> 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.
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.
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.
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.
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.
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.
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.
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.
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 the trouble with healthcare is it's secure if you're willing to work the shifts. Even dentists are often working long hours and on weekends etc. (although I don't think night shift is a thing). Even the best doctor will struggle to find a 9-5 that they leave on time every day. Swings and roundabouts.
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.
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.
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.
I mean, my job title is currently "Full Stack Software Engineer" and I manage to get by only writing Typescript. Yes I have to do all of the things mentioned in the article: React, CSS, AWS, Docker, Databases, etc. We do a lot of greenfield so I'm the one setting these things up.
But it's basically all in the web paradigm. I don't have to work on mobile apps or drivers or something. So I think "Full stack" isn't really a good descriptor. I'm more so a "Web developer" than anything. Which is complicated, yes, but if you were a mobile developer your world would be completely different and have its own software ecosystem.
This 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.
> It's not an "incredibly easy career", otherwise everyone would do it.
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.
If people don't care about work being easy, then all the people in this thread should stop telling people they're not allowed to complain because their job is easy. The job being easy either matters or it doesn't.
There are plenty of people who would do uninteresting work for many multiples of median wage. Jobs like factory workers and postal sorting etc. have high turnover because they offer neither interesting work nor good pay. I've never worked with anyone who left software because they weren't autistic enough to find it interesting.
> There are plenty of people who would do uninteresting work for many multiples of median wage.
Sure. We've all watched an increasing number of these people arrive in the software industry over the years. But they are not representative of everyone. Plenty of people can't force themselves out of bed in the morning for money alone. If they could, they'd be working in software.
> Jobs like factory workers and postal sorting etc. have high turnover because they offer neither interesting work nor good pay.
Manufacturing especially offers the illusion of interesting work. In fact, there is a whole political thing going on in the US right now trying to increase manufacturing job availability because of that illusion. I expect you are right that people are going to find out that it isn't what it seems, but so long as they believe it before they try it... Software, on the other hand, doesn't even try to pretend.
> Being a software engineer is tough.
No, it isn't. Software engineering is one of the easiest careers. We are so coddled that we think what is described in this post is tough, that alone is evidence of how not tough our career is.
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 think the answer is that it depends. Software engineering is incredibly hard if you are a perfectionist who wants to make efficient, secure and maintainable software. But most probably it is not even possible to be that perfectionist and stay within any given budget. And the requirements are most often not your own.
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.
> 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.
This is the hardest lesson to learn for a lot of software engineers. By nature, computers are unforgiving, so a lot(most?) of us are wired to do things 'right'. The apparent fundamental incompatibility of that mindset with modern corporate environments is a pretty painful lesson to learn.
This is not to say that any one of the approaches is the one true approach. To a company software is a means to its ultimate goal of more profits.
To an engineer though it's often both, a means of livelihood and a source of joy. Reconciling the second with the first is easy in theory and hard in practice.
couldn't agree more! these people who are not that passionate and build software for a living tend to care less, and when we care less we do more. also rarely they come up with crappy solutions, that might not be good but work. making things even harder for the passionate perfectionists.
I started it as a dance instructor (after competing since I was 13 years old) then I saw that the dance studio director still shared a room (!!) with somebody else in a really crappy part of New York City, so I got a job on the airport from a classified ad my husband clipped from NY Times and I got really interested and passionate about aviation. Took a few lessons and went through a course for my dispatcher license.
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.
CCIE is legit!
Just wanted to say that's impressive.
In my long carrier I've seen many devs. Those who came for money really suffer the whole life. I started programming as a kid and can't stop even now ;)
I’ll be honest I would have left by now if I could have, but I don’t regret my career in the slightest. I still code for fun, but our jobs are rarely about just coding, and the money has brought in a lot of toxicity.
exactly, also these days coding is not about creativity or fun anymore.
Yes, in big projects you don't see the result. it becomes a boring routine. But when your hobby robot makes first steps it's a completely different feeling.
For me work is work. Getting up on Monday Morning is always going to be a bummer. So I might as well get PAID and air conditioning.
Upvotes for you. I have also worked a ton of odd jobs out of necessity. Many doing things that would frankly disgust most people, or people would say is a worker’s right violation, or is a safety violation. I enjoyed these jobs more despite the conditions.
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.
Thanks I appreciate it, re safety violations, yeah some of it was those laws were just badly applied across the board, and it was hard to find a place without some degree of violating the letter of the law, so I think they just got flippant.
Re “source of sanity” I’ve caught myself doing the same with extra work, but sometimes it backfires when the little fun tool you wrote solves the purpose so well that it becomes the company standard and then the politics comes in, I don’t mean the “oh we need this feature super badly that breaks a bunch of other things can you do it for us” that’s just having a successful project. I mean when it starts figuring into political finger pointing and you’re forced to be involved in it all since you are the creator of a tool tangentially involved in some inter office politics. I’ve not figured out how to avoid that yet.
>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.
Why do you have to fight if it's extra time? And couldn't you avoid the fighting by just doing it on regular time?
I wonder if that conviction would actually survive you being dependent on the income of that garden (and the ability for crops to survive, grow and be sold at a good price to sustain you) or if you're just dreaming of vacation where you poke at the land a bit.
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.
PP above says working on a grounds crew was their favorite job ever. I think that's what they're talking about.
Yes was talking about the grounds crew, no one was harvesting trees for money, it was my favorite job and would happily do it again if I didn’t have family obligations (I had mentioned this in the post).
That said the farm I worked I knew the farmer and his dad pretty well and I worked there year round for a couple of years with breaks in the summer. Harvest time was insane and not all the years were good, but the family were comfortable and most of the time the workload was reasonable. It maybe different now but I lived in farm states then and I personally knew several well to do farmers that were living very well with more assets than I currently have. So I’m not sure I’m fully on board with your view of farming. It depends a lot on time and place I’m sure though, I’ll fully admit that I’m no expert.
I’m sorry this caused such a negative reaction but I think you stopped reading too soon, we agree more than disagree. Listen, I’ve paid my taxes on those jobs that I miss, so I know what it is I’m saying.
How inspiring.
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.
> I feel like most computer problems are made up, and so many real-world problems draw in your emotions and senses.
It’s funny, I feel the same but come to the opposite conclusion. I don’t want to look back on my life thinking that I spent all my time chasing fake problems. The calculus is different for everyone though.
>I don’t want to look back on my life thinking that I spent all my time chasing fake problems
Neo-liberal capitalist economies are full of fake problems.
Take flash trading for example. I know why it exists, and I know why it works. I don't fault people for getting involved in it, because they (and we) exist in the system we have.
Yet, think of all the money that has gotten both pumped into that industry and the industry has made in profits, and all for...being able to algorithmically trade penny differences in value at a profit due to volume.
Is that a problem that is worth solving? Well, in our current economic system, it is, but should it be?
I don't know whats better per se (I'm not arguing for communism or some other clearly failed economic political system) but I sure feel like I can identify problems that could quite easily fall into the made up category.
Doesn’t flash trading basically contribute compute to force prices to settle at equilibrium faster thereby improving pricing efficiency?
I’m not sure it’s worth the required effort input at a system level vs other places the effort could be applied, but there is at least some abstract benefit to it, I think.
Very inspiring comment. I suppose that software development was a much more impactful job back in the days.
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 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.
I find it super satisfying, and would probably be some sort of computer programmer even if it paid a lot less and was generally looked down upon as mundane clerical work by most people. I am thankful to live in a time where it is a high paying job.
Yeah, where is all the hate coming from? Writing software is difficult, challenging and, at some level, fun.
Writing software underneath MBAs who are clueless about engineering, driven by sales and marketing teams who are clueless about engineering, constantly "sprinting" to get stuff out the door...
There's a lot of stuff in the industry to suck any joy out of writing software
Software engineering can also be incredibly satisfying regardless of money. It depends on what you're working on and who you're working with. There's a great feeling when you get into flow while writing interesting software or tackling a puzzling problem.
> 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.
I think you just described most people who aren't SE's. The only difference is that they can't land better paying jobs.
In America. If you work in other markets the salary is much lower. The only engineers I know who make above 100k euro are either lead or founder level.
It is possibly to earn over £100k as a software engineer employee in the UK, however those tend to be very specialised fields. (Not all of them are finance related).
I do recall a software manager (OK apples to oranges) grumbling about 10 years ago about him exceeding that level, and having to play games to avoid being bit by the tax impact which cuts in between £100k and £125k.
That said, I do know engineers who indicate they earn in excess of £100k, and they're not lead nor founder level - just experienced in the appropriate area.
Contracting will do it. (Caveats apply - understand IR35, keep 6+ months of money in the bank, be able to temporarily relocate, YMMV)
100k USD is about 90k EUR (and 77k GBP), which you may say doesn't change your point materially, but I'm not splitting hairs, that's more than a 10% difference.
I think people often put the goalposts further away than they truly are by comparing numbers cross-currency directly like this or just round numbers in general.
FWIW that 10% almost entirely comes from the current economic shock. At the beginning of 2025 1 USD was about 1 Euro.
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.
>Compare working in big law to big tech
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.
>except maybe for the US workers
Nope, so called 'dark matter' developers are the majority in the US too. HN is such a small sliver of the developer community, those who work for big tech even more so
That’s a fair point, but I am not sure how it is relevant, unless devs at mom&pop shops/legacy businesses/etc. and those outside of the US work more than the US lawyers (or any other highly-paid white collar job) or have barriers to entry similar to those. From those I know working at those places (and from working at a legacy business myself at one point, a big bank), that didn’t seem to be the case at all. At startups, sure, but that’s just a high risk/high reward type of a deal, and they still don’t have almost any barriers to entry either.
Is it the case outside of the US? Genuine question, because I am not super familiar with close reality dev jobs outside of the US. But from what I saw, it didn’t strike me as an obvious thing that they get ground to the bone or have high barriers to entry (as opposed to other highly-paid white collar jobs).
most devs are not highly paid outside the USA. they're good jobs for sure, pay-wise it would be around plumber range?
no high barrier to entry whether you're worked to the bone or not depends on the place
but yeah, in general devs have nothing to complain about.
> they're good jobs for sure, pay-wise it would be around plumber range?
This has been my observation, software developer pays about the same as a plumber or electrician in places like England, outside of select industries like high finance in London etc
>but yeah, in general devs have nothing to complain about.
I respectfully disagree. I think there's alot of room for improvement in our industry, even in regards to pay we could do better. Think of the value delivered per engineer vs what they're paid, the ratio is typically very high, meaning engineers are paid a fraction of what value they provide.
Looks like we are in agreement.
Interesting sidenote, given you mentioned plumbers: being a plumber in the US has higher barriers to entry than being a dev (gotta have your apprenticeship program completed under a licensed master plumber and pass the journeyman plumber exam). On the flip side, they get paid pretty decently well.
Wrong. It is tough.
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
Indeed, GP's hypothesis can be trivially challenged by asking "If it's so easy, why isn't everyone doing it?"
I mean, everyone's trying. I've noticed a marked increase in the number of people in software engineering who are there first and foremost for the paycheck. Some of them don't even like writing software!
This doesn't necessarily correlate to skill at writing software, but I've also encountered a higher ratio of poor performers from this growing demographic, as well. The end result is that the median skill level seems to go down over time.
Which isn't necessarily a bad thing, and seems like it should be expected as the pool of people working in software development grows.
But as time goes on, there are definitely more and more people who are trying (and succeeding!) at doing it.
> and probably the most competitive industry in the world
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.
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.
Maybe we should agree that all jobs can't be compared apples to apples. I have 3 good friends that fly for major airlines. I'm pretty familiar with the jobs.
-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.
Yep. OP fell into the classic trap of making generalizations across two COMPLETELY different fields despite only having knowledge in one of them. I got my PPL nearly a decade ago (obv a far cry from ATP but still) and it's ludicrous to try to compare the skill sets of computer science to piloting.
That's it. Piloting isn't easy, and you do have to study a lot, but it is rote memorization for the most part.
That is a completely different kind of thing than the kind of thinking that we do in programming. One isn't better or easier than the other, just different.
> I was talking with friends at a party last night about their white collar jobs, .... One friend had just finished a 3 month program to certify to fly a certain type of airliner.
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...
That's foolishly confusing.
It breaks the original metaphor, and nobody knows it or the confusing borders of the definition - bad for communicating.
Most people seem prideful to self-identify into blue-collar or white-collar.
What's the meaning of the obviously next step pink-collar or black-collar?
A couple of decades ago I heard "pink-collar" used for jobs that were female-coded (nurse, teacher, personal assistant). <shrug>
Yah. Profusion of terminology is confusing.
I don't think anyone in that room would have agreed with that term.
Why?
Frankly, trying to claim their jobs, which all require more education and have much higher pressure and consequences for error than mine, aren't white collar would have been rude and insulting to everyone.
I find your definition of "insulting" really confusing, as pretty much all "white collar jobs" are "I sit on my butt all day and think lazily about things with very little pressure" jobs. They push paper and write reports on things, maybe doing some annoying math at times, but the entire concept of a "high pressure" job with "consequences for error" seems entirely at odds with white collar, and I'd personally have expected people who actually do something important on a daily basis (unlike, for example, me) might would find being categorized as "white collar" insulting?
It's equally insulting to insinuate that some blue collar jobs don't also require more education and have much higher pressure and consequences for error than many white collar jobs.
There are many blue collar jobs that require a lot of education and the consequences of errors is loss of life.
Most of the people in that room had worked blue collar jobs, worked through school, and retrained in white collar professions.
I would have been incredibly rude to tell them "No, your job isn't _really_ white collar, and you haven't changed your social standing as much as you thought."
White/Blue collar, while correlated with income, has nothing to do with social standing.
A friend of mine is a construction foreman. He lives in a mansion in a suburb of a suburb, is a member of a highly regarded country club and makes more money than me. He’s blue collar.
In the US about 60% of the workforce is "white collar".
Being proud of that is like being proud of a six figure salary in California.
A person cannot be proud of their individual achievements, self improvements, working at a job they wanted, or providing for their families? Simply because many others have done the same?
Are you saying 60% of California workers earn minimum six figures?
Some weird caste-based thinking straight from the subcontinent you've got there
Did you read the Wikipedia article? Grey collar is work that takes both intellectual and physical skill. It even includes surgery as grey collar. Thinking white collar indicates more education and pressure is the issue. There's white collar jobs that can be done by high school graduates, and blue collar jobs where life and death are literally a split second away most of the time.
I get that people want to Categorize All The Things, but this doesn't seem like a particularly useful category. If you look at the list in the Wikipedia article, it includes "skilled tradespeople/technicians". That alone represents a pretty big chunk of work traditionally considered "blue collar."
Whether you want to use a "grey collar" category or not, it's still best to avoid putting white collar on a pedestal over blue collar.
The Wikipedia article that comment linked to in a later edit says it's a controversial definition and says that such professions are typically described as white collar. That seems to support my statement?
I feel like I've experienced the opposite honestly. I'm a mechanical engineer, and my wife's old college friends consist of a bunch of silicon valley techies.
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.
Can you give your salary (or a range)?
Seems shocking that a SV swe would make what a mech eng makes after 4 years.
> a 3 month program to certify
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.
> One friend had just finished a 3 month program
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.
> by the time you finish your 3 months course the tech is considered obsolete.
This is a meme that’s just not true. Nobody outside of the most junior applicant or most transient contractor is paid for the skills they learned this year.
The most important skills last forever. Getting a good CS or EE degree is still the best way to get started.
Exactly. In the past ten years the main differences in my professional tech stack are that I write Go instead of Java and my software runs in containers on Kubernetes instead of JAR files on CentOS. My friends have all had much more significant changes and retraining in their careers.
Yep even within internet technology this is ridiculous. Imagine we time machined a Perl old-head from 1995 only knowing http, Unix, networking, etc. They could be invaluable at any company in a month.
>They could be invaluable at any company in a month.
That's a made up fantasy. They wouldn't get hired at all in real life. Ask me how I know. Where I live recruiters only check that your recent experience and stack match the ones on the job, otherwise your resume goes in the bin.
Like Ygg2 said below, employers don't want generalists with generic CS knowledge, they want people they can immediately slot in and start crushing Jira tickets.
> employers don't want generalists with generic CS knowledge
That's not true. Like I said, this is more of a problem if you are trying to break in.
> people they can immediately slot in and start crushing Jira tickets.
This is representative of the only the most precarious software contracts.
> They wouldn't get hired at all in real life.
I have hiring capability and I would hire them.
The poster said their skills would be out of date. I think you're confusing a sales problem for a skill problem.
>That's not true.
It's the case wherever I applied, which makes it true for me.
>This is representative of the only the most precarious software contracts.
Same argument as above.
>I have hiring capability and I would hire them.
Where are you located? Do you hire fully remote?
> Do you hire fully remote?
I think this may be the real problem you are facing.
> In the past ten years the main differences in my professional tech stack are that I write Go instead of Java.
Ten years isn't enough time to standardize something and make it a job requirement.
Do you want the list of things that haven't changed since I started programming as a kid?
I still write a lot of Python and shell. I still use Linux, mostly systemd. (I did have to use initscripts early on and do not miss them at all. systemd's way easier.) The entire networking stack has changed only minimally, with only early versions of SSL/TLS becoming obsolete. All the software I use to do my job is the same (A terminal, Vim, Firefox, GNU coreutils, and a smattering of other tools). I still use the same cloud services and databases. The skills I learned in school are equally as useful today as they were then, especially math and CS theory.
The only major shift during my career has been migrating from Linux VMs to containers on clusters (first on Mesos, then Kubernetes). Having administered both at scale, Kubernetes is a lot easier.
> I still write a lot of Python and shell. I still use Linux
All of those listed things have changed. Python went from 2 to 3, number of shells has multiplied like rabbits. Linux changed in leaps and bounds. It got async, BPF, different tech stacks, and window environments.
> Do you want the list of things that haven't changed since I started programming as a kid?
Sure basic principles have remained the same, but huge chunks of ecosystem have been transformed. Perhaps we are looking at it from different perspectives.
It's kinda like ecosystems. Amazon tropical rainforest looks the same now as it did 1000 years ago from birds eye view. But on the ground entire species came and went, and the species living there changed dramatically, in quality and quantity.
My issue is, employers don't want general knowledge, they want an easily slottable asset. You need to know their tech stack. Even if it changes. Hence why LLMs are so in demand.
Python 3 is not that different from Python 2. Yes, if you're a mindless interpreter designed to specifically parse and evaluate Python 2 code, you're going to have a hard time with Python 3. Thankfully, software developers are humans and should not have this issue.
The number of shells that are relevant to any workplace I have worked in have been two, possibly three if you're working somewhere heavily Apple-based. All three of these shells are POSIX-compatible. Other shells exist, but are entirely optional and rarely used (I say this as someone using one of those other shells).
Linux has changed more, and is probably the biggest source of change in the list that the previous poster described, but as they point out, most of these changes make managing Linux systems simpler, and shouldn't really cause significant problems.
I think you're strongly exaggerating the scale of changes here.
> My issue is, employers don't want general knowledge, they want an easily slottable asset. You need to know their tech stack. Even if it changes. Hence why LLMs are so in demand.
I'm a frontend developer. Every job I've had, I was not familiar with the specific framework they were using when I went in for that job. In every case, that's not been a problem at all, because I've been able to clearly demonstrate that I understand the foundation of frontend development, which is far more important than the precise technologies used in the company's framework of choice. My experiences in general are the complete opposite of what you describe here: every single employer that I've worked for has wanted primarily deeper general knowledge rather than specific knowledge of their specific stack.
Maybe this is a market thing — maybe things really are that different here in Europe — but your descriptions do not ring true at all for me.
The comment we are responding to said it takes 3 months for tech skills to go out of date.
> Kafka is out. It's all about Iggy! What do you mean it's different language? Learn it!
Are people really using Iggy/hyping it already? TIL it's now an Apache project[0], that's awesome, it looks impressive!
Sure, most reasonable people are definitely not ripping out Kafka for Iggy yet, but I'm certainly happy to hear it getting more usage/at least being considered.
[0]: https://blog.iggy.rs/posts/apache-incubator/
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.
Realistically, do you not think most of these things are largely solvable by a few, intentional changes to your daily routine?
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.
Realistically, 30 minutes of walking a day is not enough to offset the long hours of sitting (no matter how great the chair is); standing desks aren't necessarily a better solution here either. Gym and healthy eating are a must, but not everyone can afford them (in terms of time).
Anyhow, unlike my non-programmer friends, I can never leave my work - whenever I'm walking my dog, working out, cooking dinner, or taking a shower - I still keep thinking about the things I need to solve, the failing tests, the PR comments, my open-source projects, etc.
Yes, I still love my job and wouldn't trade it for anything else. Sure, I'm very happy that I don't have to leave the house at 2AM to risk my life, but still, it isn't really one of "the easiest careers" - I am easily disposable, I don't ever receive a pension, whenever I need to find another gig - I have to go through seven circles of hell, and it never is the same hell to go through, I have too many bosses, I constantly have to keep learning new skills, routinely prove my worth, and defend my opinions, because even after twenty years of building expertise in various areas, in our field of work, one can never confidently call themselves an expert.
I agree with your posts.
I've been battling RSI and stuff for the past two years and am starting to make progress although it's required me to get both of my wrists fixed and potentially both of my elbows in the future.
It's easy to just say "Oh, do this workout" but it can be very difficult to do that if you either lack the time or have other health issues that prevent you from doing them.
For me, I have rods in my legs and fused ankles so even though I try to hit the treadmill regularly, doing so means I wind up in a lot of pain.
None of this has got in the way of my passion for building software, although for me there is a distinction between what I do (or want to do) in my own time vs. what I have to do for work.
It's a good day when I can really apply myself to a problem at work.
It's less great when for whatever reason, I'm prevented from being able to do a good job.
And the sad thing is that often, you're not prevented from doing a good job because of any technical or time constraint, it's usually all political.
That's the thing that sucks most :)
Good luck doing all of these if you're already in the hole, then.
All those things are solvable. If you choose not to take care of your body, it’s going to fall apart
ever consider moving your body a couple times a week?
My comment wasn't self-referential, I'm not complaining, I do exercise. Have you noticed the use of terms of possibility and not certainty in my prior comment? I'm just stating the general facts on long-term career of a software engineer.
Dont listen to those kids. Ive seen a lot of youngsters coming as Software Engineers. They have no skill, no motivation to learn, they just spend a lot of time in coffe talks and get nice paycheck. If they fail, they are being pet and said: no worry, we will find you easier task to do. And then they come to some "oldfart" engineer and ask him to do the thing.
I have first hand story where my colegue had a cow-worker like this and wanted to get rid of him.. Took whole year to do so, but NO.. he wasnt fired.. he was promoted!!! But my colegue said: At least, we get rid of him :)
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
That does not sound like normal work for a software engineer. That sounds more like you have found an unusually bad workplace. Why are you changing out tools every few months? Why are you working overtime for free? Why is there only one person who knows how to fix things when they break (especially if that happens so regularly that you have one person who "normally" fixes it)?
The other two are dysfunctional but in the US, SWE are pretty much universally classified as exempt and legally aren't entitled to overtime pay.
I see from your bio that you are based in a country with much better worker rights than the US.
Ah, if that's the case I can understand the argument a bit better, but maybe the article should then be titled "the insanity of being in one of the best-paid professions in one of the richest countries in the world, and still having poor working conditions".
> Why are you working overtime for free?
Thats what oncall is, every job ive seen makes you do it
Apparently this is an EU/US thing, because here overtime and on-call is always paid extra (as is essentially anything beyond your usual 40 hrs/week, or whatever you've got in your contract).
That said, I also see very few jobs that involve on-call. Maybe that's because companies know they have to pay extra for it and therefore don't hand it out willy-nilly, but typically there'll be an ops team who do have on-call, and whose job is to triage and fix anything they can, otherwise just minimise the damage, and then maybe the most business-relevant couple of teams will also have an on-call rotation in case the problem can't be solved by ops alone.
Personally, I've never had on-call.
This. I've worked plenty of places that have awful work/life balances, friends that work in the trades are getting 1.5x to 2x on overtime while I'm working 12-16 hour days and weekends for nothing extra except the possibility of getting fired for performance if I didn't.
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.
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.
Exactly. Tell a truck driver, construction worker, farmer, fast food employee how hard your software job is.
I think it's an unfair comparison here.
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.
> I think it's an unfair comparison here.
Don't say that to a truck driver, construction worker, farmer, or fast food employee.
> 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!
Going home at the end of the day and not having to think about work is sure great, except that fast food employee is probably doing their second job. As for that farmer, in one respect or other they're almost certainly operating their own business. Not managing. Operating. They're going to have trouble setting aside the stress of the job at night as well. Construction workers, well, they will be all over the map. Some will be like farmers, operating their own business. Some may be doing heavy or dangerous labor. Day to day, their job may rank as tiring. Over extended periods, they are expending their body. Short of switching to a trade, their career is on a clock. Truck drivers have their own issues to deal with. Again, a lot of them are operating their own business (even when the work arrangements make it feel like they're employed by someone else). If they're working within an urban area, they're typically driving in less than ideal circumstances for hours on end and dealing with a system that tries to make the system's problems the trucker's problems. Some long-haul drivers may earn a decent paycheck, at the cost of being on the road for days on end and being pushed outside of the safety envelope.
So yeah, everyone has something to complain about. But if you want those people to think that SWE's are arrogant jerks, then just go on saying how much worse your job is than yours.
hmm, kind of feel like you're cherry-picking the most difficult versions of those jobs. No need to to into too much depth, but for instance, yeah, not all fast-food employees are working two jobs (many seem to be high-schoolers?). Not all farmers own their own business and are employees. I had a roommate who was a truck driver. He was simply an employee and worked a 9-5 and didn't own his own truck (many of them do, but this is becoming less common).
Although, I agree, there is a lot of blue-collar work that is tough, especially on the body - have done a few weeks of construction work myself, it can destroy your body quickly if you don't learn how to pace yourself and use your body correctly (it's not something I personally would ever want to do long term). But there is also a ton of cushy blue-collar work that are easy - my roommate works at an Amazon warehouse, and she says that her role is mindless work that anyone can do sorting items in boxes.
Yeah, I am probably somewhat biased, but saying that the average fast-food employee's job is more difficult that an average SWE's job (with its deadlines, stress and politics, not to mention all the years of studying), that seems like a stretch. I'm all for the blue-collar worker, but let's be reasonable. Yeah, at least from what I've seen, often, it's not their jobs that are tough, it's the circumstances of their life (many of course are low paying, which makes everything difficult) and lack of advantages they had growing up...
... although, I do admit there are a lot of devs that once they get over the learning curve just coast at their jobs, learning little that is new and working on the same system year after years. Hmm, interesting...
> 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
That’s not normal or typical.
It's actually quite common and typical for freelancers.
Unfortunately when you evaluate a project, initially everything looks and feel just right, that you wouldn't have any problem delivering the end result as soon as possible.
But..! We know how customers ask for small "favors" of "tiny" changes that won't affect the whole project, or so they think(!), which eventually end up delaying the whole development as they become painful hurdles, only to find yourself struggling to deliver the project so you can get paid in time.
Those who know this nightmare, know!
That sounds like a self inflicted problem. If you agree to do free work for customers then don't complain about lack of sleep.
think this is more about that there is a variety of types of work in tech. As you probably have experienced yourself, if you join a fast moving startup, they'll work you to the bone, whereas a large, a wealthy corporation will let you just go to meetings 50% of the time.
I have joined a few fast moving startups and that hasn't been my experience. Moving fast doesn't mean doing more work.
Hmm, i guess in my opinion, think most devs would agree that startups in general are more work than the average corporate job. Maybe we don't have a basis to have a discussion if we don't hold common beliefs in our field. No worries I guess (shrug)
Just want to echo the person who already replied, but contracting is a different world. One might argue that when you're a contractor you're also an independent businessman — and thus you own the responsibility of win or die.
> A developer, programmer, software engineer, call this category of work however you like, it uses the brain at such relentless limits,
Its so weird that development that pays well over $200K uses about 5% of the brainpower I used for college, when I got paid about $9 an hour to clean plates for 40 hours a week.
Maybe it's time to switch to a new role/project?? :)
But, agree, many tech jobs require you to initially mount a difficult learning curve, then coast, doing the same thing over and over (although, for better and for worse, this was rarely what my jobs in tech were like. Was always jumping around having to learn new things).
Truck driver is a special kind of hell because of the time away from home.
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.
Both construction and mowing lawns are two jobs I can say felt much more rewarding than programming. Each day you walked away with a sense of having "built" something (or, er, tidied up in the case of mowing lawns).
And accomplishing anything with your hands and manual labor is instantly gratifying.
There are a lot of programming jobs where people never get to build anything, only fix things that other people didn't do well enough. Many people have never seen greenfield. Other people work jobs where they're pumping out new creative works. So when people talk about how spiritually satisfying programming is we're gonna hear this discordance.
> And accomplishing anything with your hands and manual labor is instantly gratifying.
May I add that Agile (which appears to be the currently prevalent work methodology in SE) takes away much of the gratification of software engineering?
I work in software, farm, and in a restaurant (albeit not fast food).
They are all easy and hard in their own dimensions.
I think you're conflating job satisfaction and the difficulty of doing it.
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?
How about this: tell a truck driver, construction worker, farmer, fast food employee: software engineering is so easy, you should go do it.
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.
Winning in software is as easy as winning in chess. Often times you're making ripples with just the flick of a wrist. You make a few clicks and suddenly you're matched against someone from across the world. Other times you're just staring at the monitor, looking intently but doing nothing.
Even children could make it to the top of the world in this activity of intense sitting.
I guess the argument could be...
They can't do my job.
I won't do theirs.
Actually when I was gutting salmon in Alaska, making pizzas at Godfather's, mowing lawns, working as dishwasher in the dorms to pay tuition ... these all were much less stressful jobs that I look back on almost fondly. (Well, maybe not the cannery.)
Not easy either but they have less of "the reward for work done is more work more learning".
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.
Quite a pronouncement to make with no supporting detail. Reads like troll bait if I'm being honest. But I'll respond in kind:
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.
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.
Easiest careers, but also the hardest job to keep things from becoming an ungodly mess.
I used to work in a hospital. Software ain't bad at all, haha.
At least software engineers can do something to not make a mess or change it. Once you get to real physical world that might not even be realistically done...
I think most jobs are hard, but "grass is always greener" means we focus on what is hard in our job and easy in other jobs.
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.
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.
> 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?"
What’s about sharing documents which is still it’s primary purpose. And most of the current complexity stems from the sprawling JS API surface. We know how to sandbox software (VM and malware analysis,…), browser’s complexity is mostly corporate driven.
I had forgotten the original purpose of web browsers was to view hyperlinked documents. It seems like we abandoned that as the primary use case over 20 years ago, with technology such as Flash, Silverlight, and Java Weblets.
I don’t think that has been its primary purpose for a long time. If you want to share a document for the most part you email it. It has long since moved from documents to applications.
s/sharing/publishing/
The web was never much used for sharing documents in the emailing sense.
Let me update what the OP wrote:
"How do we run arbitrary code on client hardware in a way that's safe for all parties and without installation step?"
15+ years ago, installing software on customers' machines could take days of efforts of dedicated teams. Today it mostly "just works".
Perhaps I was a bit hyperbolic.
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.
VMS was a sandbox-based OS released in the 70s that solved "how do we run arbitrary code on client hardware in a way that's safe for all parties?" Browsers are not that.
Browsers do have this component, but that's not the reason they exist.
I wonder how productive it is to mention that though. Sure, that may not be the reason they exist and came to be (something about exchanging documents) but it may be how they are mostly used today.
You are insisting on justifying all of the complexity of browsers by claiming the same functionality that people got in the 70's with a small OS that was hand-written in assembly.
Sorry, but you don't seem to want a productive discussion. You just have a preconceived idea that turns out to be wrong.
I am not insisting anything. I wanted to point out that the "reason why browsers exist/came to exist" can be relevant in this discussion but is not a direct logical contradiction to their current complexity.
If I say, the pdf came to be in order to be a simple way to digitally represent printed/printable documents that may be correct but wouldn't actually express anything about the current complexity of the pdf format. Admittedly perhaps a bad example due to how similar it is.
It's possible I misunderstood though. If so, I apologize.
and do you think having 20+ different of JS framework is the way to solve it ?
I'm not sure there is anything like it.
Over the course of my three-decade career I worked on apps, system frameworks (none of this web stuff, backend stuff) and nonetheless I too had to learn all manner of new (to me) languages, API, frameworks, tools, etc. And that doesn't really cover the changes in how software is created/delivered: agile development, tech-lead driven, QA then no QA, unit tests, code reviews, etc. Always a moving target.
(To add some examples.
Some languages I have known: Pascal, C, 6502 assembly, (introduction of the PPC and with it a whole suite of new callbacks), C++, Objective-C, (introduction of Intel hardware and now endianness issues), Javascript, Swift.
When I started my career, being good about managing memory, keeping things small and fast, was a sought after skill. Somewhere about halfway through my career you had to be an expert in concurrency — you had to be able to hold in your head multiple processes running where one can complete before another, where several threads might read or write to shared variables, and UI is being updated on the main thread, etc.)
And it was unevenly distributed as well. At Apple (and likely other big companies) there were "good" and "bad" teams. And I use the quotes because I think it is often relative for the specific engineer. That is, a team I dislike — perhaps it's a highly competitive team, or one under the company spotlight — another may thrive in.
After working for a few years on a particularly "bad" team, I, strangely, developed serious gastrointestinal issues that required surgery and the removal of part of my intestinal tract. Coincidence? I have no idea. But I tell people still in the field to take stress seriously.
Also anecdotal: as someone who still writes checks to pay many of my bills, I can tell you that I noticed my signature was shit during periods of stress, only got relaxed and smooth again when I was also able to relax. I watch my signature now for signs that I am tense.
> tech-lead driven
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.
It's maybe a bit orthogonal? (Or maybe misleading.) I'll fill in with anecdotes and try to make more sense:
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. ;-)
> For many engineers (and me of course) this can be the most rewarding way to work.
Agreed, this is also the world I grew up in. Nothing is as rewarding as working on something where you have ownership to set the direction and deliver.
For most of my career I had never heard of "product managers" and it was bliss. Somehwere along the line software engineer transformed from being the intellectual lead of the business, to simply a ticket-taker writing code for things some completely non-technical "product managers" decided should be done this week. And the inability to be allowed to think or plan for anything beyond a two week sprint window is mentally crushing.
I've moved to different roles now since software engineering became such a miserable job. I'd jump back in a heartbeat though if there was a company operating like we did in the 80s and 90s where engineers owned engineering.
How much time have you invested into it as a skill set ?
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.
Similar to the other reply, I don't manage people or drive the methodology changes.
I'm dev lead on a small (3 dev) sub-team within the larger platform team. We generally follow the same methodology as the rest of dev. They're reportedly following agile but it has the classic hallmarks of being driven by senior management: little/no training or education in agile (even in product), devs don't speak to clients, retros are consistently cancelled for lack of time, process changes are dictated by the product team (which is managed by the company's MD), etc... . I'm actually not convinced that the company can pull off agile. Partly because management don't understand it, and partly because our major business client are rigid about roadmaps and deadlines. Also partly because my own sub-team engages in research-heavy, long-term features. A lot of our work consists of thinking up blue-skies algorithm changes, trying them out, and going back to the drawing board if it doesn't pan out. Month-long iterations of work with potentially no viable changes after each one. When I read about agile it tends to describe stuff where you can muster up an MVP for a feature within a week or two at most, so it has been tricky to interpret how to apply it.
So basically, it's not working great and I have limited influence to change things. What I can do is fight my team's corner with well-backed arguments. E.g. there was recently a period of a few months where the entire platform team (~25 people) took part in a daily standup lasting 30 mins on average, on top of their own squad catchups. This was obviously wasteful but the engineering manager liked feeling ontop of things. After I repeatedly raised the issue, the frequency got dropped to weekly for my team and twice-weekly for the wider team. So I'm keen to learn more about agile vs alternative systems so I can continue to fight effectively my team's corner in this way. The ideal end-goal would be to extricate my team entirely from this half-baked agile mess, whether that means following agile more "correctly" or switching to something more bespoke. I appreciate the references and have started glancing through "Agile Estimations and Planning", it's okay so far but nothing revelatory. I don't have a lot of time to devote to this so I'm naturally skeptical of "just put in lots of hours of reading and I'm sure you'll see the benefit".
I wasn't the manager calling the shots. As an engineer though it will always be abominable to me. Others, as I say, like it.
> 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.
>All of this complexity is there for a reason
Having gone from junior Web designer/developer to CTO/CPO and then into startups over the last 25 years, I'm absolutely convinced that the reasons for complexity in what we do day to day now is for no good reason other than CV building for FAANG type job hunting, job niche building and job security self-indulgence, and a fundamental disregard for maturing the industry.
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 ?
Imo this is the root problem with SWE as a profession: the best solution to most problem is usually very simple aka career suicide.
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.
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.
> blame the engineers for the complexity
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.
Nope, engineers are engineers because they push back on bad decisions. I don't consider web devs engineers because they refuse to take responsibility for their actions
> 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.
> You do a good job. You’re promoted to manager. You need to learn a whole other job
Relevant: https://nebula.tv/videos/coldfusion-why-are-managers-so-bad-... (or https://www.youtube.com/watch?v=m7-UdDg5uIw if Nebula won't show it to you)
The tl;dw is that quite obviously the years and years spent learning one skillset absolutely does not translate into the ability to "debug humans"
a.k.a. the Peter Principle
https://en.wikipedia.org/wiki/Peter_principle
That was one of the main topics of the video, yes, but the rest of it looked at some research into how to address it. One study showed that just promoting people at random had better outcomes, and a separate study showed that "up or out" was also effective. I would guess that the choice between them is mostly about the culture of the organization
I'd like to read that random promotion paper. I wonder how high up they actually implemented this strategy, because the idea of the CEO just being the person that chosen at random more than anyone else is hilarious to me.
My mental model is that "promotion" is something that only happens to middle managers; board relevant seats are either appointed by the board or come from the good ole' boy network (which I do recognize is almost certainly worse than promoting a bad manager from within, who at least has existing relationships and business context)
As best I can tell, it's this one https://www.sciencedirect.com/science/article/abs/pii/S03784...
> Then came DevOps. Some cash-strapped company somewhere decided that now all of this would be handled by the engineers and everyone agreed.
Gave me a chuckle. I don’t think it was a cash strapped company but yea that’s pretty much what happened.
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.
> "We work onsite, 7 days a week"
That's how you get them pyramids built! Onsite weeklong lashings!
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.
Front-line managers and PM’s have the same incentives.
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.
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.
This should be called "The Insanity of Being a Web Developer". You can be an SE without ever touching JS.
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.
This, some people recently forwarded a "tech pay" survey to all dev teams (ours does C++/Qt desktop software), and there was only (basically) "Frontend dev", "Backend dev" and "AI/ML dev" in the job list.
It reminded me of that KotH skit "- So, are you Chinese or Japanese? - Huh, I come from Laos and... - Chinese, or Japanese?".
Crooter: "So tell me about your work at XXX Robotics. Was it more front-end or back-end?"
Me: "It was robot control software. It controlled a robot. Also I did some UI work, based on the same framework as the control software itself."
Crooter: "Ah-huh, and which database did you use? Oracle? MySQL?"
I feel the opposite. Sometimes I feel non-web developers don’t consider web devs as “real devs”, esp. the frontend ones.
This is an extremely mild version of what it feels like to be a minority. Web developers are the most common type of developer. It is simply natural for them to equate "developers" and "software developers". Out of sight, out of mind. It's not a hostile thing, it's not something people necessarily want to do. But it still happens. It's a human thing.
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.
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.
Absolutely & very well said - my contention lies in the fact that certain skills are just that - technical. Especially when it comes to architecture, code, complex systems and so on.
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.
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.
Awesome! I am about halfway (~25 years) in and all I needed so far was C#/SQL Server/VS etc. Do you think I can get away for another 15 years?
Specialization hasn't occurred because everything keeps changing and specialists become either stagnant, bored or unemployable.
The size of a brick was standardized in 1840, then 1970 for metric. Let's get that kind of stability in software before we start specializing
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!)
Your second category inncludes those adept at "making the problem smaller".
Not always easy, but that is the first thing that comes to mind, no matter the context.
This is a great point. The first question a great software engineer should ask is “how can we avoid using software to do this?”!
I'm always reminded of the software optimisation hierarchy, smallest to highest impact:
1. Micro-optimisation, e.g. programming language choice, tightening a loop, cache hits etc.,
2. Change the algorithms,
3. Change the problem.
Sometimes changing the problem makes the software completely go away!
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.
"If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization." - Gerald Weinberg
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.
How would that not rot and be full of leaky abstractions?
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.
> 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.
> 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.
IMO most of this boils down to understanding if you need SEO or not. There’s no right general answer
I tend to think all jobs are exactly as hard as the people doing them can handle.
It plays well to the myth of the hard worker. We're all rugged individualists.
It means companies soak as much work as possible from labor. We're all exploited.
And we all accept that without question because it's the status quo.
As a software engineer myself, I agree that there are certain aspects of the job that are annoying or mentally fatiguing.
That said, unfortunately I had to learn much more than I had wanted about the work of neurosurgeons and ICU units three years ago.
This made me completely rethink the difficulties I face at work so I no longer complain.
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)
That just sounds like a knowledge work job.
Lots of knowledge. It’s moving. And you don’t know it all. You learn and muddle through.
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.
I really liked your article; it expresses more or less my own personal concerns around technology.
I am certain that whenever the opportunity arises to change my professional direction, I will do it immediately.
To me personally, as a profession, technology is not worth it anymore; it has lost its meaning.
I just use it as my leisure, nothing more.
It's not that all of this is hard. Staying afloat is actually easy by mimicking whatever you see around. I guess it's akin to blissfully selling CDOs all around, right before the 2008 market crash.
It's just that it's impossible to master the tools. We lie to ourselves thinking that we do, but when shit hits the fan, we're as powerless as anyone in the madhouse to figure out what is actually going on. We're all emperors with no clothes.
Individually we know we're naked, but somehow, we think that someone out there isn't. Someone knows what they're doing. No they don't.
Throwing LLMs into the mix will only supercharge the madness.
This whole thing is a collective suicide pact.
Very much a case of “grass is always greener”. I work in pre-sales at $FAANG and would do everything to take a 20% pay cut and go work a low pressure SWE role flinging golang around.
My lord… the lack of political maneuvering, fiefdom building and defending, workaholics chasing deals and responses through the weekend or first thing at 5:30am when they wake up…
I did a short stint as part of a pro services team at a SaaS once. Some of the most fun I’ve had, moderate to low pressure, interesting but not overly challenging problems, mostly a creativity challenge not “configure systemd” challenges.
Now I know whT you’re thinking: “oh but here in SWE land we have all the problems you mentioned too!”
Yep that’s my point.
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
Related: https://www.stilldrinking.org/programming-sucks
> Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro,1 you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”
> They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.
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.
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.
Other then all the frameworks you need learn, if you are not an expert in a specific field, in my experience, you are completely disposable as well.
The insanity of modernity, progress and change.
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.
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.
not many professions allow me to work from home in my underwear for good sums of money
That sounds compatible with insanity.
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.
Article completely forgot what's really important: software is supposed to provide value to users so SWEs need to understand the domain and design a system that does so. Some might say that it's the job of the business analyst but the BA doesn't design the system or feature.
So happy humans will be able to stop using their brains soon due to AI !
For a profession that has improved the world so much, we are a pessimistic lot aren’t we?
This was a fun read.
We’ll keep raising the amount of knowledge needed to be employed until it’s no longer sustainable. This is just the nature of capitalism: extracting as much value from someone’s salary as possible.
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.
This is why we pay experts a lot of money.
I mean, my friend's wife is an eye surgeon. My husband's cousin is a pediatrician, with neonatal specialty. I'll take software engineering.
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 the trouble with healthcare is it's secure if you're willing to work the shifts. Even dentists are often working long hours and on weekends etc. (although I don't think night shift is a thing). Even the best doctor will struggle to find a 9-5 that they leave on time every day. Swings and roundabouts.
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.
All this is still way simpler than designing and building bridges, for example.
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.
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.
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.
You haven't been tasked with mobile and AI ... YET !
uhh just use vite
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
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.
> It's not an "incredibly easy career", otherwise everyone would do it.
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.
If people don't care about work being easy, then all the people in this thread should stop telling people they're not allowed to complain because their job is easy. The job being easy either matters or it doesn't.
The job being easy doesn't matter, but neither do anyone's arbitrary statements.
There are plenty of people who would do uninteresting work for many multiples of median wage. Jobs like factory workers and postal sorting etc. have high turnover because they offer neither interesting work nor good pay. I've never worked with anyone who left software because they weren't autistic enough to find it interesting.
> There are plenty of people who would do uninteresting work for many multiples of median wage.
Sure. We've all watched an increasing number of these people arrive in the software industry over the years. But they are not representative of everyone. Plenty of people can't force themselves out of bed in the morning for money alone. If they could, they'd be working in software.
> Jobs like factory workers and postal sorting etc. have high turnover because they offer neither interesting work nor good pay.
Manufacturing especially offers the illusion of interesting work. In fact, there is a whole political thing going on in the US right now trying to increase manufacturing job availability because of that illusion. I expect you are right that people are going to find out that it isn't what it seems, but so long as they believe it before they try it... Software, on the other hand, doesn't even try to pretend.