January 21, 2022
Created at: 2024-01-21
Updated at: 2024-10-13
TLDR: This is the kind of book I wish I had read before taking my first job as a developer. Though I probably wouldn't get as much from it as I did by reading it today as I reflect on my experience so far.
The Pragmatic Programmer was originally written in 1999. Fast forward to 2022 and the book feels like it was written yesterday.
This book shows history repeating itself. The good and bad patterns talked about back in 1999 propagate all the way towards today's software developement era. In all the companies and cultures that I had worked with: Brazil, Argentina, U.S, and New Zealand; these patterns came up.
"I wrote this, and I stand behind my work." Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a real professional.
The book talks alot about professionalism. Taking responsibility. Knowing that testing is not only important, but fundamental. Leaving code better than it was when you interacted with it for the first time. Understanding the importance of refactoring. Taking the time to make things good, and to making them rigt.
The last one on that list has been a stone in my shoe for a very long time. I am guilty of enjoying delivering things quickly and in vast amounts (who doesn't?). I also put myself under false pretences that if I don't maintain a decent throughput I am going to be fired or scrutinised somehow. That is self-sabotage at its finest. I am sure other programmers feel the same way.
The problem is, every little issue that we leave behind in order to deliver things quickly, be it a test that you can't bare to write, be it a little refactoring that you are going to leave until tomorrow (never), means that someone else will have to get to it later.
Reasons may vary, but someone will have to deal with it and at that point chances are the problem has become bigger. By ignoring problems and allowing ourselves to go faster individually, we made everyone else go slow.
In conclusion I think this is a book I will have to read over and over again so that the principles and values can be hammered against my brain. Sometimes we slack off and need to be reminded of good work etiquette and for that we need to wear our pragmatic programmer hat (-: