Curing “Shy Developer Syndrome”

One of the most common issues I have seen with experienced professional software developers who start to work on community software is a reluctance to engage with public communication channels like mailing lists. Understanding the reasons why, and helping your developers overcome their timidity, is key to creating a successful and fruitful relationship with the community you are working with.

In my experience, common reasons for this timidity are a lack of confidence in written English skills, or technical skills, nervousness related to public peer review, and seeing community interaction as “communication” or “marketing” (which are not part of their job), rather than just “getting stuff done” (which, of course, is part of their job).

Lack of confidence

Shy Kittens
Shy (Credits: maong@flickr, CC BY-SA)

For non-English speakers, this phenomenon is more prevalent, but in general, professional software developers have not developed writing skills during college, and often have not been required to learn them as part of their job. In addition, while most engineers appreciate good logic, they are never taught how to structure an argument. The end result is that when asked to write about their work, or to ask a question on a public forum, they hesitate.

One engineer I worked with would (eventually) write an email about a topic if I specifically asked him to, but would not react to responses or questions from community members. When I approached him, he would rationalise, say he hadn’t had time, or didn’t see the need to reply, or refer the questions to someone else. But as part of a pattern, I concluded that he was nervous about sending an email to a publicly archived mailing list. He was nervous about making a mistake, writing something he shouldn’t, overstepping some unwritten corporate policy, or felt uncomfortable expressing himself in writing. It doesn’t help that “bad netiquette” is often dealt with rather harshly, reinforcing the lack of confidence.

The only way to cure the problem is with baby steps.

A great first step is to get your engineers answering questions. One way I have found to help get this to happen is to publicly refer a question to an engineer on the mailing list, while affirming his expertise in the area. “Tommy knows the RLE algorithms inside out – Tommy, would you mind answering Franz’s question, please?”

This serves a triple purpose: an individual can easily ignore a question if it is addressed to a group, but it is a rare person who doesn’t answer when you ask them a question directly – it’s human nature; affirming your engineer’s skills makes him feel good about himself, and gives him more confidence; by identifying an individual engineer with a specific skillset inside your team, you are giving people outside your company a glimpse inside the walls – you are making your team human, a collection of individuals with different strengths and weaknesses, rather than an amorphous group – “the Acme Co developers”.

Another good step is to give a series of creative writing workshops to your developers. It is not enough to stand over people with a whip and ask them all to have a blog. First you need to get them in the habit of writing regularly. Since terse language, often in bullet form, is the norm for mailing lists, the goal is not to turn them all into novelists, writing perfectly crafted works of art. The goal is to get your team in the habit of writing.

Finally, you should train your engineers in basic netiquette and writing good email – there are lots of good resources out there, including Producing Open Source Software by Karl Fogel, The Open Source Way, the Linux Kernel Contributors Guide from the Linux Foundation, and ESR’s “How to ask questions the smart way“. Michael Meeks suggested to me that developers should treat writing email in a similar way to patches – when you generate a patch, typically the last thing you do before you send it is you check over it, to make sure nothing silly is included. Michael suggests that the same habit applied to email will identify any places where phrasing is awkward and ambiguous, resulting in better email.

Nervousness related to peer review

Tough crowd
Tough crowd (Credits: seedingchaos@flickr, CC by-sa)

It is one thing to have engineers answer questions when they have the knowledge to do so. It is another thing to have them submit their plans and patches to a community forum and have them exposed under the harsh light of peer review.

On more than one occasion, I have heard a hiring manager say that he didn’t have time to have a developer go through peer review of specs or patches – after all, he was hired because he was competent to do the job, and what are we paying him for if he’s going to be second-guessed by “the community”? After a first job or internship, peer review is more an exception than the rule for professional software developers (regrettably, I might add).

In community projects, peer review is expected – in fact, it is a best practice, one of the things that separates successful community projects from the crowd. Developers expect to hear about features before they are developed, and have an opportunity to suggest better ways the feature can be implemented. They expect new contributors to submit patches that they can review – it is the way a new contributor builds trust before getting the keys to the house. It is such a recommended practice that the only treatment I can suggest is that you should help your developers to get over their nervousness & embrace peer review, by making it the norm in your team.

The best way I know to get people used to peer review is to have a company policy against the “day one commit bit” – the practice of getting commit access to the project repository on the day you start in the company. For corporate-sponsored projects, new developers should go through the same review process for their work that contributors outside your company have to go through.

For corporate contributions to community projects, that means discouraging internal branches and a “gatekeeper” project structure, where one or two developers commit the work of others in the team. Developers should submit their work upstream at the same time it is being submitted internally. For those changes which only apply to your internal branch, you should create a probation period when patches are submitted via an internal mailing list, and subjected to the same peer review you would expect outside the company. This is a hard change for many organisations, but one which is necessary to transition your team
to successful community contributors.

Having new developers go through this review period is important for a number of reasons – the most important is that you are demonstrating that employees have the same burden to prove themselves in the project as non-employee contributors, and it ensures that new employees have a period where they familiarise themselves with project coding & communication conventions & norms, and when they also introduce themselves to the community at large.

Communication & marketing are not my job

Under the bed
Hiding (Credits: stuartpilbrow@flickr, CC BY-SA)

The developer I mentioned before shied away from the mailing list because he set a very high bar for himself on any public communications. In his mind, posting project plans to the mailing list was an announcement, and needed substantial preparation. In reality, most communities have a very high tolerance for things like spelling errors, incomplete plans (as long as they are marked as such) and other things which would be unacceptable in a press release or an official announcement. This is very definitely a case where Voltaire was correct: the perfect is the enemy of the good.

The developer was framing “sending an email to a mailing list” as “making an announcement”, something which fit in the “marketing” box in his head. One other developer I worked with once told me that he didn’t have time to send email to the mailing list because he had real work to do – “dealing with the community” was my job as community manager, as far as he was concerned.

Part of this issue comes from a general discomfort with written communications. But another part of it comes from the culture which is pervasive in most companies – only a small number of people get to talk for the company, and everyone else should just keep quiet. The authors of “The Cluetrain Manifesto” claimed that in the modern connected world, there is no such thing as a marketing department, that every interaction between an employee of your company and someone outside your company is an opportunity to win or lose reputation.

In free software development teams, this is even more true. There is no marketing department for project communications, and nor should there be. To be productive you need to talk to your peers, so the institutional barrier to external communications *must* disappear for people dealing in community projects.

It is all fine & well to say that this should be the case, but even if the organisation is clear about giving engineers a free hand to talk about their work, the engineers may impose limits on themselves, requiring proposals to be perfect before sending them on (which, of course, they never are). In fact, waiting until a proposal is finished is usually a lost opportunity, since by the time it is finished, there may be so much emotional investment in the proposal that making changes to it can be difficult. It is better to release a rough early draft, giving the author an opportunity to integrate early feedback.

The best way to prove to your team the benefits of “release early, release often” is to do so by example. As a team lead or manager, you can lead by publishing team plans publicly and early, and pointing out the benefits which result to your team. Breaking down this barrier will take time, but by making it clear that perfection is not expected, and by rewarding early release of information and encouraging feedback, your team will soon learn that participants outside your company are peers, not an audience.

Another useful technique is to ask your engineers to break tasks into smaller parts, so that even if they do hold off until the first part is up to a high standard, information is still getting out there more quickly, allowing feedback to inform later stages of the process.

However, another phenomenon is fighting against this desire for openness.

It is not uncommon for companies to want to keep their plans secret, so as to have a Big Reveal announcement effect at a major trade show. This can lead companies to ask their engineers to work internally on significant features for fear that the big surprise will be ruined otherwise. The alternative seems to be to announce a project when you start, rather than when you have something to show – but this can result in a long wait before products get to market, and impatience and bad press from the mainstream press.

I would argue that having engineers talk about design decisions & implementation details of significant features in a mailing list will not result in significant attention outside of your community – and when the press release and announcement comes, the community who knew it was coming will feel better about having been in on the secret from the beginning, rather than feeling worse because they have to deal with a big code drop which no one person can review.

Bashing bashfulness

The key lesson here is that you want your developers to feel a connection to people working outside the company. That requires people outside your company to feel a connection with them, too. By drawing the curtain on your team, its members and their skills & priorities, you are creating the circumstances for people to come to appreciate each other as peers, and to feel comfortable discussing features & patches on their merits. When you get to that point, you have already won – it’s impossible to be shy when you’re among friends.

Hi Dawn,

I plan to put this live tomorrow, and I'd really appreciate getting any
thoughts & feedback you might have. It's still missing a re-read or two
& some links and maybe a photo or two but I think the content isn't bad.

Thanks!
Dave.

One of the most common issues I have seen with experienced professional
software developers who start to work on community software is a
reluctance to engage with public communication fora like mailing lists.
Understanding the reasons why, and helping your developers overcome
their timidity, is key to creating a successful and fruitful
relationship with the community you are working with.

In my experience, common reasons for this timidity are a lack of
confidence in written English skills, or technical skills, nervousness
related to public peer review, and seeing community interaction as
"communication" or "marketing" (which are not part of their job), rather
than just "getting stuff done" (which, of course, is part of their job).
Lack of confidence

For non-English speakers, this phenomenon is more prevalent, but in
general, professional software developers have not developed writing
skills during college, and often have not been required to learn them as
part of their job. In addition, the art of rhetoric, structuring an
argument or thought to make it convincing, is not taught to engineers.
The end result is that when asked to write about their work, or to ask a
question on a public forum, they hesitate.

One engineer I worked with would (eventually) write an email about a
topic if I specifically asked him to, but would not react to responses
or questions from community members. When I approached him, he would
rationalise, say he hadn't had time, or didn't see the need to reply, or
refer the questions to someone else. But as part of a pattern, I
concluded that he was nervous about sending an email to a publicly
archived mailing list. He was nervous about making a mistake, writing
something he shouldn't, overstepping some unwritten corporate policy, or
felt uncomfortable expressing himself in writing. It doesn't help that
"bad nettiquette" is often dealt with rather harshly, reinforcing the
lack of confidence.

The only way to cure the problem is with baby steps.

A great first step is to get your engineers answering questions. One way
I have found to help get this to happen is to publicly refer a question
to an engineer on the mailing list, while affirming his expertise in the
area. "Tommy knows the RLE algorithms inside out - Tommy, would you mind
answering Franz's question, please?"

This serves a triple purpose: an individual can easily ignore a question
if it is addressed to a group, but it is a rare person who doesn't
answer when you ask them a question directly; affirming your engineer's
skills makes him feel good about himself, and gives him more confidence;
by identifying an individual engineer with a specific skillset inside
your team, you are giving people outside your company a glimpse inside
the walls - you are making your team human, a collection of individuals
with different strengths and weaknesses, rather than an amorphous group
- "the Acme Co developers".

Another good step is to give a series of creative writing workshops to
your developers. It is not enough to stand over people with a whip and
ask them all to have a blog. First you need to get them in the habit of
writing regularly.

Finally,you should train your engineers in basic netiquette - there are
lots of good resources out there, including Producing Open Source
Software by Karl Fogel, The Open Source Way, the Linux Kernel
Contributors Guide from the Linux Foundation, and ESR's "Asking Smart
Questions".
Nervousness related to peer review

It is one thing to have engineers answer questions when they have the
knowledge to do so. It is another thing to have them submit their plans
and patches to a community forum and have them exposed under the harsh
light of peer review.

On more than one occasion, I have heard a hiring manager say that he
didn't have time to have a developer go through peer review of specs or
patches - after all, he was hired because he was competent to do the
job, and what are we paying him for if he's going to be second-guessed
by "the community"? After a first job or internship, peer review is more
an exception than the rule for professional software developers
(regrettably, I might add).

In community projects, peer review is expected - in fact, it is a best
practice, one of the things that separates successful community projects
from the crowd. Developers expect to hear about features before they are
developed, and have an opportunity to suggest better ways the feature
can be implemented. They expect new contributors to submit patches that
they can review - it is the way a new contributor builds trust before
getting the keys to the house. It is such a recommended practice that
the only treatment I can suggest is that you should help your developers
to get over their nervousness & embrace peer review, by making it the
norm in your team.

The best way I know to get people used to peer review is to have a
company policy against the "day one commit bit" - the practice of
getting commit access to the project repository on the day you start in
the company. For corporate-sponsored projects, new developers should go
through the same review process for their work that contributors outside
your company have to go through.

For corporate contributions to community projects, that means
discouraging internal branches and a "gatekeeper" project structure,
where one or two developers commit the work of others in the team.
Developers should submit their work upstream at the same time it is
being submitted internally. For those changes which only apply to your
internal branch, you should create a probation period when patches are
submitted via an internal mailing list, and subjected to the same peer
review you would expect outside the company. This is a hard change for
many organisations, but one which is necessary to transition your team
to successful community contributors.

Having new developers go through this review period is important for a
number of reasons - the most important is that you are demonstrating
that employees have the same burden to prove themselves in the project
as non-employee contributors, and it ensures that new employees have a
period where they familiarise themselves with project coding &
communication conventions & norms, and when they also introduce
themselves to the community at large.
Communication & marketing is not my job

The developer I mentioned before shied away from the mailing list
because he set a very high bar for himself on any public communications.
In his mind, posting project plans to the mailing list was an
announcement, and needed substantial preparation. In reality, community
fora have a very high tolerance for things like spelling errors,
incomplete plans (as long as they are marked as such) and other things
which would be unacceptable in a press release or an official announcement.

The developer was framing "sending an email to a mailing list" as
"making an announcement", something which fit in the "marketing" box in
his head. One other developer I worked with once told me that he didn't
have time to send email to the mailing list because he had real work to
do - "dealing with the community" was my job as far as he was concerned.

Part of this issue comes from a general discomfort with written
communications. But another part of it comes from the culture which is
pervasive in most companies - only a small number of people get to talk
for the company, and everyone else should just keep quiet. The authors
of "The Cluetrain Manifesto" claimed that in the modern connected world,
there is no such thing as a marketing department, that every interaction
between an employee of your company and someone outside your company is
an opportunity to win or lose reputation.

In free software development teams, this is even more true. There is no
marketing department for project communications, and nor should there
be. To be productive you need to talk to your peers, so the
institutional barrier to external communications *must* disappear for
people dealing in community projects.

It is all fine & well to say that this should be the case, but even if
the organisation is clear about giving engineers a free hand to talk
about their work, the engineers may impose limits on themselves,
requiring proposals to be perfect before sending them on (which, of
course, they never are). In fact, waiting until a proposal is finished
is usually a lost opportunity, since by the time it is finished, there
may be so much emotional investment in the proposal that making changes
to it can be difficult. It is better to release a rough early draft,
giving the author an opportunity to integrate early feedback.

The best way to prove to your team the benefits of "release early,
release often" is to do so by example. As a team lead or manager, you
can lead by publishing team plans publicly and early, and pointing out
the benefits which result to your team. Breaking down this barrier will
take time, but by making it clear that perfection is not expected, and
by rewarding early release of information and encouraging feedback, your
team will soon learn that participants outside your company are peers,
not an audience.

It is not uncommon for companies to want to keep their plans secret, so
as to have a Big Show announcement effect. This can lead companies to
ask their engineers to work internally on significant features for fear
that the big surprise will be ruined otherwise. I would argue that
having engineers talk about design decisions & implementation details of
significant features in a mailing list will not result in significant
attention outside of your community - and when the press release and
announcement comes, the community who knew it was coming will feel
better about having been in on the secret from the beginning, rather
than feeling worse because they have to deal with a big code drop which
no one person can review.
Bashing bashfulness

The key lesson here is that you want your developers to feel a
connection to people working outside the company. That requires people
outside your company to feel a connection with them, too. By drawing the
curtain on your team, its members and their skills & priorities, you are
creating the circumstances for people to come to appreciate each other
as peers, and to feel comfortable discussing features & patches on their
merits. When you get to that point, you have already won - it's
impossible to be shy when you're among friends.

-- maemo.org docsmaster Email: dneary@maemo.org Jabber: bolsh@jabber.org

7 thoughts on “Curing “Shy Developer Syndrome”

  1. Very well said, David! (And I’d think so even without the name check, but thanks for that.)

    One point:

    You wrote: “I would argue that having engineers talk about design decisions & implementation details of significant features in a mailing list will not result in significant attention outside of your community – and when the press release and announcement comes, the community who knew it was coming will feel better about having been in on the secret from the beginning, rather than feeling worse because they have to deal with a big code drop which no one person can review.”

    I think you’re right in most cases, but high-profile software projects often have journalists following even the development lists (or sometimes following the developer’s blogs / planet feeds / etc, which can amount to the same thing). When an interesting new feature is being discussed, a tech journalist/blogger will sometimes write about it in a place that draws a lot of attention. The company or companies sponsoring the development may be leery of that, if they wanted a Big Reveal.

    Maybe the safest thing to say is that Big Reveals are incompatible with open communities. You can make surprise marketing splashes if you have the kind of government-level secrecy capabilities of Apple, Inc (well, lately they’re doing better than most governments, *cough* wikileaks *cough*, but I digress). But if you’re participating in an open development community, then you just can’t count on full marketing control… or rather, you have to do a different kind of marketing, perhaps? I’d be interested to know your thoughts.

  2. Software development was only a minor subject for me, but we had to write reports, so I’m not sure about a lack of confidence in writing skills. I think the hesitation is more like a lack of confidence in public speaking, in the ability to defend one’s viewpoint if questioned by hostile developers.

    Publicly referring to individuals on a mailing list is a double-edged sword. It might bolster the confidence of the named individual, but it also reduces the confidence of other people who might have answered the question. In general, I feel it’s best not to personalise comments on-list. Some e-democracy groups require all messages to be addressed to a (fictional or powerless) chair or editor, similar to the letters pages of The Times.

    I think the other sections are more broadly correct, but I ran out of time to consider it all in detail.

    1. Hi,

      I think you allude (unsuspectingly) to part of the problem. Many software developers treat “sending an email to the mailing list” with “writing a report”, clearly two very different things – one takes days/weeks and a lot of work, the other should only take somewhere between 1-15 minutes of your time in 95% of cases.

      I agree with you that you need to leave space for recent newcomers to answer questions (in fact, this was one of my key take-away points in the “Community Anti-patterns” talk I gave at the MeeGo Conference recently), but in this particular case, the manager is stepping in when a question hasn’t been answered in a timely manner (or when there is a track record of questions not being answered). In this situation, rather than scaring people away, you are on the contrary creating activity – no-one likes hanging out with the tumbleweeds. Of course, different projects have different dynamics and needs. That particular piece of advice is best suited to projects with a primary company contributing and maintaining, looking to grow the community. I disagree with you on personalising comments. In my experience, nothing is less effective at getting a specific individual involved than asking a general question to a list.

      Thanks for your feedback!
      Dave.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>