How to identify programmers and cope with their different coding styles.
Everybody has their only personal touch when it comes to pumping out code. Oftentimes the difference is negligible since similar work items are usually delegated to one programmer or department, minimizing the chance that you will ever have to sort through their source since it 'appears to work'. Having to decipher another person's code can be time consuming and runs the risk of erroneous implementation of code. Being able to recognize a particular programmer's style is the first step to successfully utilizing their work for your benefit. Listed below are a number of different programming styles that you are likely to come across in your workplace along with their distinguishing traits.
The Clutter Bug:
More often than not this type of programmer can be identified by looking at their workspace alone. These 'cluster-coders' lack organization and are more concerned with results than upholding standards. Clutter Bugs are the product of loosely defined business requirements, poor fundamental programming education (or a personal indifference towards accepted programming methodology), and not enough team experience. The Clutter Bug gets a bad rap, because they often are the most intelligent programmers. Most Clutter Bugs know their code like the back of their hands and given a conflict can resolve it promptly. Other symptoms include inconsistent lunch schedules, late hours, and unkempt hair.
The Dungeon Master:
These programmers assume that others will adopt and follow their programming styles down to which data structures they use. The Dungeon Master is resilient to change and is always ready to defend their work with a lengthy list of reasons why their style is superior to yours. They are quickly irritable when dealing with other persons' code, and will become quickly lost if too much or too little whitespace is present. Individually they might stand out from the crowd, but when working within a team environment they oftentimes become the nitpicker and inhibit work from getting completed by requiring that all deliverables meet their standards first and not the clients'. Some Dungeon Masters are the product of the Dinosaur mental block (can't teach an old dog new tricks), but more often than not they are just prideful and have an insurmountable prejudice.
The Spatially Aware:
If there was a beauty pageant for code-writing the Spatially Aware would win every time, however they might fumble when asked how they would use their code to better the project. The primary flaw of the Spatially Aware is that they probably have spent more time organizing their code than writing it. Some of them are tightly bound by the instructions of their first programming teacher while others simply have some form of textual spacing Obsessive Compulsive Disorder. This type of programmer may make it extremely easy for you to find what you need from their code, but they will struggle immensely with your code if you have not mashed your 'tab' button to death. They also tend to waste valuable time making code look presentable even though the client will never touch the source.
The Shape Shifter:
Always looking for a new and improved way to perform the same old trick, the Shape Shifter will solve the same problem three different ways in three different places. Their included files list usually has to be placed within a collapsible tag to keep it from taking up half the page. The hardest part about dealing with a Shape Shifter's code is learning how their code works or learning the foreign resource they decided to pull in. Other programmers struggle with Shape Shifter code, because it requires them to learn alternative ways of implementing a solution that they are already capable of doing with tried and tested logic. Shape Shifters are usually technical bookworms, random bloggers, and tend to jump into a problem headfirst without analyzing the needs of the project first.
In the brain/processor of the T-1000, coding standards are expendable. Opening up a T-1000's code is like opening a Windows Media Video file with notepad. Class and variable names look more like serial codes than descriptive titles, lines of code run together, and commenting is, in the programmer's opinion, unnecessary. These programmers are living machines and should be watched carefully when working on a team project, especially if you have employees with the last name of 'Connor'. If you're delegating an entire project to a T-1000 rest assured that it will function correctly, but do not expect great documentation. T-1000's can understand anybody else's code, but others will struggle to understand the simplest statement of a T-1000 program.
While it is impossible to unite all coders under one programming standard, it is very easy to alleviate several issues that may occur between clashing programmer mentalities by implementing and enforcing rudimentary practices. This can be as simple as defining naming standards, having a logic flow associated with work items (aka use cases), or enforcing good commenting. Below are a number of steps that can assist in tightening the nuts and bolts on your development team:
- Create a predevelopment process where overall project analysis and design is performed. This includes designing database schema, use cases, naming conventions, and business rules.
- If your team is large, or your projects expansive enough, you may consider developing a business-specific software development cycle where project workflow can be custom-tailored to your business's needs and methodology.
- Getting your developers to discuss their ideas openly in Developer Meetings can help establish what kind of standards are necessary for your workforce, and will also promote constructive technical discussion between programmers.
- Commenting is a simple and easy way to describe what your code does. This is the only reason commenting exists…so use it!
- Documentation is painful to compile, but it will save your developers time, your end users even more time, and your customer support department 50% on their phone bill.