> I'm tired. I'm tired of the artificial deadlines
I think the ephemeral nature of software really plays poorly with the artificial deadlines, and the artificial importance of some projects in general.
Eventually you recognize the pattern, and there's no logical way to justify it, so it's harder to motivate yourself. You know the deadline isn't real, and you know the software will be rewritten next year with some new technology. You may even be rewriting last years right now.
Tooling churn hurts here as well, because eventually after enough iterations, new tools are just in the way of getting real work done. You know it's not gaining you anything by putting in the effort to learn Toolchain X, because arbitrarily different Toolchain Y is about to become the new industry fad, and will make all that prior arbitrary knowledge pointless.
Some of my favourite years in software were when I worked at an eCommerce agency that served only one framework. Learning I invested directly impacted my work for the coming years. I began to master the tools, which feels amazing. I could also see the real world effect the software had. Sure, it was simple, selling products to people. But commerce is an interesting problem space, and a fundamental part of society, so it was neat to be a part of it and see real companies I worked with grow because of my software.
This is why open source software at least is good -- it tends to have much longer lifetimes, so chances are decent that your code will still be running decades down the line (so long as you picked the right project).
For example, one of the open source projects that I contributed to most heavily, PyWikiBot, has been around for almost two decades now, and most of my contributions were made ~13-15 years ago, plus some minor maintenance since then, and most of those features I wrote are still in continuous use to this very day by me and many others. And that's just some random tooling library for Wikipedia stuff; imagine how much long-term impact your work would have if you were editing MediaWiki itself, or the Linux kernel, or gcc, or any number of other incredibly widely-used things.
> the ephemeral nature of software [...] it's harder to motivate yourself
It's been a few years since I left the industry, and I'd be surprised if any of the code I wrote professionally hasn't been superseded by now. Even worse, plenty of it was scrapped before it was even released.
Of course, I knew this would be the case when I was writing it - that does indeed affect one's motivation.
I doubt if more than 25% of my work-hours as a developer have gone toward any kind of program or product that went on to provide enough benefit to have been worth the effort and expense. It feels like being one of the monkeys in some kind of million-monkeys Shakespeare project. Like the system just tries random shit and sometimes something works but mostly it just wastes everyone's time (lives).
I can tell you that working with legacy turd (that will probably run for another decade or more) isn't necessarily much better.
Again the deadlines and lack of planning ahead bites. Look we just need this little feature now, it can't take long? And again, and again. You never get enough time to take a step back and re-evaluate design decisions (or, God forbid, plan ahead and do it right in the first place) and fix what wasn't done right. No, it's always this little feature that needs to be quickly hacked in, another branch, another special case, how it interacts with other past or future special cases is anyone's guess, and the code base that was already full of hastily hacked together barely-functional crap grows more and more poorly thought out crap. Tests? What tests? No tests, so if you dare go back and try quickly fix some poor design.. well, someone is eventually hopefully going to find out what you broke and give you a completely uninformative bug report. Updates? Well there's no ticket for that. And besides, something might break, because there are no tests. There's no ticket for tests.
Sometimes you might even wish that the whole thing would be discarded and done from scratch..
I prefer working with legacy turds over steaming hot new shit, but I have a hard time finding companies who will pay me for that work. Everybody wants the steaming hot new stuff.
The code I wrote in my first job out of college is still running in thousands of locations 25 years later. But then, it was Windows software for a particular industry, not a website. Most stuff I've written since then has been replaced or will be soon.
> code I wrote professionally hasn't been superseded
Well, the state of New Jersey is looking for programmers to update COBOL programs that were written 50 years ago, so you might be underestimating the sheer power of inertia in software development...
I think the ephemeral nature of software really plays poorly with the artificial deadlines, and the artificial importance of some projects in general.
Eventually you recognize the pattern, and there's no logical way to justify it, so it's harder to motivate yourself. You know the deadline isn't real, and you know the software will be rewritten next year with some new technology. You may even be rewriting last years right now.
Tooling churn hurts here as well, because eventually after enough iterations, new tools are just in the way of getting real work done. You know it's not gaining you anything by putting in the effort to learn Toolchain X, because arbitrarily different Toolchain Y is about to become the new industry fad, and will make all that prior arbitrary knowledge pointless.
Some of my favourite years in software were when I worked at an eCommerce agency that served only one framework. Learning I invested directly impacted my work for the coming years. I began to master the tools, which feels amazing. I could also see the real world effect the software had. Sure, it was simple, selling products to people. But commerce is an interesting problem space, and a fundamental part of society, so it was neat to be a part of it and see real companies I worked with grow because of my software.