7 ms·

I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here re

I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here read the first edition, and what was your impression of it?

acconrad 9y ago
I really enjoyed the first edition, though I will admit I didn't read the true original, I read the Ruby version that was adapted for (and approved by) Martin himself. Given I do Ruby/Python programming, it was a better book for me than the original, but since I also do plenty of JavaScript programming, I imagine I will at least skim the 2nd edition as well.
scrame 9y ago
I found it to be somewhat basic. The primary language is Java so a lot of the techniques are rooted in the kind of "move the dirt around" refactoring that you get with that language, and indeed covers what became the "refactoring" options in Java IDE's. Its a good overview of the ideas of refactoring, but often ends up creating more code and structure, since its often hard to change things in Java without adding more code. Javascript has a lot more first-class options other than classes and interfaces, so there might be some more insight. As far as good programming books, I quite liked Code Complete when I was a younger programmer, and found that Anti-Patterns was helpful in giving me a lot of vocabulary and patterns in recognizing what happens in job-settings, as well as refactoring overviews as a solution to real problems.
mherrmann 9y ago
I read it 15 years ago. No other book has influenced my programming as much as this one. The main value I got from it is that it teaches you what "clean" code looks like. Highly recommended.
- thaumaturgy 9y ago
  You might also enjoy "Beautiful Code" then. While not everyone will agree that every example in that book is "beautiful", usually there's something in there for everyone. It's currently my favorite generalized programming book.
  - mherrmann 9y ago
    Thank you for the suggestion. I started that one but somehow never finished it.
jacobkg 9y ago
One of my biggest lessons from the book is right in the introduction. To paraphrase: "If a change you want to make to the codebase is hard, refactor the codebase until that change is easy, then make the change". I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.
- saryant 9y ago
  A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time. Keep those tasks separate.
  - jmsaucier 9y ago
    I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.
    - pelhage 9y ago
      The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line
      - konamicode 9y ago
        At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.
    - 9y ago
Silhouette 9y ago
Has anybody here read the first edition, and what was your impression of it? It's a decent book, though obviously looking a bit dated now, particularly in the OO-centric presentation. I would confidently recommend it to someone like a junior developer at work or a keen self-taught programmer who had figured out the basic mechanics and was starting to explore ideas about building and maintaining bigger systems. I probably wouldn't recommend it to anyone further down the path, though, just because the techniques described tend to be quite simple and they're mostly things that people learn with experience anyway.
blktiger 9y ago
Keep in mind that the original was written back in 2000. So most of the ideas in the book are pretty much mainstream these days. The second edition should be pretty interesting because of the move away from being class-centric. When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful. [1] https://www.martinfowler.com/books/r2p.html https://www.martinfowler.com/books/r2p.html
mcguire 9y ago
I found it very interesting for being one of the very few books that deals with code as a formal system. You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries. The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now. Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike. [1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=pd_sim_14_6?_encoding=UTF8&pd_rd_i=0201103427&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan... [2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/0070342075/ref=pd_sim_14_1?_encoding=UTF8&pd_rd_i=0070342075&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Elements-Programming-Style-2nd/dp/007... [3] https://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X/ref=pd_sim_14_3?_encoding=UTF8&pd_rd_i=013937681X&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Unix-Programming-Environment-Prentice...
- slobotron 9y ago
  Would you recommend "Software Tools in Pascal" vs the original?
  - pmarin 9y ago
    The original one in written in RATFOR with no structures/records or recursion which make some of the programs more complicated than they should. It easy to find the two versions on Internet. They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.
  - mcguire 9y ago
    Either. The details aren't especially relevant in either case. I just picked one.
arthurjj 9y ago
The first edition suffers from being a victim of its own success. Much of it has become common wisdom and many of the refactoring techniques now have IDE support. "Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it. 1. https://amzn.to/2I4rIWP https://amzn.to/2I4rIWP 2. https://amzn.to/2GfxVTa https://amzn.to/2GfxVTa 2.
realSlavojTrump 9y ago
I enjoyed the first edition immensely. Some folks are calling out that most of the refactorings are mainstream, but IDE integration doesn’t mean that it has become common practice or second nature to most engineers. If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/ https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book. Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference. The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code. Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)
beat 9y ago
It is a must-read for anyone who programs systems bigger than a student class project.
funkymike 9y ago
To me refactoring doesn't need a whole book or set of terminology. So long as a person understands and values the principles the individual refactorings will come naturally with experience. In my view it comes down to three main points. 1. Refactoring does not change functionality. The observable behavior should be the same before and after. 2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct. 3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well. I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough. Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better. I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).
tankerdude 9y ago
It was a seminal book on software engineering for me. Kind of like Effective C++, More effective C++, the old Win32 Charles Petzold book, GoF, etc. To me, it was a classic, and much appreciated it as that was also when the whole TDD thing took off.

acconrad 9y ago

I really enjoyed the first edition, though I will admit I didn't read the true original, I read the Ruby version that was adapted for (and approved by) Martin himself. Given I do Ruby/Python programming, it was a better book for me than the original, but since I also do plenty of JavaScript programming, I imagine I will at least skim the 2nd edition as well.

scrame 9y ago

I found it to be somewhat basic. The primary language is Java so a lot of the techniques are rooted in the kind of "move the dirt around" refactoring that you get with that language, and indeed covers what became the "refactoring" options in Java IDE's. Its a good overview of the ideas of refactoring, but often ends up creating more code and structure, since its often hard to change things in Java without adding more code. Javascript has a lot more first-class options other than classes and interfaces, so there might be some more insight. As far as good programming books, I quite liked Code Complete when I was a younger programmer, and found that Anti-Patterns was helpful in giving me a lot of vocabulary and patterns in recognizing what happens in job-settings, as well as refactoring overviews as a solution to real problems.

mherrmann 9y ago

I read it 15 years ago. No other book has influenced my programming as much as this one. The main value I got from it is that it teaches you what "clean" code looks like. Highly recommended.

thaumaturgy 9y ago
You might also enjoy "Beautiful Code" then. While not everyone will agree that every example in that book is "beautiful", usually there's something in there for everyone. It's currently my favorite generalized programming book.
- mherrmann 9y ago
  Thank you for the suggestion. I started that one but somehow never finished it.

jacobkg 9y ago

One of my biggest lessons from the book is right in the introduction. To paraphrase: "If a change you want to make to the codebase is hard, refactor the codebase until that change is easy, then make the change". I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.

saryant 9y ago
A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time. Keep those tasks separate.
- jmsaucier 9y ago
  I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.
  - pelhage 9y ago
    The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line
    - konamicode 9y ago
      At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.
  - 9y ago

Silhouette 9y ago

Has anybody here read the first edition, and what was your impression of it? It's a decent book, though obviously looking a bit dated now, particularly in the OO-centric presentation. I would confidently recommend it to someone like a junior developer at work or a keen self-taught programmer who had figured out the basic mechanics and was starting to explore ideas about building and maintaining bigger systems. I probably wouldn't recommend it to anyone further down the path, though, just because the techniques described tend to be quite simple and they're mostly things that people learn with experience anyway.

blktiger 9y ago

Keep in mind that the original was written back in 2000. So most of the ideas in the book are pretty much mainstream these days. The second edition should be pretty interesting because of the move away from being class-centric. When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful. [1] https://www.martinfowler.com/books/r2p.html https://www.martinfowler.com/books/r2p.html

mcguire 9y ago

I found it very interesting for being one of the very few books that deals with code as a formal system. You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries. The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now. Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike. [1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=pd_sim_14_6?_encoding=UTF8&pd_rd_i=0201103427&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan... [2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/0070342075/ref=pd_sim_14_1?_encoding=UTF8&pd_rd_i=0070342075&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Elements-Programming-Style-2nd/dp/007... [3] https://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X/ref=pd_sim_14_3?_encoding=UTF8&pd_rd_i=013937681X&pd_rd_r=P39N5Y5EKKB56MVG272T&pd_rd_w=76jW2&pd_rd_wg=rlGKB&psc=1&refRID=P39N5Y5EKKB56MVG272T https://www.amazon.com/Unix-Programming-Environment-Prentice...

slobotron 9y ago
Would you recommend "Software Tools in Pascal" vs the original?
- pmarin 9y ago
  The original one in written in RATFOR with no structures/records or recursion which make some of the programs more complicated than they should. It easy to find the two versions on Internet. They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.
- mcguire 9y ago
  Either. The details aren't especially relevant in either case. I just picked one.

arthurjj 9y ago

The first edition suffers from being a victim of its own success. Much of it has become common wisdom and many of the refactoring techniques now have IDE support. "Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it. 1. https://amzn.to/2I4rIWP https://amzn.to/2I4rIWP 2. https://amzn.to/2GfxVTa https://amzn.to/2GfxVTa 2.

realSlavojTrump 9y ago

I enjoyed the first edition immensely. Some folks are calling out that most of the refactorings are mainstream, but IDE integration doesn’t mean that it has become common practice or second nature to most engineers. If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/ https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book. Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference. The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code. Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)

beat 9y ago

It is a must-read for anyone who programs systems bigger than a student class project.

funkymike 9y ago

To me refactoring doesn't need a whole book or set of terminology. So long as a person understands and values the principles the individual refactorings will come naturally with experience. In my view it comes down to three main points. 1. Refactoring does not change functionality. The observable behavior should be the same before and after. 2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct. 3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well. I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough. Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better. I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).

tankerdude 9y ago

It was a seminal book on software engineering for me. Kind of like Effective C++, More effective C++, the old Win32 Charles Petzold book, GoF, etc. To me, it was a classic, and much appreciated it as that was also when the whole TDD thing took off.