[nightski]

A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful.

I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.

[adrianratnapala]

Yes it is good to understand people and the business, but you are also hinting that much of the bad code around the place is some kind of big-picture smart optimum of technical debt. vs. development velocity.

But this is unlikely if you stop to think about how humans behave. Who in an organisation has an incentive to find such an optimum? Shareholders and the board maybe; but they can only drive things by rewarding and punishing middle-level individuals. And they can only reward impact that they can see. Thus the incentives are to create visible impact which can be spun as a net gain. If that creates technical debt, then that is somebody else's problem.

[sanderjd]

Yep, this is difficult, but I think it is the correct approach. To follow on: if you do this successfully and you also demonstrate technical value to the organization, you are very likely to find yourself with enough credibility to successfully advocate for (or lead) efforts toward better engineering practices.

If you do all this, and never gain that credibility, possibly due to problematic individuals at the higher levels of the organization (which you can't control), then it's probably time to move on.

[zoul]

I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?

[ravenstine]

Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.

[drvdevd]

Especially in a startup, but obviously in established companies as well, this will give you an idea of where it’s all headed.

If you’re in a place that’s reliant on good code (and good execution strategies) to exist, and the other people don’t or won’t or can’t really grasp the magnitude of what good code means to the company - leave.

[mistermann]

> At the end of the day the goal is not to produce clean code. It's to make your company successful.

An even more accurate description: don't assume anything, determine what the goals of the power player employees at the company are, and follow their lead. Assumptions of doing a good job, helping the business, fulfilling the mission statement all seem like reasonable goals, but assuming you are working in a reasonable organization is not always a safe one. Sometimes, the whole thing is mostly smoke and mirrors, and someone coming along with the aim of doing a good job will become very unpopular.

If you happen to find yourself in one of these places, just imagine yourself on the set of a TV series about an IT department, say all the right things, and you might very well be able to get paid to play around with things that interest you 90% of the time while keeping up appearances with your other 10%. Be mindful of what this can do to your resume and skillset, but as long as you're making productive use of your time learning new technology, you can typically lie about what you did at your last job and most interviewers won't have a clue anyways.

[laythea]

This is a very good, professional response.