Pragmatic Programmer is a book everyone should read at the start of their career. The earlier the better. This book can give you a lot of practical advice on how to write flexible, dynamic, and adaptable software.
The value which this book provides appears when you say “No, we shouldn’t do it that way.” and someone asks why and you’re like “I don’t know. It just doesn’t feel right.”
“it doesn’t feel right” is no argument, so your team does it that way anyway. 6 months later the codebase goes to shit and you’re like “See! That’s why”.
In this article I will write about my outcomes gained from such a great guide.
The Cat Ate My Source Code
“Don’t blame someone or something else, or make up an excuse. Don’t blame all the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses.”
Everyone Is Responsible for Everything
It is possible that during a debug session you find a problem with a piece of code that someone else wrote, some developers just say “I didn’t write this code so I’ll not fix it”. Pragmatic programmers fix the code, not the blame, it doesn’t matter whether the bug is your fault or someone else’s. It’s still your problem. Remember to communicate with your team so you can create a common healthy culture. The authors strongly encourage to have robust respectfully debate about code, this is an important way to share knowledge and ideas.
The Myth of a Perfect (Bug-free) Software
Zero bug development is a myth that should be dispensed with. Building software is about trade-offs. Perfect software doesn’t exist and the more you chase perfection, the more off target you’ll be. In order to stay relevant, you need to keep things fresh. Twitter, Facebook, Gmail, Dropbox, and other companies constantly improve their software, as we can see in the What’s new section of app store listings. They make improvements to meet end users’ evolving expectations along with changing web and mobile technology.
The authors introduced common techniques that help us fix up existing code continuously as we go. Write code that works and prove it by writing tests and after that make sure that they are executed often and automatically.
Record every change of your codebase using a version control software, shared the code in a directory is not acceptable as a version control system. This kind of system lets you go back to a previous version of your code, so if you made a mess you can just back to a previous version and start again. In addition, you can always know who made a modification on a specific line of code or which files were modified in a specific version. This information is invaluable for bug tracking, performance, and quality purpose.
Save System Variables in Automated Hands
To really make your code adaptable and flexible you should keep external to your app all those values that can change when your software will run in a different environment or for different customers.
Common things you probably want to externalize are environment credentials, API links, build variants, etc. It’d be better to add these values to your CI pipeline to be injected in compile time. If you don’t use automated delivery techniques you’ll probably find a solution to pass and encrypt these variables to the compiler during compile time with keep the default values of these variables points out to your development or sandbox environment.
Do What Works. Not What’s Fashionable..!
You are not Google. You are not Facebook, Amazon, Netflix, Apple, or Spotify either. What works for them will not work for you.
Listen to the trends, try their ideas, judge for yourself.
What works for Google in 2020 wouldn’t work for Google in 2010. Every team is different. Find what works for you now. Change when it stops working.
Software Is a Sequence. Plan it..!
“All programs transform data, converting an input into an output.”
When you think of code as a sequence of steps; events that trigger actions which return states, then your life will be easier. Small discrete steps, rather than large objects and codebases.
Designing the software according to such concept is discussed in the books and courses of OOP Design. You can spend time learning how to build UML class diagrams, Activity diagrams and sequence diagrams. Personally I’ll recommend OOP Design course by University of Alberta.