Solo coding can be done so-as not to be "in a corner" and produce high quality code.



> This thing was not done in a corner

[Acts 26:26](https://www.lds.org/scriptures/nt/acts/26.26?lang=eng#26)

## How We Describe Things

How we describe things exposes what we think about them.  Often I have heard solo coding as "in a corner", as "coming out of a dark room after hours of coding", as "anti social", or as "magical", "arcane", or "unknowable".

Is that how it is?  Perhaps sometimes.  Is that how it _inherently_ is?  I don't think so.

## Preferences

We choose our practices based on good-faith efforts and heuristics gained from past experience.  If we've had good experiences in something, we'll gravitate towards it and try it again.

If we want to code in a social setting, we should.  We should pair.  We should mob.  Whatever flavor, we should find a way that works for us.

So should others.  We don't have to yuck their yum.

## Desirable Qualities

When we choose to code in a certain way, we're trying to optimize for qualities we desire.  These qualities might relate to the experience we desire in coding. These qualities might relate to the product we desire to create.  Experiential qualities are important.  For example, they have be large factors in why many of us have chosen to work certain jobs.

But here, I'll focus solely on product-related qualities that we desire more of when we choose to code a certain way.

## Code Quality

It is stated very often that code quality is higher when it is the product of many viewpoints because it can be verified by others and is the summation of the best thoughts of the best minds at hand.  There is truth here -- a _lot_ of it.  I still think we think this and repeat this too blanketly sometimes.  There seem to be a growing number of people within my knowledge that feel their best work is created in a solo environment.  Can this be so?

Even so, I believe a solo coder can leverage the potential wisdom of crowds and doesn't have to be in a social setting at the time code is typed into the terminal in order to do so.

## Unsoloing

Yes, if you work at a company or on a team, you can't be an island.  Still again, the only solution is not social coding.

Here are some examples on how we can help each other produce high quality code.

We can do code reviews.  We can see the code, run it, and ask questions about it.  We can challenge the code and ideas upon which it is written.  If we desire stricter parameters, I've seen code review gatekeeping processes work out well.  In asking for reviews, we can go beyond our normal coding partners, asking people from greater circles with relevant expertise.

We can see code in the open.  There is so much code that is open source -- within and without our companies -- that we use and can scrutinize.  People can see our product and offer increasingly better viewpoints and implementations on how we might increase quality.  We can offer our help to others.

We can design review.  We can counsel with people all the time in an effort to start in better directions, even before code is written.  Sharing a vision in these stages is so much less expensive that later after code exists.  This can be as simple as asking a question in chat or drawing at a whiteboard with someone and be effective.

We can ask for mentoring.  We often need others' guidance and help to help us navigate difficult portions of code or ideas.  We should be humble and ask for help.  We should admit when we don't know something.

We can use the Internet.  Has their ever been a larger body of knowledge collected?  Have you ever pair programmed with Stack Overflow?  You can expand beyond the heads in the room by querying the heads of all those published on the Internet.

So if a coder does these kind of things, can we even consider him a "solo" coder anyway?

At the very least, coding -- even solo coding -- isn't necessarily done in the corner.  It has the same inherent potential for quality as coding done in tandem with others at the time of typing.

What do you think?  Are solo coding and code quality compatible, mutually exclusive, or something else?

Solo coding can be done so-as not to be "in a corner" and produce high quality code.

Not Done in a Corner

Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep developer knowledge separate.  Sometimes these barriers are referred to as silos.  We can create better teams and products for our organizations if we can break down these silos -- or if particularly scrappy, blow them up.



<div style="width:425px" id="__ss_5324753"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/rockycode/breaking-down-knowledge-silos" title="Breaking Down Knowledge Silos">Breaking Down Knowledge Silos</a></strong><object id="__sse5324753" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=breakingdownknowledgesilos-100930104326-phpapp02&rel=0&stripped_title=breaking-down-knowledge-silos&userName=rockycode" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed name="__sse5324753" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=breakingdownknowledgesilos-100930104326-phpapp02&rel=0&stripped_title=breaking-down-knowledge-silos&userName=rockycode" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/rockycode">rockycode</a>.</div></div>

This presentation was given to our group of developers at an offsite.  I worked with many of these developers on relatively closely related projects.  The catalyst for this presentation was my observation that team dynamics on my current project plus at least the previous four had somehow or another encourage some amount of knowledge siloing.  This fact has at various times become inconvenient for me personally and by extension my current and previous projects.  

<h2>Some silos from my past</h2>

<ul>
<li>I knew something that no one else knew (at least at one point) and was approached about it months later and asked to explain it to a new developer.  There was no one left close to the project to help this person come up to speed.  If I had imparted this knowledge in closer time proximity to the original construction of the code, the likelihood of a maintenance developer sharing my knowledge would possibly be higher.</li>

<li>I came onto a project that was about 3/4 complete.  I was tasked to implement various new features that spanned the application.  For specific portions of the app, there were often very specific, singular persons that I sought out in order to get a feel for the code more quickly.  If these people were unavailable or over-burdened, as was often the case, I was left to do the detective work that necessarily was more inefficient and took more time.  Perhaps if more people were educated on various portions of the app, more fellow developers would have sufficient knowledge to give assistance.</li>

<li>A developer on a project that I recently rolled off of was on an extended vacation.  He had worked on a complicated portion of the app that I had been less-than-eager to touch (and possible trigger massive explosions).  While he was gone, there was an issue and I was asked to consult on the solution.  My inexperience with this portion of the software was weighed with what turned out to be a low level of urgency, and we decided to wait until the original developer returned to face this issue.  Perhaps if I had dug into this code earlier in the presence of the original developer, the issue would have been dispatched more quickly when it arose amongst limited resources.</li>

<li>I recently completed the point-0 version release of a software project.  This project was on an aggressive schedule that the developers responded to by each scrambling to get features of the software complete, often in isolation from other developers.  The result ended up to be ok.  The product shipped complete, but the innards of the software were often inconsistent in their style, how they flowed and handled problems, and the DRY principle was broken several times through recreated business logic.  Perhaps if the developers had spent more time in communication about their solutions to separate features, a more consistent, stable, safe, non-repetitive product would have been created.</li>

<li>I was recently on a project where, and I've done this several times myself, one person had (fantastically) tackled numerous hard portions of the development by himself.  These pieces were so complicated, in fact, that they were bug-prone.  On several occasions, when there were problems with these modules, this one developer was always called upon, sometimes late at night or on the weekend, to resolve them.  This led to a burn(-ing, then -nt out) developer.  Perhaps if more fellow developers had been pulled in to assist with those modules, more people would have been able to share the load troubleshooting more easily.</li>
</ul>

Well, these are some of my experiences.  I feel that knowledge siloing probably negatively affected each of these scenarios in some degree.  I feel that each challenge was, in the end, overcome.  I think that speaks to the caliber of individual developers that I've worked with being able to adapt to their ever-changing, imperfect environments that they are asked to work in.  At the same time, I feel that we can often make situations a little easier on ourselves if we're introspective enough to ask the right questions to help guide ourselves out of knowledge silos.  Here are some potentials:

<h2>How to choose your pair</h2>

<ul>
<li>What don't I know about?</li>
<li>What's high risk?</li>
<li>What's highest priority?</li>
<li>What's the hardest/easiest? Why?</li>
<li>What has the least/most bugs? Why?</li>
<li>What's behind/ahead of schedule?  Why?</li>
</ul>

Once we ask those questions, let's use the answers to help us:

<h2>Silos in our future</h2>

<ul>
<li>Consider how you can open knowledge silos you've been privy to</li>
<li>Consider what silos you don't but should probably know something about</li>
<li>Consider how you'll influence the organization to form fewer silos</li>
</ul>

Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep develope

pair-programming