Skip to main content

Sensitivity and Introverts

"Software developers are creative human beings and they need to make sense of unpredictable, turbulent environments"

- Daniel Graziotin, Xiaofeng Wang, Pekka Abrahamsson "Software developers, moods, emotions, and performance" https://arxiv.org/pdf/1405.4422.pdf

Team output can vary dramatically based on the emotional state so neglecting emotions yield to worse performance.  Beyond the pure output no one wants to spend much time in a place where they do not feel good.  It can lead to turnover and engineers applying their talents elsewhere.

There is a stereotype of engineers being highly analytical so in communication with them "facts is all that matters."  This point of view is often not correct.  In "Quiet: The Power of Introverts in a World That Can't Stop Talking" Suan Cain talks about the correlation of introversion, hypersensitivity and involvement in professions that require deep thought, such as software development.

The same engineers that one might assume do not care about the delivery of the message might actually care about it much more:
"Highly sensitive people also process information about their environments— both physical and emotional— unusually deeply. They tend to notice subtleties that others miss— another person’s shift in mood, say, or a lightbulb burning a touch too brightly."

Often times the people who are the worst at treating engineers are other engineers.  When dealing with a sensitive individual who is working hard, stressed out because the project is behind and just inherited a bunch of legacy code it's important to come back to values of empathy.

As a person managing or trying to manage a team of highly technical creatives it's important to pay attention to emotional queues.  Unfortunately e-mail and work chat do not relay a lot of the moods.  Emoticons are a poor substitute and require the sender to be self aware of how they are feeling which often times they are not.

Hyper sensitive individuals shy away from a lot of high bandwidth communication, but in my management practice I have found it incredibly important.  While in person meetings, lunches and phone calls might suck up a lot of energy, they are the only way to understand the subtle moods and get a head of emotional problems.

Comments

Popular posts from this blog

Quality of Code is Quality of Life

About 20 years ago when I started working in technology companies I remember “the best” engineers had similar patterns:
-They worked crazy hours
-They knew the systems no one else knew
-They could react and deliver something faster than anyone else
You could always hear other employees say: “Bob is really smart, no one knows how to get anything done in system X besides him!”

This reinforced optimization around being the only person who knew how to do something in some part of the code.  That in turn reinforced job security and bargaining for those engineers, but also chained them to a particular system.  We had big code bases of C++ or Java code where some “Bob” hacked up features as soon as he possibly could.  “Bob” would have occasional nuclear disasters where he’d sleep in the office or through the weekend and then everyone would thank him for how he “saved the day.”  “Bob” sacrificed his quality of life to get praise when he hacked stuff up quickly and then the second time when n…

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team.

I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me!


SDE/T or QA Engineer interview checklist from Mike Borozdin
If you like this checklist you might want to check out these posts:
Emotional Intelligence in Software Teams  and Good-bye manual tester, hello crowdsourcing!

Code versus Configuration

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of
different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers.

Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily accessible…