I'm 20 years behind you, and I don't know what effect that will have on my views. But I don't really recognise the picture you're painting. Compared to the first steps I took as a developer about 15 years ago, almost everything about software development seems better to me. I find developing software to be easier, more consistent, and less frustrating than it used to be. Good development practices—things like testing, CI, coding standards and so on—seem more prevalent than they used to be. It's easier to get code out to production than it ever was. Everything in the ecosystem—like tooling, libraries, and services—feel far more open, consistent, and accessible than they used to.

I am almost certain that on the whole I spend a far greater proportion of my time now actually writing code that does interesting things, as opposed to code that hacks together some junk to try and make it work with other junk.

I think I'd draw the conclusion that everybody's opinion on how the industry works is going to be heavily influenced by their individual experiences. Maybe I just enjoy software right now because I've now got the technical competence and confidence to avoid some of the frustrations that I experienced earlier in my career, and in another 20 years I'll be right there with you lamenting the state of the industry. Who knows?

Programming has become joyless.

There are ever-shrinking spaces where a developer gets to build something novel - something that's state of the art, that's creative, that taxes their intellect and brings the pleasure of achievement forth. It seems that for every developer working on rocket guidance systems or self-driving cars there are a hundred toiling away on yet another CRUD app, or wrestling with a hydra of microservices. It pays well, but fun it is not.

Everyone thinks they are productive but value is being burned all day, every day in most companies all over the world. The level of reuse is depressing and people, especially here, firmly believe we need to use the latest frontend and backend crap to rebuild what was working perfectly fine before.

More and more everything appears resume driven and to extract more hours billed or even higher LoC or commits per day. It is a nightmare and I refuse to play more and more. The over architecting for shit one off projects burning 10000$s a month ‘in the cloud’ so it probably, maybe it won’t crash with the 5 users per day it has using it.

Yes the tooling is better but the drive to use every latest tool and tech really makes no sense for almost any project.

Fitting anecdote; a company from LA was contracted to build a crud app for a big corp; they used react, typescript, node, express, aws, aws lambda, redis, dynamo and rds. For a crud app. They got $50k for it. For a crud app. Costs were through the roof running it as you need actual good people to run it. It failed a lot of times for such a setup as it was all the latest of the latest architecting wise. Brittle as hell even with all the tests and resume driven busywork. I rewrote it 1 php + bootstrap and jquery file in 1 day with a perl script to migrate the data and running on a 1.99$/mo server. Cheap, easy and no worries; handles a lot of traffic for the cost of a cup of coffee, does not need devops and they paid $2k for it to me. This is not the only story; microservices + serverless + the cloud really are excellent for making money, but as you say, no fun and in my experience, no benefit. Just added complexity.

It only looks like reinventing the wheel every time if you're completely ignorant of the subtle differences of each problem domain. And if you make a bunch of changes to create arbitrary lego bricks then now everyone has to learn your brick framework before they can make an 8x2 brick.

That's a good seam upon which to filet this analogy. A quick Google search turns up uncertainty as to how many different bricks there are. It could be in the 3000s, 6800s, or over 12000. We are all ignorant of the available lego blocks.

The authentication thingy you got as lego block did not quite fit and now you are using more code than the module has in it to add what you need for it to do, making the original module probably impossible to upgrade without a lot of work and creating a problem for maintenance. Now you can fix this by telling your client; ok, I won’t do this because your idea of auth is wrong. But then the client might kick me out (probably not a bad plan if they are doing trivial things significantly different than the rest of the world). I can just implement it like I mentioned above and make money maintaining it (risking having also to maintain the original lib). Or I can just make a new lib and for which I know it does what it was.

Then, my favourite option, is just take something that just works already, deploy that and adapt a few people their habits around it. It fits 95%, stop whining. The least popular option ofcourse, so there we are, creating slightly different wheels with millions of almost the same LoC and unused andor unmanaged libs that should not have been written or used, again, imho.

There are sometimes edge cases that are not possible to implement, but they are rarer and rarer as the service portfolio grows. In those cases the only option is to write your own container and deal with the usual package-level dependency issues in whatever programming language you use.

( * ) The only thing that doesn't work forever is Node.js, which is deprecated every few years and needs to be upgraded to a new major version. I'm looking forward to the possibility of WebAssembly/Deno replacing Node.js as an "evergreen" application platform.

Same thing is happening with mechanics. Young mechanics repairing parts less often, more handing off parts in need of minor repair to specialists and a focus on fitting parts.

Kubernetes sucks when managers need it.

And yet now OP is making wood furniture, which has been made before the same thousands of times. Some people need originality some don't. Some just like the work for its-own sake. For those who need originality they should find a job working on something that's not a CRUD app. Not everything is a CRUD app. That's on them.

Not sure how it fits wood furniture; you cannot copy a chair in a nanosecond; you can software. I am not saying there is no space or need for bespoke and unique software but if you are doing LoB apps for/in a big corp, as many of us do daily, chances are there is a) a perfectly fine version already running in your corp somewhere and b) a completely identical product in all the companies around the block.

You and I have very different experience with big corps :)

My experience is closer to "There's a half-finished version running somewhere that was cut short because of budget/deadline constraints. The team that worked on it is long gone, and it has been maintained by an outsourced team of junior resources for 3 years".

Re-writing a customer-facing system to be closer to the "modern" web experience they're used to on their everyday apps and sites _can_ make a substantial difference to customer experience, and ultimately the bottom line.

I recently worked for an org that had quite a large software suite (internal system) that was 99% CRUD. For every single CRUD operation, there was a front-end call, to a back-end service, that called a specific stored procedure. So pretty much 4 stored procedures for any construct stored in the database. No ORM, very little dynamic building of queries, thousands of database tables. Releases were a nightmare, change management for database objects is its own complexity, especially with so many objects. I think people were open to change, but with a decade of existing data structures+data, and a long list of projects, nobody wanted to make a change...

My one regret, with respect to that org, is not driving the necessary change.

This seems overly cynical to me; the reason software developers are well-paid (overpaid, some would argue) is that what they build is measurably better that what was there before (at least in dollar terms. I'm not getting into the moral quagmire of automation replacing human jobs ATM)

Code reuse is often a red herring, when taken to extremes. Here's a thought experiment: all software developers are now required to implement all CRUD software in SAP or Peoplesoft (pick one). How much of the code do you think will be re-used, and how much will be in the customizations?

In fairness, if your web app does more than CRUD, or if you expect it will in the future, then PHP and jQuery wouldn't be my first choice. I'm very familiar with how much of a mess an app can become when pursued that way -- a nasty soup of callbacks and conflicting states. As tooling around React improves -- and it's already quite good -- it will be easier to cost-effectively write a React CRUD site.

If you just want a CRUD site that works, and you want it fast, a Rails site with scaffolding will probably give that to you in an hour or two -- with almost the whole hour being spent thinking about your data model.

“The best minds of my generation are thinking about how to make people click ads.” –Jeff Hammerbacher

Every paying software job I've ever had was in some way involved getting people to click on ads. Either directly making a product where ad click rate is a measured metric, or products that helped people make products where clicking on ads was a metric...

I have usually been able to find a lot of joy in solving the problems in the smaller areas where I was focused, but whenever I took a step back and looked at what I was helping work towards it felt very meaningless.

I think finding a job today where you feel like the work you do does genuine good for the world is an incredibly rare and difficult thing...

I've been in the biz for coming up on 25 years and I've never tried to make anyone click on an ad.

It also may help to downgrade "doing genuine good" from "solving the world's biggest problem once and for all" to "helping people get food reliably" or "keeping this industrial process that provides value to thousands of people going" and so on. Sometimes I do lose a bit of track of what I'm doing, but in the end the jobs I've worked still end up helping people do useful things, or protecting people, not making them click on ads.

There's a lot of jobs in programming that don't involve making them click on ads. Even in the heart of Silicon Valley, there's going to be a lot of jobs that don't boil down to that.

But you may have to, you know, change jobs.

But I don't want to hate my job. I don't always love my current job... as I like to say, they're paying us precisely because this isn't what we'd be doing of our own free will... but I don't want to hate it.

Because it's more than just the hating the job. It's coming home every day to your family in a bad mood. It's your children associating you coming home with the guy in the bad mood coming home. It's being on hair trigger all the time despite your best efforts. It's living in a place I don't want to live.

The funny thing is, I look at that and I don't feel like I should be willing to pay $300,000/year for that... but apparently I am.

Most corporations in the US that are for profit aren't about doing good, they're about making money, and publicly held corporations are even legally encouraged by US law to put the shareholders' bottom line first and foremost.

Non profits can care a lot more, but they generally (at least the ones that exist not) don't focus on something abstract like software, they generally serve an immediate need like affordable housing or surplus food distribution or job training.

Until the business climate in the US changes, about all anyone can do if they want a job where work actually helps people is either work somewhere they get paid enough to use surplus cash to help people or work for a non profit.

I think an idea that hasn't really been tried yet is building a non profit for software... not fitting a non profit base to an existing package, but building a corporation that is made to produce software for the public good.

Mozilla? Unfortunately, they weren't successful at creating new things of value (with maybe Rust being the exception).

I'm a happy low level systems developer. I solve hard and interesting problems that have nothing to do with ads.

Maybe you think banks are just as bad as advertisers but I tell myself I am enabling the tens of millions of Americans who have retirement accounts. The day-to-day is enjoyable nonetheless.

Banks as in consumer banks? Maybe not. Commercial banks, brokerages, hedge funds? Welp. I admit that some of those have made my imminent retirement possible, but from a broader view I don't see much good about how large the US financial sector is compared to the overall economy or the preferential treatment they get from our government.

> I tell myself I am enabling the tens of millions of Americans who have retirement accounts.

I'm sure many at Facebook would say they're enabling small businesses and non-profits directly through advertising, and many more "little people" through the platform(s) that those ad dollars pay for. They're also enabling some very unsavory people and behaviors, as are most in fintech. Read the news lately? ;) Everyone likes to dump on ad-funded businesses. I've done so myself. It's not entirely unjustified, but sometimes it seems disproportionate and even hypocritical.

Interesting point you make: there is definitely selection bias going on because of this, but I've honestly never thought about it that way before!

That's an amazing fact.

May I ask how old you are?

I've been designing SOCs, DSPs, Control Systems and a lot of software for various systems since 1985, and I can only recall one that might have been close to "clicking on ads" (it was a personalized "on hold" system for dial-in to major retailers (like JCP), to replace Muzak with offers and information and stuff). I was the VOIP-to-Enterprise-Telecom integration guy, so not directly tied to the ad-part, but the company pushed couponing to their clients pretty hard.

"The best minds that I know are thinking about how to make people click ads."

There is a considerable number of exceedingly intelligent people in pure mathematics and (theoretical) physics that don't work for Google, Facebook etc. and never would. Those that do often have nothing to do with Ads even three to four edges removed (think Martinis or the people at MSR).

They're not really though. Ads may be the revenue stream but it's not like the top engineers at Google were on ads. They were building the search engine.

People that hate ads love that quote because they like using it to lambast the tech industry (in general, and advertising in particular), even though only a small percentage of engineers or other tech industry employees work on ads.

People in the ad space love that premise. You know what's worse than that premise? Admitting to themselves that they're not the best minds of their generation and they're still stuck doing work trying to figure out how to optimize ad clicking - the worst combination. At least they get to pretend they're the best minds of their generation, if they buy into the quote, that's a consolation prize.

The best minds are largely not working in advertising (maybe a small share of them are). They're figuring out how to leverage CRISPR to cure and prevent disease, or trying to figure out a therapy for Alzheimer's disease, or working on immunotherapy. They're the kind of minds that were working at Pharmasset figuring out how to save tens of millions of lives by curing hepatitis C. They're designing and building the next generation of semiconductors at ARM, Apple, TSMC, Samsung or Nvidia, pushing against the boundaries of what's physically possible. They're working on electric cars at Tesla or VW. They're trying to solve our battery problems. They're launching rockets at SpaceX or Rocket Lab. They're designing the next airplanes for Airbus. They're at NASA, ESA, JAXA, CNSA, heading to the Moon and Mars, or working on James Webb, figuring out if Venus contains life, and so on. They're designing the next generation of nuclear reactors, ITER or maybe working at LHC. They're working at Illumina, Boston Dynamics, Intuitive Surgical. They're in national and university labs all over the world, trying to solve very hard problems on a daily basis. They're even working on hypersonic weapons, military drones and designing nukes. And that's not meant to exclude the rest of this giant world, as the world is filled with examples.

If you meant to say that Google's top engineers _used to_ work on the search engine but nowadays they work on making people click on ads because that's were the money is, then I wholeheartedly agree with you

This is interesting, thanks for sharing that.

Of the nine organizations that have paid me to write software since 1993, only one of them would fit in your criteria.

Note: I am in no way doubting your claim, and I actually appreciate your perspective and the quote you cited.

I will more deeply consider that when categorizing companies in my mind going forward.

But it pays for nothing. I make more money as a street musician than with my open source projects that have more than 100k users. But I got paid a lot for improving some online gambling site. This is how it is.

Total Compensation = Salary + Benefits + Intangibles

Those Intangibles can be things like working environment or commute, but they can also include your affinity for the organization’s mission. People are willing to take smaller salaries when they’re working on something they love & respect. It takes more money to convince people to work on boring or undesirable things. It’s the exception to be paid well for something you like.

work that I actualy care about is difficult to get paid for

I think it might be possible to say that relative to the entire industry the space for novel or interesting work is shrinking – possibly. But I don't think that actually means there's less interesting stuff to work on. If anything, the spaces for that are growing – maybe more routine work is growing faster, but I can't really say. I'd wager that the majority of software for its entire history has been pretty boring.

There's a big gap between software craftsmanship and the algorithmic trivia interview expectations nowadays, and it seems to keep widening.

The people interested in doing cutting edge work will find a way to be there no matter what. The vast majority of people overestimate themselves.

Every time I hear this quote, I remember all the small businesses and ventures that only exist because of Instagram, Facebook and Google Ads. Housewives baking cakes, a leatherworker making custom backpacks, a blacksmith restoring antique knives - those are just personal friends of mine who wouldn't be able to build their businesses if not for what those brightest minds of our generation are doing.

Is all of this really worthless to you?

(Copied over my recent comment on this exact topic, I hope it's OK with the mods).

Can you imagine what the medical field would be like if the majority of general practitioners started complaining about the fact that they don't get to work in neurology research?

    100% vanilla Javascript
    no dependencies
    no cookies
    100% client side; no server side state, no ajax
    state is stored entirely in the URL
    state is correctly maintained across page loads (i.e. page edits its own URLs to maintain state)
    Javascript is 100% local, so it's instant and doesn't require any data fetch
    correctly detects a potentially spoiler-full page load by looking at the referrer (so it doesn't annoy you as you navigate around the site)
    ... and the entire thing is less than 100 lines of code

https://exanderproject.com/spoiler-test/

The other thing that stuck me, as I was doing this, was how much the Javascript ecosystem has improved over the last 10-15 years. It was possible to do this in a very small amount of code with no dependencies precisely because of the all the bells and whistles that have been added to Javascript over the years. Maybe this isn't so obvious to someone who has been neck deep in Javascript for 15 years, but as someone who has been mainly in other languages, it was a very noticeable and dramatic improvement. The web platform is way, way nicer to develop for now than it used to be when I first got started.

Now I'm trying to figure out what other small projects I can get involved with.

Over the next year or two I hope to develop a mobile app.

After 15+ years of big messy corporate server programming I think this might be the place joy is hiding.

I accept that I will probably not make the money I have made gluing clouds together the past couple years. But maybe I can make something useful that people like to use.

I program in Arduino where I only have 2.5 K for my variables, programming with so little memory really forces you to think about your program methods.

I built small projects using 74LSxxx chips, building logic instead of programming it can be refreshing.

When I need more space I program in C++ on a Haiku machine, 32 GB of ram and 12 CPUs gives you the power, but the lack of frameworks means it is all your own coding.

https://en.m.wikipedia.org/wiki/Haiku_(operating_system)

I too am relatively young. When I was a kid, Bill Gates and windows was the devil. Nowadays I realize I judged him too harshly and that he does a lot of good in the world, but at the time Microsoft was the bridge troll.

Looking back, everything seemed so simple. Programming open source things had meaning to it. People didn't program open source back then to my knowledge as part of a larger corporate strategy. They did it because it was fun.

Corporations entered open source programming as far as I'm aware en masse in the early 2010s late 2000s. Around the same time Facebook and Google reached their peak of popularity. It felt awesome to have corporations join in the fun and it felt like the software got much cleaner and much higher quality.

After a while though it just felt like corporations took over the place. Software is better now but it's tailored to corporate needs even in the open source world.

Now that our apps have millions of users, and we can see how they interact with the app in near real time, there is a constant push to manipulate the behavior of the user. Like our app? Leave a review! How likely are you to recommend our product to a friend or colleague? And so forth. To your point, we have always been asked to do things like this but in the 90s there wasn't nearly as many ways to do so. Seeing the greater capacity of our code being used for yet more greed is disillusioning.

I get it, everything is terrible, and it always has been. But I do wonder if we haven't lost something from the '90s to now. I feel like there have been several Eternal Septembers, but instead of our communities getting flooded with trolls they have been flooded with corporate interests in communities that didn't used to have these interests at play.

To try and combat this feeling, I have tried to find those communities for programming that try to get back to our indie roots. In the '90s we didn't care or need corporations to sponsor us or our open source projects. I'm still sure there are those out there that run their projects without the need for GitHub Stars or corporate funding but it's now seen as unreliable or otherwise undesirable to use projects that are simply done for fun. I think remembering that that's all I ever used to use will help me find more fun like I used to have. Preserving the space of programming is a hobby I think is really what's at stake here.

building there is a creative process and it pays better than big tech

The onchain codebases arent that big because they cant be.

I suspect a nontrivial number of programmers in that field will find themselves making license plates or exploring harbors with concrete shoes a few years from now.

And the programmers have easily translatable skills, so nice try at making a point but it doesn’t make sense when there is a real conversation to have

But you werent actually here to debate the differences in how that could affect programmers in that industry vs other industries

Your preconceptions are a random incoherent mixture of things that are oddly excusing bad actors or bad companies by ignoring them and conflating it with blaming a specialized skillset or sector

You could have kept all that in your head because this was clearly a copypasta rebuttal prepared for any conversation about crypto

> Maybe I just enjoy software right now because I've now got the technical competence and confidence to avoid some of the frustrations that I experienced earlier

Just as some but not all of my (mostly negative) perception is surely personal, might I suggest that some but not all of your (mostly positive) perception is not? Perhaps the industry really has improved in some areas that you care about during that interval. Yay! OTOH, that doesn't necessarily put your perception and mine in opposition. There are other areas and other intervals, and other priorities as well. It's great that your experience has been positive. I hope it remains so.

I'm very much aware of how bad some parts of the industry can be (particularly having recently dipped my toe into some machine learning work and discovered an entire sub-field in which nobody has ever heard of documentation, testing, coding standards, or things like releasing software that actually works).

If you mean this is better, I hardly agree with you:

https://twitter.com/thomasfuchs/status/810885087214637057?la...

Separating the HTML, JS, and CSS is an approach that works up to a certain size/complexity app. When I’m working on some functionality, I need to be able to understand the relevant parts of the HTML, JS, and CSS. With a smaller app, one person can more or less grok the code base well enough to find everything they need. With simpler apps, you might have fairly uniform or boring styling and not a ton of CSS rules. If I’m setting something up with Bootstrap and just getting it working, I can probably ignore CSS for a LONG time.

If you’re working on something larger and more complicated, you really want to have all of the HTML, JS, and CSS for a particular piece of functionality right in the same place so you don’t have to go searching for it. It’s how you survive in large/complex apps. You’ll think, “The margins in this box are too large” and you want to be able to fix that without trying to grok some massive set of CSS rules, and when you do get the CSS rules that you want, you want to know that they’ll be delivered to the client—something that is easy if you deliver all of your CSS rules to every client, but hard if you want to split your CSS.

I think the only real tragedy here is that too many people are copying “the way Facebook does it” without wondering if Facebook might have a completely different set of priorities than they do.

But yes – I do think React is a pretty good approach to UIs compared with many things I've used in the past. There are good and interesting discussions to be had about the different possible techniques that can be used; this isn't an entry into one of them.

The joy is in programming, not in software engineering. At least that's how I interprete the GitHub comment (and all these stories about developers that cannot take it any more and burn out).

Today's 'process' is no more efficient than, say, deploying rails to heroku in 2007. And even before that, you'd spend half a day writing an automatic deployment script, and then deployments would take a couple of clicks and you'd never think about it again.

In many technical interviews, they want to talk about "scalability", using fancy big data software for horizontal scalability etc

But I also know from experience that many, many of these problems would be more elegantly solved by more traditional tools like Postgres, especially since servers have gotten more powerful, the cloud service options more plentiful and reliable, and the software more optimized. The "scalable" approach can lead to massive amounts of wasted person hours unless you're sure you really need it. But if you say, "just use RDS or CloudSQL, or maybe BigQuery", you get perceived as a newb by the 24 year old who just got his MS doing Spark work on toy problems.

Ultimately, we get paid to solve business problems, not to have fun with programming.

Me too. And all I can do is point at Javascript in webpages. Which, as a Java dev (if I can still call myself that 15 years into doing all sorts of other stuff too), I want nothing to do with but somehow get dragged into all the time.

I can really relate with the idea that we're feeding the beast we built rather than the one borne of necessity. Unfortunately, which I'm sure the latter still exists, it's the former that always seems to pay the bills.

There were few and brief moments in my career as a software developer when I was truly happy at my work. Most of those involved implementing an architecture or algorithm I figured out from scratch, or took from scientific literature - either as prototype or directly in the product. Sometimes as "hold my beer, I got this" moments. But as you can imagine, this is maybe 1% of the things I've been doing at various jobs.

From where I sit (a backend developer, thoroughly burned out by webdev a couple years ago), most of coding I do is software bureaucracy. Turn this data into that data, ensuring module X and Y get paged in the process. Oh, half of the code I'm about to write is implemented elsewhere - quick, figure out how to juggle the dependency graph to somehow route control from here to there and back. This data I want to convert is not of the right colour - oh, I need to pass it through three sets of conversion layers to get back essentially the same, but with a correct type tag on it. Etc.

It's utterly and mind-numbingly boring, unless you architectured the whole codebase yourself, at which point it's somewhat fun because it's your codebase, and who doesn't like their own Rube Goldberg machines?

At this point, I've learned a coping strategy: just forget the project scope and focus on your little plot of land. Doesn't matter that the software I wrote half of is going to help people do exciting stuff with industrial robots. What matters is that the customer changed some small and irrelevant piece of requirements for the 5th time, and I now have to route some data from the front to the back, through the other half of the code, written by my co-worker (a fine coder, btw.). So a bunch of layers of code bureaucracy I'm not familiar with, and discovering which feels like learning how to fill tax forms in a foreign country. If I start thinking about the industrial robots I'll just get depressed, so instead I focus on making the best jump through legacy code possible, so that I impress myself and my code reviewer (and hopefully make the 6th time I'm visiting this pit easier on everyone).

Maybe it's a problem of perceptions. Like in the modern military - you join because you think you'll get to fly a helicopter and shoot shoulder-mounted rockets for daily exercise. You get there and you realize it's just hard physical work, a bit of mental abuse, and a lot of doing nothing useful in particular (at least until you advance high enough or quit). And so I started coding, dreaming I'll be lording over pixels on the screens, animating machine golems, and helping rockets reach their desired orbits. Instead, I'm spending endless days pushing people to simplify the architecture, so that I can shove my data through four levels of indirection instead of six (and get the software to run 10x faster in the process), and all that to rearrange some data on the screen that really should've been just given away to people on an Excel sheet with a page of instructions attached.

(Another thing that annoys me: a lot of software I've seen, and some I've worked on, could've been better and more ergonomic as an Excel sheet with bunch of macros, and the whole reason they're a separate product instead is to silo in the data, the algorithm, and to prevent the users from being too clever with it. Also because you can't get VC funding for an Excel sheet (unless you're Palisade).)

Got a bit ranty here, sorry. I guess my point is: I accept the industry is mostly drudgework, but I refuse to accept that this is all essential complexity. Somehow, somewhere, we got off track, because all this shit is way harder than it should be.

The end goal of software I work on is to help airplanes land safely. But actually, I work on the software which presents the user interface that displays and sends configuration settings to a device on the ground that helps achieve that.

So my day to day is figuring out whether two bytes in a serial buffer an ad hoc protocol are actually transposed, or if the comments are in 20 year old code are lying about which is which. Or trying to figure out whether a Win32 font setting command from two decades ago is still interpreted the same on Windows 10.

The rabbit holes and yak shaving just go on and on. I have it in me to enjoy doing the work, but when I think about how many steps I am removed from the actual airplanes and I feel badly for filling my brain and my workday with trivia.

Yeah, I also initially felt this is some kind of failing (I'm usually the "big picture guy"), but ended up accepting this as a coping mechanism. It's not that I forget about the purpose completely - just learned to think about it more when planning and designing, where the wider perspective also affects the task in a meaningful way. When deep in the codebase, I try to put it aside, so that I don't get in a depressive session of thinking "why do I have to shovel this garbage back and forth to satisfy some low-level requirement, instead of, I don't know, talking to people who'll use this on-site and getting some real feedback from them?". Rationally, I know that shoving garbage is an important part of getting quality software that helps others do exciting things. Emotionally, I just wish I was in their shoes (probably just as much as they wish they were in mine).

You seem a bit more positive than me when facing this reality, so I'm glad you have it in you to enjoy this. I almost have it, so I find ways to cope, and enjoy the opportunities to do something less mundane that come every now and then in such projects.

I do it as well; I think organizationally it's a failure, but it is an effective personal coping mechanism. In other words, it's bad for the organization that their codebase isn't really a melting pot of different developers' ideas but instead, if you zoom in enough you notice that it's really a series of hundreds of small fiefdoms each with their own slightly different customs and semantics. This is what creates that software bureaucracy.

For employees though, it works. It's about the only way that I really derive any sense of satisfaction from software engineering. When I can stand back and say yes, this package is mine, I made it and I will take care of it. With the melting pot packages it feels more ambivalent; some portion of the code is mine. Probably not the clever bits, they're probably bugfixes. So I don't have enough mindshare to get satisfaction from achievement, I don't have the satisfaction of at least solving one of the hard problems. No, those people have come and gone, and I'm left with the shale oil of satisfaction: fixing bugs, writing unit tests, and adding documentation. Like shale oil, the joy it brings is very close to the effort it takes to extract it. This isn't the "I accidentally hit an oil vein while digging a garden" joy of really getting to solve something.

Some people derive a lot of joy from doing things that help others (like unit tests, bug fixes and documentation); I'm unfortunately not one of them. Sometimes I wonder if it isn't at least partially because it's so hard to feel the impact. I know HN hates the idea of gameification, but I wonder if it couldn't be applied to good effect here. If someone could make an integration with CI, and with major editors, we could scrape data regarding how many times your unit tests have caught bugs, and how many times your function/class documentation has been viewed. There could be a leaderboard for people that are into that. But for me, just the raw numbers is enough. "Unit tests you have written have exposed 137 bugs in PRs, and documentation you have written has been viewed 138,476 times" would be a huge motivator. It gives me that warm and fuzzy "I actually productively contributed" feeling. Right now I get nothing back; I have no idea if anyone has ever read the documentation I spent hours writing, or if my unit tests have caught any issues.

Love that. Yes, the 1% (of which I've been a part) often get to control both the structure and rate of change for a large codebase, and in perfecting the fit to themselves they almost inevitably make the experience worse for everyone else.

And yet accepting that, I still can't shake the feeling that things are more complex than they should be. That also applies to the code I'm writing myself (which is immune from the "rewrite because I could do it better" urge)!

I no longer code outside of work though & found a happy balance of learning on the job with my productivity. I find the amount I do get to spend coding also has gone down - a lot of my time is spent mentoring, in meetings, writing planning docs, and just thinking about projects, or occasionally researching what’s the best paradigm for my problem. I am ok with this, as I am taking more joy in being a leader than directly coding necessarily. I recognize not everyone shares the same perspective though.

I get what your are saying and you are getting a lot of positive reinforcement about this. I would suggest to you a caveat.

I've worked in some orgs where this mentality becomes entrenched. In these new-fangled tech startups with people changing roles and even companies every two years this probably happens less. But I've seen people entrenched into their own kingdoms for decades. An individual, or small team, creates a moat around their "little plot of land" and they become intransigent. This leads to two bad outcomes: they resist any change to their systems or process, going so far as to obfuscate it to protect it. They also don't pay attention to holistic concerns, caring only about maintaining some idyllic vision for their own "plot of land" to the detriment of any larger objectives.

I think this is a real concern when divisions within a larger org compartmentalize around code or system boundaries. It is not something to shrug off as if it couldn't happen to you.

Honestly, I've used an unfortunate turn of phrase in my original comment. "Your little plot of land" indeed implies a fixed, entrenched moat. What I meant was something different - the area of code I'm currently working on. That may be a different place with every new task. My coping mechanism isn't building little kingdoms - just focusing on the code a given task involves while purposefully forgetting about the global context of the application, in order to not think about how minuscule and irrelevant the task is to the exciting things the company is doing. That context is usually not useful when doing the changes I've already planned beforehand, and it is emotionally distracting.

For me, tools, including languages, do matter. I can well imagine that programming in Java would be soul-deadening (although Java is still better than some languages of the past).

Incidentally, I am not dunking on languages of the past. Lisp has been around for a long time, as has Smalltalk or Haskell or ML. Many of those languages were not accessible to anyone without a mainframe or expensive workstation. This situation has improved greatly in the past decades, which to me is another reason to prefer coding today versus the past.

Obviously, most of us are not able to cherry-pick our toolset for work. We use whatever our employer says to use, or whatever the demands of our project require. This may be part of why many people find coding to be an uninspiring experience. Also, the problems that people work on might be dull, it's hard to get motivated about a basically tedious problem.

Last, it's worth acknowledging that some people just don't love coding all that much. It's hard to imagine doing really well at something you don't deeply enjoy day in and day out. And your passion can change over time: you might really enjoy something in one part of your life, and not derive much joy from it at another part.

Supportability, risk-mitigation, debuggability, etc. are all thrown away in most of today's environments. An awful lot of tech companies are running mostly on hope.

I think it's amazing to see CICD tools which make it super easy and quick to deploy web apps-- such as Vercel, for example.

Simply by booting up a github project, and starting from a template, I can deploy a SSL-secured site within minutes-- as a frontend example.

On the backend, using infrastructure-as-code solutions, to again, "templatize" a starting point, such as an AWS service or set of connected AWS services.

Whereas up until recently, I'd typically go rent a chunk of a server to run Linux, and setup NGINX-related security features myself. Not that tough, especially the more I learned NGINX. However the 3-click deployment via tools like Vercel take away so much headache. That said, at times, I think it's can be necessary and easier to simply setup a linux server, so as to have full control over the process.

It's just nice to have the additional options.

I love how much the software-supporting ecosystem has evolved.

It lets me focus more on development, and less on devops. And that what I want, as a developer-- To get to coding ASAP, and not worry about tangential concerns-- as a matter of specializing.

(Disclaimer: I only have about 2-3 years of professional experience, but prior to that, was teaching myself for about 5 years off and on. In that timespan of 7-8 years, I feel so assured and emotionally secure given the reduction of headaches due to the fact that I no longer have to learn so much ecosystem related stuff, and can focus more on programming)

All true points.

As an individual developer, if you are working on what you want to be working, we are in a great time. You can pick from a selection of outstanding tools and we have, for all practical purposes, access to infinite hardware.

As a developer that's part of a team... it sucks. Expectations are getting ever more unrealistic - probably because so many things are quickly done, but other things are just as slow or even slower. Most people's jobs consist of wiring together 150 libraries across 30 'microservices' (which are rarely microservices, but often distributed monoliths) and that's after spending a lot of time bikeshedding on what the tech stack is supposed to be like.

At least the UML craze seems to have died down.

From my journey on the chart, things have only gotten better since the time I crashed a C++ compiler just because I was using std::map.

I think you work for a better company than me :)

Also, the whole industry has been strongly commercialized. Before, people would share source code on the internet just for the fun of it. Nowadays, that is a surefire way for someone else to take your source code and sell it as theirs. I mean that's basically what Cloud providers do. They rent out access to open source software.

The insane pressure of money also makes sure that most software nowadays is not build to any reasonable engineering standard, even when it really should be (like Boeing MCAS). Instead, every piece of software nowadays is optimized for the sweet spot between sucking so bad that nobody buys it and not spending a penny more than what is necessary.

The goal of software development has changed, and I think $1 phone apps nicely illustrate the new commercial landscape. It's the bare minimum quality at the bare minimum price.

BTW, on a related note, most bicycles made in 2000 still had a much more stable frame than the 2020 models. The marked switched from costly steel to cheaper aluminum so that you can make $300 supermarket bikes. And obviously, the quality has suffered.

It appears that in general, there's always a race to the lowest possible quality in the hopes of reducing costs, thereby increasing profits. Does anyone have any suggestion how we could reverse this trend in general?

Thee $300 supermarket bike (I have one and put over 40 miles on it weekly and it's help up fine for four years) provides access to folks who otherwise can't afford the fancy $1,500 aluminium/carbon machines. Fancy bikes are still getting made and even getting better.

Newly rich kid or VC funded startups distributes money from wealthy people to an every growing software industry. It allows people like me to work in software; something that was previously only available to elite educated people who happened to live in the correct zip code.

tl;dr: The pie has increased in size and become much more inclusive. Yes, there is a lot of low-quality pie out there. But there is also plenty of high-quality pie for those who can afford it. This is good for everyone except the very elite entrenched class.

While I agree with your point that hobby startups distribute money and enlarge the market, I was trying to point out that people working under management with no experience will probably not learn their craft well. In my opinion, the old apprentice system used for jobs like becoming a carpenter would be quite appropriate for software engineers. But it only works if there are enough master level programmers around to teach everyone else.

As for the pie analogy, I don't share your opinion. When the market moves towards lower quality, that usually makes high quality more expensive or even outright impossible to acquire. Case in point, I'm not aware of any bicycle that is rated for 200kg+ for driver and luggage. Not only are there no cheap bikes at that stability level, but also nothing in the $2000+ premium range. So something that used to be easy to buy for everyday folks 20 years ago is now too expensive even for rich people. And all that only to drive the price of the cheapest bikes down from $500 to $300, which I presume won't make much difference to anyone because a good bike will last you 10 years, so it's <$1 monthly in either case.

Not only will it easily take that weight, it's designed to comfortably carry a passenger and cargo. Or the Yuba Mundo, there are a few other brands. And you can get them in electric, if your thighs aren't made of steel cable.

Yuba Mundo is $1800, which sounds like a lot, but with inflation that's well under a grand at the time when more bikes were heavy and over-engineered. With the nice side effect that they could carry a lot of weight....

If you don't like rich kids, don't work for them.

I was shocked that a LOT of startup founders are well-connected rich kids who have no skills or ability to lead a tech company. I learned that, while saying that you have a huge trust fund isn't very cool, saying that you're a tech entrepreneur CEO is perceived as cool. So the rich family uses their connections to raise a few million (often indirectly) and suddenly the kid is an "entrepreneur", despite lacking any relevant skill sets. It's not like there's any expectation for these companies to make a profit anyway.

Yes, you can avoid these companies, but it's worth warning younger engineers that this is maybe 50% of tech startups. It's more of a problem with NYC based companies than SF based companies (as NYC has more old money and less emphasis on tech companies actually building real tech) but I've seen it in both cities.

If you were to look back at the early 1900s, or even 1980s, its much better today than back then

I'm very grateful to be in this industry despite not having the "correct" background.

You have a very solid extremely valid counter point and I think the person you're responding too created a false dichomtomy.

Cheaper does not eliminate the quality. They can both co-exist and indeed do.

The lower tier just opens the door for a group of people who never had access before.

Thank you for your input.

> Cheaper does not eliminate the quality. They can both co-exist and indeed do.

It sometimes does, if it eliminates quality out of the market. Say a quality frame costed $500 before; then you have a new, cheaper technology that can achieve similar performance by cutting out more extreme loads / road conditions; as manufacturers jump at it to save money, suddenly the whole $100-$800 range uses just that, and the quality frame rises to $1500 due to collapsing demand. Can't say whether it's good or bad on the whole, but it annoys the hell out of me in cases where I could afford the quality product but I can't, because nobody is making it anymore.

Instead of middle range products you get low tier and high tier products and those absorb their different shares of the market from the middle.

This type of extreme seems to happen in all facets of human society over time including jobs, housing, cars, etc..

The middle becomes pushed out.

That's been a big issue for a long time.

Alot of access is given to people who previously had no access but the middle is somewhat eliminated.

A working culture tuned to movement of a minority of capital “haves” isn’t much different mathematically than a monarchy and his lords and barons, etc.

There’s a gentler temperament, but “work the jobs we will pay for, while deflating your buying power to maintain historical human narratives” isn’t exactly fostering free flow of capital, labor, and ideas.

Like, I could make the exact same complaint except I'd situate it about 10 years earlier, around the first dot-com explosion.

And somewhat earlier than that, I remember grizzled programmers from the 1980s who hand-tuned their C and assembly and who thought we were flagrantly wasting computer resources on garbage platforms like the web.

(However, bringing it back to the 2010s and beyond, you're right that open source development has been completely co-opted.)

I'm in my 50s, and I've been getting paid to build software for over 27 years now, and started programming on a near daily basis on a TRS-80 in the 1970s.

Please don't feel sorry for me. I still very much enjoy building software.

I won't necessarily disagree with the particular challenges you cite.

The total complexity is enormous now, but the tools and abstractions, which themselves have variable quality, and bring their own complexities, are tremendously powerful, and, though it often doesn't feel like it, effective.

Beyond the specifics, I acknowledge that 'the industry' has evolved in many ways and directions, not all of which are positive.

I face non-technical challenges today that, had I known about them 30 years ago, would have probably caused me to switch careers.

So, I acknowledge what you're saying, and to it I will only add this: each of us exerts a great deal of control over how we perceive the world around us. It's possible that the difference in the way you and I 'grade' the software industry is that I am, for no knowable or particular reason, more fundamentally optimistic about things than you. It's also possible that, primarily for reasons beyond our control, I've ended up working in more positive organizations.

To other people reading this far: two specific anecdotes about how the software industry has changed over three decades provides very little concrete indication for how your personal experiences are likely to go.

Whenever I get burned out on software (in my case, Vue and React) -- and build complexity -- I always remind myself of those TRS-80 days. The only learning references around were the books for sale by the TRS80's -- a couple books on TRS80 graphics, Rodney Zak's 'Z80 Assembly Language', and William Borden's Z80 books. And of course the Tandy version of Zork in the little plastic baggie hanging from a wall hook beside 'Eliza' and 'Dancing Demon' -- and then the wall of brown folders of 'Scripsit' and 'VisiCalc' on TRSDOS 1.3 (?). Maybe the editor/assembler at the time, too -- 'EDTASM'. Don't remember if that was in a baggie on the wall hook or in a Tandy brown TrapperKeeper with the cassette insert and several tapes.

Those were great days -- and everything (for me, at least) was new and exciting. Nothing was ever too daunting or too complex -- even as daunting (and as complex) as Z80 assembly seemed to me -- a 13 year old at the time.

That's a feeling I always try to recapture in very deliberate ways these days. It's good remember how it all started.

Complexity is daunting today. I believe, however, that the power available far outweighs the total difficulties.

I am still inspired by the basic possibilities that most anybody can, with nothing but access to a computer and the Internet, write some javascript and html in a simple editor and make it available to most everyone in the world.

Objectively speaking, that's simple and approachable, far more so than anything I ever did or was aware of.

A computer contains practically infinite possibilities, and people who lose interest in that are really just lacking creativity, and maybe some cognitive ability.

I don't only program though, I am creative in other ways and I build many things that have nothing to do with computers, but I do often incorporate programming into these creative pursuits, because it sometimes pushes the project to the "next level".

If someone only writes "glue code" then yeah, that will get boring. There are so many other kinds of programming though, that many never even explore. 3D is a whole entire interesting field that is far removed from "glue code". Home automation is one of my latest obsessions. The list goes on and on.

I'd love to hear a couple of examples if you have a few moments. (:

This quote from Built to Last is going to stick with me for a while: "... many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers."

I'm not leaving the industry any time soon. At least in the abstract, I do like what I do for a living, and believe that there are still some habitable spaces left in the field of informatics. But there's a part of me that is beginning to wonder if the best and most comprehensive literary (sort of) analogy for modern software engineering culture isn't the Orks from Warhammer 40,000.

[1]:https://logicmag.io/care/built-to-last/

> the last thing many male computer scientists entering the field wanted was to make the field easier to enter or code easier to read, which might undermine their claims to professional and “scientific” expertise.

> Take the C programming language: it was created in 1972, but as one of the current COBOL programmers I interviewed pointed out, nobody makes fun of it or calls it an “old dead language”

> There’s an old joke among programmers: “If it was hard to write, it should be hard to read.”

> it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use

And, of course, the quote from the comment to which I'm replying:

> many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers.

If any of these quotes even resembles something you _might_ think about this field, maybe you'll get something out of reading the whole article. Personally, these quotes are so backwards to me that the author could just as well have written "Programmers can breathe under water" or "grass is the cornerstone of a well balanced diet".

It's never about the code. It's about getting the job done, and the code is just a tool for getting it done. And getting the job done is ultimately about domain expertise, or design skill, or engineering acumen, or any number of more abstract skills. When developers get all protectionist about complex technical tooling instead of focusing on perfecting their ability to get the actual job done, that's a moral own goal. It doesn't challenge the idea that developer skills are inherently low-value and replaceable, it takes the idea as a given, and asks, "OK, since we're inherently low-value and replaceable, how can we artificially make it harder to replace us?"

Me, I don't want to respond to the idea that I'm just a code monkey by trying to be the fanciest code monkey imaginable. I don't want to be a code monkey in the first place.

Last year I wrote a small book called "Splash of Code", which teaches newcomers to code (in JavaScript) in a way that similar to the way I learned 30 years ago. I selected JavaScript because the barrier to entry is low, you just need a browser. Many programming ecosystems are daunting to setup these days but there are still some easy systems we can use to introduce newcomers without all the modern complexity.

Browsers have come a very long way in the last 10 years and are a pretty amazing platform for development. Once you learn a little bit you can start to write amazing software for a cross-platform worldwide audience.

Don't forget the ones who jump onto a new language or framework so that by dint of experience they can be the gatekeepers for the next generation. This was staggeringly apparent with both Java and Go, each in their time.

I learn new languages for technical development and to stay curious and fresh. You learn new languages for job security. They want to gatekeep the next generation.

I think it’s gotten a whole lot simpler in the past 10 years. People used to have to rack their own hardware, install PDUs, check temperature gauges, plug wires, configure the switches, setup RAID and backups, make sure you have that serial cable plugged in so you can telnet in in case the switches don’t work, and lock the data center doors without forgetting their keys back in the day. And this is before actually developing and deploying your application software.

Now you can just buy a bunch of db cycles and scale to >10000 qps without batting an eye (though you’ve got to watch your wallet).

I think because some of the hard stuff got a lot easier, the easier stuff got unnecessarily complex. And there are so many ways to scale things that some of these constructs and idioms used over time stopped being used because they mattered less if you could just turn a knob to scale your crappy code.

Yes, and other people did this job, not programmers. People that loved tinkering with hardware, low-level OS stuff, networking, etc. We even had a name for them: "system administrators" and "network administrators".

Nowadays everyone's expected to tweak CSS and configure kubernetes in parallel.

So when my job title switched away from programmer to some kind of DevOps thing and I was shoved back into the sys admin role, I was unhappy about it.

Trouble is they tended to be interesting but poorly paid jobs

What you describe is what used to be considered sysadmin work. I too did quite a bit of it, but most of it went to people who specialized in those things. And no, I don't do any of it now. On any given day I'll probably deal with machines in at least a dozen geographic locations across two continents, and if I tried to enter any of them I'd be stopped at the door - no, at the gate before I even got to the buildings. Instead, I write code to interact with the deployment system and the provisioning system and the multiple monitoring systems and the automatic remediation system and so on. Is it better? It scales better, but as a matter of personal satisfaction and avoiding fury at other people's crappy code I think I'd rather be plugging in cables and configuring switches.

> I think because some of the hard stuff got a lot easier, the easier stuff got unnecessarily complex.

There's a lot of truth to that, and I don't think we necessarily disagree on the outcome. However we got here, whichever specific things make modern software development more unpleasant, it seems that it is more unpleasant than it used to be.

But yeah it's like over time we ended up scaling the crappiness of software along with the software itself. At the same time, I'm inclined to believe that software development at large is in a much better position to solve a whole bunch of other problems than ever before. That keeps me motivated personally, though I get the frustrations for sure.

Kids in their rooms still do write the next big things. The difference now is they now raise a ton of money along with it. They scale a whole lot further, and much faster. There are more entering the engineering profession through Lambda School and bootcamps and what not. They also leave around a lot of shitty code that usually ends up building some business value. Much of this was true back in the day. It's just gained a whole lot more momentum IMHO.

But ...

I used to code for fun in my spare time and more recently I'm finding myself working on "shop" projects. I sold my pocket-cruiser (a small yacht) and I'm building a couple of small wooden boats. I have a '71 Saab Sonnett III I'm in the process of restoring and a '71 VW Karman Ghia that's next on the list. I thoroughly endorse the idea of doing something with your hands - it's so much more satisfying than sitting in front of the TV.

- The arbitrary deadlines that serve no purpose. Example: we have to update our app every week/month because reasons.

- The utter lack of understanding of the concept of feature completeness. Example: operating systems that update every year for no good reason whatsoever. What's the point of updating from Mojave to Catalina as a user? What new does it bring? How does it empower the user in a way not before possible? No one knows because it does not. It merely moves things around for the sake of change.

- No one wants to understand what they're abstracting away. People keep piling abstractions upon abstractions yet can't answer the basic questions about how their operating system works at low level.

- Fashion. A lot of it. Basically, if you're doing Android, you MUST want Kotlin and Jetpack and Compose. Same for web — SSR is soooo 2010, gotta make that news website a single-page application because how come would we not use React. IMO, fashion has no place in engineering.

- This "we'll always be able to ship an update" attitude. This is the worst. No one wants to make high-quality software any more, they want to move fast and break stuff at the expense of the end-user sanity. I can't understand how this way of thinking came to exist tbh.

- Business incentives. They ruin everything, but it's especially felt in software engineering.

- Priorities in general. No one is considering what they're making a tool to help the user achieve something. They're making these monstrosities that always put their own interests before those of the user. Dark patterns, purposely inconvenient and awkward UIs, spammy notifications that don't correspond to real events, you name it. In my book, that's not the way to go.

No matter how visionary, proficient, and user-respecting you are as a developer, if you aren't complicit in earning all the money in the world at all costs, you're gonna get replaced by someone else who is.

There are plenty of small companies chasing a dream other than total economic world domination. Obviously if you look at Facebook etc that's all you're going to see.

Also, good luck running a business, any business of any size, without caring about money. Once you're responsible for the the livelihood of your employees and yourself (and maybe even SO and your progeny) your perspective changes radically.

That is until they are pressured to "grow" by their investors that they do have more often than not.

> Also, good luck running a business, any business of any size, without caring about money.

I've worked at a company that was alive and well without chasing profits. It did a bare minimum of monetization to cover its expenses and get a little extra, and that was it. Users were happy, we were happy too. Then the investors decided they've had enough of it, sold their shares to others and those forced the CEO to leave. It was then acquired by a big corporation. I quit in around two years after that when I realized there's no going back and it's only going to get worse over time. It took a lot of effort to make myself go to HR and tell them I'm resigning. I still miss the spirit that was there when I joined. And I'm not sure there are any more companies like this, especially in 2020.

Another point you are missing is that not all companies work that way either. Many people start their own business with their own money and don't have to answer to investors. Look outside of tech: restaurants, design studios, stores, etc.

Yes and you will eventually get it back if your company turns profit — any profit. That doesn't in any way imply growth at all costs which is what the world is obsessed with today because stocks. Practically, it doesn't make much sense to earn hundreds or even thousands times more money than what you spend, yet most companies do just that. It ends up laying idle on bank accounts, not benefitting the end users and society at large in any way.

> Would you be happy giving your money away?

Yes if that meant making the world better.

> Many people start their own business with their own money and don't have to answer to investors. Look outside of tech: restaurants, design studios, stores, etc.

And those usually respect their users/clients.

Truly? Or do you mean you feel bad for people who still have to work for a living? Because if you still have to work for a living I can think of 9000 jobs that suck more than working on software. Btw, I'm turning 60 next month and have been doing this for a living since about 1992, before that I did lots of other things, so I have several points of comparison.

I started my career as a software engineer with web development in the 90's. Everything seemed simpler. Literally.

Then, fast forward to 2020. I'll cite you an example of what happened EXACTLY yesterday. I have a web application which is complete and ready to be deployed. It's a backoffice application for one of our e-commerce sites. It's built using Phoenix, so there is a separate assets folder which contains a webpack config and its own package.json as well. The frontend updates require me to update the assets manifest as well. So, we've setup CI for it to automatically do that for each deploy. So, as usual, it simply runs npm install, but, suddenly, everything broke. Remember, this was fine until our previous deploy. It was some weird error from node about not being able to do something with Babel. I had to spend about almost an hour to figure out it was coming from some other package that was making use of Babel. (If you're interested the error is this one[1])). OK fine, we upgraded the babel version as indicated in that issue thread. However, it wasn't compatible with some other package on the OS we were running on. So, now I had to downgrade the entire node version itself to something we knew that worked.

We lost a good amount of engineering time simply because of this unwanted complexity. Remember, all I wanted to do was JUST deploy. Our backend code was perfectly fine. Just for one new added feature, we had to pay a price with our time. This is hardly an exception, this is becoming in the norm.

[1] https://github.com/nodejs/node/issues/32852

Junior engineer: thinks they know everything

Intermediate engineer: thinks they know nothing

Senior engineer: hates computers

On the engineering side we’ve fully embraced the ephemeral, disposable nature of code, which tends to run counter to business needs which may require hastily constructed code hack jobs to stick around indefinitely. Really makes taking pride in workmanship impossible. You’re allowed to feel good about what your company is doing, but if you feel good about your code then perhaps you’re indulging yourself on company time and could be more productive... so you end up feeling guilty about doing good work.

I also think over the last 20 years there’s been a concentrated movement to remove technical expertise from the product design process. Engineers are present to provide estimates and gauge feasibility, but aren’t granted much leeway beyond that. Decades ago, you needed dev skill to actively shape technical projects since there wasn’t even that much user-level experience with computers and technology to make judgements.

This loss of balance tends to mean software is driven forward almost exclusively by either new features or redesigns. Technical enhancements are rare, unless they exist to support existing features. Nobody wants to spend a few sprints on "Make this thing feel 30% faster" or "Deal with our memory usage issues in these cases" until it reaches crisis levels or customers complain. So you get bigger, bloated software that runs slowly because nobody is authorized to make anything faster or use less resources until a product market position is threatened because of such technical deficiencies.... although sometimes the answer by product leadership to such problems can be even more features.

I think it's worth mentioning that I'm 27 and almost 4 years into my career in software. I am convinced I have the best job of any of my friends, or just about anyone I meet at my age. I make more money and work less hours than >95% of my (all college-educated) friend circle. I don't feel stressed at work ever. My team supports me, my manager encourages me to expand my skillset to whatever interests me.

My career trajectory is looking phenomenal, and I find software development generally fun & rewarding (although certainly not all the time!).

But who knows, maybe that will all change by the time I'm 55 and I'll hate that I spend my career in software dev. Seems unlikely.

Desktop development is the Once And Future King of computer functionality and personal productivity.

I obviously am at a different place than you but I don't think everyone who enjoys the work has Stockholm Syndrome and needs to be pitied. Some of us honestly enjoy it and I plan on working as long as possible as I really like the external supply of ideas to create.

Though had my carrier taken a different path than it did I can easily see being as burnt out as you. I worked briefly at a large enterprise company (not software makers, think greek sneakers) which was so terrible.. if that sort of job was my only option I wouldn't have lasted a decade in this business. That place was seriously depressing.

We aren't working hard because we just want money. We want to save up enough money so that we can retire at 55 and stop working. Then we can start spending all our time complaining that the software industry is going in the wrong direction.

Because in any other industry, the effort:earnings ration isn't nearly as good, so we'd have to work into our 60s before we could do that.

If that's what anyone takes away from my jeremiad, then I actually think that's pretty great. Except ... why not 45? Maybe if more people could use software development as a quick route to something else that created more personal satisfaction and/or social value, that would actually be a good outcome. A bit more "it's just a job" and a bit less "it's my holy calling" is a necessary ingredient in that formula.

For myself, I simply wanted to be free from financial worries and financially independent. I hit that at 35, and yes, I'll probably be able to retire by 45, but I'm a bit too frugal for my own good. For someone living a more 'balanced' lifestyle I think 50 or 55 is a fine goal.

It may not be perfect, but man is it better than what so many people do.

However if you're really burnt out, and still want to exercise your skill, take a break and give open source software a try! I'm still having fun building http://www.oilshell.org/ after many years.

If you're building it for yourself, open source software can be fun, and it should have the side effect of being useful to some others as well.

I'm not saying that it's the way to spend the least time at the computer :) I'm saying it is a way to avoid being burnt out.

If you are building something for yourself, and others incidentally get some use out of it, you'll be less likely to burnt out than killing yourself for a deadline made-up by a VP. And then the whole project gets through away, and no customer ever cared about it. I've seen that a lot.

-----

Related story: Many years ago I got burnt out by my job, and I took a woodworking class at night (lol, definitely a programmer thing). It was great, and I'm typing on top of a desk I made in that class right now.

However I bought a bunch of magazines about woodworking, and I noticed that everyone had 8 or 9 fingers, so I didn't go further with it :) The thing that the OP pointed out is real!

A couple recommended talks about this subject.

Preventing the Collapse of Civilization: https://www.youtube.com/watch?v=pW-SOdj4Kkk

The Thirty Million Line Problem: https://www.youtube.com/watch?v=kZRE7HIO3vk

The purpose of a lot of software is to make software, not to solve problems.

Well, I think the big question is, are you /developing/ or /hacking/? Hacking is fun, developing is a job. Hacking is in a language and stack that's probably a bit unstable, that most shops wouldn't let you use in production. Developing is writing code at about 30% of your ability to express yourself, to avoid someone half-reading your code later from misinterpreting it.

Sometimes you can intermix the two to make the job better. Sometimes not.

This seems a really sheltered perspective without a real idea of the kinda struggles that exist for a lot of other careers. Not unlike some doctor/lawyer/scientist/executive talking about the profession as a "train to hell" because it doesn't satisfy some sense of technical purity.

Before building software, I was stuck in dead-end sales jobs with a humanities degree that had no career prospects. Switching to software development has required a great deal of sacrifice, and I'm genuinely thankful every day I get to write code for a living I'm thankful.

- I'm thankful I can get paid well enough to live comfortably.

- I'm thankful I work in clean, climate-controlled offices.

- I'm thankful for a profession full of interesting people to work with.

- I'm thankful I can engage my mind and excercise a certain amount of creativity in my work.

I really hope 55 year old me can remember to be thankful.

But I've always enjoyed tinkering on non-productive personal projects more. Exponentially so. I'm with you on most of the things sucking in software development.

I spend so much time on shit. Politics, presentations to justify spending 0.000001% of our budget on things I need, convincing others that maybe we should leverage well established best practices, not even controversial or cutting edge kind, but the actual ones people everywhere use, rather than re-inventing the wheel every time.

Right now I'm expected to inventory our software catalog, again, because someone doesn't want to get that information from the place we are using to already document it.

And it's only Monday. This week will be long, so very long.

Startups became about flipping crud apps that try to get users addicted to them.

There are still cool and honest jobs out there! Work in a space you care about and have fun, filter out anything with VC money or FAANG. Usually older companies can be more rewarding from a career perspective, you also get to work in bigger projects with more responsibilities as well as you aren’t competing against 50k’s of software engineers to climb the ladder.

I don't think I've ever worked a day in my life.

Well, not strictly true, I've had several jobs that start out with interesting problems to solve and then became "it's another CRUD app." I quickly left those jobs to find other work.

I'm not cheap but then I'm not well compensated. I don't make FANGMAN income, but I am financially comfortable. I've found joy every day in my work, even if there are many days where the work in utter frustration, by simply seeking out the kind of work that makes me happy. With an interesting problem I will work all the hours my mind and body can muster. With a 9-to-5 "what's the point/what am I learning/this has been done eefore" regular work-a-day job there is no amount of money on this green Earth that could get me to focus or be happy. Well okay, there would be a certain amount, at which point, after 12 months, I'd quit, take the money and go do a different job that pays less but is more interesting.

This course of action isn't for everyone, not everyone has the privilege of saying "F* it! I'm out." when they are doing something they don't find joy in. I've just made sure that I never put myself in a position where I couldn't choose that course of action. The road has been hard some days, and money has been tight more often than I want to recall, and I won't die a wealthy man, but I will have had adventures along the way that keep me still striving to build software every day.

Footnote: My job last year consisted of writing kernel drivers to speed up SSDs. My job at the beginning of this year was control a radio controlled car from your cellphone. Then I built a dashboard for my home that tracks my phones and my cats and the weather. My job, right now, consists of building a stupid simple app (with a lot of screens and moving parts) on a mobile device that talks to OpenWRT to put a pretty and simplified user interface on what is a complex piece of software. I've never had to build a mobile app that tries to simplify a complex router interface before. It is a learning experience. But once I've learned that lesson, I won't be building another one. I'll go find something else to do.

Life is what you make it.

Honestly it’s easier now to do things like that than 15 years ago when I first started.

It shocks me, just how often OOP is just not nearly the best approach to something. I certainly still lack in experience though. But why use OOP for something like putting data from a sensor onto a bus? And stuff like that.

Me, I'm about to turn 50, and I don't see being able to retire until... well, ever at this point.

I might change careers some time, but I doubt I'll entirely give up on software. Maybe just do it for fun.

Asking for a friend.