Writing quality code and adhering to coding standards requires a lot of discipline. As a senior developer, it’s difficult to stress the importance of standards-based code to junior developers.
Junior developers (and occasionally lone-wolf senior developers who’ve never worked in a team) can find code online and bring together a working application fairly easily sometimes. Sure, there are books and documents about writing code in a certain style, but they can’t see why anyone would trouble themselves to read any of it.
I get this a lot.
Some of my more recent contract positions were working as a senior developer and guiding junior developers through software projects. They get something working and say they are complete. I review the code and ask them to change it. “But it’s working,” they say. I agree that it is working, but it is not coded to the standards. They protest that I am being nit-picky (and I suspect they think I’m jealous of their code).
But the reason we need to document and adhere to coding standards is that standards allow multiple people (in the current team and future developers) to work on the same project. Coding standards are not so much created for version 1. They are made for version 1.1. That’s when the value shows itself.
I think I can build a house. Okay . . . there’s no way I can build a house. So, let’s say I can build a shed. I can buy some plans and build them according to that plan. Or, since it’s fairly simple, I can just wing it and build a new shed. It’s faster to wing it. It will save me time and money to just build it and not spend any time planning or taking classes.
Halfway through building a shed, though, I realise I need help. There’s no way I’ll finish this thing. So, I hire a second builder. I need to explain to him why I did things the way I’ve done them. I may need to re-do some parts of the shed so he can work on his part. This could take hours with a shed . . . but days or weeks with software.
Then, after the shed is complete and a few years have passed, I decide I want to add a new feature . . . like a back door. I would need to spent hours looking at how I built the thing. I can’t hire a contractor, because he will spend longer trying to figure out why I built it that way so he doesn’t undo something that was intentional. Version 1.1 (my new feature) will cost me a fortune to add and I will have to do it myself. All because I did not build to standards.
Think about a good builder. They build the same thing in the same way over and over.
They learn from other builders and discuss technique. A builder has worked on enough hatchet jobs that he will never create a hatchet job himself. Builders are very good about discipline. There is a way of doing things.
The surprising truth about software is that, although there are standards and practices for quality code, very few developers actually follow them.