Whenever a team leader position has opened up at work, I’ve been very clear that I’m not interested. While I have no problem with managing people – many of my jobs have involved this – I’m currently focused on improving my development skills.
However, running a project I have no issues with, and for the last few months I’ve been in charge of my team’s web migration project. This has largely consisted of planning out our timelines and helping our newer developers get up to speed on our team’s standards for web development.
I ended up sending one development log back to the developer several times with instructions to put things in the correct order. I don’t mean that the code didn’t work; I mean that I wanted the overridden methods, helper functions, and properties to be in the same order, and functions to be named the same way, as they are in the other classes. Given that the compiler doesn’t care, why do I bother?
While we’ve been transitioning our legacy code to web, I’ve been taking advantage of the rewrite to ensure that the code is easier to read and update in the future – best practices have come a long way since it was originally written! One thing that makes no difference to the computer, but makes a lot of difference to the programmer, is consistently doing things the same way from file to file. Once you’re familiar with the conventions, it’s very easy both to locate the code for a given piece of functionality and to understand how the logic works.
This is the same reason that we have naming conventions for variables and functions. In C#, if I see a variable name in camel case I know it’s a local variable, while Pascal case means it’s a property. In JavaScript, a function call in came case is for a JavaScript function, while a call in Pascal case is for a C# DataMethod. The event handlers for the save and restore buttons might have different code in different activities, but they’re still named and called the same way. Consistency means that developers aren’t using brainpower to process trivial differences in the code, which makes it easier to focus on the functionality. At a functional level, solving the same problem the same way each time makes it easier to avoid bugs in the code, as we only need to make a particular mistake once.