Know When to NOT write code

Writing code that is not useful is a waste of time. As software developers, writing code can seem like our only purpose and the only way to prove our value to the company. But way too often software is written only to be never used or thrown out. So you want to know exactly what you will be building and exactly how it will be useful.

Don’t Write Tests

Make sure every keystroke is useful. Ok, I didn’t say NEVER write tests. But if you are working on something new or unproven you should limit the amount of tests you are writing since it effectively doubles the amount of code you need to write and maintain. When working on a new project often times code is written then thrown a few times before it goes into production so you are making a lot of unnecessary work for yourself by writing tests too early. When code is already running in production and you are doing maintenance on it, it’s a good idea to write tests for the parts you are changing.

Don’t Change Code that is Running in Production

Reduce production incidents and fire drills. If you can get away with it, just keep your hands off the keyboard. But if you really need to change some code in production, try to only change tiny parts of production code at a time. This will limit the number of possible bugs introduced by your code. It will also make your code easier to read for your reviewers and make it more likely to be approved.

Index Knowledge Into your Codebase

Expand your impact through other developers. Documentation is useful when indexed correctly. I recommend keeping a “docs” directory where documentation can be found for general knowledge of the system. Like diagrams, ADRs and other miscellaneous documentation. Identify critical parts of the codebase and add documentation like README files in the same directory as the code. This will put relative documentation next to the code it is documenting. Update documentation by adding new files with dates in the names.

Solve Problems Permanently

Expand your impact through automation. If you find yourself doing the same task more than once, you need to find the root cause and automate the solution. Ex. There is an alleged data discrepancy that requires an engineer to investigate. The immediate solution is to investigate and report on findings. Fixing the root cause would be constantly scanning for the data discrepancy and alerting someone when there is a problem plus generating daily reports for any audit queries.

Remove Yourself From Processes

Automate yourself out of processes, this will reduce your liability for making mistakes and free up more time in the day. This can be done by creating an internal tool so that engineers do not need to be involved in the process.