Comment by Copenjin
9 months ago
You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them.
Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a software engineer like many other prominent authors at the beginning of the agile era. The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.
Horrible recommendations that produced a lot of code that is a pain to work on with the abundant amount of indirection it has. Really painful guys.
> The success is only the result of a wave of junior devs searching for some sort of guidance, something that there is a never-ending need for.
The issue is that, some never grown out of it. I interviewed with companies where they give the book to any new intern/junior. Then, during the hiring process, they don't even ask if you read it, they straight up ask questions about your knowledge of it. Like "What does Uncle Bob says about X in his book Clean Code?". And they constantly refers to it. Some people go as far as quoting it in PR.
The worst part being that once they leave their company, since they don't know anything else, they'll apply the same stuff elsewhere & convert their new company to it.
(English tip: advice isn't a countable noun, so you don't pluralise it)
I agree entirely. My encounters with Uncle Bob were as a junior developer receiving advice [no "s"] from other junior developers.
And yes, I too find it suspicious how many mavens of the "Agile era" never really managed to ship anything.
It's important to note that Kent Beck is not one of those people, as he shipped the first unit testing library, as well as a bunch of ones in other languages later.
Like, I personally prefer the bare assert style of testing (like pytest), but the junit style is basically everywhere now.
Kent Beck is just as bad as Uncle Bob! He drank his own proverbial Kool-Aid and went all in on the crazy XP programming fad he started (... which contains brilliance like requiring pair programming for every line of code written).
Look, both authors are very smart people who have great insights into development that we can all learn from ... but both also have the failing of being way too in love with their own ideas.
It blinds them to the flaws in those ideas, and makes it so when you read their work you have to be skeptical and evaluate each individual idea on their own.
7 replies →
Thanks for the correction, my opinion on the lack of credentials is that in the early days you just didn't need them to become popular, so little content that no one checked. I bit like it's happening nowadays with the anime profile pic twitter accounts acting like they invented AI, with zero code or achievements being shown.
It is very instructional to read the source code to FitNesse framework.
https://github.com/unclebob/fitnesse
You can see how all his ideas come together into a ball of hundreds of almost empty classes, and gems such as "catch Throwable".
I was completely ready to agree with you, but the code that I browsed actually looked really good.
https://github.com/unclebob/fitnesse/blob/master/src/fitness...
Yup, OK, got it. The FitnessContext looks a bit rough, but no big deal.
https://github.com/unclebob/fitnesse/blob/master/src/fitness...
That's completely readable, I get it.
https://github.com/unclebob/fitnesse/blob/master/src/fitness...
Again, looks fine.
The main issue with all of these files is that there is quite a bit of boilerplate code, but that's Java's fault, not the code's fault.
I'm sorry, but I disagree. Looking for the most substantial pieces of code that I could find, and they look really good. I'm sure there are some little utils or something that look strange out of context, but I would be thrilled if I were called to work on legacy code and it was this nice.
A Philosophy of Software Design on the other hand is concise, excellent, and based on decades of teaching experience.
If I win the lottery, I don't want a building named after me I want to donate a copy of that book to every university computer science[1] student and make it required reading
1: I'm aware it's a software engineering book, but since there are very few B.S. Software Engineering programs out there, You Know What I Mean ™
More importantly, experience writing great software.
The world isn't binary
what's your point?
2 replies →
Clean code, design patterns etc. were also picked up by teachers, professors and course instructors.
I think these paradigms and patterns often operate on the wrong layer of abstraction, while mostly ignoring the things that matter the most, like efficiency, error handling and debugging.
But getting good at these things requires a lot more blood, sweat and tears, so there's no easily teachable recipe for that.
Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already efficient).
Of course error handling and debugging are part of maintenance. However there is a lot more than those two that need to be considered as well.
There is reason to hate Clean Code, but the worst adherents to the rules are still producing far better code than some of the impossible stuff that happened before. "Goto considered harmful" is one of the early steps in fixing all the bad things programmers used to do (and some still do), but you can follow the "rules" of goto considered harmful and still produce really bad code so we need more.
From personal experience, the most time consuming maintenance issues arise because of the following things:
- third party dependencies, compatibility issues, breaking changes
- code that is bloated with abstractions and indirection
- performance issues, especially when worked around via caching etc.
- bad error handling
- inconsistent data
Simpler code that can be followed and stepped through in a straight forward manner avoids 3/5 of these from the get go. Patterns and abstractions that emerge over time are sometimes beneficial. Legacy code or third party code that overuses abstractions is really more of a hindrance and significantly slows down how fast I can understand, own and fix things.
4 replies →