1. Never assume anything
This is the number 1 sin. Every developer is guilty of this because testing is boring. Still the time spent getting it right first time means more pub time for post release drinks. If you have 10 different scenarios then test each one. Don’t be of mind set of ‘it works for this one so it will work for the others!’
2. Don’t be rushed
This goes for everything! Developers are often put on the spot to give an estimation of how long something is going to take. Don’t give an estimation until you’ve investigated the task. Or give a ridiculous estimate ‘text change..erm October 2047 that will be ready’. The same rule applies to bug fixes. They take as long as they take!
3. Communicate
Generally speaking developers are quite introvert. So communicating doesn’t come naturally to many of them. However, the amount of times I’ve seen hours wasted due to a lack of communication. The key is to share ideas at the start to determine whether it’s been done before or whether you’re on completely the wrong path.
4. Don’t be a douche
This should go without saying. I’ve worked for large Dev teams where a few individuals have been involved in the ‘whose got the biggest brain’ ramming of horns. Don’t get involved, it’s such a waste of energy. Try to absorb different opinions and don’t belittle people who need your advise!
5. Test test and test
No one likes it but it has to be done. Unit testing and front end automation can only cover your arse so far. Test driven development is the way forward if the business allows this approach. As a developer we need to envisage every single permutation for our code. So test every single permutation as you go. It’s easier to resolve issues at the start!
6. Document is boring but essential
See communication for explanation in the social flaws in developers. For this reason we need to document our work. I’ve worked in too many places that don’t take documentation seriously enough. Yet they still joke ‘make sure you don’t get hit by a bus’. There’s no magic brain scoop to get all of that vital info out of your head. Also ensure that everyone can understand the documentation. Unless of course you are ignoring commandment 4?
7. Never say too many alerts
Business critical scripts need to have alerts. Whether it be texts, Nagios alerts or emails they have to be in place should the worse happen. Make sure the list of recipients are kept up to date and relevant. The alerts need to be as annoying as possible so that no one can ignore them.
8. Don’t be afraid to ask
I often made the mistake when I was younger of pretending I knew something and finding the answer for myself. You can get away with this up to a point. It comes back to communicating with your fellow developers to ensure that everyone is singing from the same hymn sheet. When dealing with the business it’s even more essential to ask questions. They are the ones that are signing off your work so it’s in your interest to keep them on side as early as possible.
9. It can wait, focus
Too many times in the past I’ve got stressed because of the number of bug or enhancement requests thrown at me. You need to have a system of logging, prioritising and coding these changes with your up most attention. Maybe have a part of your day dedicated to receiving these requests. People will be told not to bother you outside of this period so you can concentrate on the job at hand.
10. Be clean Be lazy
Are you like me? Do you find highlighted SQL files sexy? Just me then! Fairly obvious, aesthetic code practises should be a given. So correct indentation, layout and spacing. Other things I think are essential are ensuring that duplicate methods are removed, only helpful comments included and variables that aren’t being used to be removed. Being lazy actually goes in hand with being clean. By having a standardised coding practise you can automatically generate code that will adhere to your standards!