Stories about Software


Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More


Your Coworker’s Bad Code: Having The Hard Conversation

Editorial Note: This post was originally written for the SmartBear blog.  You can check out the original here, on their site.  If you’ve never had the chance, take a look at their blog in general.  A lot of good authors over there.

Last time, I talked about how to prepare for a tough conversation with a coworker about having bad code.  This included understanding what not to say and creating a game plan of specific shortcomings to address and concrete outcomes you want from the conversation.  This time, I’m going to talk about how to actually engage with your teammate, who I’m calling “Bob.”


Having built your case ahead of time, it’s time to go have a chat with Bob. You’re calm, you’re rational, you have a legitimate argument, and you’re all set for a constructive dialog…but the lead in for the conversation threatens to be awkward. What I’d suggest doing to put the conversation in more natural terms is to ask for his help. “Hey Bob, I’m chasing a defect through the code and it led me to this method of yours. It’s a little hard to follow at first glance, so I was hoping maybe we could trace through it together?” Now you’re not coming over to preach to Bob about the evils of his code but rather to ask him to help you solve a problem.

Once you’re looking together at a screen and starting to dig in, one of the most effective ways I’ve found to surface code problems is through the Socratic Method. Instead of telling Bob that the method is too long, ask a series of questions. “Wow, good thing you’re here—this is a pretty long method with a lot going on. How long do you think it would take the average team member to understand it?” “Huh, wow, three or four hours seems like a pretty long time to spend trying to understand a method, don’t you think?” “What if it were smaller?”


Making proclamations of fact or strongly stating opinions tends to put people in a defensive posture. Asking questions, even leading ones, doesn’t get people’s hackles up as much. They tend to join you in problem-solving mode rather than argue against you in debate mode. Still, asking questions this way may not lead to the desired outcome, which is why you’ve done your homework. Switch gears from the questions to statements of your experience and how you feel. These are inarguable. Read More


The Aspiring Free Agent Survival Guide

It often feels as though I have no idea what I’m talking about.  I don’t say this in an attempt to garner sympathy and I’m not really suffering from impostor syndrome (at least not in this domain).  It’s more that running my own show, business-wise, has demanded of me a form of trial-by-fire, just-in-time learning.  It’s as though I moved to a small village in Germany, in spite of the fact that I don’t speak a lick of the language.

But in muddling my way through all of the details, large and small, I’ve actually managed to pick up a fair bit.  What I’d like to offer today is a preparedness guide of sorts.  The free agent’s life is an attractive one in a lot of ways, and I definitely recommend at least considering it.

I have no regrets, myself.  But I do acknowledge that it can seem like a pretty daunting leap, particularly if you’re well established in life and have responsibilities.  People telling you to take the plunge probably seem like friends swimming in an chilly lake, already used to the water, telling you that it’s fine.   I’m not that used to the water yet, though, so I can still appreciate your position.  It’s cold, but it’s refreshing.  And I’d like to offer some thoughts before I get too acclimated to the temperature.


So here are those thoughts.  These are things to be aware of if you contemplate, however idly, the free agent life. Read More


Building Superior Code … Is It Achievable?

Editorial Note: this post was originally written for the SmartBear blog.  You can read the original here, on their site.  As I’ve mentioned before, they have some good authors that I respect writing over there, so give it a look!

I’ve made stops in a lot of software development shops in my career, both as an employee and as a consultant. This has afforded me to the opportunity to learn that some questions and concerns are universal in the industry. One such question, asked by Fortune 500 CTOs and tiny startups alike, is “How do I make sure we have good code?” If that seems like it’d be hard to answer, rest assured that it definitely is. As much collective practice as the world has writing software, we’ve not managed to agree on the answer to a deceptively difficult question: what is good code?

David Starr wrote about this topic some time back in an excellent article entitled “Defining Code Quality.” It’s hard to opine about how a software group can have and maintain superior code quality when, as David points out, it’s difficult even to reach consensus on what it means to have superior code quality. So let’s talk about that first.


Read More


If You Promote Bad People, You Promote Bad Culture

Most of my cynicism toward the corporate world is safely directed into my new book these days, so there’s not a ton of spillage onto the blog.  But I’m going to make an exception today and talk about corporate culture.  To understand some of the terms I’m about to use, you can buy the book, if you’re so inclined, but you can also see an original definition here in this post.

I originally intended for my notes on this topic to make it into the book, but one of the main uplifting themes of the book is that I see programmers creating a professional working arrangement in which the corporate idealist doesn’t exist.  And since deliberate company culture, which I’ll refer to as “corporate religion,” is largely theater for idealists, spending a lot of time talking about it in the book would be somewhat superfluous (I do mention it, but not extensively).  But that’s not to say that corporate culture and religion don’t matter.  And, all these half-formed notes I have ought to go somewhere.  So, here they are.

Corporate culture is more or less defined by three things: what it takes to advance within the company, and what it takes to stay in the same role within the company, and what it takes to be walked out by the company.  Paintball outings and “bring your pet to work” don’t define or even describe company culture.  Perhaps more surprisingly, neither do things like company “mission,” “values,” and “principles.”  These things, which constitute corporate religion, are mainly orthogonal to culture.  Corporate religion consists of ceremonies, outreach activities, and the official canon (mission statements and expressions of “official values”).  But none of these things are culture, any more than the Ten Commandments, New Testament, and church bake sales are the ‘culture’ of a rural evangelical town in the USA.

If you look up the definition of the word culture, you’ll have to scroll all the way down to definition number 5 to get to an actual definition of corporate culture.

The behaviors and beliefs characteristic of a particular social, ethnic,or age group: the youth culture; the drug culture.

For our purposes here, we’re talking about the social group “people who have opted to work at this company.”  This means that we’re talking about behaviors and beliefs of employees when we talk about culture, and this is why culture and religion are disparate and sometimes orthogonal entities.  Corporate employees are forced to attend religious ceremonies and memorize the canon, but what they actually believe and do outside of structured activities is another matter altogether.  Plenty of people who show up to church every Sunday go forth immediately afterward and pound beer and gamble on football.

ArmchairQuarterback Read More