Pragmatic tips for Software Engineers
Before getting into some kind of recap of Andy & Dave’s advices on “The Pragmatic Programmer” (advices I fully agree with), I would like to make the following disclaimer:
True pragmatic engineers know that there is not only one “right way” to do things, and that the “right way” depends fully on the given context (resources available, cost, time, etc.). That said, the following tips won’t be applicable in all circumstances 🤓
Build easy to change solutions because there are no “final” decisions.
Designing loosely coupled (orthogonal) systems make them easier to work with, to test, and to change, because you can change one component without the fear of breaking something on the other end.
Testing is not only about finding bugs, and having 100% code coverage doesn’t guarantee that the code is bug free.
Writing tests improves a lot the way you write code, as it forces you to write decoupled and testable code. In addition, it helps us think about our code in a more goal-oriented way, and it gives us a better picture of the requirements (especially unit tests).
Despite the code coverage is a great quality indicator, all lines of code may have been executed but only one or few input scenarios were really tested. Property testing is a useful addition to your test suite because it runs one statement hundreds of times but with different inputs, testing lot of different scenarios (empty lists, negative numbers, really long lists or strings, etc.)
Code “good enough” software and avoid over engineering.
Well-crafted code doesn’t mean at all over-designed code. Do frequent meetings with your stakeholders and ensure that your solution satisfy their needs. Avoid premature optimisations, that increase software complexity unnecessarily (sometimes this is driven by our desire of using new technology or applying a specific design pattern). And remember, no one know exactly what they want, it is our responsibility to help others understand.
Use “tracer bullets” to correct your aim.
Get a small part of the system working as soon as possible, to get quick feedback from users and stakeholders, and to reduce the risk of the following changes. This is also known as building a “walking skeleton”, because it works as a backbone for future developments (in opposite to prototyping that generates disposable code). Go on taking small steps, always, checking for feedback and adjusting!
Don’t leave a broken windows if you don’t want the rest of them to be broken soon.
If you find a “broken windows”, and you don’t find confortable with it, DO something about it, and show you are on top of it (fix the issue, do some refactor, or just schedule to making it happen). Neglect accelerates the rot faster than any other factor.
Always be aware of what you’re doing and avoid programming by coincidence.
Program always deliberately, understand what you are doing and don’t rely on luck and accidental successes, because when something goes wrong (and it will!!), you won’t understand what the hell happened. Proceed from a plan, rely only on reliable things and test your assumptions.
Crash early, don’t panic and don’t blame.
It doesn’t really matter whether the bug is your fault or someone else’s – it is still your problem, and it still needs to be fixed. Reproduce the bug (make it reproducible if it’s not), visualize the data (using debugging tools), understand what happened before and after (log tools may help), explain it to someone else, and always focus on discovering the root cause of the problem. Although it is possible that a bug exists in the OS, the compiler, or a 3rd party tool, it should not be your first thought, check your code!
If you want followers, show them a glimpse of the future and you’ll get them to rally around.
How many times were you convinced that something would work but didn’t get the support you wanted and abandoned the whole idea? Sometimes we just need to start working to then get the opt-in of the rest, as people find it much easier to join an ongoing success.
Finally, keep on learning and investing on your knowledge portfolio
Reading non-fiction books will help you stay curious and motivated about your profession (they don’t have to be all technical). Stay current, take classes, learn new languages. As an investment portfolio, you will reap the benefits of all this later on!
