It really feels to me as if developers these days care much more about the development process itself, and how their code looks, than about the end product of their work that the users see. Same for designers — they want their UIs look "clean" and enjoyed like works of art, disregarding obvious, glaring UX issues that arise when any person at all tries to use the thing.

Also another problem that doesn't seem to be talked about a lot is that way too often, the stake holders and the developers have nothing in common with the end user.

Apple in particular is a good example here. They used to position themselves as a company that makes great tools that empower people. But now they're putting their own agenda, and, conveniently, bottom line, before that. That's how we end up with endless redesigns of things that worked perfectly fine for everyone (e.g. safari).

I don't want to work at a place that has "business goals". I don't want to work on a proprietary product either. I just want to use my skills to make the world a better place, and moving money around ain't that. I don't want to participate in the rat race or help it in any shape or form.

I worked at VKontakte (Russian social network) and was the only Android developer for several years. It was amazing when Pavel Durov was still the CEO. I was living the dream. It all went downhill form there when it was acquired by mail.ru group and I had to quit because it started feeling like an abusive relationship. My app being closed-source didn't help either.

Then was Telegram. Same Pavel, mostly same team, but the tasks were much more ambitious, and the product itself much more complex and internally intertwined (every single update touches the chat screen, which in the Android app is more than a megabyte of pure Java). I did the VoIP library from scratch. In hindsight, this certainly isn't a one-person endeavor, but I didn't know any better. So, yeah, eventually, but very unexpectedly, I was fired by that same person who I was a huge fan of for so many years. The reasoning was that "our calls are shit". Apparently I was supposed to write code that didn't contain bugs and just "test it myself". Oh all those foolish other companies having QAs, right?

I have no idea where to go now. I want my 2011 back. I want to be passionate about something again.

* It's (mostly) all open-source.

* It's self-directed. Don't like a team? There are a dozen others waiting scrambling for developers that you can join with no bureaucracy nonsense. Want to work alone? The tools are mostly mature enough that you can release products as a one man team.

* You seem to have disinterest or even aversion towards money, from its role in tricking people into mindless jobs. DeFi is about the roots of what money is, voluntary transfer of value between people, which is something I think everybody can agree is fundamentally good.

* You can have a huge impact.

Though, yes, if I wanted easy money, I could go work at such a company. Or I could as well go to a FAANG-ish megacorp and earn craploads by working an hour a day.

Be very careful when putting your trust in visionaries.

Developers want to change stuff and do greenfield because it's fun, but that's a whole different beast to a career track whose job it is to change things. This goes beyond just poor incentives ["Googler gets a raise because shiny new thing"], into "upper management have created a construct whose purpose it is to disappoint existing customers who like what's already there".

There may be an argument that you'll draw in more people with shiny stuff, than you'll lose when you break old stuff. I only have anecdotes and personal experience that that's untrue [digg? reddit? metro?], and no examples of cases showing that argument to be right.

Also, personally I get my jollies working on other people's old code. I work with several FORTRAN codebases that pre-date my birth, and I enjoy it.

Sure, but companies aren't being blindsided by project managers who sneak into their org charts and start driving change unbeknownst to company leadership. They're hired to do these things and their performance is based on how well they do them, just like anyone else.

This might be a good example of the struggle of middle management: You get blamed from all sides for just trying to do the job you're assigned.

So my resume always needs to be fresh. I can’t be working with older technology because when it comes time to jump again, I won’t have the skills to do so.

Asking an iOS developer to work on Objective-C is asking them to sacrifice their future prospects.

Devs have a lot of the same incentives product managers do.

I also see the same pattern in "Ask HN" posts and many comments here from people venting about how they've started so many side projects but can never finish them. Starting new projects is fun. Shipping things can be hard and requires some tolerance for boredom.

A lot of people get into the field because they like to program and play with new programming things. Regardless of jobs or compensation, there's a strong pull toward doing new and different things. There's also a strong aversion to working on someone else's project.

To throw another log in this rant bone fire, a few decades ago software was seen as harder and more expensive, and while there was some frivolous and/or stupid apps, big enough development projects were usually bound to some purpose.

Our industry in its current form is more open to build meaningless things and trash after a while. I knew devs who were specialized in home page redesigns, and they viewed it as facelifts to show the client company is still alive. It has a business purpose, but in the grand scheme of things the only person that really enjoyed the project was the guy using it to learn vue.js.

Or a team porting an app from Objective-C to React native, not because they think it’s shiny but because hiring is hard/expensive and/or the business wants to have one size fits all apps for iOs and android.

The FAANGs have tons of Objective-C code. The largest and most popular iOS apps in the world are actively developed in Obj-C and C++.

It’s absurd to me that mobile developers actively undermine their ability to get those extremely well-paid jobs by limiting themselves to one language.

The impact a language has on your career prospects is U-shaped. Knowing new languages is good for your career. Stagnating on an 'old' language is bad (Swift is only 7 years old...). But eventually knowing the old language puts you back in demand again, to port and support old codebases.

This just sounds insane to me being a non-programmer. Literally nothing in my job requires me to be up to date on technologies that are less than 10 years old to be considered for a job.

No wonder they don't want to work on someone else's code, they don't even want to work on their own old code :)

It's a hard problem. Sometimes it's unnecessary but sometimes the tech debt is real. It's not uncommon to have one blessed path for doing most things but hey, here's this edge case that doesn't fit our mental model and is a pain to test and bloats our bundle and we keep getting paged for it and the engineers who built it left the company and didn't leave any documentation or tests, so let's just kill that feature.

And now users are pissed and don't understand, because from their perspective, they think the cost of leaving the feature alone is zero. But the truth is the cost of keeping it is quite high and there just isn't enough usage to justify engineering effort to reduce ongoing maintenance costs.

If you look instead at a mature ecosystem, like, say, C++ or Java, you might reasonably maintain a codebase for a decade without needing to adopt new language features.

So that feedback loop is going to incentivize short term thinking and small changes that might not be beneficial to the whole.

Some of the best software I've used are mostly developed by solo developers or small teams (Sublime, YNAB4) because they actually care about their product instead of the underlying tech.

But YNAB is also a great example of apps-getting-worse — you're explicitly praising the 2012 version over the 2015/evergreen version.

(In YNAB's case, they had business reasons to make the app worse (or thought they did), but I bet that's true of many of the examples in TFA)

I’m fortunate that the company I was hired at doesn’t care that I haven’t worked on Kotlin or React. But I was passed up by many companies because I didn’t have react experience - can’t help it if my last few jobs were all angular.

Many engineers are focusing on doing what will help them get the most compensation. And following industry trends is part of that.

In most fields, there are also second-tier jobs. You get to enjoy a nice middle-class lifestyle with a good work-life balance in a stable long-term job. The incentives are there to do your job well, because you have to face the consequences of your choices. I know plenty of software engineers in jobs like that. When the company eventually goes bad, they have no trouble finding new similar jobs, because good experienced software engineers are scarce.

Surely there must be a point where the product functions as intended and the peak number of users like it like that. Instead we carry on. Everyone has to keep proving their 'value' right? Always changing, always growing. Everything eventually gets iterated to death. Any piece of software or design, no matter how much you might like it will eventually be replaced. It's as true of software as it is of car shapes or curtain patterns.

Just imagine being the CEO of Evernote (mentioned elsewhere in the thread) announcing to the world that they are feature complete. It's a finished product and they are laying off everyone except customer support and marketing. They would be considered insane despite that decision delivering the best profits and customer experience.

Probably because Google says Kotlin is the way. You can't use Compose, Google's reboot of the View system, from Java. Why did google create Compose? To eliminate a decade of cruft and problems for one, so congrats ... now your developers are stuck with it.

This is why "it's the PMs" is a refrain -- because the changes they make are very tangible in the end product.

Backend folks do this too btw. I’ve seen adoption of Docker, Kubernetes, microservice architectures, Rust, etc. driven more by a desire to use the latest trends than the best tool for the job.

While I don't think appealing to new hires should drive your tech stack, telling them we still used SVN was something you kind of said under your breath with a bit of shame. As for "nobody wanted to work on someone else's codebase" is true, but I think needs some give and take. If you're making someone responsible for something you need to give them some latitude for running it their own way. I'm going to grumble less about dealing with my own mistakes over someone else's, but rewriting everything every time someone quits isn't an option either.

Resume driven development is a bad anti-pattern and leads to software nightmares. Avoid it.

> Everyone wanted to work on greenfield projects and technologies that would look good on their resume going into the next job.

Greenfield = easy. Fixing a 10 year old architectural mistake = hard.

> Blaming product managers is an easy out

Resume driven development and product managers who make changes for the sake of their own resume are two sides of the same coin. It's all putting good for yourself over good for your customer and good for your employer.

Wouldn't this not happen if the employers just paid more? From what I understand, people do resume-driven development because they want to work at a place that will pay more at some point.

If I was maintaining some decades-old legacy code and knew that my employer will most likely still be around and pay me a competitive salary for the rest of my life, I wouldn't mind just mastering COBOL.

But most companies go bust or lay off developers at some point, so keeping yourself employable by working with the latest tech stack is unfortunately quite a necessity.

[1] https://marker.medium.com/why-dont-tech-companies-pay-their-...

> If I was maintaining some decades-old legacy code and knew that my employer will most likely still be around and pay me a competitive salary for the rest of my life, I wouldn't mind just mastering COBOL.

That is how I feel too. In fact I'd prefer working on something that really lasts compared to the latest fad. But the differences in salary make this a difficult choices.

That doesn't mean you should actually do it, but as someone who's had more than enough time to get over the new and shine syndrome there's a lot to be gained by migrating as often as needed (ie. the productivity gain from the new outweighs the migration/current support cost in a reasonable timeframe).

Programming tools, techniques and languages are still evolving quickly and even in the same ecosystem I don't use many of the tools and a frameworks I did 5 years ago.

This isn’t actually the developers’ fault, either. I think we need to blame the tech industry as a whole for this.

What is it in it for the developers to work on Object-C and other older technologies?

Swift is hardly new anymore... are you going to maintain an ObjC codebase in perpetuity?

What's the objective benefit of rewriting something already working into a different language?

I am just writing some hardware test app using C++ and wxWidgets.

But in general, yes, you are completely right. It's just virtual signalling between developers. You can't just write something, it has to be Instagram friendly. It needs to be popular and have hundreds of stars in GitHub.

Despite hating the game, I'd probably create similar incentives if I had a company. Because the other option is stagnation.

Is there a third option?

Yes: some companies have employees who don't quit as soon as a new JavaScript framework is launched. Do what they do. Yes, large companies operate by different terms than startups, but I assume (big guess here) there are startups who aren't just angling for acquisition or unicorn-or-bust layoff pits. Note that they may not say they're going in those directions, but they will definitely manage you in those terms.

[In fact, I'd be curious how many <20ppl companies with 80hr/wk soldiers aren't hustling for acquistion or aren't running out of money]

For GP, it seems obvious that they're interviewing the wrong people. It could be their phone screening, it could be their ad, it could be their industry sector. For instance, don't advertise for a Front-end Developer, advertise for a [thing you're actually hiring for] Developer, and screen resumes on this basis regardless of what you put in the ad (which hopefully is accurate as to job responsibilities and necessary skills).