I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists.
I can, however, imagine quitting if my manager is a shitty person.
I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low.
But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.
> It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low.
If most of my income derived from being an owner of a company, I would care deeply about this problem.
Since it doesn't, its really no sweat off my back, either way.
> It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches.
In my experience, tech churn is one of the top reasons for why code has gone to shit. "It's been three years since the last re-write, let's rebuild the product again, in a framework that nobody here knows how to use!"
On the bright side, both the re-write, and the cleanup of the resulting mess means steady employment.
> Since it doesn't, its really no sweat off my back, either way.
Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.
Do you think so? If you do, and you hire people, you should seriously consider not thinking in that way.
Any manager who can put two and two together should be well aware that the impact that an average IC has on the success of a failing company that's bigger than 100 people is near-zero.
It's just pedigree snobbery, to look at a resume, and go: "Oh, well, he worked for losers, he must be a loser, reject."
So would you work the rest of your life before retirement to dig a hole and then fill it up again, over and over. Let’s say you get to make 10x whatever you are earning now. Oh, and, the manager is a nice guy, he gives you lemonade and stuff on breaks.
Most people do exactly that for a living. I don't let my 9-5 define my life. It means I'll retire in two years, and be able to work for a cause that I deeply care about - or, better yet, for myself.
A better thought experiment is to ask yourself how many of your co-workers will come in tomorrow, if all your code became the most beautiful code ever written, with rainbows, and unicorns... but on the flipside, that they stopped receiving paycheques.
> Plus it's often only beautiful to the person that wrote it.
From what I've seen, this may be true in some particular cases, but this is not a general pattern.
I've found that beauty, in software (as in art and design in general) very often has common elements. People certainly have different preferences in how the elements are put together, but I think many people can appreciate the underlying principles.
Here are some examples of the principles behind beauty in software:
* A component obeying the principle of least surprise
* A function having a clear purpose
* A function using a small (perhaps minimum) number of arguments for its purpose
* A codebase cleanly separating concerns
* A codebase reusing standard components
* A codebase having appropriate documentation suited to the team working with it
* A codebase having good testability
* An algorithm (e.g., one based on a published paper) solving a problem by doing less work
* A function having fewer lines of code
None of these are absolute. (For example, the last two may sometimes exist in tension with one other.) I see the concept of beauty as relative to a set of goals and values. Beauty almost always often involves a sense of balance and proportion: trading-off principles that are not perfectly orthogonal.
Of course, there are different perspectives on how to achieve a particular balance for a particular situation.
I'd like to add an unsupported claim (that I happen to believe, given a set of mostly rational people working together in a healthy work environment): If you get these people together and say "is codebase X beautiful for purpose Y?" I think you'll find a lot of consensus. In areas where they disagree, I think the resulting discussion will likely be constructive. I would bet that the discussion will lead to a better design in the end -- as perceived by the participants. This assumes that the people learn from each other; e.g. proponents who tend to favor one principle are willing to listen to proponents of other principles.
Code that is easy to work with is usually that way because the author went out of their way to make it easy to work with, often this takes 2-3x as long to write as normal code that just works. Publicly exposed api's typically get this special attention and internal things get the normal spaghetti treatment.
