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!
Top comments (13)
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. 😒
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
Shiftand arrows - up and down arrows select a line, left and right select a character. Adding theCtrlmodifier selects a word (left-right) or paragraph (up-down).Thanks! I use VSCode - maybe I'll do another post about the shortcuts :)
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.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!
Thanks Murray!
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.
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.
I read TPP a couple of years ago, one takeaway for me is not to live with broken windows.
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.
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 :)
Thanks for sharing. It is on my list of books to read. I'm currently reading Code Complete Volume 2.
Good post, thanks. As a side note, with your last name you were destined to become a programmer. Good luck!
Thankyou! I guess you're right 😆