It's probably time to stop recommending Clean Code (2020) • Hacker News Board

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

#61

Post by emodendroket » Sat, Feb 18, 2023, 7:35 AM UTC

ornornor wrote: post #48

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…

Of course the people signing the checks don't care about that directly, but it's something you can do as you add functionality.

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

#62

Post by noisy_boy » Sat, Feb 18, 2023, 7:36 AM UTC

ornornor wrote: post #48

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…

> They all say they do of course, while actually being afraid of doing this because it takes more time and money.

That is my experience too with most places - they say that they support clean, well tested and maintainable code and then turn around and ask things to be delivered in unreasonable time resulting in quick and dirty code.

> I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible.

Indeed - furthermore, because the code lacks quality, it requires more effort to manage and (intentionally or not) helps them to demand headcount which requires more managers which results in them building hierarchies, moving up and having their fiefdom. It is a smart approach too in a perverse sense: how will you get to a position managing 100 people if you only delivered with 5 people due to your efficiency? You'll be labeled as "lacks experience managing large orgs".

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

#63

Post by inimino » Sat, Feb 18, 2023, 7:37 AM UTC

YouWhy wrote: post #40

Towards the end of my tenure in a team, a new boss instituted mandatory viewing sessions of Martin's training videos; I grew somewhat averse of them. While the heart of Martin's teachings are about expressivity and semantics, the praxis is much more about recipes than about what matters to me as a professional, which is: 1. Well-definedness of the computation being done (in a mathematical sense of the word), 2. Engin…

I agree. Martin's approach is amenable to bureaucracies that want to increase (the perception of) organizational control over software projects. It is opposed to the Fred Brooks approach. It favors a lower standard of individual skill and relies on bureaucratic control of the process instead as the guarantor of good outcomes.

We shouldn't be surprised that it's popular, or that it's highly associated with Java (and certain other languages today).

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

#64

Post by d4mi3n » Sat, Feb 18, 2023, 7:39 AM UTC

ornornor wrote: post #48

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 as professionals many of us like to take pride in our work. A natural way to do that is for code to be "clean". The problem, as I see it, is that this is often a subjective metric and what we take pride in doesn't always align with what delivers tangible value to an organization (a point you alluded to).

Clean code can bring tangible value, but big rewrites taken on for that goal can often not. I personally try to be more pragmatic--what is valuable depends a lot on context and the point in life of a particular project+team+organization.

Sometimes the most valuable thing is to ship a messy code that works to get the ball rolling or prove viability of an approach. Other times it's to make sure what you deploy is bullet proof to avoid liability or expensive downtime. The value of clean code will be reflected by your team and organization's needs at that point in time.

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

#65

Post by xtian » Sat, Feb 18, 2023, 7:39 AM UTC

siva7 wrote: post #35

ZephyrBlu wrote: post #11

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is c…

That would lead to a Big Ball of Mud if given to an inexperienced or reckless developer as i've witnessed many times in my career. The problem with such best practices/patterns/thought pieces is that they stem from highly experienced developers but given to the inexperienced they are like a hand grenade in the hands of an ape.

That’s true of every methodology used by inexperienced or reckless developers. There is no shortcut to quality or experience. But Carmack’s approach has the distinction of ultimately delivering results by orienting one towards the objective necessities of the problem at hand rather than, for instance, the never-ending spiral of arbitrary and inefficient abstractions that OO ideology commonly produces.

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

#66

Post by emodendroket » Sat, Feb 18, 2023, 7:39 AM UTC

Groxx wrote: post #59

Yeah. This fits with my reading of it as well. Periodic chunks of "yep, makes sense" scattered through a really disturbing miasma of questionable stuff and incredibly tightly bound methods sharing gigantic balls of state that must be called in an order, but with nothing that hints at or enforces that order. It adds up to a really horrific result pretty frequently. I'm not sure how it got its status at the beginning,…

It reminds me of the Elements of Style, which has for decades had a reputation as the book every English writer should read. In reality, it's a mix of obvious truisms ("omit needless words," gee, thanks, but how do I identify the needless ones?) and grammatical advice where the authors are so confused about the concepts that they constantly violate their own precepts. However, at least EB White was a talented author whose writing was beloved. Seems hard to say much complimentary about the sample code presented here.

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

#67

Post by inimino » Sat, Feb 18, 2023, 7:41 AM UTC

DanielVZ wrote: post #30

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…

There are literally hundreds of better books for newcomers. As just one, I would mention Programming Pearls by Jon Bentley. I would say it communicates a much more healthy approach to the craft.

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

#68

Post by porker » Sat, Feb 18, 2023, 7:41 AM UTC

albertopv wrote: post #55

userbinator wrote: post #51

Earlier quoted context omitted.

It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases. I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages lik…

After some years I recently had to work on a very old PHP project with linear and untested code. Full of bugs, unmanaged corner cases, unnecessary code duplication, magic numbers...we didn't even try to understand the business logic or reverse it. I still think it's just low skilled devs vs professional ones. You can make similar mistakes with many, many languages, it seems to me that Java went out of fashion, consid…

As a counterpoint I'm working on an ex-PHP4 codebase, that's been "developed" (in the loosest possible meaning) by assorted people over 15 years. It's full of security vulnerabilities and the worst code I've seen in my career.

I'm also working on a modern Symfony PHP codebase using popular 3rd party Symfony bundles. I've used Symfony for a decade but find the compiler passes and levels of abstractions (particularly when debugging 3rd party bundles) slow me down and make the code less understandable. Yesterday I spent half a day tracking down a bug which was the wrong setting in the config, but was obscured by too many layers of indirection.

I'd take the terrible but understandable codebase any day as I know I can debug and improve it more easily.

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

#69

Post by emodendroket » Sat, Feb 18, 2023, 7:41 AM UTC

wizofaus wrote: post #8

userbinator wrote: post #5

A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every functi…

Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - providing of course they have sensible names (and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot; in a 5000-line function, fuhgeddaboudit. My personal guideline is "it should fit on a screen"…

Hyperbole aside what can actually be said doesn't make great bumper sticker advice: functions shouldn't be too long because that's hard to understand, but they shouldn't be too short either because that's also hard to understand. I think a decent rule of thumb is if it doesn't fit on your screen it might be too long.

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

#70

Post by emodendroket » Sat, Feb 18, 2023, 7:43 AM UTC

userbinator wrote: post #28

wizofaus wrote: post #8

Earlier quoted context omitted.

Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - providing of course they have sensible names (and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot; in a 5000-line function, fuhgeddaboudit. My personal guideline is "it should fit on a screen"…

Yes I have, and some even approaching 10kl. It's actually easier when you only have one "dimension" to worry about, and can simply scroll up and down instead of having to jump around between functions, or worse, files. That said, a lot of these huge functions were basically for implementing defined step-by-step processes, and comments delineated the sections as well as loop and condition ends.

It's not better unless the smaller ones do a poor job of breaking up functionality. One class owning, say, all the code related to making database calls is much better than a bunch of database code strewn throughout unrelated logic.