This is what is fundamentally wrong with the industry. Often those who don't care or don't do much are the highest paid and get more reward that the ones who care the most and always try to do something. Obviously, the environment eventually turns those who care into someone not caring as much. Eventually not caring at all, thus a toxic environment is formed. Some may also feel that this is the norm in most companies and leave for freelancing etc.
That's why I like open source projects. People writing open source might not write perfect code, but often they at least have opinions and beliefs about how things can or should be. Even if you disagree with decisions, you'll learn something.
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.
I think I've encountered more vitriol on corporate software than corporate things (related to code). Much of the battle is often not about code, but about process, other parts of the organization, etc.
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.
I prefer open source applications for this reason. If the code is ugly it's less likely to work, and if you write ugly code publicly you are less likely to get work.
Can we stop using the word 'smart' as a synonym for cheating and fraud please?
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: "But you didn't account for all the edge cases. Your solution seems to work at first glance, but now someone else is going to have to redo what you've done and fix the data problems that resulted from the half-assed job you did."
In my experience, a careless engineer will create something brittle and unwieldy that works at first glance, declare success, and move on, leaving others to deal with a painful mess. A thoughtful engineer will think hard about design, comment where there be dragons, and often get rewarded by being reassigned to one of the aforementioned messes.
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.
>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.
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.
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.
