4 ms·
This book has been my own personal technical revolution over the past few months. I've been programming professionally for 7 years now, so while I'm not the mos
by quaunaut 8y ago
This book has been my own personal technical revolution over the past few months. I've been programming professionally for 7 years now, so while I'm not the most experienced I'm certainly no one new either. Some takeaways from how it changed my flow:
1. It gave me specific goals in terms of my own improvement, and the chapter titles did a good job of being a stand-in for challenging my own intuition.
2. In mentoring other developers, those I shared some of the lessons in the book with saw huge improvement literally week over week. I saw, personally, one of my mentees go from producing code that was hard for me to step through without bringing up half a dozen issues, to producing code where my largest criticisms were ecosystem dependent.
3. It created common language for discussing with teammates why certain code felt wrong.
4. It significantly reduced time spent refactoring later. The subtleties in some of the points make a re-read valuable as well. One of the better examples of this, was "Make code just a little generic"- often, we attempt to code things as generic as possible, and end up making what is effectively code soup that doesn't help accomplish the problem. Instead, building specifically for this problem, but trying to spot places it can be made just a little bit more generic, has altogether eliminated times I know I would've had to refactor again later if I hadn't been thinking of it.
5. The book knows what it isn't. He even says right in the forward and on the related Google Talk[1], that this first version is probably not the most value it can produce, but that hopefully by version 3 it'll be there.
For my time and energy, it's been more influential on how I develop software than anything else I've read. Furthermore, despite coding in primarily functional and/or dynamic languages, the examples used never made that a problem despite always being based on C. I recommend it highly.
1. https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY
- ilyanep 8y agoInteresting. I'm in a similar boat as you (5 years of professional experience) and I had decided to pass on my co-workers' reading group for this book, but based on your review I'm now reconsidering!
- chrisweekly 8y agoWow, that is a compelling endorsement! Thanks for sharing w/ this leve of detail.
- hnmonkey 8y agoI want to pile on to the other commenters on this review of your takeaways and thank you. This detail and enumerating the specifics really provides a very clear (and relatively concise) picture of what benefits this book has in store for someone. Thanks!
- barbs 8y ago> 4. It significantly reduced time spent refactoring later. The subtleties in some of the points make a re-read valuable as well. One of the better examples of this, was "Make code just a little generic"- often, we attempt to code things as generic as possible, and end up making what is effectively code soup that doesn't help accomplish the problem. Instead, building specifically for this problem, but trying to spot places it can be made just a little bit more generic, has altogether eliminated times I know I would've had to refactor again later if I hadn't been thinking of it. Wow, I've often felt this during my time coding. Unnecessary abstractions often just make things more convoluted and increases boilerplate when adding new things. Great to see this being addressed.
- MaxBarraclough 8y agoThis principle is well known: 'YAGNI'.
- gitgud 8y agoYou Ain't Gonna Need It is a great principle, but I think this is slightly different, as it implies it's useful to abstract it a little... So maybe JAIL? Just Abstract It a Little
- TeMPOraL 8y agoAgreed. JAIL is YAGNI/KISS with a little bit of sanity sprinkled on top of it. You generally want to keep code simple and straightforward, but that doesn't mean avoiding the most obvious and most probably useful generalizations.
- jsight 8y agoYeah, I've had this discussion with a lot of developers over the years with regards to DRY as well. I've seen people refactor code to fix "DRY" problems and the code ended up increasing in size due to the "deduplication" and increasing in complexity. When asked, "well do not repeat yourself isn't about reducing LoC". That is technically correct, but is it then about increasing code size and complexity? Sometimes