Breaking your own code and designs

Most developers start out their career with an aversion to knowing the failure modes of the software that they write. They treat the software that they write as their baby, and don't like to see it get hurt. This isn't necessarily a conscious decision but more a subconscious mind-set. So when I am coaching a junior, one of the things I concentrate on is breaking them out of this mind-set.

Code analysis rules versus training and coaching

I have an ongoing and friendly disagreement with colleagues over the value of code analysis rules and training. I focus part of my time on training and coaching as I feel that this is a great investment both in people and also in the quality of the software that is developed. The argument of my colleagues is that training needs to be repeated over and over again in order to cover the large developer base and as new people arrive. Also you can do a training session with a development team but that doesn't stop them from committing bad code.

Being Open, Sharing Your Knowledge

If you're a team lead then being open is part of your job description, if you're not a team lead but want to be one then being open will help you get there. Sharing knowledge isn't just for team leads and senior developers, it is for everyone and should be part of the team mind-set. Sharing your knowledge with other people makes your team and organisation more successful, it makes you more successful and helps you build relationships with others. I cannot recommend more highly sharing your knowledge openly with others.