The Pragmatic Programmer by Andrew Hunt & David Thomas
After being involved in software developing for around 4 years, diving over tutorials to reach the best practices and why to do so, I got many problems and goodies unconsciously. Sometimes I was like “Oh, I shouldn’t do this because everything will collapse”. Then I read the Pragmatic Programmer, and I could name some of these practices and issues.
This book is recommended for the whole team and it will be useful disregarding your rank or expertise.
For beginners this book will give a lot of tips, but it still have some content that maybe this kind of reader could not understand without external research; which in fact is not too bad, feel encouraged to research about these “key words”.
If you’re a programmer, then this book will fit you good enough, I think this could be my case, the reading is not boring (like some of other programming books), it is more like “useful theory” and some practice examples.
But what about if you’re a team leader or if you are “the client” and you will give requirements to programmers about your software idea/product, well, good news, this book will help you to understand why sometimes a project could have slowness, how you can lead a project with non high expertise programmers, and to avoid taking “random decisions” (for programmers this is the same as programming by coincidence).
This book uses a lot of metaphors, and nice quotes; so you won’t feel punished of what you have done all this time, instead you will have it like the cool uncle who tell you how one of your parents did the same mistakes and guide you to avoid some other problems you may face later soon.
I don’t want to spoil you the book, but it will be a little bit necessary at this point.
Some of the advices you will find in this book include:
- Pay attention to what you’re doing while you’re doing it.
- Craft small pieces, it will be easier to maintain later and/or for others.
- Do not blame others before taking a look to your own code (Not even the cat, see Figure 1).
- Use source code control (I’m pretty new to Git and it seems good for me) for everything.
- If something shouldn’t happen, assert it (the caller should assert it) *
- You can do bad programming practices if the benefit is higher like better performance **
- Make it configurable, because species that do not adapt, die.
- Don’t use wizards code you don’t understand.
- Don’t assume it, prove it!
* I don’t know if this tip is the best choice, but it helped me to make the decision. I was writing a piece of code that receives the result of calling a function and suddenly I needed to decide where to put the condition for the arguments of that function, should I throw an exception? should I let it crash if I pass a bad argument? or should I write a condition before calling the function? After reading this, I took it as an advice and worte the condition before calling.
** I being doing this a lot of time, now I don’t feel so bad. Recently a teammate had a problem regarding to denormalize a little bit a database table to gain performance; he asked for help to one of the ninjas (high level expertise programmer) and he just said “If performance is a constraint, you should do it.”
Figure 1. The cat ate my source code.
One of the best methapors I’ve read that apply to programming is the Broken Window one, please take a break to check it if you still don’t know about it (but come back!).
Finally the last spoiler is one of the terms I learned: Decoupling.
Well, maybe this term could be known by many of the readers, but in my case, I knew the problem, I even used good practices to avoid it, and actually I thought that such a thing must have its name. In general, coupling is that relying on “remote” modules or objects, and how the Law of Demeter helps to reduce this weak point.
I hope you have the opportunity to read this book, specially if you are related to the software development area.