Pragmatic Programmer Rules any developers should know

I’ve listed some of the most essential rules any software engineer should know. Those essential principles are taken from the Pragmatic Programmer book, by Andy Hunt and Dave Thomas.

Algorithm Speed 🚀

Although this is nothing new for any experienced engineers, you should always be careful and cautious when dealing with multiple loops. This is the complexity of a simple loop O(n). Now, if we introduce a function/method inside it that also loops something, the complexity will immediately become O(m x n). Always see the side effects of any kind of changes in your code to ensure that there will be no impact on scaling your application in the long term.

Best isn’t always best 💡

Be aware that premature optimization isn’t always the appropriate decision at the start of any project or proof of concept (POC). At that particular stage, it’s impossible to know the traffic and eventual iteration/direction for your application. Instead, it’s always wiser to keep us simple and small.

Be a Pragmatic Programmer. Not a Coincidence "CodeMonkey" Programmer 💥

Coding isn’t a mechanical job. As a pragmatic programmer, you need to make the right decisions. You need to think critically about all code and the impact it could have, as well as how much your code and software architecture will scale in the future.

On the other hand, a Coincidence Programmer/Code Money will write code without it panning or looking at the big picture. They tend to add mechanical code in an inefficient manner.

Automation 🤖

Automating things is an important concept in the lifecycle of an application. However, like optimization, if you automate too early things that might not be repetitive, it will only add unnecessary extra hours of work.

Learn what you need 📝

Learning well the right tools (could be Jenkins, Docker, a framework, shortcuts, your favorite IDE, a benchmark tool, …) will be your best strength in your career

Don’t write Dodo-Code 🦤

Writing dodo code implies that your code won’t adapt well over time. The dodo didn’t adapt to the presence of humans. They livestock on the Mauritius island, before extinction. Don’t give the same future to your code. Keep your codebase agile and well-maintained with good design patterns that will allow new changes and feature implementations easy.

Testing before production 🍳

Although this can seem logical, too often I see “last minute important changes” that need to be shipped on production as soon as possible. And then, since the software engineer(s) don’t have the time and necessary resources, they proceed by shipping the changes right away to please their manager/c-level people. However, this can end up quite bad. It’s always so easy to underestimate that everything will go well until you wake up one morning and the entire online service is down because of a missing assignment operator or a missing semicolon/comma in a file giving an incorrect behavior. No matter how much you trust the release, you are never 100% sure of the consequences of each change in your code. Integration and acceptance tests can be very handy to have. A good practice could also be the use of the “chaos monkeys” technique on your application to make sure there are no obvious issues with it.

Debugging mindset 🧠

Before starting debugging, it’s important to adopt the right mindset when it comes to debugging. Debugging can be tricky and time-consuming.

However, here are some rules of thumb that make this “mental digging” more pleasant 🤠:

1. Immediately think about what tier/layer of your code the problem could come from.

2. Crash early will tell you more directly and instantly where something isn’t working. You should always fail early instead of quietly going to the next function when something isn’t supposed to happen.

3. Use breaking points and exception tracing.

4. Speak to your “rubber-duck” (or any other rubber animal) will help you to understand clearer and see the big picture of what’s boy working. Very often, you will have an “aha” moment and understand what’s wrong in your code when you explain to a rubber duck or a colleague what doesn’t work, what has changed and where you went through in the code.

5. See the big picture of the entire architecture/infrastructure to locate with more ease the problem.

The boy-scout rule 🧹

The boy-scout rule says “Always leave the campground cleaner than you found it.” It means you need to clean it when others leave dirty things, no matter what kind of excuses. No matter if you haven’t done that mess. The rule aims to make the codebase granularly better, baby step after baby step, every time you touch a legacy outdated part of the code. So, every time you need to add/change something in an existing function/class, identify a little thing you can also improve. A little tiny improvement won’t add new problems or make the code-review harder, but that little tiny improvement for every update will make the whole codebase much nicer in the long term.

Happy coding! 🤠