The Pragmatic Programmer
Ratings125
Average rating4.2
Added to listSoftware Developmentwith 4 books.
Added to listOwnedwith 1 book.
Last month I finished reading The Pragmatic Programmer. I will admit I don’t necessarily *enjoy* reading software development books in my spare time, but I definitely got some good insights out of this book that I want to apply going forward.
Build a knowledge portfolio
Your knowledge portfolio is all the facts, experience and knowledge that you have related to programming. Similar to how you’d build a financial portfolio, you should make sure that your knowledge portfolio is diversified - you don’t want to put all your eggs in one basket! Keep an eye on technology trends, and make sure to “invest” in new areas or new technologies. Learn a new language once in a while.
If you want to “buy low and sell high”, you could learn an emerging technology before it takes off, which can lead to a large payoff (if it does take off!). The authors suggest also reading technical books, taking classes in a new area you’re interested in, or joining meetups.
I know for me personally right now I’ve been very focused on React due to my job, but I do want to branch out into checking out other frontend frameworks and technologies like Svelte, Preact or Vue. I’ve also got my eye on learning a bit of Ruby on Rails so I can try and contribute to the DEV repository.
Make sure your code is orthogonal
In software, two things are considered orthogonal if a change in one does not affect the other. For example, if you had an app with a database and a UI, swapping out the database shouldn’t require you to touch the UI.
Ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected?
As a general rule, you want your components to be self-contained. This reduces risk - if you’re relying on a third-party library, but want to swap it out for another one, this should become relatively straightforward. If you make changes in an area, you will feel confident that these changes won’t affect anywhere else. Having simpler, smaller components will also mean it’s easier to write and run tests on them, as well as making things more reusable.
Achieve editor fluency
Being fluent with an editor basically involves knowing a lot of shortcuts. When you’re writing code, you want to spend less time thinking about *how* to write the code into your editor and more time spent being in the flow of writing the code. I know how to comment and un-comment a line, but I have no clue how to select a select a word at a time or line at a time (I just use my mouse to select things) so I know this is something I need to work on.
If you want a challenge, you could stop using your mouse or trackpad for a week, and only use the keyboard to code. The less painful way to achieve editor fluency is to ask yourself, as you code, if there’s a simpler way of doing the thing you’re doing. Then go and find that out, and start using it whenever you can. This may be a new keyboard shortcut, or it may be a new extension you can install on your IDE. If you can’t find a solution, you could even write your own extension.
Have an engineering daybook
The authors recommend carrying around a paper notebook, and using it to take notes every day with what you’ve been working on. It can also be a place where you store ideas. The benefit here is that you can look back on it later, and re-remember why you decided to do something the way you did. The act of writing a problem or solution down can also help you take a step back and realise if you’re doing something wrong.
The book specifically recommends using paper and not a digital solution - which is not something I’m sure I agree with. I do currently take some notes on my laptop when I’m stuck with something and find the solution later, which has been useful as ideas for blog posts, and I definitely want to keep this habit up. I might extend it to writing more of a daily log of what I’ve been working on.
Use property-based testing
When you write unit tests, you generally think about the ways your code could go wrong, and write tests to cover those cases. But what happens if you make an incorrect assumption while writing these tests, or don’t realise you’ve missed a specific edge case?
Enter property-based testing. Instead of providing one input and testing for one specific output, you’d provide a property (for example, when testing a sorting function the property would be asserting that the result is properly sorted) and then the test would test a bunch of different, random combinations to try and see if the property ever fails. Depending on the language you use, there will be probably be a property-testing library out there, e.g. JSVerify for JavaScript.
Originally posted at www.emgoto.com.
Last month I finished reading The Pragmatic Programmer. I will admit I don’t necessarily *enjoy* reading software development books in my spare time, but I definitely got some good insights out of this book that I want to apply going forward.
Build a knowledge portfolio
Your knowledge portfolio is all the facts, experience and knowledge that you have related to programming. Similar to how you’d build a financial portfolio, you should make sure that your knowledge portfolio is diversified - you don’t want to put all your eggs in one basket! Keep an eye on technology trends, and make sure to “invest” in new areas or new technologies. Learn a new language once in a while.
If you want to “buy low and sell high”, you could learn an emerging technology before it takes off, which can lead to a large payoff (if it does take off!). The authors suggest also reading technical books, taking classes in a new area you’re interested in, or joining meetups.
I know for me personally right now I’ve been very focused on React due to my job, but I do want to branch out into checking out other frontend frameworks and technologies like Svelte, Preact or Vue. I’ve also got my eye on learning a bit of Ruby on Rails so I can try and contribute to the DEV repository.
Make sure your code is orthogonal
In software, two things are considered orthogonal if a change in one does not affect the other. For example, if you had an app with a database and a UI, swapping out the database shouldn’t require you to touch the UI.
Ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected?
As a general rule, you want your components to be self-contained. This reduces risk - if you’re relying on a third-party library, but want to swap it out for another one, this should become relatively straightforward. If you make changes in an area, you will feel confident that these changes won’t affect anywhere else. Having simpler, smaller components will also mean it’s easier to write and run tests on them, as well as making things more reusable.
Achieve editor fluency
Being fluent with an editor basically involves knowing a lot of shortcuts. When you’re writing code, you want to spend less time thinking about *how* to write the code into your editor and more time spent being in the flow of writing the code. I know how to comment and un-comment a line, but I have no clue how to select a select a word at a time or line at a time (I just use my mouse to select things) so I know this is something I need to work on.
If you want a challenge, you could stop using your mouse or trackpad for a week, and only use the keyboard to code. The less painful way to achieve editor fluency is to ask yourself, as you code, if there’s a simpler way of doing the thing you’re doing. Then go and find that out, and start using it whenever you can. This may be a new keyboard shortcut, or it may be a new extension you can install on your IDE. If you can’t find a solution, you could even write your own extension.
Have an engineering daybook
The authors recommend carrying around a paper notebook, and using it to take notes every day with what you’ve been working on. It can also be a place where you store ideas. The benefit here is that you can look back on it later, and re-remember why you decided to do something the way you did. The act of writing a problem or solution down can also help you take a step back and realise if you’re doing something wrong.
The book specifically recommends using paper and not a digital solution - which is not something I’m sure I agree with. I do currently take some notes on my laptop when I’m stuck with something and find the solution later, which has been useful as ideas for blog posts, and I definitely want to keep this habit up. I might extend it to writing more of a daily log of what I’ve been working on.
Use property-based testing
When you write unit tests, you generally think about the ways your code could go wrong, and write tests to cover those cases. But what happens if you make an incorrect assumption while writing these tests, or don’t realise you’ve missed a specific edge case?
Enter property-based testing. Instead of providing one input and testing for one specific output, you’d provide a property (for example, when testing a sorting function the property would be asserting that the result is properly sorted) and then the test would test a bunch of different, random combinations to try and see if the property ever fails. Depending on the language you use, there will be probably be a property-testing library out there, e.g. JSVerify for JavaScript.
Originally posted at www.emgoto.com.
Added to listEngineeringwith 2 books.