Completely agree. It's the equivalent to keeping a tidy workspace with others in mind. Teams should spend time narrowing down coding styles, naming conventions, and general rules together over time, and stick to them.

As new people are onboarded, stick with those rules but have periodic moments where you solicit feedback from your team on the approach and make changes.

It really does help to have a team agreeing on these things collaboratively, and ideally having a more senior person enforcing it during code review where it's reasonable.

It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.

This is a great analogy.

There’s some related thoughts on safety practices that would be readily apparent to someone on a job site that apply to software as well. In my personal experience, people who don’t take pride in their work are the same ones that end up creating unsafe situations. The software parallels are easy to imagine.

> It's basically like a construction site - plenty of low rent projects are done in a totally disorganized "get 'er done" way. You won't see that as much for a high value construction site with top tier vendors and workers who value their craft.

The Salesforce tower in San Francisco begs to differ: https://www.popularmechanics.com/science/a29329189/salesforc...

> for a high value construction site with top tier vendors and workers who value their craft.

Is it really that, or are there just so many parties involved, that a heavy bureaucracy/coordination layer is required to keep the project from collapsing on itself, and this happens to manifest as everything looking neatly organized and structured?

This and construction is governed heavily by codes (in the US, at least). This constrains how much freedom builders have to design any-which-way they want.

But to the OPs point, there is a stark difference in the quality of work between tradespeople who respect their craft and those who look at it as merely a means to a paycheck.

Is there such a thing as clean code? What’s perfect now can change at any moment.

New business or acceptance criteria, architectural changes, and other human created obstacles.

What exist is code that can be maintained, and code that just cannot (in practical time). There is no sharp cut, is a continuum. But if nobody cares, at some point it grinds to a halt.

Software has been around long enough that many companies have been burned by bad code and so they are willing to give training and time to making it better. While there are trade offs, spending several years of no features while engineering rewrites the whole thing isn't acceptable.

Extensibility is the term that speaks to this situation. Extensible code, updated by skilled developers, will allow for radical business logic changes without sacrificing the quality of the code over time.

It's like a skyscraper. The critical structural stuff is fixed but the architects and engineers try to minimize those pieces and create flexible spaces that can either be high density cubicles, enclosed offices, a cafe, etc...

Eventually it's true that you have to tear it all down and there's nothing wrong with that - a good developer will know when that makes sense based on the needs of the stakeholders and make that recommendation.

I like it, but I think how easy it is to replace is more important than how easy it is to extend. Otherwise it might end like those massive class hierarchies instead of a function.

For me, pure functions and enforced types do the trick.

the word 'care' is doing a lot of work here.

Not all code is created equally, not all code needs to be clean or have a lot of time spent on it. Many times those who "care" about clean code have difficulty understand when it is, and isn't appropriate.

I agree with this. The metaphor I use is restaurant kitchens. Some kitchens are permanently greasy and look like a bomb went off. The best 5-star kitchens are a whirlwind of constant cleaning and mise en place.

"Clean code" is useless when it's an artistic aesthetic, but operationalizing the sense of "everything has a place, clean up as you go" has concrete value. You can spot teams that DGAF vs. teams that treat their responsibilities like a 5-star kitchen. In both cases, it's "just" a job, but that doesn't equate to carelessness.

There is often no better feeling of leaving a job where spaghetti code is a constant problem. I've worked on projects where co-workers took numerous short cuts that I'd regularly have to fix months later after they ditched their role. There is no real way to fix the problems of that kind because companies that emphasize proper testing and clean code simply don't weather tight deadlines and cost cutting that the rest of the industry imposes on everything, that's why there is often no better feeling of leaving a job where spaghetti code is a constant problem, :P

Like with many of the examples in the replies - they may not care about how clean your code is, but they sure as hell care (and notice) if they're constantly having to untangle someones shitty code after it broke production again.

It's about where you are at relative to the median in the group, typically, not about any absolute standard.