The Most Important Non-Programming Skills for Programmers

Edit: Obviously, I'm not GP, but here's my take on this.

> doesn't clean code always deliver a higher value as opposed to, say, messy code?

I'll agree with you there, but I'm under the impression that the phrase "clean code" is somewhat too ambiguous.

Coding style per se is very subjective anyway, so obsessing over it propably is not a good thing in most cases, yes. But if the "quick and dirty" approach also influences the architecture of what you're developing (i.e. it also affects other code) I'd very well argue that taking a stand against it is a good thing to do.

On a similar note: I find the notion of "technical debt" to be quite useful in a lot of ways: By taking the short path, you'll be forced to make up for it at a later date, be it through slower development, a lack of reliability or the necessity to clean up the "hacks". Where the metaphor breaks down (and seems to be contraproductive) is that it leads many business people to assume the debt (i.e. the negative impact) will be easy to quantify and can be treated like some other expense (and thus it often is ignored for far too long).

So, the first thing I ask whenever the "business side" asks for a quick and dirty fix for something (often mainly because of some production issue) is "When and how are we going to fix this properly? How will we deal with the downsides in the mean time?". This usually achieves my goal of making them think about the implications more -- I don't believe that's a very viable strategy in bigger companies, though.

As the other response stated, it depends on what you mean by clean code. When used in a positive sense, “clean code” just means well written code that’s easy to reason and maintain. When referenced in the pejorative sense, it means “overly engineered”, or potentially that the author of the code spent an excessive amount of time writing something that could have been done much faster.

As for whether or not clean code always delivers higher business value, the answer is no. Businesses rarely deal in absolutes and clean code is not always better. Business and engineering is just a huge game of trade offs, and code quality is just one knob you can turn up or down when discussing priorities for you and your team. Is it one you should frequently sacrifice to accomplish company goals? No. But, sometimes it makes sense.

> Just wondering, in terms of value for the business, doesn't clean code always deliver a higher value as opposed to, say, messy code?

Of course it does, and writing clean code should be one of your goals. But it should never be the primary goal. You always want to be aware of why you're being paid: it's to deliver value and increase profits.

Maintainable code is important, but our thought leaders have been putting the idea of clean code on a pedestal lately. Because of this I feel like many developers sweat over minute technical details but completely ignore business goals.

"Clean code" is not some objective quality though. Does say the open/closed principle lead to clean code or to overly complex code? It depends on the use cases for the code which in turn depends on the business goals.

Clean code is an ambiguous and subjective concept.

Assuming you’re referring to the practices taught in the book, I disagree that it always delivers a higher value than messy code.

I worked with a code base recently that on the surface checks all the boxes, but honestly, the code was way over engineered for the problem it actually solves. The team itself was great at writing clean code, but they over indexed on it to the extent that they were paralyzed and couldn’t actually get anything out the door. Honestly, they don’t know how to deliver.

I would prefer a team or even one decent engineer who knows how to make trade offs. Instead of only optimizing your logic, also invest time to figure out how you’re rue going to deliver. Make sure there’s instrumentation and metrics. Load test your system and understand your dependencies and their limits. Do they need to scale too? What hardware do you need? If your traffic calculations are off and you have problems, how quickly will you be able to get back into your SLA... speaking of, what is the SLA? Have you built your run books? If dependency A fails or if this part of your architecture fails, what happens? Did we failure test? How many calls will this system get per second? Will it be sustained or bursts?

Thinking of software only as a code style optimization problem doesn’t work, unless you’re in an organization where developers are explicitly code monkeys.

Not op but: do skip useful parts of work you don't feel like doing. Do boring or annoying parts of work even when it is tempting. Do not skip test just because you don't feel like. Do clean up code after yourself even if it already works. Write documentation, ask questions even if you would rather code, etc. Finish tasks before moving to shiny new ones. When you know about bug, dont ignore it and at least put it into tracker. Send that mail to administration/management/customer, fill taxes, don't leave mess in common kitchen. If you promised you will do tasks in some order (e.g. prioritized them) follow what you said.

Don't come to work sleep deprived too often, eat properly, exercise. It may also mean taking time for socialization/family/help friends even if you would prefer to code right now.

Effectively, it means same thing as discipline in any other context.