Teams With Poor DevX Are Teams With Poor Emotional Intelligence
It’s no secret that programming (and STEM broadly) attracts a statistically high amount of on-the-spectrum people as compared to other fields. People on the spectrum often have more trouble than typpies when it comes to inferring the emotions of others, receiving social cues, and anticipating whether or not their listeners are interested in listening to the 30 minutes of obscure Star Wars lore while they are speaking. They generally show less emotional intelligence.
For us engineers on the spectrum (lets be real, that’s most engineers), we can tend to hyper-focus on problem solving in a way that becomes tunnel-vision and all-consuming. We love to occupy a problem space for hours or days, until triumphantly emerging with a solution. Society values this skill, especially in software, so we double down on it even more to receive validation, praise, and pay in a reinforcing feedback loop. But what else could we be missing when we have tunnel vision, caught up in running on that reinforcement loop treadmill?
To you, the programmer, I want you to notice two things:
that the more time you spend cultivating skill tree X, that is necessarily less time you have available to put towards improving skill tree Y.
Successfully getting good software built relies on more skills than just hyper-focused problem solving. Not just managing customer expectations, sales and marketing, good designers, but you have to somehow corral a team of autistic engineers to work and communicate together effectively, while keeping them happy enough to want to stay at their job. “herding cats” is a phrase i’ve heard on many teams.
At it’s essence software is made by teams of developers. Every developer on that team has an experience of what it’s like going to work every day.
Is it an enjoyable experience?
Is it fun?
Stressful?
Is it the unbearably awful depths of suffering?
Team dev jobs exist out there all across this entire range of experience. source: I have worked on all such teams.
You thought we were solving for User scale, or Security compliance. Yes, you are solving for those things, but are ALSO always simultaneously solving for the KPIs of:
maximizing team member happiness
maximizing and optimizing team communications
lowering friction points in tooling
If your team is not continually solving for these KPIs in parallel to your software KPIs you are on a losing path.
Sure, you nerds solved the engineering challenge, you did. Your solution does have a certain mathematical elegance to it, and it performs to all the original specs. But what is the developer experience for the next engineer coming into the project and seeing your code for the first time?
Are there 25 cryptic terminal commands that must be entered in a perfect sequence to make the code work or is everything self-contained, automated and documented?
Does the next engineer have to read an entire manual to understand the exotic architecture, or does the code have all the right comments in the right place, linking to additional up-to-date documentation?
How clear are your algorithms to sight-read?
How clearly were your variable names and function names chosen?
How consistently are you following a convention in many areas of your software, versus violating the convention in other places?
Does a new developer require gaining a background in 10+ technologies and frameworks in order to be effective at contributing to the system, or can they hit the ground running and learn as they go?
How well are things “generally where you’d expect to find them” within the app code, versus completely surprising and something you’d never expect and never seen? Lang files, models, controllers, helpers, etc, they should be structured in ways we’ve all seen a thousand times before.
Do the comments and documentation have an air of smugness or condescension? How does that make the next reader feel?
A positive developer experience encompasses more than just code. What emotional experience are you curating in developers who will join this project in the indeterminate future and contribute to it?
It starts from chat and email communications, to how your github issues are formatted and maintained, to having clear hierarchies and ownership roles established on the team.
Dumb is good.
Keep It Simple Stupid.
Is there a pain point that every single new developer on your project always runs into?
Fix it!
What does every developer on the team have to say in private about their most hated part of their workday? Eliminate it! Fix it! Budget time to fix it!
DevX is really just business speak for emotional intelligence in a field thats conventionally low-emotional-intelligence.
To work on improving DevX is to have the emotional intelligence (and compassion) to think about how the experience of being on your team and building your app will feel day to day. Pair that with the motivating idea that happier, better-communicating, non-burnt out developers will stick around longer, form stronger teams, and deliver better results.
It’s amazing that allocating necessary time and care towards DevX is a radical notion, but it shouldn’t be.
