The Pragmatic Programmer

I liked this book, but if I had to suggest just one book for someone to read to become a better programmer I'd choose Clean Code instead. There are a lot of good tips in here, but there's also a lot of outdated information (I should have checked that I had the 2nd edition). Some of the stuff they recommend is no longer applicable because tools exist for that task.

In general though, a lot of the advice is timeless and useful, even if the perspective seems to be from a consulting standpoint and not as a member of a team working on software that's continuously being updated. Again, maybe a difference in the times (everything now is continuously shipped SaaS products).

I think a lot of the ideas in this book were probably revolutionary at the time this book was published, but are common knowledge now (or common sense). Still, its good to get reminders and I did find myself highlighting a number of passages as I went along.

A great book presenting the best practices of what it takes to be a great developer. I'm reading the book while already knowing quite a bit of the topics discussed, but the book still managed to surprise with little bits of additional insight or perspective. I find the way the things are discussed to be very accessible and fun to read. Every developer looking to learn about best practices (and not just to blindly follow them, but understand the principles behind them) should read this book (among others).

The Pragmatic Programmer is an insightful book for those who deals with any stage of SDLC. Andy Hunt and Dave Thomas published the first edition of this book at 1999 and elaborate Software evolution during last two decades within 20th Anniversary Edition of their book. They have illustrated best practices in the industry and their underlying concepts by sharing their experience and soliciting feedback from people in the industry.

https://www.amazon.com/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833FBNHV

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.

Solid Advice For Programmers Of Any Experience Level. This book, originally released just months before I started college and updated 5 yrs ago from the time I read it as this 20th Anniversary Edition, really does have solid advice for programmers of any level and within any organization. Some/ much of it is stuff that I was trained as simply being "good practice", but there are aspects to the discussion here that we *all* fail in at some point or another, and thus are good reminders of what the ideal *should* be. For those mid career coders trying to figure out where to go next, this is one of those books that can truly reignite your love of sitting down and writing code, free of all the corporate bullshit that exists any time you're writing code for someone else. For those early career coders, this can serve as a guide book for some of the pitfalls to watch out for and what the ideal should be in most situations you'll encounter. And for those truly "seasoned" veterans looking to end their career on a high note with style and grace, this can serve as a solid retrospective of all that you've seen and done and how much you've seen this industry grow, change... and do neither of those things. ;)

Truly a great text on the art of programming, and should be on every coder's shelf right beside The Mythical Man Month. (Which, for those outside the industry/ who may have never heard of it, is basically the highest praise one can possibly give a book about programming.) Very much recommended.