Live data from Hacker News

It's probably time to stop recommending Clean Code (2020)

qntm.org

111–120 of 216 posts

Re: It's probably time to stop recommending Clean Code (2020)

#111
"So... imagine that someone enters a kitchen, because they want to show you how to make a cup of coffee. As you watch carefully, they flick a switch on the wall. The switch looks like a light switch, but none of the lights in the kitchen turn on or off. Next, they open a cabinet and take down a mug, set it on the worktop, and then tap it twice with a teaspoon. They wait for thirty seconds, and finally they reach behind the refrigerator, where you can't see, and pull out a different mug, this one full of fresh coffee.

...What just happened? What was flicking the switch for? Was tapping the empty mug part of the procedure? Where did the coffee come from?

That's what this code is like."

This is such a good metaphor

Re: It's probably time to stop recommending Clean Code (2020)

#112

Earlier quoted context omitted.

> what is valuable depends a lot on context and the point in life of a particular project+team+organization. For sure, and I only target companies or teams that are mature, struggle to move forward because code quality grinds things down to a halt, and that express the desire for improvement there. However, there are very few companies that 1. Even have the awareness to realize this is where they’re at, and 2. Actual…

Any organisation with messy code doesn’t care about clean code - sure, they may regret it, they may wish it would magically go away, but if they cared then they wouldn’t have allowed all the dirty code to pile up. The only organisation in which your work will be valued is one in which the code is already clean.

Interesting insight.

I’ve never come across such an organization though. There are a handful that I think are in this spot where quality has mattered since day one but they’re so popular that I don’t stand a chance to even get noticed when applying in a sea of thousands of applicants. They also don’t hire very often.

And they’re very hard to find because what do you even search for? The ones I know, I found empirically through word of mouth, reputation, or just plain randomness by stumbling upon.

Re: It's probably time to stop recommending Clean Code (2020)

#113

From my decade writing software professionally and my current job search, I really question the actual demand for clean code. That’s unfortunate because it’s my specialty and what gives me job satisfaction. I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to…

> I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in. I am thankful that people like you exist, but after having taken on that role out of necessity mys…

I find that you can’t always fix everything. But the biggest hurdle is actually getting buy in (even if there is already buy in and that’s what you were specifically hired to do)

Rewriting is tricky. It’s sometimes necessary (outdated and unmaintained language, obscure tech you can’t find people for, or sheer tech bankruptcy) but it can also not solve anything. As you implement the new version, you rediscover all the arcane business rules, edge cases, and sheer craziness that you didn’t know about and the rewrite ends up either lacking these or becomes The Mess v2 because you had to bolt all this weirdness on after the fact making the new codebase suck in a different way but overall as problematic as the one it replaced.

It will also take much longer than estimated for the same reasons.

I’m not super keen on rewrites in most cases.

Re: It's probably time to stop recommending Clean Code (2020)

#114

From my decade writing software professionally and my current job search, I really question the actual demand for clean code. That’s unfortunate because it’s my specialty and what gives me job satisfaction. I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to…

I think you can easily roll an analogy with having a plan documented on 5 napkins, bits sprinkled over 127 emails, a few doodles on a white board, 93 photos on your phone, some files in some folder and 20% in your head.

You could start execution right away! Every bit of information is readily available, sure, the numbers in those emails might change in the process but you can just document those changes on additional napkins.

But there is a stage 2 to the plan that needs to happen in 3 to 6 years. By then there will be tens of thousands of relevant emails, hundreds of napkins, you cant find the original photos and you have so much related information in your head that that important thought is buried much like the email... I'm sure I have a folder someplace on this computer.... where is the chat log?

You made promotion so stage 2 is left to the new hire. They had a wonderful resume but for some reason it takes him forever to progress. They wont argue it would have been nice if you wrote down what stage 2 involved years ago. In stead they ask for 20 more people to organize the data.

Re: It's probably time to stop recommending Clean Code (2020)

#115

Earlier quoted context omitted.

At the call site, unless it's a keyword argument, you don't know what the parameter is named. IDEs help with this of course, but it's not just the "2 options becomes 3 options" situation that recommends against them

That's not a problem with bool arguments, that's a problem with the language and tooling.

That can be resolved with enums.

Re: It's probably time to stop recommending Clean Code (2020)

#116

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and prof…

It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.

Re: It's probably time to stop recommending Clean Code (2020)

#117
post #77

Earlier quoted context omitted.

It can definitely be confusing to hear "clean" when communicating in a professional setting. That said, in the book he covers correctness and understandability in nearly every paragraph. It's all the book is about really. It's called "clean" because it's concise and a catchy book title.

If you say the book “covers correctness and understandability in nearly every paragraph” then I’m convinced we must be talking about different books. For example, the book presents a rule for class names: > Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be…

There's whole pages of explanation about understandability in the Meaningful Names chapter preceding that distilled rule. Specifically it explains about making meaningful distinctions by avoiding vague words like Data or Manager or Info.

Re: It's probably time to stop recommending Clean Code (2020)

#118
post #36

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…

I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is sp…

I was also thinking about this book when I read that article. It's really an excellent book and it's condensed and because it's written by an expert in teaching it's easy to grasp.

It's also recommended in this article:

"Update, 2020-12-19 After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to recommend it over Clean Code".

Re: It's probably time to stop recommending Clean Code (2020)

#119
post #114

From my decade writing software professionally and my current job search, I really question the actual demand for clean code. That’s unfortunate because it’s my specialty and what gives me job satisfaction. I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to…

I think you can easily roll an analogy with having a plan documented on 5 napkins, bits sprinkled over 127 emails, a few doodles on a white board, 93 photos on your phone, some files in some folder and 20% in your head. You could start execution right away! Every bit of information is readily available, sure, the numbers in those emails might change in the process but you can just document those changes on additional…

That makes sense. But how do you retain your sanity and job satisfaction if you’re not an early part of that first phase?

Re: It's probably time to stop recommending Clean Code (2020)

#120

Earlier quoted context omitted.

If you say the book “covers correctness and understandability in nearly every paragraph” then I’m convinced we must be talking about different books. For example, the book presents a rule for class names: > Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be…

Let’s say my site has a download image feature that embeds per-user digital licenses into downloaded images at download time. This might take some processing so there is a queue and an abstraction representing the downloaded file. There are also several endpoints serving different types of image files. What shall I call the unit of code orchestrating these download processes, if not ImageDownloadManager?

I think I would go with a class called Image, which provides a method called download().
Post reply on HN