10 ms·

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 wort

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.

__loam 2y ago
A Philosophy of Software Design on the other hand is concise, excellent, and based on decades of teaching experience.
- k__ 2y ago
  The world isn't binary
  - mbonnet 2y ago
    what's your point?
    - k__ 2y ago
      I interpreted the comment as sarcasm.
      - __loam 2y ago
        It's a sincere comment.
- kragen 2y ago
  More importantly, experience writing great software.
- mdaniel 2y ago
  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 ™
wiether 2y ago
> 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.
zero_shift 2y ago
(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.
- disgruntledphd2 2y ago
  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.
  - machine_ghost 2y ago
    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.
    - lmm 2y ago
      > which contains brilliance like requiring pair programming for every line of code written Because it works. Have you tried it?
      - Copenjin 2y ago
        Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.
dgb23 2y ago
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.
- bluGill 2y ago
  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.
  - dgb23 2y ago
    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.
    - 2y ago
Scubabear68 2y ago
It is very instructional to read the source code to FitNesse framework. https://github.com/unclebob/fitnesse 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".
- snapdaddy 2y ago
  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/fitnesse/FitNesseServer.java 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/fitnesse/socketservice/SocketService.java https://github.com/unclebob/fitnesse/blob/master/src/fitness... That's completely readable, I get it. https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/http/Request.java 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.

__loam 2y ago

A Philosophy of Software Design on the other hand is concise, excellent, and based on decades of teaching experience.

k__ 2y ago
The world isn't binary
- mbonnet 2y ago
  what's your point?
  - k__ 2y ago
    I interpreted the comment as sarcasm.
    - __loam 2y ago
      It's a sincere comment.
kragen 2y ago
More importantly, experience writing great software.
mdaniel 2y ago
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 ™

wiether 2y ago

> 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.

zero_shift 2y ago

(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.

disgruntledphd2 2y ago
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.
- machine_ghost 2y ago
  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.
  - lmm 2y ago
    > which contains brilliance like requiring pair programming for every line of code written Because it works. Have you tried it?
    - Copenjin 2y ago
      Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.

dgb23 2y ago

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.

bluGill 2y ago
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.
- dgb23 2y ago
  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.
  - 2y ago

Scubabear68 2y ago

It is very instructional to read the source code to FitNesse framework. https://github.com/unclebob/fitnesse 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".

snapdaddy 2y ago
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/fitnesse/FitNesseServer.java 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/fitnesse/socketservice/SocketService.java https://github.com/unclebob/fitnesse/blob/master/src/fitness... That's completely readable, I get it. https://github.com/unclebob/fitnesse/blob/master/src/fitnesse/http/Request.java 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.