9 ms·

Tips from the Pragmatic Programmer (2000)

165 points by gasull 10y ago

beat 10y ago
I read that book when it first came out back in 1999 or so. It was the first "software engineering" book that actually felt sensible to my pragmatist mind. I still quote "tracer bullets", "boiling frogs", and "select isn't broken" liberally.
100k 10y ago
This is one of my favorite books about software development. I read it early in my career, and it was a big influence on me (for example, motivating me to learn Python). One thing I've always thought ironic is how much nicer the typography and design is in this book, which was published by Addison-Wesley, than the books the Pragmatic Press publishes. And don't even get me started on Pragmatic's embarrassing covers.
- ktRolster 10y ago
  What's wrong with their covers? https://pragprog.com/titles?f[sort_by]=pubdate&f[category]=all&f[skill_level]=All&f[title_contains]= https://pragprog.com/titles?f[sort_by]=pubdate&f[category]=a...
  - 100k 10y ago
    It looks like they did a Google image search for whatever the subject of the book is, and slap the first thing they find on the cover. Example: The Agile Samurai https://imagery.pragprog.com/products/176/jtrap.jpg?1298589898 https://imagery.pragprog.com/products/176/jtrap.jpg?12985898... Dart 1 For Everyone is even better. https://imagery.pragprog.com/products/432/csdart1.jpg?1408653364 https://imagery.pragprog.com/products/432/csdart1.jpg?140865...
zeveb 10y ago
Wow, I can't believe The Pragmatic Programmer dates back to 1999 — seems like I read it just yesterday!
- blowski 10y ago
  I first read it in 2004 and it already felt like I was being handed the stone tablets down from Mt Sinai.
- beat 10y ago
  It's a timeless book. I read it and Kent Beck's Extreme Programming Explained at around the same time, and they completely changed my way of thinking about software development. The only other book that shook my foundations so hard was the classic K&R The C Programming Language.
bluetidepro 10y ago
Great round-up of tips from the book! A co-founder (was also CTO) of a startup I used to work for recommended I read this book while I was still developing my skills, and I cannot thank him enough. This book changed the way I approached programming problems, and was an incredible influence on me. I wish I had read it sooner in my career. I now always recommend it to any developer still getting started, or even to senior developers who haven't read the book yet. I have nothing but great things to say about this book!
crazypyro 10y ago
I haven't found a better source of software engineering knowledge than this book combined with Code Complete.
- dmux 10y ago
  Check out Leo Brodie's "Thinking Forth" I read both The Pragmatic Programmer and Code Complete (2ed) before Thinking Forth. The latter provides a wonderful software engineering foundation (in clearer, more concise language too).
- gnaritas 10y ago
  Have you read Smalltalk Best Practice Patterns by Kent Beck? I'd throw it in that mix if you haven't. It and the Pragmatic Programmer are my two favorites. Code Complete is too verbose imho.
gautamdivgi 10y ago
“select” Isn’t Broken So - this one I have mixed feelings about. It is normally true. But you could have genuinely hit upon a bug. Granted it is much easier to investigate and prove with open source today. 14 odd years ago I was working on HP-UX & C applications. One of the signal commands caused things to crash. I finally figured out the test that could cause it to crash. Now HP support seemed to think I was crazy for asking me to debug their code. I took me ages to get them to understand - that the OS was their code and not mine. Well, either way, they got a tier-3 OS support person involved who collected data, confirmed the bug and provided a fix. The point is - it may very well be a platform bug. That is code too. It just shouldn't be your first (or may be even second or third conclusion) and you should have a unit test to exercise the bug.
- blowski 10y ago
  It's "select isn't broken" for a reason. Another way of phrasing it is "What's more likely?". In other words, is it more likely that you and only you have discovered a bug in a very widely used function that's been around for ages, or that you made a typo? In 99.99% of cases, it's the latter.
  - gautamdivgi 10y ago
    don't disagree - its much easier to discover that now with opensource and publicly communicated bug databases. What I'm saying is that it is much harder with proprietary software (which is probably a good reason to avoid it in the first place).
  - toast0 10y ago
    I wish I lived in that world. I deal with mobile clients, web browsers, and tls stacks; everything is broken, not just select. I always check to see if it's my software that's broken first, out of hope...
- beat 10y ago
  When I was a fresh junior programmer (a few years before the book was written), making my first independently designed and significant change to the system I worked on, I tripped over a "select is broken" kind of bug - specifically, mmap() was broken on AIX 3.2.5, in certain cases. It was weird and wonderful, because my code worked in the test environment, but not the production environment. The response of the senior engineers was "What's really wrong with your code?" Ultimately, I was able to prove an OS bug with IBM, but it required extraordinary proof. And you know what? If some smart junior programmer came to me and said "I think there's a bug with a low-level OS call", my response would be "What's really wrong with your code?" As it should be. Heck, if a lead engineer said that, I'd have the same response. If I said it, that would be my response to myself. That's because select is very rarely broken. The exceptions just prove the rule.
muzzio 10y ago
> Use a Single Editor Well This seems impossible to me, although I agree that it would be an extremely useful practice. I mainly develop Java and Swift, and both languages are extremely dependent on using an IDE. I honestly don't see how I would ever be able to use only a single editor across all the languages I use, even though Jetbrains seems to be trying their hardest to make that possible. (Unfortunately I don't think AppCode is quite there yet.) Even using the same tools across operating systems causes issues: Using IntelliJ on MacOS at work has entirely different keybindings than on Linux, because MacOS doesn't monopolize the Super/Command key so heavily. ...Or is this just referring to things like having Vim bindings across all your editors? That seems much more doable.
- edwinnathaniel 10y ago
  It made sense back in the days when the book was published and there weren't too many IDEs (or development that depend on IDEs).
- jimminy 10y ago
  In the case of Java, while the IDE systems are good, the last time I used Java I decided to do it within an editor and use CLI scripts for building and packaging, and enjoyed it much more than any Java IDE in past experience. It made me feel more productive, anecdotally. Mind you most of my prior Java experience was 2007-2010, and the last time with the editor + CLI was in 2014, and just with a fun example. The editor + CLI workflow was still solid and similar to Node or Python workflow in that regard.
  - BurningFrog 10y ago
    I think an IDE is a must for Java. You get an astonishing power to refactor the code in ways I couldn't have dreamed about before.
    - JonathonW 10y ago
      ^ This. It's not so much about reducing the boilerplate you have to manually enter. While that's nice, the real value of a good IDE is in its refactoring tools, taking trivial but tedious tasks like class, function, or variable renaming and automating them so that they can happen both instantly and error-free. And variable renaming's the simplest refactor that a tool like IntelliJ or Resharper can perform.
deleted 10y ago
[deleted]
rudedogg 10y ago
This is one of the few programming books I've read from front to back. It's full of so much good stuff, I've been meaning to read through it again. Can anyone comment whether Programming Pearls is as good?
- zphds 10y ago
  It definitely complements TPP. For me, Pragmatic Programmer was a better bed time book.
agentgt 10y ago
"Use Tracer Bullets to Find the Target Tracer bullets let you home in on your target by trying things and seeing how close they land." All the other tips I appreciate but embarrassingly I have hard time with the analogy on this one (besides the bullet reference). I mean I think I get it but I can't figure out how it maps to anything I have done. I would say it is like a "software spike" [1] but somehow the analogy description doesn't fit. Maybe someone has a real world example? [1]: https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development)
- zevyoura 10y ago
  Prototypes: http://www.artima.com/intv/tracer.html http://www.artima.com/intv/tracer.html
- cjcenizal 10y ago
  I think this correlates strongly with the idea of "Defaulting to Yes". If someone has an idea or a suggestion, your default position should be, "Let's try it and find out" instead of the unfortunately more common "That won't work because..." response. Discussion is good (because ideas are surfaced and knowledge is shared) but long discussions are bad (because action is delayed). Action is good because that's how you learn things. By adopting an "Let's try it" attitude, you can move from discussion to action more quickly.
- softawre 10y ago
  Huh. I always interpreted this as a sort of binary search algorithm you apply when working out a feature or trying to find a bug. "I know the bug happens between this and this, so lets try this - nope, before then. Divide and conquer.
- ctb_mg 10y ago
  I work with a customer who is notorious for not defining requirements. Their culture is that everyone is either too busy or not knowledgeable enough of all the working parts of a system to define requirements. It's a culture problem over there. The tool I work on generates reports. Rather than defining requirements for reports, the only way to make progress is to understand their general needs through conversation, then provide them a draft report - your best guess. They tell you what to change or what they don't want, then you make changes and provide another draft. When enough tracer bullets are shot, you arrive at the report they actually need.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
lliamander 10y ago
> Provide Options, Don’t Make Lame Excuses This has helped my career more than any other single piece of advice. The critical mindset of the engineer can quickly lead to cynicism (especially when faced with bureaucracy). Don't get me wrong; cynics make great advisors. But the money is in solving problems, not (merely) pointing them out.
- mikeash 10y ago
  I like to put it this way: look for solutions, not problems. Many programmers spend their effort on figuring out why something can't work, rather than how it could work.
clock_tower 10y ago
That page has some impressive reverse-adblocking. I was somehow redirected to a no-Javascript page despite having all Javascript from the site blocked (including pragprog.com), and it looks like they only show content if you specifically enable their advertising servers. I don't know if adwalling is a term or not (analogous to paywalling), but here's what's probably the same content without Javascript and ads: http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/Pragmatic%20Quick%20Reference.htm http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/Pragm...
- gvb 10y ago
  It is very simple and very annoying: <noscript> <meta http-equiv="refresh" content="2;url=https://pragprog.com/no_js"> </noscript> Disabling autorefresh on Firefox: http://lifehacker.com/5321420/disable-automatic-web-page-refreshing http://lifehacker.com/5321420/disable-automatic-web-page-ref...
mahmoodadv 10y ago
Its a good post i like it http://greenlahore.blogspot.com/2016/07/air-quality-worsens-in-city-but-epa-has.html http://greenlahore.blogspot.com/2016/07/air-quality-worsens-...
dllthomas 10y ago
"DRY—Don’t Repeat Yourself Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Always good to revisit original phrasings of things. I think the catchiness of the lower-information acronym did this one a disservice. I find myself explaining with some regularity that repetition of code is not necessarily repetition of ideas, and if I have `f(x, g(y), h(z))` both here and there but for different reasons then it's introducing artificial coupling to break it out into a single function. The focus, in the longer expression, on knowledge is exactly right. DRY isn't a call for "Huffman coding".
- InclinedPlane 10y ago
  I like DRY and generally I'm the sort of person who's always spinning off chunks of code into their own functions, classes, modules, etc. and almost always hating anywhere I have duplicated code. That said, I think DRY can sometimes lead people astray. One problem is that the boiled down concept of "DRY" has nothing to say about quality. Reusing bad code can often be much, much worse than the alternative. Sometimes it's critical to "sunset" code that is "working" because it's not good code, and it would take too much to make it good. Then tie any new attempt to reuse that functionality to an effort to create a better replacement. If instead people think "oh hey, this exists already and it sorta works, whelp, better be DRY!" then they can turn a small problem of bad code into a big problem of horrible code that becomes even less maintainable and more of an effort sink as it acquires little patches and fixes to add support to all the new stuff using it, and as it becomes more and more indispensable and costly to replace. Whereas if the first person deciding to be aggressively DRY had looked at the code and instead said "this is garbage, I'm writing my own better thing" then maybe everyone else coming along later would have ended up using the better replacement and over time it would have become trivial to migrate the one usage of the original to the better version. The mental model I've started to adopt is instead one around "littering". Basically: don't create garbage code, and don't use it. Garbage code is code that has future cleanup inherently attached to it. Repeated code can be garbage code because there's inherently either deduplication work or duplication of fixing/redesign/adaptation work attached to it, it's basically like littering in the code base. But by the same token you don't solve that problem by finding a use for garbage, you still have future cleanup and bug fixing work attached to the code, only now it's worse because it has different use cases to support and higher consequences if it breaks.
deleted 10y ago
[deleted]

165 points by gasull 10y ago

beat 10y ago

I read that book when it first came out back in 1999 or so. It was the first "software engineering" book that actually felt sensible to my pragmatist mind. I still quote "tracer bullets", "boiling frogs", and "select isn't broken" liberally.

100k 10y ago

This is one of my favorite books about software development. I read it early in my career, and it was a big influence on me (for example, motivating me to learn Python). One thing I've always thought ironic is how much nicer the typography and design is in this book, which was published by Addison-Wesley, than the books the Pragmatic Press publishes. And don't even get me started on Pragmatic's embarrassing covers.

ktRolster 10y ago
What's wrong with their covers? https://pragprog.com/titles?f[sort_by]=pubdate&f[category]=all&f[skill_level]=All&f[title_contains]= https://pragprog.com/titles?f[sort_by]=pubdate&f[category]=a...
- 100k 10y ago
  It looks like they did a Google image search for whatever the subject of the book is, and slap the first thing they find on the cover. Example: The Agile Samurai https://imagery.pragprog.com/products/176/jtrap.jpg?1298589898 https://imagery.pragprog.com/products/176/jtrap.jpg?12985898... Dart 1 For Everyone is even better. https://imagery.pragprog.com/products/432/csdart1.jpg?1408653364 https://imagery.pragprog.com/products/432/csdart1.jpg?140865...

zeveb 10y ago

Wow, I can't believe The Pragmatic Programmer dates back to 1999 — seems like I read it just yesterday!

blowski 10y ago
I first read it in 2004 and it already felt like I was being handed the stone tablets down from Mt Sinai.
beat 10y ago
It's a timeless book. I read it and Kent Beck's Extreme Programming Explained at around the same time, and they completely changed my way of thinking about software development. The only other book that shook my foundations so hard was the classic K&R The C Programming Language.

bluetidepro 10y ago

Great round-up of tips from the book! A co-founder (was also CTO) of a startup I used to work for recommended I read this book while I was still developing my skills, and I cannot thank him enough. This book changed the way I approached programming problems, and was an incredible influence on me. I wish I had read it sooner in my career. I now always recommend it to any developer still getting started, or even to senior developers who haven't read the book yet. I have nothing but great things to say about this book!

crazypyro 10y ago

I haven't found a better source of software engineering knowledge than this book combined with Code Complete.

dmux 10y ago
Check out Leo Brodie's "Thinking Forth" I read both The Pragmatic Programmer and Code Complete (2ed) before Thinking Forth. The latter provides a wonderful software engineering foundation (in clearer, more concise language too).
gnaritas 10y ago
Have you read Smalltalk Best Practice Patterns by Kent Beck? I'd throw it in that mix if you haven't. It and the Pragmatic Programmer are my two favorites. Code Complete is too verbose imho.

gautamdivgi 10y ago

“select” Isn’t Broken So - this one I have mixed feelings about. It is normally true. But you could have genuinely hit upon a bug. Granted it is much easier to investigate and prove with open source today. 14 odd years ago I was working on HP-UX & C applications. One of the signal commands caused things to crash. I finally figured out the test that could cause it to crash. Now HP support seemed to think I was crazy for asking me to debug their code. I took me ages to get them to understand - that the OS was their code and not mine. Well, either way, they got a tier-3 OS support person involved who collected data, confirmed the bug and provided a fix. The point is - it may very well be a platform bug. That is code too. It just shouldn't be your first (or may be even second or third conclusion) and you should have a unit test to exercise the bug.

blowski 10y ago
It's "select isn't broken" for a reason. Another way of phrasing it is "What's more likely?". In other words, is it more likely that you and only you have discovered a bug in a very widely used function that's been around for ages, or that you made a typo? In 99.99% of cases, it's the latter.
- gautamdivgi 10y ago
  don't disagree - its much easier to discover that now with opensource and publicly communicated bug databases. What I'm saying is that it is much harder with proprietary software (which is probably a good reason to avoid it in the first place).
- toast0 10y ago
  I wish I lived in that world. I deal with mobile clients, web browsers, and tls stacks; everything is broken, not just select. I always check to see if it's my software that's broken first, out of hope...
beat 10y ago
When I was a fresh junior programmer (a few years before the book was written), making my first independently designed and significant change to the system I worked on, I tripped over a "select is broken" kind of bug - specifically, mmap() was broken on AIX 3.2.5, in certain cases. It was weird and wonderful, because my code worked in the test environment, but not the production environment. The response of the senior engineers was "What's really wrong with your code?" Ultimately, I was able to prove an OS bug with IBM, but it required extraordinary proof. And you know what? If some smart junior programmer came to me and said "I think there's a bug with a low-level OS call", my response would be "What's really wrong with your code?" As it should be. Heck, if a lead engineer said that, I'd have the same response. If I said it, that would be my response to myself. That's because select is very rarely broken. The exceptions just prove the rule.

muzzio 10y ago

> Use a Single Editor Well This seems impossible to me, although I agree that it would be an extremely useful practice. I mainly develop Java and Swift, and both languages are extremely dependent on using an IDE. I honestly don't see how I would ever be able to use only a single editor across all the languages I use, even though Jetbrains seems to be trying their hardest to make that possible. (Unfortunately I don't think AppCode is quite there yet.) Even using the same tools across operating systems causes issues: Using IntelliJ on MacOS at work has entirely different keybindings than on Linux, because MacOS doesn't monopolize the Super/Command key so heavily. ...Or is this just referring to things like having Vim bindings across all your editors? That seems much more doable.

edwinnathaniel 10y ago
It made sense back in the days when the book was published and there weren't too many IDEs (or development that depend on IDEs).
jimminy 10y ago
In the case of Java, while the IDE systems are good, the last time I used Java I decided to do it within an editor and use CLI scripts for building and packaging, and enjoyed it much more than any Java IDE in past experience. It made me feel more productive, anecdotally. Mind you most of my prior Java experience was 2007-2010, and the last time with the editor + CLI was in 2014, and just with a fun example. The editor + CLI workflow was still solid and similar to Node or Python workflow in that regard.
- BurningFrog 10y ago
  I think an IDE is a must for Java. You get an astonishing power to refactor the code in ways I couldn't have dreamed about before.
  - JonathonW 10y ago
    ^ This. It's not so much about reducing the boilerplate you have to manually enter. While that's nice, the real value of a good IDE is in its refactoring tools, taking trivial but tedious tasks like class, function, or variable renaming and automating them so that they can happen both instantly and error-free. And variable renaming's the simplest refactor that a tool like IntelliJ or Resharper can perform.

deleted 10y ago

[deleted]

rudedogg 10y ago

This is one of the few programming books I've read from front to back. It's full of so much good stuff, I've been meaning to read through it again. Can anyone comment whether Programming Pearls is as good?

zphds 10y ago
It definitely complements TPP. For me, Pragmatic Programmer was a better bed time book.

agentgt 10y ago

"Use Tracer Bullets to Find the Target Tracer bullets let you home in on your target by trying things and seeing how close they land." All the other tips I appreciate but embarrassingly I have hard time with the analogy on this one (besides the bullet reference). I mean I think I get it but I can't figure out how it maps to anything I have done. I would say it is like a "software spike" [1] but somehow the analogy description doesn't fit. Maybe someone has a real world example? [1]: https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development)

zevyoura 10y ago
Prototypes: http://www.artima.com/intv/tracer.html http://www.artima.com/intv/tracer.html
cjcenizal 10y ago
I think this correlates strongly with the idea of "Defaulting to Yes". If someone has an idea or a suggestion, your default position should be, "Let's try it and find out" instead of the unfortunately more common "That won't work because..." response. Discussion is good (because ideas are surfaced and knowledge is shared) but long discussions are bad (because action is delayed). Action is good because that's how you learn things. By adopting an "Let's try it" attitude, you can move from discussion to action more quickly.
softawre 10y ago
Huh. I always interpreted this as a sort of binary search algorithm you apply when working out a feature or trying to find a bug. "I know the bug happens between this and this, so lets try this - nope, before then. Divide and conquer.
ctb_mg 10y ago
I work with a customer who is notorious for not defining requirements. Their culture is that everyone is either too busy or not knowledgeable enough of all the working parts of a system to define requirements. It's a culture problem over there. The tool I work on generates reports. Rather than defining requirements for reports, the only way to make progress is to understand their general needs through conversation, then provide them a draft report - your best guess. They tell you what to change or what they don't want, then you make changes and provide another draft. When enough tracer bullets are shot, you arrive at the report they actually need.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

lliamander 10y ago

> Provide Options, Don’t Make Lame Excuses This has helped my career more than any other single piece of advice. The critical mindset of the engineer can quickly lead to cynicism (especially when faced with bureaucracy). Don't get me wrong; cynics make great advisors. But the money is in solving problems, not (merely) pointing them out.

mikeash 10y ago
I like to put it this way: look for solutions, not problems. Many programmers spend their effort on figuring out why something can't work, rather than how it could work.

clock_tower 10y ago

That page has some impressive reverse-adblocking. I was somehow redirected to a no-Javascript page despite having all Javascript from the site blocked (including pragprog.com), and it looks like they only show content if you specifically enable their advertising servers. I don't know if adwalling is a term or not (analogous to paywalling), but here's what's probably the same content without Javascript and ads: http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/Pragmatic%20Quick%20Reference.htm http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/Pragm...

gvb 10y ago
It is very simple and very annoying: <noscript> <meta http-equiv="refresh" content="2;url=https://pragprog.com/no_js"> </noscript> Disabling autorefresh on Firefox: http://lifehacker.com/5321420/disable-automatic-web-page-refreshing http://lifehacker.com/5321420/disable-automatic-web-page-ref...

mahmoodadv 10y ago

Its a good post i like it http://greenlahore.blogspot.com/2016/07/air-quality-worsens-in-city-but-epa-has.html http://greenlahore.blogspot.com/2016/07/air-quality-worsens-...

dllthomas 10y ago

"DRY—Don’t Repeat Yourself Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Always good to revisit original phrasings of things. I think the catchiness of the lower-information acronym did this one a disservice. I find myself explaining with some regularity that repetition of code is not necessarily repetition of ideas, and if I have `f(x, g(y), h(z))` both here and there but for different reasons then it's introducing artificial coupling to break it out into a single function. The focus, in the longer expression, on knowledge is exactly right. DRY isn't a call for "Huffman coding".

InclinedPlane 10y ago
I like DRY and generally I'm the sort of person who's always spinning off chunks of code into their own functions, classes, modules, etc. and almost always hating anywhere I have duplicated code. That said, I think DRY can sometimes lead people astray. One problem is that the boiled down concept of "DRY" has nothing to say about quality. Reusing bad code can often be much, much worse than the alternative. Sometimes it's critical to "sunset" code that is "working" because it's not good code, and it would take too much to make it good. Then tie any new attempt to reuse that functionality to an effort to create a better replacement. If instead people think "oh hey, this exists already and it sorta works, whelp, better be DRY!" then they can turn a small problem of bad code into a big problem of horrible code that becomes even less maintainable and more of an effort sink as it acquires little patches and fixes to add support to all the new stuff using it, and as it becomes more and more indispensable and costly to replace. Whereas if the first person deciding to be aggressively DRY had looked at the code and instead said "this is garbage, I'm writing my own better thing" then maybe everyone else coming along later would have ended up using the better replacement and over time it would have become trivial to migrate the one usage of the original to the better version. The mental model I've started to adopt is instead one around "littering". Basically: don't create garbage code, and don't use it. Garbage code is code that has future cleanup inherently attached to it. Repeated code can be garbage code because there's inherently either deduplication work or duplication of fixing/redesign/adaptation work attached to it, it's basically like littering in the code base. But by the same token you don't solve that problem by finding a use for garbage, you still have future cleanup and bug fixing work attached to the code, only now it's worse because it has different use cases to support and higher consequences if it breaks.

deleted 10y ago

[deleted]