Ep. 25 — Your code can affect many people’s lives, not just your end-users’

There are a few simple things you can do before that final commit to make your code more friendly to everyone.

Photo by Miguel Á. Padriñán from Pexels

a) Your fellow engineers (and successors who you may never meet) will read the source, digest the change history, fix bugs and delete chunks of it gingerly in the years to come.

b) Your colleagues on the Release team will read your code to figure out why the build stops working on a Friday afternoon. Is it the code, the tests, the toolchain upgrade or an underlying OS patches that broke it?

c) The infrastructure team, who may be in a different city, will try to decipher the logs and error messages your code created to figure out what to do next? Should they restart the servers, route traffic to backup sites, or rollback the changes to protect the integrity of the overall system?

Here is simple list of actions that your colleagues will thank you for.

1. Clean logs: Spend the extra time to review the console logs before you check in the final version. Do your best to clean up those WARNING that doesn’t affect end users functionality. So, others won’t mistake them as actual warning signs of trouble or security breaches.
2. Baseline & compare response time: If there are important deltas, note or fix them. For example, login-flow has gone up from 1.1s to 1.3s because of XYZ. Increases are often unavoidable. But if you can stop unintentional growth, everyone will thank you.
3. Validate with https enabled: (a) There are very few legit reasons to use unsecured http in production any more. (b) Configuring https for localhost is easy nowadays. Yes, I still prefer debugging without encryption to inspect the payload. But a simple, final verification with https will save a lot of integration effort.
4. Make version # visible to everyone at run-time: For web apps, include a simple HTML comment or console log at startup. For backend APIs, include the version in the payload. For native mobile, write to device log. Your teammates outside of the dev team will find good use of the extra info.

Happy coding.