How to code better
We all aspire to code better. If you don’t aspire to code better then you’re not a coder which — if you’re not paid to code — is fine, but if you’re a programmer… well, maybe you… shouldn’t be?
1. Have Pride
It’s good for the soul to have a sense of mastery. A friend of mine once borrowed my skateboard for years to develop mastery of at least skateboarding. He didn’t bother, and instead makes loads of money building houses instead. What he made me realise was that people want to know they’re good at something, and if you’re paid to code then mastering coding is definitely an open goal, waiting for you to put some effort in.
Likewise, not just for self esteem but for your own brand, do a good job. Leave a good legacy. In the UK at least the software industry is surprisingly small, you could one day meet someone that works with your (old) code before they work with you. How does it feel to think that rather than try to figure out your code, someone instead set it alight and redid it? Speaking from experience I can tell you it’s embarrassing. Far better to hear “Oh you’re H4xz0R! Your commits haven’t been touched in 8 years.”
“Wow it still works?”
“Works? It’s still the team’s benchmark!”
2. Document
The best coders on the market document things before they’re asked to. Documentation shows that you care about people, you care about helping other people and you care about others’ opinions. If you don’t write good documentation, and you don’t do that early… what do you think that says about you? If you don’t have time to document something what you’re saying to me is that you don’t have time to finish the feature, and that’s just not true is it? The feature’s going to get finished, and documentation is just part and parcel of that feature.
3. Lint
Every time you follow coding standards within a team, you make the world a little bit better. You make your team mates happier, you make the lives of those that follow your code happier. Whoever looks after engineering is happier. Literally everyone in your company is willing you to use coding standards.
When you join a new company, and they use different standards, do not be that guy that talks about changing over to your standards. Each and every time someone tries to do this in their new team/company fairies lose their wings, every time.
4. Use Patterns
At River Island, when we started out we liked certain patterns and so used them. Today — as is the case in many companies — we use patterns because we know we like them. Know the patterns you should be using. If you’re in a team, ask to see the menu. If there isn’t a menu, set to making one because I guarantee you there are set patterns being followed, and you’d do well to follow them yourself. In that menu should be the what, the why, the when and the when not to use.
5. Handle your tech debt/drag
I don’t care if you do it in secret because management would otherwise stop you, or if you‘re loud and proud about it, just make sure you do it. Smell that? That’s your responsibility, handle it.
At River Island we had a problem whereby we were focusing too much on delivering new features — through no fault of those on the ground — and not enough love was given to technical drag. To fix this we now monitor how much technical drag is being handled and Delivery play a big part in championing it getting handled. I can’t tell you how much of an improvement to culture this loud and proud approach has created.
If ‘management’ is forcing you to hide your technical care and diligence you’re either working with the wrong people, or you’re not making yourself heard well enough.
