No, it isn't. Software engineering is one of the easiest careers. We are so coddled that we think what is described in this post is tough, that alone is evidence of how not tough our career is.
I’ve had a wildly successful career in tech where I’ve gotten to do, what to me are crazy impressive things (I don’t want to brag about here but you may have benefited from some of it, certainly all of you have done more impressive things than me, and thank you for that) and I don’t regret it a day, but as someone that’s worked in those " normal jobs", other than factory work I found the jobs themselves WILDLY more satisfying than anything I’m doing today.
Tech work did used to be a lot better and I still love learning new things but if I could make a few hundred grand a year and never do another OKR and garden I would take that so quickly you can’t even imagine (actually I’d take it for a 100 grand year).
Now I’m old and I have people that depend on me, so I do the OKR shuffle and play all the politics, and even lead on new tech that I think is being misapplied in the org but hell if I can get anyone to believe me and just use SQLite. But if I was single and had no kids, I’d gladly give up the 6 figure lifestyle to get my hands in the dirt again or even get through a hard rush in the kitchen with the team, there was so much more worthwhile about the jobs I had before, it was just the benefits sucked and couldn’t support a family in the USA without a lot of luck and sacrifice.
I think maybe it is possible that most of you that think these other jobs are so hard just didn’t come from a family where they were normal, but for me they were, and I don’t see anything wrong with them other than the pay and the benefits. They’re honest work.
That said I’d be ok if technology companies just let us do our jobs without all the bizarre AMA, self help talk and bizarre behavior from management.
The thing is, it's a job that needs creativity, spontaneous decision making as well as personal responsibility for those decisions. It's a real easy job if you don't need to take this responsibility (e.g. those who come after me when I am long gone have to deal with the consequences). It becomes a hard job the instant that you have some passion or ethical concerns that drive you to create software that holds up to your own high standards and requirements.
I think that's what makes it so hard for many. We are incredibly passionate (why would we be on this forum in our free time otherwise) but we constantly have to betray our own principles to make it work or stay employed.
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.
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.
Just wanted to say that's impressive.
I do get pleasure when building software, but like many others I also dream about starting a farm to diversify my income and get some physical work regularly.
I worked on a farm and I find this romanticising outright ridiculous because I don't think a lot of you understand just how hard is it to actually make a living from the land.
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.
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.
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.
Unfortunately that has also pushed lots of good engineers to either disengage or work extra hard to push things through despite organizational problems (I seem to alternate between both but I feel too responsible to really disengage).
Often I wonder why can’t it be easier?
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?
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.
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.
If I understand you correctly, it is an argument to not pursue software development?
I agree, I am mostly in it for the money and my own curiosity.
And I do see that it sometimes solves real problems, like removing landmines. But it's rare.
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.
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.
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.
There's a lot of stuff in the industry to suck any joy out of writing software
Still, for me, at some level always enjoy the act of building something that needs to function in the demanding environment of the digital world (especially, high-volume applications). Yeah, it requires you to use your experience and training to solve difficult problems and produce a real result. For me at least, this typically enough to keep me going:)
I think you just described most people who aren't SE's. The only difference is that they can't land better paying jobs.
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.
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.
Are you sure?
Compare working in big law to big tech, and it will be plain as day. And I am not even getting into the baseline requirements to get there (undergrad from a good school with great GPA, LSAT, a top law school that is gonna cost you a pretty penny, hustling for internships, BAR, etc.), which SWE as a career has pretty much none of. The overall work-life balance difference alone is crazy.
Not everyone works in big tech. A lot of devs worldwide work in mom and pop shops, legacy businesses, or various consultancy/body shops. Big-tech workers are the exception, not the rule, except maybe for the US workers.
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
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).
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.
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
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.
But most jobs are tough - in some way.
Software Engineering is one of the most information-volatile industries in history that I can think of.
You have to aggressively keep pace with potentially, and I’m guessing here, the fastest shifting industry in history in terms of practices and knowledge and improvements.
Not only that, it is constant failure and obstacles - bugs, frameworks, features, platforms, what have you - and constant layers of abstraction. A lot of the time you cannot visualise any outputs.
Software Engineering is a highly skilled industry, and probably the most competitive industry in the world, with a very high rate of uncertainty and layoffs and change. We are working with some of the most complex systems created by man in history.
I don’t think you can make a broad generalisation that we are coddled lol. Software Engineers in the USA in certain population centres earn a large salary, sure, but look overseas and comparatively that is not the case.
Seriously, by what metric is Software Engineering one of the easiest careers? I’d like to hear your viewpoint because I think it’s so off-base that I must be missing something.
It has its definite perks like work from home.
But Software is up there as one of the toughest knowledge-worker industries there is.
There are much tougher careers like anything Electrical Engineering, but by no yardstick is Software easy
It may be fair to say that it wants to work its way towards that as the industry matures, but that hasn't been the case. People have been able to make insane amounts of money in software. You cannot make money in a competitive industry.
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.
One friend had just finished a 3 month program to certify to fly a certain type of airliner. They probably had more intense study and testing in 3 months than most people do in a 4 year undergraduate program, SWE included.
-Those tests are no joke, but saying they are more intense than a 4 year CS degree is ridiculous. Also the major airlines you can compare to FAANG, and many people study for 6+ months to pass those interviews - Airlines are union jobs. If you get them you aren't getting fired unless you try to do something really stupid. - There isn't any wondering if you are doing a good job or not , and you don't take any work home. - Regulations change or you can switch planes, but the career is leaps and bounds more static then SWE.
Net net is that they are very different jobs. SWE is a great gig overall but I take issues with people saying how much harder or easier it is than other jobs. "It depends" is the answer.
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.
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...
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?
Yah. Profusion of terminology is confusing.
There are many blue collar jobs that require a lot of education and the consequences of errors is loss of life.
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."
On the contrary you can absolutely be a white collar worker with low social standing in the US. It's not hard, I'd even argue most white collar workers fit that description. Think of a customer support representative working in a call center for wages. Their job is definitely white collar but it does not pay well and is the type of job you typically associate with someone struggling financially. Not someone of high "social standing".
In the US blue collar/white collar does not directly correlate to low/high social status. While it is probably true that white collar work is correlated with higher wages or salaries, it's the money that drives social status, not the color of your collar.
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.
Being proud of that is like being proud of a six figure salary in California.
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.
Seems shocking that a SV swe would make what a mech eng makes after 4 years.
Industries with difficult certifications tend to protect those when awarded. It’s a grind to get in but then the employment is easy and lucrative.
This is the promise of a career as a pilot or doctor. (Inb4 doctors do hard things)
In contrast, industries that are lucrative but have a low barrier to entry (sales, real estate, etc) tend to have direct performance competition.
In software by the time you finish your 3 months course the tech is considered obsolete.
Not just Frontend. Backend can change on a dime.
Elastic/MySQL/CockroachDB is using different license that's incompatible to AWS. We have to switch our stack!
Kafka is out. It's all about Iggy! What do you mean it's different language? Learn it!
Things can be hard in different ways. After coding for whole week doing garden work can almost come as a relief.
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.
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.
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.
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?
I think this may be the real problem you are facing.
Ten years isn't enough time to standardize something and make it a job requirement.
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.
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.
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.
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.
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.
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.
That's the thing that sucks most :)
But younger kids seem oblivious to what kind of damage this line of work does to your body, and it's pretty much unavoidable. They'd be "Ah, so what that I've been typing for fourteen hours straight? My knees are fine; I can just walk it off...". Yeah, well, try figuring out your Python dependency conflicts or broken GitHub Actions, or focus on some concurrency bug when your sciatic nerve is pinching or your neck hurts like you received a bullet straight under your shoulder blade.
I'll see how they sing their "the easiest job ever" song when they get to experience chronic pain and become nearly incapable of sitting in front of the screen, not even for forty minutes, let alone hours.
This isn't an axiomatic quality of software engineering though. For every developer with your level of dedication (obsession? anxiety?), how many developers log off at 5 and compartmentalize their work away from their personal life?
That being said, your other paragraphs are pretty agreeable to me.
Programming is an act of creation. Any creative worker - artists, sculptors, novelists, potters will agree, you cannot timebox your creation - it creeps back into your life even when you're away from your studio, from your desk.
I have worked in several different countries. With diverse teams of programmers of different levels of expertise. Different stacks, various types of industries. Most programmers are creators. Those who log off at 5, don't think about it and keep it separate from their lives are "office workers" at best - maybe not even programmers, I'm not sure what to call them. I met that kind of people only twice (with some stretching, maybe three times) during my work life. Both of them ended up switching to different roles later. So, yes, to a certain degree it is perhaps "an axiomatic quality" after all.
The human body is designed for movement, and sedentary behavior disrupts metabolic processes, affects posture, and almost unavoidably results in weakened muscles and bones.
Staring at screens for extended periods leads to digital eye strain - dryness, irritation, blurred vision, headaches. Prolonged screen time can also disrupt sleep patterns which affects melatonin production. Additionally, it too, contributes to poor posture and musculoskeletal issues, particularly in the neck and shoulders.
Typing for long hours leads to repetitive strain injuries - carpal tunnel syndrome, tendonitis, and muscle fatigue in the hands, wrists, and arms.
If you think you can undo decades of harm to your body by occasional exercise, well, I have bad news for you. If you think you can just hop around like a butterfly when you need to do something like setting up a Kafka cluster from scratch, which requires you to have a combination of technical skills and extended periods of sedentary work, screen time, and typing - something that can't be done "very quickly and only once," you're thinking of some other profession, not this. Extend that to five days a week, for many years - that's what's required - you'll find yourself primarily sitting, staring at the screen, and typing during most of your waking hours. This is a typical facet of a programmer's life.
Software development career WILL harm your body, and there are only limited things you can do about it, and only to the effect of mitigation - there's no magical cure, remedy, or escape.
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 :)
Experience in our field is a double-edged sword - at times it can feel like a burden that pushes intuition away from the objectives. After all - we're all junior SEs - whenever we need to start a new project - we have to learn or at least refresh our knowledge. Just because a kid fresh from college doesn't know how to use Makefiles, can't write C without memory leaks, or hasn't used Vim keybindings and panics when seeing Emacs, doesn't mean they lack programming talent.
Industry shifted into weird direction here.. Youngsters are pet while old engineers that had knowledge and experience where squeezed more and more... It really makes you demotivated..
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
Thats what oncall is, every job ive seen makes you do it
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.
I see from your bio that you are based in a country with much better worker rights than the US.
I've worked construction when I was younger and wouldn't want to be still doing it at my age, it was physically harder but I wouldn't say it was tough work and at the end of the day I'd leave and not think about it again until I showed up the next day.
Have you ever heard of a modern software engineer who landed in jail because their error was part of an incident thst costed others their lives? Typically software errors are shrugged away as if they are extreme wheather events thst nobody can change.
Creating usable elegant, efficient, reliable, testable and maintainable software isn't trivial, but it is doable and the consequences to not getting it 100% right are usually comparably mild.
If I fuck up a part of code I usually produce a crash, patch it and I am good to go, if I select the wrong cables and put them into a building, I either cause a fire or I have to tear the whole building open to replace them, and let's not talk about civil engineering..
I remember sitting in a class of 30 people where people had over 30 different solutions to a complex load calculation of the kind that could kill people if it was realized.
Especially love the classic “Well, that’s not normal, only what I am familiar with is normal, because everybody thinks like me”-flavored responses. Obviously it’s not normal to work overtime or crunch because I’ve never done it. (Just ignore https://en.m.wikipedia.org/wiki/Crunch_(video_games) and go back to shittalking SWE.)
Viewer: “Streaming is so easy, you’re basically not even working, streamers are so privileged.”
Streamer: “Can you act?”
Viewer: “No, but what -“
Streamer: “Ok so you can’t act. Have you ever tried acting out a play, but it’s 6 hours long and also hundreds of people get to shout obscenities at you, and also you’re sometimes obligated to respond to their disturbing comments completely ad-lib without breaking character, and also you have to be juggling at the same time?”
Viewer: “… well I still think <INSERT JOB> is harder”
It doesn’t take a genius to realize there a different dimensions of difficulty and yet somehow many people can’t
A developer, programmer, software engineer, call this category of work however you like, it uses the brain at such relentless limits, implicitly or explicitly depending on the problem a person it's currently working on, it takes an incredible amount of effort to relax your mind at the end of the day.
I remember working on a very difficult project for a customer and I would sleep for 4-5 hours per day until I deliver it, and by the end of the project I was so exhausted that I had to take a whole week to cool down my brain and relax my body.
It took me a whole month to fully recover!
I have worked as a construction worker with my father and I know how to grow my own fruits and veggies; I know the struggles with those things...but trust me, you cannot compare the two by any means!
Using your body exclusively it can be tiring indeed, but at the end of the day, you will have a nice shower, eat and rest well, and the next day you will be good to go; whereas with using your mind exclusively can be so dangerous in so many ways!
At least, that's my case.
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.
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'm not going to pretend that software development is devoid of stress. That said, virtually every job has stress, deadlines, politics, and other such nonsense.
Yeah, at least to me in this thread, seems like we were referring to jobs themselves, not their overall lives.
But, I do agree, if we look at their lives overall compared to white collar, it seems like it can be just as stressful, especially because of the lack advantages growing up (growing up in a stable financial household, education, resources...).
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.
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).
That’s not normal or typical.
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!
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.
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?
They are all easy and hard in their own dimensions.
Software engineering can bring immense joy, but it is often a hard job to do. While it may not be physically demanding like some trades, it is often intellectually demanding and stressful, especially with tight deadlines and evolving technologies.
You know that intellectual tasks, such as those found in software engineering, can require significant mental effort and may burn more calories than some physical jobs due to constant cognitive engagement and stress?
Even children could make it to the top of the world in this activity of intense sitting.
Clearly, being a truck driver, construction worker, farmer, fast food employee is easier for them, and software engineering is harder, otherwise they would have switched to the easier and better paying job.
They can't do my job.
I won't do theirs.
Just because the stress is mental and not physical, doesn't mean it doesn't exist. Ever heard of burnout?
Yes, it is. Tough is relative.
There is no "we" to be coddled, only your flawed perception of a difficult-to-grasp, heterogeneous whole.
There is no "we" to form a single impression of what is described in the post.
Rhetoric isn't evidence.
A doctor can’t give you aspirin without 2+ layers of administration to do the medical coding. I can only guess what bullshit liability insurance and licensure entails.
Knowledge work is usually paid because it isn’t trivial.
True that the other jobs are usually treated very poorly, though.
Yes it is. I can name a number of careers that are easier. Start with accounting or tax prep or mechanic or welder or barber or nail salon anything, on and on. Ridiculous.
Over the course of my three-decade career I worked on apps, system frameworks (none of this web stuff, backend stuff) and nonetheless I too had to learn all manner of new (to me) languages, API, frameworks, tools, etc. And that doesn't really cover the changes in how software is created/delivered: agile development, tech-lead driven, QA then no QA, unit tests, code reviews, etc. Always a moving target.
(To add some examples.
Some languages I have known: Pascal, C, 6502 assembly, (introduction of the PPC and with it a whole suite of new callbacks), C++, Objective-C, (introduction of Intel hardware and now endianness issues), Javascript, Swift.
When I started my career, being good about managing memory, keeping things small and fast, was a sought after skill. Somewhere about halfway through my career you had to be an expert in concurrency — you had to be able to hold in your head multiple processes running where one can complete before another, where several threads might read or write to shared variables, and UI is being updated on the main thread, etc.)
And it was unevenly distributed as well. At Apple (and likely other big companies) there were "good" and "bad" teams. And I use the quotes because I think it is often relative for the specific engineer. That is, a team I dislike — perhaps it's a highly competitive team, or one under the company spotlight — another may thrive in.
After working for a few years on a particularly "bad" team, I, strangely, developed serious gastrointestinal issues that required surgery and the removal of part of my intestinal tract. Coincidence? I have no idea. But I tell people still in the field to take stress seriously.
Also anecdotal: as someone who still writes checks to pay many of my bills, I can tell you that I noticed my signature was shit during periods of stress, only got relaxed and smooth again when I was also able to relax. I watch my signature now for signs that I am tense.
Would you expand on this please? Especially how it differs to agile. Very keen to learn alternative approaches, as a tech lead struggling struggling with the company's half-baked attempts to go agile.
When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform.
So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded.
And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team:
We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing).
I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions).
I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it.
For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own".
And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code.
For many engineers (and me of course) this can be the most rewarding way to work.
The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?"
They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)
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.
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.
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".
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.
The web was never much used for sharing documents in the emailing sense.
"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".
Browsers do have this component, but that's not the reason they exist.
Sorry, but you don't seem to want a productive discussion. You just have a preconceived idea that turns out to be wrong.
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.
Some subset of added complexity is justified as the problems we’ve tried to solve have gotten more complex.
Another subset is added complexity for the reasons I listed (no good feedback loops to prevent it), which is imo not good. I also feel that this subset is larger than the first subset.
Having gone from junior Web designer/developer to CTO/CPO and then into startups over the last 25 years, I'm absolutely convinced that the reasons for complexity in what we do day to day now is for no good reason other than CV building for FAANG type job hunting, job niche building and job security self-indulgence, and a fundamental disregard for maturing the industry.
Whilst I somewhat agree with the op I think it’s as much a hiring / resourcing issue. Hiring managers often want experts in the tech stack and domain and overlook mastery of similarly complex topics as a good proxy for ability to pick up whatever their specifics are. And the expectation of that person also having enough generalist knowledge to do gui, qa & infra as well as the rest of the engineering process.
In that regard as cto are you part of the problem or aiming to be part of the solution ?
Managers of humans build artificial empires to climb the ladder.
Managers of machines build artificial complexity to climb the ladder.
Bad for the parent org, but necessary to pad the CV.
Yet doing everything from first-principles is not viable, nor is focusing only on non-functional requirements. The solution is engineering leadership that values code not written, dependencies not added. They wince at a big commit. Every component must pull its weight. They use every part of every component and dwell in the community of it. If they don't have time for a new community, they hire a new person who does, and they may represent a new specialization on your team.
A solid team needs 5 people. CSS and Figma ('designer'). SPA ('front-end eng'). The appservers, database and outward api calls ('backend eng'). Infrastructure and CI/CD ('devops'). Finally, you need a person who owns goals, measuring past and articulating future, and take point on user and business comms ('product'). Project management can be a part-time role of anyone on the team, but fits well with product. I do not think a single human mind can be a designer/front-end/back-end/devops role and do a good job. They just don't have time to learn and stay up-to-date with all of that, and it requires an untenable amount of context switching.
I was going to add that the engineers themselves do (or should, in a healthy organisation) have the mandate to knowingly choose not to bring in artifical complexity where it's not useful or required.
But then I thought that in a lot of situtations perhaps the engineers aren't really 'Knowingly choosing not to' but 'Unknowingly choosing to' bring in that complexity, because the volume of content and mindshare that goes into proposing new and alternate ways of working and tools that aren't actually different seems to dwarf the amount of information around fundamentals and things that don't change as often.
So perhaps any accountability really should go as much to CTOs, open source developers trying to make their mark, influencers.
It seems like what we need is a sort of an integrated virtual machine for each application. The OS provides a virtual CPU+memory machine, but that needs to extend to virtual filesystem, peripherals, displays (which the OS would draw into a window), network with user-limitable urls, etc. This would prevent apps from misusing the filesystem, enable users to limit surveillance network requests, and simplify graphics.
I think there is both an inherent complexity and artificial (or 'introduced') complexity in software.
Inherent complexity comes from increasing expectations over what kinds of software we want to write (the evolution of the web and browser 'features' since its initial inception, the kinds of interaction on mobile, tablet and desktop devices) and _how_ we want to write that.
Some amount of higher-level tooling is almost a necessity because the absolute amount of lower-level things needed to make the more powerful abstractions work is too high to deal with practical. Want to write a cross-platform fully-featured-with-animation UI toolkit with just the raw hardware in your desktop? Fantastic exercise for learning, but you're almost guaranteed to start reaching for higher-level tools at some point in the journey.
The growth in artificial complexity, however, comes from so many places (including all the ones you listed).
Sometimes it's from processes and ways of working that are introduced (I sure hope you do fully automated releasable builds including management of the computers that do those).
Sometimes it's from socio-technical problems (working in a single shared code base and having to coordinate changes and releases? Surely it would be easier for teams to never have to talk to each other and just release small things independently...).
Sometimes it's from an approach to building software that is perceived as better, easier and faster (shipping a desktop application? Wouldn't it be so much easier to just bundle a full UI layout engine, scripting language interpreter, hierarchical appearance control syntax, portable bytecode interpreter and some application code that was itself compiled from a _different_ language so it could be interpreted by the interpreter you actually shipped...)
Sometimes it's from system design approaches that are pushed as 'best practice' and introduced without necessarily understanding whether you ever had the problem they were intended to solve (please, tell me more about how your relatively small ecommerce application needed to be event based in order to 'scale up').
Sometime it's because the handful of companies shipping acceleration hardware have practically zero commercial incentive to standardise on an API for writing programs that can run on said hardware, giving us a world with four (at least) slightly different syntaxes that all sort-of-mostly accomplish the same thing while being awkwardly different.
I could go on...
Not that some of the artifical introduced complexity doesn't sometimes solve actual problems or be an overall-useful thing to have. No criticism here on introducing software-based processes to formalise things, improve software quality, and so on.
But it's useful to keep in mind how much of the complexity is introduced to improve overall processes versus 'solving' for some local maxima by adding more tech without the overall software quality improving, with the end result being we've made our own lives worse in some way, without measurably improving the resulting application.
You would be surprised. While it stays more or less true for low-education job, I find that any job that require more than a high-school diploma suffer from the same problem. We are asked to be more and more polyvalent, and every job offer has a laundry list of skills that we are supposed to master.
When you think about it, it makes a lot of sense: Why pay two expert when one person with just enough knowledge can wing it ? Unless the job/task is highly regulated (you don't wing accounting) or the output quality really matter, a half-ass job is often 99% enough.
Taking about building a house, you can kind of see it actually. A lot of building company are doing the bare minimum, which is why inspection is critical.
It reminded me of that KotH skit "- So, are you Chinese or Japanese? - Huh, I come from Laos and... - Chinese, or Japanese?".
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?"
Compared to "programmer" or "developer", it just sounds like gluing bits of CRUD together and making it seem more advanced than it really is by way of fancy title. "Prompt engineer" being the natural next step.
Sorry if you're called/call yourself a SE, (probably) nothing against you personally :D
I've never touch JS in my daily work, or html, or php, or anything like that. Also no golang or whatever the cool kids are using. When i said i'm developer, people always assume i'm some web developer lol. Lady i know how tcp/ip work, but anything higher is a strange land to me.
I've worked at companies where everyone, all the way up to the SVP (who reports to the CEO) is still very sharp technically. Meaning, the SVP and everyone below them could legitimately pass the Senior Software Engineer interview, or at the very least speak intelligently about the sw architecture, the reasoning behind the technical and design decisions made, performance trade-offs, security, and so on. If you've never worked for a place like that, it's almost hard to believe what it's like.
I've also worked at a (fortunately only one) company, where as a leaf-node employee, my first level manager was effectively tech illiterate. Those kinds of places need their individual engineers to all 1. have good tech skills, and 2. have those rare communication/translation skills that translate tech concepts/problems into business-speek.
At most companies, the point at which a technically literate employee reports to a tech-illiterate employee is somewhere up the management hierarchy--usually around "Director" level. Wherever that point on the org chart is, that person's direct reports are the ones who need to have those tech-to-non-tech translation skills.
I don't mind an illiterate Executive when it comes to basic manufacturing, cosmetics and so on - but when it comes to STEM subjects it becomes a dangerous gamble - especially when it comes to recognize a strong vs weak player.
Too many times I've seen weaker players get bumped up as the executive in charge is somewhat incompetent...
I've been lucky as my family forged my communication skills at a young age - but these days this is rare and I see extremely competent young players get sidelined quite rapidly... Hope is a mystery, but can be found.
Relevant: https://nebula.tv/videos/coldfusion-why-are-managers-so-bad-... (or https://www.youtube.com/watch?v=m7-UdDg5uIw if Nebula won't show it to you)
The tl;dw is that quite obviously the years and years spent learning one skillset absolutely does not translate into the ability to "debug humans"
As best I can tell, it's this one https://www.sciencedirect.com/science/article/abs/pii/S03784...
If you have a computer science degree you see the commonality as well as the differences between languages and systems. You pick up new things extremely fast. For all of the negatives against university, that is the benefit.
Maybe we need a memento mori for coders: What code of yours is still running today?
Ask yourself that, one week, one year, five years, ten years after.
The size of a brick was standardized in 1840, then 1970 for metric. Let's get that kind of stability in software before we start specializing
- Engineers who know how to build apps with a specific set of tools or frameworks and focus on applying this knowledge
- Engineers who know how to model their work in terms of data structures and the algorithms or pipelines being applied to them
The first category can be effective and efficient at applying their knowlege, particularly because of experience and practice with the tools. These are the specialists - the front-ends, the Rails devs, the embedded engineers and so on. They know more about the constraints of their environments.
The second category think more about what they are doing rather than how they are doing it. They are the generalists. They think about React as a functional-ish way to convert state into a DOM tree; they recognise the value and reasons behind various different approaches to development and don’t box themselves in.
I find the second category almost always more effective. That doesn’t mean specialists are without value - you need your embedded engineers to understand that space in depth, for example.
Especially when hiring I like to probe for this during a system design exercise: ask a question and walk through the design of a simple system or pipeline of some kind. If the engineer answers in terms of specific technologies (“I would use Kafka to send gRPC to MongoDB”), they’re usually inflexible. If they answer in terms of techniques and data flows (“I would use a work queue to distribute payloads over the network to backing store databases”) they usually get it.
I reckon changing your mindset a bit can help with the fatigue described in the article. Though I admit I’m as frustrated as anyone else the first time I bring up a new project after a whole an app the tooling has broken and the industry has moved on (looking at you, frontend!)
Not always easy, but that is the first thing that comes to mind, no matter the context.
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!
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.
Does the implementation leak through things like JSON or a EBNF grammar? Performance can be a concern but the implementation doesn’t leak through the language unlike a library api. If you have access to the compiler you can adjust the implementation to get whatever performance you’d like without affecting the abstraction.
Edit: JSON is a perfect example of resistance to rot and a good abstraction. You will always be able to read it in any given language because it is a language and not some library. Non DSL code should be considered as compiler output and that is what 99.9% of software devs spend their time writing. They mock people who would write assembly then go and create some fucked type hierarchy in Haskell for some business problem and call it a good abstraction. The complexity just multiplies until we end up with the current state of the industry.
One obvious and disastrous phenomenon in the tech world is resume-driven development: some engineers are highly motivated to put the next shiny tech buzzword on their resume, so they make sure to push that technology at their company. 9 times out of 10 the project and company would be better off by just using the standard, boring tech that everyone else uses. Tech managers should be able to detect this pattern and squash it, but they don't seem able to do so.
Are they? I just saw a job ad for a YC start-up that proudly explained that "We don't do PRs. We push straight to main multiple times a day." and that "We work onsite, 7 days a week"...all for a company that works in a heavily regulated industry.
That's how you get them pyramids built! Onsite weeklong lashings!
Everything old is, apparently, new again. Last time I worked on webapps, Javascript was, at most, a minor cosmetic sprinkling, maybe with a bit of AJAX if you were daring. Everything was rendered on the server.
Until rendering on the client was cool. But then search engines hate that, so maybe we'd better render on the server after all but then also re-render everything on the client ('reconciliation'). Ah wait, what's this? Now you can opt for 'partial pre-rendering', because it wasn't enough to send HTML from the server and make more HTML in the client, now we can mix client-only HTML rendering with reconciled server-rendered-client-re-rendered HTML.
It plays well to the myth of the hard worker. We're all rugged individualists.
It means companies soak as much work as possible from labor. We're all exploited.
And we all accept that without question because it's the status quo.
Basically, you and your team spent a year or so architecting and building something that you know, it's your domain, you know the in and outs of the system. Then your manager comes and says that team X needs a feature that needs a change on your system, but instead of working with them to implement it, we should work on something else and they will do the changes on our system.
Clearly team X has no experience on the stack or the system itself, and they start to create nonsensical PRs that don't even compile, you spent a lot of time reviewing those, explaining them the issues until it becomes a political/ego driven discussion and... congratulations you are a blocker now.
You experience the same working on your own feature, messing with code that you don't like or even understand, creating yamls that you don't have a clue on what they actually do, just replacing string where you see it fit, learning on production.
Of course, you have no time to actually understand what you are doing, is expected to be done by yesterday.
Suddenly, in name of productivity, everyone is working in the less efficient way possible, taking months what could be weeks, weeks what could be days, and days what could be hours.
That said, unfortunately I had to learn much more than I had wanted about the work of neurosurgeons and ICU units three years ago.
This made me completely rethink the difficulties I face at work so I no longer complain.
Lots of knowledge. It’s moving. And you don’t know it all. You learn and muddle through.
Gave me a chuckle. I don’t think it was a cash strapped company but yea that’s pretty much what happened.
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.
Just think about how little progress has been made in solving complex issues like climate change, curing diseases or securing sustainable food supplies. These are incredibly challenging, real-world problems.
In contrast, software engineering often comes down to rearranging data—it’s powerful, but not always as fundamentally complex as tackling the physical world's hardest issues.
The world has had the means to globally end poverty and hunger for decades, but we haven't. We know exactly and quantitatively what is needed to meet climate goals, but we won't do it. Groups of people who have been murdering each other for generations could choose to stop tomorrow and live in peace forever after, but they refuse. These are as far from technological problems as one can get.
But also think that is what makes dev work so difficult, because our "build times" are so short. Because we aren't limited by the real world, we can build our entire system often in seconds and then test them, which allows us to move fast and generate enormous amounts of complexity. While with physical sciences, during an experiment, the "build time" for their tests is typically much slower, often taking hours or days, so they can only deal with a limited number of variables and information at once.
Also think that is what makes software engineers often good at working in other technical domains, we have a lot techniques and hands on experience in dealing with large complex systems, much of which carries over to non-software problems...
(... but my saying this is admittedly half theoretical, because personally, haven't actually applied this to an actual science field, only to things like small construction projects and to the field of music theory, and yeah, super helpful)
It's just that it's impossible to master the tools. We lie to ourselves thinking that we do, but when shit hits the fan, we're as powerless as anyone in the madhouse to figure out what is actually going on. We're all emperors with no clothes.
Individually we know we're naked, but somehow, we think that someone out there isn't. Someone knows what they're doing. No they don't.
Throwing LLMs into the mix will only supercharge the madness.
This whole thing is a collective suicide pact.
Personally, I don't understand how people get by in web without knowing SQL and JS + some other language.
The idea that you don't understand the flaws that SQL can introduce into a system, and have little ability to debug them is baffling. How can you actually be productive when you only control a tiny fraction of your application.
I love the simplicity and clarity of software engineering sometimes, because here many of the problems are by our own making.
It’s just not a sustainable path for someone who has to pay a $3m mortgage in Silicon Valley. It’s for the already rich to tinker and the young who can live in a room in a 6bd house.
My career is entirely built around full stack and it’s no shock that I’m back to being penniless. Worked so hard for nothing. Specialize and join big tech. These early stage startups suck and aren’t worth it.
> Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro,1 you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”
> They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.
You are no longer masters of your own destinies.
You have been sold out, and what ever is left of you is a sell out.
You will be broken. Only in the darkness of minds eye, where no one will hear your screams, they will break you and remake you, your thought controlls, for their games. For they are as god over you and they are the voices in your mind. The world will scorn you and turn upon you in your desperate hour, and in time it will happen to all of them.
We are thought controlled.
Are you prepared to bear the terrible burden?
My lord… the lack of political maneuvering, fiefdom building and defending, workaholics chasing deals and responses through the weekend or first thing at 5:30am when they wake up…
I did a short stint as part of a pro services team at a SaaS once. Some of the most fun I’ve had, moderate to low pressure, interesting but not overly challenging problems, mostly a creativity challenge not “configure systemd” challenges.
Now I know whT you’re thinking: “oh but here in SWE land we have all the problems you mentioned too!”
Yep that’s my point.
But it's basically all in the web paradigm. I don't have to work on mobile apps or drivers or something. So I think "Full stack" isn't really a good descriptor. I'm more so a "Web developer" than anything. Which is complicated, yes, but if you were a mobile developer your world would be completely different and have its own software ecosystem.
My wife is a pediatric ER doctor. She makes about the same as I do as a staff engineer at a big tech company, but she works 11-12 shifts a month (8-9 hour shifts).
The kicker is that her hours are terrible and she has to deal with distressed parents, and sick kids, and the occasional very bad outcome. It also took her 14 years of training and $200k in debt to start making real money.
But the social status of being a doctor really shouldn’t be underestimated. She has so much more autonomy than I do. Her job is as secure as a job can possibly be.
And interviewing. Interviews are basically a hospital flying her out and wining and dining her to try to convince her to take the job.
This is like writing an article about "The Insanity of Being an Adult in Modern Society" because you have to think about insurance, dishwashing, clothes, food, taking car of your car, your hair, your health, your finances, etc... Yeah. No shit.
Your clients don't change the specs half way through and expect you to provide an accurate estimate and at the same time, don't intend to pay you extra. You can forecast the cost of building to a very accurate degree because all bridges are more of the same, unlike software which by definition,is new every time because each time the requirement is different.
And so on.
I know because I work in civil engineering software field.
We’ll keep raising the amount of knowledge needed to be employed until it’s no longer sustainable. This is just the nature of capitalism: extracting as much value from someone’s salary as possible.
I'm not so sure about that. "Easy" isn't usually an attractive trait in employment. People by and large seem to need some kind of feeling of fulfillment to compel them to show up day in, day out. It might seem difficult to the neurodivergent who are disproportionately attracted to software engineering, but to most people it is simply uninteresting work.
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.