Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

301–310 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#301

Earlier quoted context omitted.

Clean Code zealots are consistently some of the least likable, least productive, least pragmatic people I have ever worked with. I've had multiple clients where the whole team is threatening to quit unless the CC zealot is fired. And when they are fired guess what - bugs go down, shipped features go up, and meetings become productive. "Idiots who froth at the mouth" is an understatement IMO

This too seems like a fairly hardline stance to take. I think it's not surprising that you'd have a hard time collaborating with people you'd refer to as unlikeable, unproductive, unpragmatic, overzealous, frothy idiots. It reminds me of the standard joke about veganism: "how do you know someone is vegan? Don't worry they'll tell you" It's a very ironic joke, because the people I hear talking about veganism the most…

On top of that, the argument was "i hate clean code people because they use bad reasoning (read something in a blog)". These are exclusive from each other. The OC basically argued there are no good reasons for clean code.

I prefer readable code, but I wouldn't call myself a "clean code" person.

Re: Clean Code vs. A Philosophy Of Software Design

#302
post #192

Earlier quoted context omitted.

I’ve noticed the worse someone is in a language, the worse they format it. People then develop fastidious code formatting rules because they realize well formatted code is easier to read and extend. Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”. So people with fastidious rules are in that middle ground of…

Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…

I've been trying for years to track down a quote I lost, and it sounds like something you might know, because I think it would have resonated with you.

It was from Charles Simonyi, talking about how as he got older, his prodigious ability to juggle large amounts of information in his head declined, and as a result, he started writing better code. Do you know it?

Also, I half agree with your point, but I see it happen in two different ways. When writing ad hoc code for research purposes, I see very gifted people write seemingly sloppy, to-the-point code because it's the quickest way to the result. I say seemingly sloppy because another programmer would see an intricate mechanism that in so many places is a hair's breadth from being wrong, and they would want to reorganize it to make it more obvious that the code is correct. The savant who wrote the code is like, it's already 100% obvious, how could any change make it more obvious than that?

In the software development context, I sometimes see very gifted people write incredibly complex code because they enjoy flexing their intellectual muscles and seeing the ornate towers they can create. But I also see average programmers and dumb programmers do the same thing, the only difference being that the gifted people can get away with more before it starts to hurt them. What's more, I see very good engineers, gifted but not as gifted, try to follow the example of a savant and end up accomplishing far less than they could if they cut themselves a break and wrote plain code without all the flourishes and ornaments. A gifted programmer usually gets tired of this and grows out of it, but some of them enjoy it so much they commit to fooling themselves and other people that it's the right way to write software.

> So the tendency to have this ocd need to write clean code among smart people is random

It is if they work entirely alone and their work doesn't depend at all on the success of others using their code. However, when it comes to big software projects, my experience is that it's not random: the smartest people do end up writing good code, unless they have ulterior motivations or a severe social blind spot.

Re: Clean Code vs. A Philosophy Of Software Design

#303
post #161

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

Remember when most people give presentations about a technology, they’re in the honeymoon stage

[dead]

Re: Clean Code vs. A Philosophy Of Software Design

#304
post #294

Earlier quoted context omitted.

Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…

>> ... TDD is unlikely to help you solve problems that are beyond incremental changes. Thank you for expressing this niggling problem with TDD. Personally I just cannot use it for "new stuff", I need to explore and create direct with "real" code for anything non-obvious.

I'm more of a DTT man myself: Develop, Then Test.

Re: Clean Code vs. A Philosophy Of Software Design

#305

It's sad that we demoted the field from engineering to philosophy. But it is what it is. Next step - fashion and belief.

It's an improvement over demagoguery and blind rule-following. Moreover, the book argues for engineering principles (in pretty much all possible senses of that phrase).

Sure!

I'm not saying that philosophy is bad. Maybe making software just never meant to become an engineering discipline. I mean making clothes, laws, and music isn't. And it's fine.

But engineering does imply some rule-following.

Re: Clean Code vs. A Philosophy Of Software Design

#306
This is actually a great read.

I'm in the middle of designing a course for a client on teaching software engineering best practices for data scientists (and folks who live in Jupyter all day).

There seems to be a huge lack of material for these types that aren't "programmers", don't live in an "IDE", and are essentially writing code all day.

Re: Clean Code vs. A Philosophy Of Software Design

#307

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

The worst engineer I worked with was one who believed if he read it in a book, that opinion trumped anything else. Once he got so flustered he started yelling “come back to the discussion when you’ve read 13 books on this topic like me!” And it was something super mundane like how to organize config files or something.

Made every engineering planning session a pain in the ass.

Re: Clean Code vs. A Philosophy Of Software Design

#308

Earlier quoted context omitted.

Why not put the prose in the name of the function?

Function names are limited. E.g. can't provide a circuit diagram of what you're controlling in a function name. But you can do that in a comment (either with ASCII art or an image link).

In addition to that, if the Why ever changes (maybe the issue was in an external dependency that finally got patched), you'd have to update the name or else leave it incorrect. Mildly annoying if just in one codebase, but a needlessly breaking change if that function is exported.

Re: Clean Code vs. A Philosophy Of Software Design

#310

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

The place I used to work at had a "architect" who would for any question to a decision he made would refer to whatever it was as a "best practice."

Was often quite wrong and always infuriating.

Post reply on HN