Not Done in a Corner
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
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?