The Pragmatic Programmer: Part 1

The following series of blogs are lessons from in the book “The Pragmatic Programmer: Your Journey to Mastery” by Andrew Hunt, David Hurst Thomas mixed with my understanding and lessons I’ve learned over the years in tweet size sections for the Generation Z & Alpha.

Chapter 1. A Pragmatic Philosophy

1. It’s Your Life

Take proactive control of your life. If you don’t like your current job or the tool set you work with, it’s your responsibility to fix that.

“You can Change Your Organization or Change Your Organization.”
― Martin Fowler

2. The Cat Ate My Source Code

You are responsible for your actions and the results of your actions, whether glorious or tragic. When you make mistakes, own up to them. Provide solutions & alternatives, admit you need help with the solution but never provide excuses. NO EXCUSES.

Even the good leaders (and programmers) make poor decisions, it’s the best leaders (and programmers) that take responsibility for them.
― Kratos (God of War 4)

3. Software Entropy

One instance of “technical debt” is too many instances of “technical debt”. Resist fixing “that” part of the code later, do it now because if you ignore it today, the technical debt will accumulate, eventually making the entire code base “ugly”.

If the code is function but ugly, your work is “almost done”, but “almost done” is not done.

4. Stone Soup and Boiled Frogs

Want to make a change in the code base that requires a lot of time & effort but definitely is the right way to go about the problem? Don’t ask for the permission, get the basic application ready then declare the fact that you’ve been working secretly on “something” and list the benefits of the “something”.

Every change meets inertia and only passion can bypass inertia. Once the ball is rolling, the team will be able to overcome the friction and get the code to the end line… step by step.

5. Good-Enough Software

No software is perfect. The key is to when it’s good enough. Understand what users want as priority (feature request) and what users need as priority (security & privacy). Once you have these two covered, ship the first version.

“All art is knowing when to stop.”
―Toni Morrison

6. Your Knowledge Portfolio

As an engineer, your ability to learn new things as the technologies and world around you changes is your professional worth. Pragmatic Programmer’s education is never over and they keep investing in learning.

Your education is over when you decide its over; otherwise it goes on.

7. Communicate!

Hard skills without soft skills can’t take you or your ideas very far. Effective Communication is a discipline in itself, “How to Win Friends & Influence People” by Dale Carnegie.

“A good idea is an orphan without effective communication.”
— Andrew Hunt

Chapter 2. A Pragmatic Approach

8. The Essence of Good Design

Think about any good design practice you know, it’s pointing you to write code that’s easier to change(EtC)! EtC is the little secret that differentiates between good and bad code.

The definition of good design is that it makes the code easier to change in the future.

9. DRY — The Evils of Duplication

Be it code, comments or documentation if you repeat your instructions to the machine, you are violating EtC! Don’t Repeat yourself!
If you violate DRY for performance reasons, the trick of sanity is to keep the impact localized and not expose the DRY violation globally.

Every knowledge or fact in your system should have a single source of truth.

10. Orthogonality

If changing one part of the code breaks the other part, they are not orthogonal. The developers should have confidence that changing one thing in the code would not break something else in a completely different module. If that happens, the code is violating EtC.

11. Reversibility

The design decisions like using a library, adding a dependency or simply using a vendor or a service should be easily reversible so that we change make the change when the requirements change.

Requirements are not cast in stone, neither should be your code.

12. Tracer Bullets

Tracer code is an end-to-end, incremental approach to the problem. It behaves like the final solution, except it works only for a limited set of input. Tracer code aims to tackle the most uncertain part of the development first, ensuring that the proposed plan hits the target.

13. Prototypes and Post-it Notes

Prototype is a learning platform that allows exploratory coding. The code has an explicit shelf life. It’s written with the understanding that you’ll need to fail once in order to really understand the task to be accomplished or explore the unproven domains and learn things.

Prototyping is the reconnaissance mission to find the target before a single tracer bullet is fired.

14. Domain Languages

Your language influences how you think about a problem. Programming close to the problem domain is bound to be a good influence to reach the solution. If your requirements consists only to manipulate matrix, Matlab should be a better tool for you than writing the entire thing in Java.

15. Estimating

You can only eat an elephant one byte at a time and estimate a large problem after dividing it in bite-size components. Once the components are ready estimate your time requirement and on completion, notice how much time did you actually take, improve your estimation ability.

It’s not the plan that matters, it’s the planning.
— Dr. Graeme Edwards

Chapter 3. The Basic Tools

16. The Power of Plain Text

If a program writes the data in binary format, the data will live only as long as the software. You unnecessarily lose the data at the end of the software life. Plain text enables us to decouple information from our programs; plain text will last longer than any program.

17. Shell Games

The GUI is great for a common user but there are only so many things that you can fit in a menu. GUI does not enable the user to stitch things together to make a completely new thing or to write automated actions. The terminal is superior for this, be proficient with terminal.

18. Power Editing

Using a basic editor or a modern text editor without using shortcuts would be like a modern day carpenter that does not use power tools. Sure, the final product would be delivered, but it would take more time and have more rough edges.

“Everything that can be automated, should be automated”
— DevOps Proverb

19. Version Control

No company runs on one developer and no software is complete in the first release. Hence, all real world solutions require the use of a VCS, it enables multiple people to work on same set of files and maintains a history of the files to build any release at any point.

“Those who cannot remember the past are condemned to repeat it”
— George Santayana

20. Debugging

The conventional way of debugging, “console.log(Hello)”, is nice but there are better options available, options that enable you to reproduce the bug and interactively check the code at that point; look into debuggers for your language. When you do fix the bug, remember to add a new unit test for it.

Find the problem, not the person to be blamed.

21. Text Manipulation

What router are to wood worker is the same as what text manipulation tools are to a developer. Powerful and versatile in the correct situation and the experienced hands. Learn awk, sed or scripting language like Python.

22. Engineering Day-books

Stuff you learn, cool ideas or just your truth table, write down anything and everything that you think could be relevant in the future. Writing things down helps to think and clear your thoughts.

“The palest ink is better than the best memory”
— Chinese Proverb

I hope you learned something new today. Good Luck with your skill development!

Stoic. Existentialist. Optimistically Nihilist. Snowdenist. Friendly. Confident. Perfectionist. Creative. Playful. Programmer. Philosopher.