You’ve got coding style

Arguments about coding style are so cliché that they’ve becomes memes from a popular HBO sitcom. As I mentioned nearly 20 years ago, using a consistent coding style greatly enhances the maintainability and quality of your codebase, but the specific style your team chooses makes little difference. I also said that arguing over coding style is a top-five time suck for dev teams.

However, there is another kind of coding style: your personal approach to coding. Are you bold—jumping right into the fray and allowing the design to emerge over time? Are you methodical—carefully crafting your code in a way that meets the current situation? Or are you analytical—writing a design doc that describes the problem and potential solutions before you touch Visual Studio? People argue over coding approach style as much as they do about the style of the code produced. In both cases, there’s a benefit to picking a style, but there’s no correct choice.

Unlike the style of written code, you don’t want a consistent coding approach for your team. “Wait, what? Our team uses [favorite agile practice] religiously. That can’t be wrong!” Being religious about coding practices is a bit much, but it’s not necessarily wrong. Shared practices and common definitions of done are important to build team unity and consistent quality. However, that doesn’t mean every team member must be bold, methodical, or analytical. People need to code the way they are most comfortable and efficient, which varies by individual. This diversity of approach is just as valuable as other forms of diversity. How can your team embrace diverse coding styles while adhering to high-quality shared practices and done definitions? Read on.

You’re not that good

Analytical engineers think methodical engineers are too quick to compromise. Methodical engineers think their analytical peers often suffer from analysis deadlock. Analytical and methodical engineers both think bold engineers are careless cowboys (or cowgirls, I’ve said it too). Bold engineers think methodical engineers are too slow and that even slower analytical engineers are better described by their first four letters. In other words, none of you are great at everything and in all situations.

Bold engineers are terrific at prototyping, debugging (due to plenty of experience creating bugs), and working quickly in an emergency. Their outsized confidence is just what’s needed under time pressure, though methodical and analytical engineers should review bold pull requests.

Methodical engineers are the most versatile. A manager can assign them anything with the confidence that the job will get done on time and with high quality. Their level-headedness and pragmatism will ensure proper tradeoffs are made when necessary, taking the business and customer into account.

Analytic engineers can tackle the most complex assignments. Legacy infrastructure restructuring, difficult timing issues, and asynchronous scalable architectures are no match for their thorough review and peerless design skills. When their code finally gets written, it works flawlessly and is built to last.

All projects and teams sometimes need to prototype, debug, deal with emergencies, meet deadlines with quality, pragmatically manage business and customer requirements, restructure legacy code, avoid timing issues, and design complex architectures. Thus, all projects and teams need a mix of bold, methodical, and analytical engineers. Animosity is misplaced—you should appreciate the value each team member brings.

You’re out of line

Most engineers are a hybrid of bold, methodical, and analytical, though each person tends to feel most comfortable with a particular style. The trick to managing a team with a diverse set of styles is to establish shared values, practices, and done definitions that everyone agrees will consistently deliver high quality and value to customers. Then allow individuals to work in whatever way they are most comfortable, so long as they abide by the team’s agreed-upon values, practices, and done definitions.

To ensure the bold don’t risk too much, have methodical and analytical engineers review their PRs. To ensure the methodical don’t go too slow or compromise too much, have bold engineers suggest solutions and analytical engineers review designs. To ensure the analytical don’t suffer deadlock, have bold and methodical engineers brainstorm ideas and review designs.

Overall, target assignments to people’s strengths and then mitigate their weaknesses. People work most efficiently and happily in their preferred style, so don’t force a square peg into a round hole. Instead, alleviate issues by relying on shared values, practices, and done definitions. You are stronger together as a diverse team than as a group of clones.

That’s the hero gig

Part of what makes software engineering fun is working with a team of talented individuals. Software is a team sport. Everyone has different insights, special skills and experience, and a personal style.

Have bold engineers write prototypes, demos, and code that must be done quickly. Have methodical engineers write features that must be done pragmatically on time with high quality to meet a variety of business and customer constraints. Have analytical engineers design the trickiest legacy restructuring, asynchronous services, and high-level architectures that must be done correctly. Then mitigate bold code with methodical and analytical code reviews, mitigate methodical decisions with bold suggestions and analytical appraisals, and mitigate analysis deadlock with bold brainstorming and methodical compromise.

Rather than be annoyed by engineers’ different styles, embrace them for the wonderful value they provide. We all have our role to play in empowering every person and every organization on the planet to achieve more. When we embrace each other’s strengths and mitigate each other’s weaknesses, we can rejoice in doing our best work together.