> Machines break, or fall behind evolving requirements
Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.
That's why I've basically quit software. The vast (vast) majority of the code I've written over the past three decades is useless. It is no longer used, and it could not be used even if someone wanted to use it. It's obsolete, because all the underpinnings have moved on. It's sort of depressing to be in the final years of my career and be able to point to nothing that I've created. I'm still working but I've quit learning new frameworks or languages. It used to be fun, now it's just tiring and seems pointless.
Sorry for a tangent: this is what I really love about some languages like Common Lisp where very old software (that may still be very useful!) still builds and runs.
Maybe find joy in the fact that without your temporary contribution, the next step would never have started ?
I mean it's like a lot of jobs: a taxi drivers cant really pinpoint his accomplishments, a nurse will see all person they ever cure die one day, things like that.
Contrary to what someone said above, software is not a machine, it's the state reconfiguration of a machine, one of its many inputs. As a programmer all you did was align the knobs to make some inputs produce some outputs, but upstream and downstream changes will change input shape and output requirement, or the machine will change its constraints or the programmers will have figured no way to state change it.
Your contribution was important, but thanl god we dont use the state configuration you wrote 20 years ago to solve today's problems.
I think its the curse of doing development professionally - except the rare case where open source monetization has worked well enough to support a long career, closed source software is designed to be disposable.
You build something fast because marketing or sales wanted it, not because it was a good idea or anybody found it useful. Most people probably hated your feature.
But, OFC, giving it away for free is nearly impossible to actually make money off of.
Like the taxi driver, probably nobody will remember you unless you said something particularly impactful to someone. Someone working as a pro-bono ambulance driver is more likely to receive accolades, but that's still difficult.
This has been on my mind for the last 15 years. I'm an ops/systems/architect person. I don't expect any of the systems and services I build to exist after 10 years. At least, not in the way I built them.
This makes me want to invest time into hobbies where I create things that endure. Of course, I don't have time for that because I'm too busy building temporary solutions to what feels more and more like unimportant problems.
Highly misleading. I've compiled plenty of older Go code. It just seems like you don't know how to deal with Go code, unless it's been nicely packaged as a module with go.mod
Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.