Corporate code just mirrors corporate structure after a while. More and more lines, where other people are or were responsible, where any reason has been driven out (your learning experience by asking "why is this written or designed like this" gets short circuited with a quick "well, who knows") - which slowly but surely spirals down quality, engagement and fun.
Or at least I should say a lot of OSS projects are corporate, so they feel the same way. The for-fun stuff can be, but it can also wear you down. There's a lot of hate among users of projects that you are directly exposed to, where a paying customer can often be a lot easier to talk to. It's weird.
It's ok and fun when you have a few users, but when you have lots, you find they can be really hard to scale -- so many different points of view, so many different conflicting needs, "managing" people you don't pay, trying to break up disagreements, many more points of compromise, etc.
See the Napoleon anecdote:
http://www.johndcook.com/blog/2010/12/27/dumb-and-gets-thing...
There is nothing smart about faking and pretending to contribute while doing nothing. All the while taking the rewards and benefits which should actually be going to people who do the real work. This even on a short period of time creates an environment which causes the real contributors to go better places leaving the overall ecosystem starved of much needed work.
Programmer: "I managed to migrate the database with the program I wrote over the past two months"
Hacker: "I migrated the database with 3 lines of code"
The enduring tension of this line of work, in my opinion, is how to balance my desire to take pride in my work with my desire not to be a thankless janitor for the chronically cavalier. Not to mention that there's value in a product that gets out the door while the competitors are still trying to make things perfect.
That's a good observation.
Fortunately I've worked myself into the code troll position on my project - nothing goes into the mainline without my approval. Everyone knows I'll reject code that's not well thought through even in the face of looming deadlines.
"They’re interesting for a while, but they’re also the same self-inflicted wounds everyone seems to deal with — why is this slow? why is this broken? how can we keep this old code limping along indefinitely without having to rewrite it? how does this thing a former employee wrote even work? They’re cute puzzles, and I can get into solving them for a while, but I don’t care about them. Because they aren’t my problems; they were just dumped in my lap, along with a canvas sack with a dollar sign on it."
Companies that write their own software create something where nothing existed before--and so by definition, all of their problems are self-inflicted.
Shit gets old, fast.
Decisions which are made after much thought, planning and running things from a long term perspective turn out to last really long freeing your time up to pursue new projects.
Jumping on to a new framework every few months because its trending on the internets is the reason why every one is in a hurry(to achieve a pointless goal) to do work which has already been done, over and over again.
I mean , is it feasible for the ordinary developer to engage in a multi-year risky R&D project that might ultimately fail resulting in nothing ?
Most people barely have any time to code. It's just because Github is your Resume (TM) that makes most people crank out their own Javascript framework so they can have it on their resume.
Could you give any examples of any such long term one man personal R&D efforts ?
This doesn't happen just in the backend. It happens even with FE frameworks. How many people have a use case for react or other jazzy frameworks?
A crude example I can give you is, this is like developing all your applications in awk or sed because that's fashionable currently. You are shoe horning your problems into solutions paradigms they don't belong to.
Programmers have a tendency to detach themsleves from the business where software is there to maximize the profit. It doesn't matter whether it's written in PHP, Ruby, or [language of the year] [0]. But if you let the programmers go wild, many of them have a tendency to pick the hottest thing just because [some reason that has no advantage from business POV]. I guess that's the sign of boredom.
Programming is fun, playing with new toys is fun, but it should not be forgotten that it's part of the business.
[0] Well, it sort of matters. Dev time costs money, good tools and languages will make you write it faster therefore maximizing money. But that's not what I am talking about here.
I was just talking with a friend that is really frustrated because in his view his team is not only trying to deal with a bunch of tech debt, they are trying to move so fast that they net create more tech debt every week. And he feels like he's the only one who will look at this squarely; everybody else just finds their little puzzles to work on. I expect eventually he'll quit and go somewhere modestly less pathological.
The root issue is not that the problems are self-inflicted. The shit-rolls-downhill ethos means that they are to the company, but not really to an individual worker. So most developer experiences are of dealing with an unending stream of unnecessary dumb puzzles, rather than challenging problems with real meaning.
This is not how it has to be. I've been on projects where the code got incrementally better each day. Where we spent most of our time on things that mattered to us and to the business, instead of sweeping up after the elephant parade.
That's exactly what I meant by self-inflicted: thank you for stating it clearly!
I don't mind working on genuinely hard problems, even if we can't get anywhere. It's dealing with lots of unnecessary silliness or trying to get one more month out of the shitty legacy code that drives me nuts.