loading...
Cover image for My 5 key takeaways from reading the Pragmatic Programmer

My 5 key takeaways from reading the Pragmatic Programmer

emma profile image Emma Goto ๐Ÿ™ Originally published at emgoto.com on ใƒป4 min read

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.


I always like seeing what other people have been reading, so if you have a Goodreads account, feel free to add me. Thanks for reading!

Discussion

pic
Editor guide
Collapse
patryktech profile image
Patryk

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.

If you know React and ES6 well, Vue.js should be a piece of cake.

I'm kind of the other way around - focused on Vue, because I like JavaScript and don't care to learn JSX -- but there's so many full-stack/front-end jobs that demand react. ๐Ÿ˜’

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.

Don't know about specific editors you may use, but for everyone who needs this... At least on Linux and Windows, you can often select with Shift and arrows - up and down arrows select a line, left and right select a character. Adding the Ctrl modifier selects a word (left-right) or paragraph (up-down).

Collapse
emma profile image
Emma Goto ๐Ÿ™ Author

Thanks! I use VSCode - maybe I'll do another post about the shortcuts :)

Collapse
patryktech profile image
Patryk

Well, ctrl-shift-{left|right} works to select a word at a time. Shift-{up|down} selects a line. Ctrl-shift-{up|down} enables multi-line editing. Useful if you want to replace a variable name on multiple consecutive lines.

I'm a big fan of Alt-{up|down} ... It moves the current line (or selection) up or down the file. Re-order your file without copy/pasting.

Collapse
murrayvarey profile image
MurrayVarey

I will admit I donโ€™t necessarily enjoy reading software development books in my spare time

Oh indeed! Why do software books have to be so dry?!

The Pragmatic Programmer was the first -- and still best -- software development book I read. My main takeaway (possibly from the introduction) was: always ask "Why are we doing this?" I feel this book is filled with answers to that question.

Great write-up Emma!

Collapse
emma profile image
Collapse
kildareflare profile image
Rich Field

Thanks for the write up Emma. I've been meaning to do something similar for all books I read.
Another kind of knowledge bank; I've not really succeeded yet though!

I like the idea of an engineering daybook, I've dabbled with this in the past too, but yet to find a way of doing it that is both easy to write and easy to search. That said I've been using Nuclino at work for a while now and that could be a good candidate.

My hand-writing is abysmal so I doubt I would use paper personally.
It would also make searching for info impractical.

Collapse
emma profile image
Emma Goto ๐Ÿ™ Author

Yeah I've been chucking my notes into Bear right now, which I'm finding is okay but I definitely have a lot of notes that kind of just get lost in there too.

Collapse
ghost profile image
Ghost

test a bunch of different, random combinations to try and see if the property ever fails

Just make them randomly but always the same random data or you may get also random non repeatable tests fails which is annoying at best :)

Collapse
canro91 profile image
Cesar Aguirre

I read TPP a couple of years ago, one takeaway for me is not to live with broken windows.

Collapse
fronkan profile image
Fredrik Bengtsson

I just finished the book last week. I think the engineering daybook, property-based testing and think about programs as transformation topics were my favourites.

Collapse
agilevic profile image
Victor Olex

Good post, thanks. As a side note, with your last name you were destined to become a programmer. Good luck!

Collapse
emma profile image
Emma Goto ๐Ÿ™ Author

Thankyou! I guess you're right ๐Ÿ˜†

Collapse
aweysahmed profile image
Aweys Ahmed

Thanks for sharing. It is on my list of books to read. I'm currently reading Code Complete Volume 2.