Those who know, know.
i guess this time the book involves a foreword in every chapter written by a woman that explains why they shouldn’t be allowed behind a computer
twitter happened, I guess
But today I stumbled across a long twitter thread that I can only describe as intentional character assassination. The author of this thread is misrepresenting facts and making some pretty nasty accusations. Again this is not all that unusual, except for the fact that I was not invited to defend myself. […] The gist of this author’s thread is that I am a misogynist; and that I should not be taken seriously in any regard. I understand that efforts have been made to have me excluded from conferences, and to boycott the publisher of my books, etc.
- Uncle Bob in 2017
This is just a lot about people’s reactions to something, but nothing about what that something actually was
It’d be nice to see what the actual something was so one could judge for themselves
Edit: I took a look at his twitter, and he seems to be pro-trump and anti-kamala and anti-walz, calling him a socialist who let Minneapolis burn, as well as transphobia thrown in here and there and more that I didn’t bother to read
…so I’m gonna go with “the people’s reactions to him likely had a point”
So… What is the problem of women in tech? Either I skimmed over this or he fails to get to that point at all.
I don’t have any examples personally, but I’ve been told by a lot of people that he has some views about women, race, sex, homosexuality, etc which many would find objectionable.
Edit: his Twitter is pretty much 50% programming, 50% GOP politics. He might be a bit more progressive than your average Republican, but he still expresses a strong anti-left/anti-“woke” set of beliefs.
There are no inherent “rules” in software development. These books are useless and a waste of time. They offer nothing but CS Dogma and are actually against freedom of expression.
Rules of thumb can be very useful for a relatively inexperienced programmer, and once you understand why they exist you can choose to ignore them when they would get in the way. Clean Code is totally unhinged though
The problem is that a lot of people don’t understand when to ignore the rules and just stick with them forever.
We had a developer once that always said KISS KISS KISS whenever we pointed out that her functions are working but not reusable, so she wrote 20 functions that all did the same thing, but with slightly different parameters. And that’s just one of the examples
Even if their style is objectively bad, as long as it works, that’s a bad hill to fight over.
i am genuinely waiting for it. read the first one almost 10 years ago and it gave me a good start into my programming journey.
even if this second version won’t bring in anything new for me, I will be glad to consume it
I’m a programmer since the 80s, who is this guy?
He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
- Functions that only do one job
- Testing makes refactoring easier
- The standard SOLID OOP stuff.
- Tech debt is bad
- Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
- Insulate yourself from change
- Duplication is bad
- Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
- Don’t mix high level code with low level.
- Build solid Entity classes to model the data and their interactions.
- Don’t write multithreaded code if you don’t have to.
- If you have to do your best to write it so they don’t share memory.
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
- Refactoring is expensive and the cost is often not justified.
- Premature abstraction is the absolute devil
- You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
- Less changes also lead to less bugs.
- Too much emphasis on functions being few lines of code instead of just being simple.
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.
The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.
That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.
Those of you who red and liked clean code (I did too), what’s your next best recommendation as a book? The pragmatic programmer?