Over the years, I have worked on and lead several development teams. The following core principles have helped guide me.
- Prime directive: Let no one have cause to alter your code
- When meeting your manager/team lead/peer, be as prepared to tell them what you should be working on as they are
- If you spot bad or faulty code, find the person responsible and have them fix it or fix it yourself. Never scroll past bad code and think it’s someone else’s problem
- It doesn’t matter if some other part of the program is broken – if it’s broken, your product is broken and you are at cause. Take it personally
- Do not let your code cause other people’s code to break. Test, document and communicate
- Do not write code that, when you come back to months later, requires you to have to re-learn your thought process. Make your code self-evident. Otherwise, document/comment in detail
- Pay attention to what my change above or below your code in the architecture stack and code defensively – wherever possible, have code break at compile time instead of runtime
- Quality of code beats quantity of code any day. Bugs are a bigger measure of your skill level than late delivery
- If you have a gut feel that what you are coding is not good code/design. Stop and ask for a second opinion from a peer. Talk it out – never rush to completion
- Take effort to make your team aware of what areas of the product you are working on and what outcomes they can expect from your work instead of simply reporting timesheets
- Always be learning – share cool new concepts that you come across
- Take ownership of the product’s success even if someone else’s way of doing things prevails. It is after all, the sum of all our efforts
I hope they serve you as well. You may also wish to write down your own and share them with your team. Nothing is static in our ever changing field. I intend to review and update these from time to time.