A little while ago, I quit my job as a platform engineer at Zendesk Chat. It was my first job out of university and I spent 3 wonderful years there. Now, with some downtime in front of me before I head to grad school, I figured I should jot down a few notes for my future self to help him in his next job.
A decently-sized chunk of my time at my job was spent working on platform integration projects with the other teams across functions and time zones. From those projects, one thing that jumps out to me as my biggest takeaway is learning to be a defensive programmer. I'm not good at it yet, but I'm trying. The points below are not completely mutually exclusive, but I’ve tried my best to separate the core ideas.
You're an interface...
... and as an interface, it is your responsibility to be able to accept (and deal with) invalid input but always return valid output. My first mentor at this gig, Ali-Akber Saifee used to call this is his guiding principle. Whenever we designed APIs, or defined behavior of any description or built architectures for new projects, this thought was my gospel.
Design by contract
Interaction and integration with other modules, services and teams was the quintessence of my job as a backend/platform engineer. This made designing by contract very important to the way I worked.
Assume everyone is going to break the contract eventually. When that happens, hope that you followed the interface rule above and are able to deal with that scenario.
Cover your butt
Make sure you've done everything in your power to make sure that when 💩 hits the fan, and it will, you can prove that the fault wasn't in your work. This may sound... unpleasant or even nasty at first, but humour me. This translates to having the necessary guards against and logging of bad input or pre/post-condition violations etc. Not only does this make debugging easier for you, by proving that your system wasn’t at fault, it also makes debugging easier for the external components/teams you’re working with.
Test whatever you can
Be it unit, integration, functional, behavioral, factorial, or foobarial. Make sure there are systems in place to inform you or someone else is when regressions are introduced.
Document your work
Assume that when things break, you'll be on vacation on a beach or hill somewhere where internet access isn't an option. When that happens, assuming your bus factor was 1 (which it ideally shouldn’t be), someone else should be able to step in, and without too much* effort, be able to find out what is wrong. If you did cover your butt, then said person would be able to point out which interacting system was at fault. If, for whatever reason, it was your component, then said person should also be able to follow your documentation and fix the problem.
*your mileage may vary
While being defensive usually has negative connotations in life, deploying it as a programmer, I’ve found it to be quite helpful.