Code Is Only Part Of The Story
Empathy might be the best programming hack
The best developers I’ve worked with all share a common trait: they are fantastic bi-directional communicators. In dialogue, written documentation, or even in casual conversation, their ability to explain their thinking or to listen to, quickly parse, and understand the thoughts, requirements, or interests of others made them incredibly useful assets not just to the development team specifically, but to the project and business more generally. These people were almost always very competent programmers, but their value was significantly enhanced by their ability to step outside of the code and view projects, clients, and business interests holistically.
Their code may not have always been the best code possible, nor was it the fastest or cleverest - but it was usually the code that made it into production with the least fuss. Typically, their output was easy for others to understand, robust enough to handle modification without falling to pieces, and provided just enough ‘cherry on top’ functionality to support integration with other areas of development without straying outside of its particular area of concern.
Though it takes all sorts to deliver a successful project - from those who knuckle down on complex systems for weeks at a time, to those who hop around different areas of the codebase, stitching things together and bringing order to chaos - I’ve found that there are a range of skills and traits that, with some encouragement and fostering, can improve the development experience, build greater understanding and cohesion between different disciplines, and significantly improve confidence, clarity, and a sense of direction.
These people may (unfortunately!) not be particularly visible; preferring instead to keep their minds focused on the task at hand rather than involve themselves in other areas without being prompted to do so, but what follows are some thoughts on the things to look out for, and the skills and habits to embrace and encourage in order to maximise potential.
The 10x Empath
Over the years, I’ve come to believe that a great indicator of a developer’s overall success is their ability to empathise with others. Developers who take an interest in the problem from the perspective of the customer / client / user, rather than rigidly following the brief, will often identify better solutions, make sure gaps in proposed functionality and features are caught early, and take an interest in the end user’s experience rather than handing over something which technically works, but is unpleasant or cumbersome to use.
People who are good empaths are usually fairly simple to identify, because communicating with them is easy. They listen well and will place themselves in the shoes of others in order to better understand a problem, rather than wait to be told what to build.
Their code is often well-structured, because they understand that others will be reading and using it, and they try to accommodate everyone’s interests (within reason) when carrying out their work. Their interactions with other departments (e.g. production, management, marketing, etc) are clear-headed and straightforward, even when problems arise, because they recognise that the bigger picture is what’s important, and want to make sure that everyone is on the same page and moving in the same direction.
Those with a good handle on empathy can make fantastic developers and team members overall, but it can be a double-edged sword: it’s impossible to accommodate everybody and everything, and it can be easy to lose focus if goals and tasks aren’t well-prioritised.
Though a developer with good empathic instincts can be a serious boon to any organisation, teams should be careful not to allow decision paralysis to cause delays. Empaths may struggle to commit to a decision which they feel doesn’t satisfy everybody, and might find themselves facing difficulty when attempting to reconcile conflicting or competing interests. It can be beneficial to ensure that empaths in decision-making positions have additional support to help prioritise the needs of the project and the business, and to act as a tie-breaker and forge a compromise when the natural tendency towards idealism becomes an issue.
Subscribe now and receive 20% off forever
Socrates 2.0
Delivering a project successfully involves a great deal of interrogation and filtering to identify exactly what needs to be built, and for what purpose.
Though it’s often easy to rely on top-down diktats when it comes to identifying what to build and how to build it, it can be very useful (or, more accurately, critical) for proposals to be challenged and questioned in order to expose gaps in reasoning, to tease out design flaws, and to ensure that everyone understands the direction of the project.
Those who aren’t afraid to ask questions or to critique decisions need to balance worthwhile interrogation against the team’s patience and capacity, but the process of asking questions and seeking justification for design decisions can be a very valuable exercise that should be embraced (within respectful boundaries).
Those with the tendency to ask a lot of questions can sometimes come across as difficult - but it’s important to recognise that it’s almost certainly worse if nobody is asking questions!
Formalising the interrogation process is wise - though, in a fast-moving environment, this can be difficult: questions might arise at inconvenient times, and even with the best intentions, it’s practically impossible to have a complete understanding of what to build and how to build it before work actually begins.
The best approach to maximise the benefits of an interrogation is to block out time: this allows the questioner to extract whatever information they’re after, or to expose whatever potential problem they’ve spotted, whilst allowing the ‘defendant’ to give the questioner their full attention, rather than being blind-sided with a scattergun approach whilst their mind is elsewhere.
As with empaths, too much can be a bad thing here: no functioning business has infinite time or capacity to accommodate an endless list of questions and challenges. Formalising the process and ensuring that there is time allocated to interrogating decisions and plans is the best method to support both parties - and a good referee can help to keep things on track, ensure that there are boundaries to the debate, and that reasonable accommodations are made by both sides when disagreement occurs.
The Tolkien
Good technical writers can be hard to find, and programmers are not, by and large, known for their literary capabilities. Anybody who’s worked on a decently sized project has probably realised that ‘writing documentation’ is to programmers as ‘deliberately swallowing kryptonite’ is to Superman. Even when repeatedly beaten with large sticks in an effort to improve documentation discipline, programmers usually prefer to write code, rather than write about code.
There isn’t an easy fix to this problem other than maintaining strict standards, linting the codebase to ensure comments exist where required, and otherwise making a concerted effort to ensure that code is well-documented, but it’s also worthwhile remembering that documentation outside of the code is often just as important as comments within the code itself.
Design documentation, user manuals, and technical specifications all form part of a project’s deliverables, and the quality of these documents is critical - especially when they’re to be delivered to third parties or released publicly.
Even the best writers on your team might not naturally be particularly disciplined when it comes to writing documentation - but identifying those who have a talent for writing clearly and accurately will never be a wasted effort.
Though programmers are not typically hired for their writing skills, the ability to effectively convey information is incredibly important, and can drastically improve confidence in the project and the team overall, especially in an environment where documentation forms a critical part of the project’s contractual obligations.
Encouraging developers to practice their writing skills might be one of the best investments you can make in your team, and the anciliary benefits are impossible to ignore: improved communication, greater understanding, and the development of an in-house ‘voice’ all serve to strengthen a project and the team behind it.
Larger companies may employ dedicated technical writers to produce edit, review and maintain documentation that sits outside of the code itself, but for smaller teams, this is often impractical, if not impossible. Depending on the size of the project, it may be useful to nominate a handful of people with good writing skills to produce the relevant documentation, but in practice, producing documentation may simply form part of the responsibilities for every developer. In this context, it might be a good idea to ensure that your best writers are given enough space to act as editors, wrangling documentation of variable quality into shape, and ensuring that any gaps or inconsistencies are cleared up before they’re forgotten about.
If you have a good technical writer on your team, then fostering their abilities and providing an avenue for them to flex can be a great way to take advantage of a talent that might be in short supply - but in the ideal scenario, everyone is given the opportunity to practice their writing skills, since documentation so often forms such a critical part of a professional team’s output.
There aren’t many downsides to quality writing, but it can be difficult for multiple people to stick to a single style and voice without a strong editorial process in place. It may be wise to nominate a single individual to act as the final check on any written output, rather than allow inconsistent styles to pollute the documentation.
The Myth of Many Hats
The skills mentioned here, when identified and honed, can all provide an enormous benefit to any team. Though they can, if mismanaged, result in problems, it’s well worth trying to identify which tendencies the people on your team exhibit, and seek to find ways to make the most of their natural traits.
Though it would obviously be fantastic if everybody was great at everything, this is, of course, completely unrealistic. Developers, especially in smaller teams, are often used to ‘wearing many hats’, and are accustomed to finding themselves occupying a variety of roles at different times during a project. However, when this pattern is left unchecked, it can breed resentment and confusion over responsibilities and expectations. It is much better, overall, to seek to identify your team member’s natural strengths and weaknesses, and to position them in roles that encourage their growth in useful areas and take advantage of their innate abilities.
Expecting an individual to exhibit all of your most desired traits is short-sighted and a quick route to disappointment. Instead of assuming that everybody is capable of stepping into any role, it’s often much more productive to try to identify your team members’ natural talents, and to provide opportunities for their strengths to shine through.
If you’ve enjoyed this post, then please consider a free or paid subscription. If you’d like to read more tips and insights into maximising your team’s potential, then check out some of my previous posts:
