5 ms·
I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and
by Manjuuu 4y ago
I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc...
Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind:
What have they ever built?
Reading code from popular opensource projects and evaluating the different approaches they took is way more useful than reading those books, full of regurgitated wisdom from people with minimal street creed. And yes, maybe it's time to stop calling him "uncle", it's not your uncle, he has very little to teach. Start building, stop reading.
- donatj 4y agoI read through a decent chunk of Patterns of Enterprise Application Architecture for class in college in ~2006 and while I was indeed young and impressionable, it left a very bad taste in my mouth for heavily OO’d systems to the extent that it had the opposite effect - I largely avoided them likely longer than I should have.
- Defletter 4y ago> What have they ever built? You have to be careful with that though. We've had a few people who'd "channel Torvalds", so to speak, by parroting his opinions with abrasive fervour. Any dissenters were treated as either thinking they knew better than him, or being ignorant of his work, or not having an appropriate appreciation for his work. And since Torvalds is very opinionated, so were they. It wasn’t exactly a fun work environment. I’d also like to challenge the premise of the question. Being a maintainer for example is just as valid as being a “builder.” In fact, you’ll probably gleam more wisdom from being a maintainer than a builder since you are, by definition, trawling through other people’s code and maintaining it. Look, it’s perfectly valid to consider someone’s body of work while considering their opinions. But dismissing them out of hand is wrong, in my opinion.
- Manjuuu 4y agoI agree with everything you said, especially with how important the role of the maintainer is to get something that keeps working over time (both are builders). And yes, holding someone else opinions strongly doesn't make you instantly a clone of Torvalds, thing that in workplaces with n>1 employees might not be desirable.
- deleted 4y ago[deleted]
- liampulles 4y agoJust read thoughtfully and treat the ideas as tools rather than laws. Reading code is good too but one doesn't have to jump straight to first principles.
- jskulski 4y ago> What have they ever built? While I agree that reading code and learning is essential, I don’t think this line of criticism is fair. I mean like most programmers I’d imagine their years and years of industry work isn’t public. I mean what have I ever built? Fowler was CTO of ThoughWorks for years and afaik they do really good and deep work, their content is quality. Bob Martin had a similar track record with 8th light, and as an organization is interesting. That said, I think lumping them together is misguided. I’ve read a lot of both. To me unky bob is can be a divisive gatekeeper who wants to be right, while mFowler is boon to the industry, literally writing the book on refactoring. He has well reasoned and measured arguments. I mean I think while formulating your own voice is important and essential, it’s also essential to learn from others and pass down knowledge. For some reason, I think our industry sees it as a threat. Unky bob is a divisive gatekeeper who I suppose did years of industry work? I guess? To lump Fowler in with unky bob, I just don’t see it. I mean Fowler I think t started thoughtworks.
- Manjuuu 4y ago> I mean what have I ever built? Most of my work is not public too, it doesn't have to be. > I mean Fowler I think t started thoughtworks. Yeah, I've been too harsh comparing the two, but as someone that have to fight daily with the consequences of the popularization/normalization/blind adoption of the microservices (his contribution was huge in this field) architecture I'm not sure anymore if his contribution is a net positive. The book on refactoring was great though, product of a different era.
- whstl 4y agoI think the difference in the material of both is quite stark too. Fowler's books are very descriptive, Refactoring is clearly a list of strategies. And there's even conflicting advice, since it's meant to be a catalog rather than a rule book. Clean Code on the other hand is very prescriptive. Not that it matters, the people that wrote the GoF Patterns book have been saying for years that their book is descriptive but very few people hear it.