Decouple Yourself!

In an earlier post titled "Show Me Your Hands!", I discussed that a great ideal to work towards is to be able to walk away from your code and still have it operate as it should. Your colleagues should be able to carry on where you left off without as much as a hitch because:

• your code is well structured; someone can read through your code and understand what it does;
• you have clear documentation that not only shows how to do things but also explains the 'philosophy' (read, design) of your code;
• you have diagrams that outline, not just the software components, but the hardware architecture;
• you have a clear roadmap on where the software is headed and how to get there (you're only suffering from a dearth of time to complete them).

Failure to have this means that you are coupled to your code. We normally talk about how elements of your code can be coupled to one another and how you should strive to decouple as much as possible. I've found that the practice of writing unit tests aids tremendously in establishing the boundaries between components. If you start writing tests either at the onset of the project or at some point along the way, you will find that your code will naturally progress towards a layered architecture with several components taking on the role of ubiquitous utilities.

But being coupled is as bad as it gets. By being coupled to the code then you run the risk of never really taking a break even for something as trivial as a holiday. You will spend endless hours doing substandard troubleshooting because you are away from your tools but have the expectation of contributing as well as you would if you had all your tools in place. All this probably with some dotty 4G signal that contantly logs you out. Even worse is the manner in which many tech concerns insist of having work chat applications which follow you into the privacy of your phone at ungodly hours.

The moral: decouple yourself. It might just save your life.