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 :)