Live data from Hacker News

“Clean code” isn't actually clean

sdegutis.com

51–54 of 54 posts

Re: “Clean code” isn't actually clean

#51
post #50
post #26

Earlier quoted context omitted.

Sure, but we've been building houses for a long time. We know a lot more about building houses today (or even 40 years ago) than they did when the practice of house-building was still relatively new. And most of this knowledge didn't come from building houses over and over, but from developing better theories of how buildings stay up, using better materials, etc....

I think we'd both be surprised on how much actually does come from "building houses over and over." My assertion being that much of material science advancement came from required advancements from previous failed houses.

That's my same experience with programming. That's kind of what I was getting at in this article actually: that you get better by doing your best and making mistakes. Nothing beats hard-earned experience.

Re: “Clean code” isn't actually clean

#52
post #50

Earlier quoted context omitted.

I think we'd both be surprised on how much actually does come from "building houses over and over." My assertion being that much of material science advancement came from required advancements from previous failed houses.

That's my same experience with programming. That's kind of what I was getting at in this article actually: that you get better by doing your best and making mistakes. Nothing beats hard-earned experience.

Completely agreed. It is good to learn from the mistakes of others, though.

To that end, it is good to have exposure to a lot of things that have failed. Seeing how they succeeded isn't as instructive, interestingly.

Re: “Clean code” isn't actually clean

#53
post #15

This just seems like poor justification for laziness. You need to keep a project clean. This means profound refactors when concepts for the product change. Some rules are: - Keep it readable - Don't over engineering - Easy to remove - Good tests (complete, min stubbing, interface oriented. Never refactor and change tests at the same time. A lot of "veterans" are just resented with new paradigms and too egotistical to…

> A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant. Sometimes, your new paradigm is actually something that they tried 10 years ago. > In the end, you can sum up all rules into one: Make it easy to maintain That is only one of the many facets of programming that you have to balance: performance, memory consumption, ... . If you want to push your system performance to the e…

Good points. For the record: I'm not saying all veterans are egotistical.

I think code based performance is something that is just not as big as an issue as before. In web world it's common to solve extreme performance via cache, replication, etc.

In any case, I think that in very few cases you get to a performance requirement so intense that you can't write maintainable code. We can't argue on extremes :)

Re: “Clean code” isn't actually clean

#54

Most guru's take an 'all or nothing' approach, this goes beyond programming, look at food-guru's "eat only carbs, never eat refined sugar" etc. This is for me the same as "always do TDD, never use static methods". People without experience often look at guru's because they can not yet think for themselves. I'm a developer in my 40s, have done a lot of projects in a lot of different companies. Having this experience g…

Please, it's just "gurus", no apostrophe needed.

its not plural, its possessive so apostrophe needed.
Post reply on HN