"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.
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 ?
There is big difference between doing new things, and doing the same things(again and again) with new tools. Take the this whole big data craze for example, almost every body I see who wants to use these tools doesn't have a use case for it. The same with NoSQL. Or Twitter's Storm. When you subscribe to this way of software development, you start shoe horning your use cases into wrong design paradigms, leading to a lot of maintenance work.
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.
That section meant something to me too, but something different.
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.
So most developer experiences are of dealing with an unending stream of unnecessary dumb puzzles, rather than challenging problems with real meaning.
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.
"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.