

Why I love solo programming (and why I hated working for Pivotal) - lladnar
http://mwilden.blogspot.com/2010/12/why-i-love-solo-programming-and-why-i.html

======
jasonkester
It's amazing what you can get accomplished with a team size of one.

For me it boils down to being able to fit the entire codebase into your head,
or at the very least have it all written in your own voice. Reading code and
packing it into your brain is the hardest part of programming, so having it
all written in your own familiar style makes it really easy to get back up to
speed on any bit of the project, even if you haven't visited it in a while.

Having even one other developer in there making changes can throw you out of
speed-reading mode and make you stop and figure out what the other guy was
thinking. That slows you down, and slowing down opens the door to distraction,
which leads to bad things.

It gets really good when you're working by yourself on a project for which
you're providing the direction. That removes the last roadblock from
productivity, the "boss requested change".

~~~
agentultra
As long as you document your style, I totally agree.

Nothing like it, if you're lucky enough to be blazing the trail.

The problem is for engineers who come in after you've left for greener
pastures. If you don't document your style, design decisions, and over-all
development process you're leaving behind a legacy... of miserable programmers
who will make up stories about how awful you must have been.

~~~
zeemonkee
Document, comment appropriately and write tests.

The engineer in question might be yourself, six months or a year later, and
you will have completely forgotten what you were doing back then.

------
defdac
My main argument against pair programming is that you never feel that you have
done anything significant. You can never be proud of a single line of code
since it's always made by someone else together with you. You can't take
credit for an invention/algorithm, and thusly never get the kick of true
craftsmanship.

You are always expendable and can be shoved around like an animal, especially
if you are a true team player that always nods and smile are "the best" to
pair up with.

In fact, the cowboy programmers still rule the programming session when you
pair up with them and they can easily take up most part of the day arguing
small uninteristing details until they get it their way making the software
theirs - not the team.

~~~
gruseom
Your second and third paragraphs have nothing to do with pair programming.
They indicate crappy management (shoving people around like animals) and a
crappy team (nitpicky argumentation) respectively.

Your first paragraph is more interesting. How does the fact that someone else
also contributed diminish pride in craftsmanship? Presumably it's the program
you're proud of, so if the program comes out better, isn't that reason to be
prouder? (If the program comes out worse, that's a problem.) Personally, it
would drive me crazy to work with people who were constantly worrying about
who contributed what. Software development is hard enough as it is. We can't
afford to waste valuable cycles on that kind of thing.

My experience has been that the solitary-genius fantasy is the calling card of
an immature programmer and is purely something to get over. (Just so it's
clear, I'm not drawing this conclusion about you, nor about the OP.)

It may be true that co-programming makes crappy teams worse, but it also makes
great teams better. As far as I'm concerned there's nothing better than a
small team of smart people hammering on a hard problem together. But there's
no question that it forces team dynamics into the open.

~~~
kayoone
Well since you should change your partner at least once a day, it is about
shoving around people ;)

~~~
gruseom
That's funny, dancers seem to able to do it without shoving each other.

------
agentultra
Pair programming just seems creepy. I can't even read when someone is looking
over my shoulder. You might as well be sticking your finger in my face just
far enough away so we're not touching. "Two sets of eyes are better than one,"
may work in the field when you're on stake out looking for the enemy, but in
programming I don't really see how that translates. Aren't bugs caught in the
code-review process?

Eliminating bugs up front is like asking human beings to be perfect.

In other words, good luck with that.

~~~
ams6110
I'm unable to pair program. I've tried it, and quit where I was working as a
result of their adoption of pair programming.

The best way I can describe it is that my "personal zone" for people not in my
immediate family is about arms-length. If you're close enough to touch me, I'm
uncomfortable. If we're sitting shoulder to shoulder at a keyboard, I'm so
uncomfortable that I can't work.

~~~
joevandyk
Get two keyboards then.

~~~
naz
Or therapy

------
fookyong
"There are a number of reasons: I get to work at a museum where I can go and
look at amazing fish, lizards, and butterflies every day"

This gave me goosebumps. If there was a way I could work this into my current
office environment, I'd be in heaven. I love looking at fish, reptiles,
insects etc...

I guess I could always buy a fish tank and plonk it down beside me.

------
ericHosick
I really liked what Mark Wilden had to say about Pair Programming. Personally,
I don't see how Pair Programming is as valuable as teams. I prefer looking at
people working on a project as a cross-functional team. This involves everyone
(the team, product owner, agile master and even sales).

From a team perspective, people can work together when they need to, or run
off to do research on their own and so on. It is an open experience where the
Team figures out on their own how to best work together.

In pair programming, developers are FORCED to work a specific way. And that
might not be the best way for that developer. I think Mark would have had a
much more enjoyable experience in a team centric environment where each person
is able to add to the team in the way they feel most comfortable.

Agile is about self managed cross-functional teams. As soon as upper
management forces a team to work in a specific way, that self managed aspect
disappears.

I do understand all of the advantages of paired programming but think you can
get those and a lot more focusing on teamwork instead of pair work.

My two cents.

~~~
danparsonson
Personally, I see pair programming as one of a set of tools that should be
deployed when necessary, rather than followed religiously. I've found it
useful when I'm trying to solve a difficult problem, or teach a new starter
about the company's code base. I also don't see it, as some other posters do,
as being about 'code ownership' or bragging rights - that seems absurd to me,
but perhaps I would feel differently if forced to program that way full-time.

Likewise TDD (famously: <http://www.infoq.com/news/2007/05/tdd-sudoku>),
Agile, etc. None of these things is a panacea, but they can be very effective
if thoughtfully applied.

------
codeglomeration
My problem with pair programming is that it doesn't allow me to get in the
mental state of "flow". The most productive state at least for me is when, for
a period of time, I'm so focused on the job at hand, that I'm not aware of my
surrounding. This is where my most productive work happens. You're completely
immersed and focused.

When pairing I never can get into that state because I keep getting
interrupted with "name that method x", "move that method before that method",
"refactor now". It really breaks my focus.

I find it useful when tracking obscure bugs, where you can bounce ideas off of
someone and basically nail the problem faster.

~~~
ollysb
I've found that when I'm in the backseat we can be most productive as a pair
if I spend my time trying to keep the driver in flow. When I first tried
pairing the programmer control freak in me made this very difficult. I was
effectively trying to write code by commanding someone else's hands to do what
I was thinking.

By focusing on keeping the driver in flow you begin to appreciate when it's
better to shut up and let them get on with writing the code, accepting that
people have different coding styles is important here. You can then use your
attention to either help out when they get stuck or maybe to tell them what
the next test should be.

------
tptacek
How does pair-programming mix with the dynamics of software consulting? It
seems like it would tend to make project scope (persons/weeks) larger for
clients --- something Hashrocket and Pivotal might not have a problem with.

~~~
steveklabnik
It's a quality differentiator. You may pay a bit more, but you're guaranteed
to get excellent code.

(This is what they'd say, at least. I like pairing, but I don't know if I'd be
comfortable making an absolutist statement like that.)

~~~
tptacek
That's what I'd say too. If hiring weren't our bottleneck, a story that made
us able to add 1-2 people to every project we ran would be... lucrative.
That's what set me off here.

(Our typical project scope is 2 people, 2 weeks; small projects 1x1/1x2,
bigger projects tend to add weeks and not people).

~~~
samd
Do you think you're producing quality software that meets your client's needs
now?

Do you think your clients will pay more than they currently are for quality
software that meets their needs?

If so, just start charging more. Make up whatever story you want about why
you're charging more.

If you don't think you're producing quality software that meets your client's
needs, but you think your clients would pay more for such software, then take
whatever steps necessary to make better software and then start charging more.

~~~
tptacek
That's how consulting pricing works in a vacuum. It's not how consulting
pricing works in the real world. Scope abuse is _absolutely_ an issue in
enterprise consulting.

~~~
samd
What's scope abuse? Sounds like when you add features to the project and
charge more without approval from your clients.

My language was vague, but I didn't mean to imply that you charge current
clients more, just charge new clients more.

It struck me as odd that you'd have to tie any price increase to an increase
in your costs. If Lexus wants to start charing more for their cars they don't
need to think of ways to use more steel. They just charge more and justify it
however their marketers think is best.

If you sell developer-hours instead of products why not just charge more per
developer-hour?

~~~
tptacek
Here's an example from my field, software security:

 _"Oh, you want this application tested? Well, first you want a 2-person,
2-week threat modeling project where we give you a report on your attack
surface, then you want a 3-person 4-week testing project, and if that turns
anything up, you'll absolutely want a 1-person 3-month deep code review."_

Here's an example from web design:

 _"Oh, you want a website for your new product? Well, first you'll want us to
study the market for a week. Then you'll want a wireframing project so we can
agree on what we're going to build; that's going to take 2 weeks. Then we'll
spend 2 weeks on design and get you some comps to look at; if you want
changes, we can do another week of that. Oh, you want HTML? Sure, we'll add on
3 weeks of coding."_

I'm sure that some witness to software consulting could provide you with a
story that fits this thread more directly.

Why not do X or why not do Y? Obviously, you're not a golfer. They do it to
make money, without alerting the client to the fact that they're simply
ratcheting up the dollar cost of the whole project.

~~~
samd
So scope abuse is when you sell each component of a project separately and
tell the client that they might not need some components even though every
component is required for a complete project?

I can see why it's unethical to deceive the client about what components they
will actually end up needing. I can see how you'd make money by luring clients
in with cheap prices up-front then once they are locked-in charging more for
the things they will inevitably need but didn't pay for already.

How does that relate to how you, as an ethical consultant, could raise your
prices without raising your costs.

Are you saying that the only way you could raise your prices without raising
your costs would be through scope abuse?

~~~
tptacek
No, the opposite; it's when you break a project into component parts, inflate
the effort required for each part, and convince the client they need to buy
all of them. "Rustproofing" is another term for it.

------
staunch
Are there really companies that do all pair programming? Does Pivotal?

~~~
tomstuart
There are many. For example:
[http://blog.obiefernandez.com/content/2008/08/the-
hashrocket...](http://blog.obiefernandez.com/content/2008/08/the-hashrocket-
way-pair-programming.html)

~~~
binbasti
When the question is about 100% pair programming I'd say there aren't that
many. Hashrocket is one of the few companies (I believe Pivotal is, too) where
it seems to be true, but most teams that I know are only pairing part of their
time.

------
spidaman
Having inherited code developed by lone wolves a few times, I have come to
believe that healthy code is like healthy DNA; it needs a variety of
contributors. Yes, it can be difficult at times. It can involve struggles but
I have no sympathy for the complaints about them, the struggles make you
stronger.

~~~
codeglomeration
Multiple contributors does not necessarily mean pair programming.

~~~
spidaman
Seems like the comments here on HN are talking about pair programming far more
than Mark's OP. The top line of his post was that he prefers to work alone,
that the arguments and social overhead of collaborative development have made
him unhappy. Pair programming isn't the only way (and often isn't the best
way) to collaborate; reading each other's commit messages and talking about
them is often sufficient.

And sufficiency is at the core of what makes software development fun and
productive: a sufficient number of eyes on the code, a sufficient issue
tracking app (and/or other collaborative apps) and sufficient amount of
automated test coverage is often all you need.

------
mcantor
I went back to read the year-old post he links to at the top, and it seems
like his issue wasn't with pair programming, but with pair programming with
poor communication skills and a crappy programmer partner.

------
rickmode
There more to life than money. It's thought provoking and inspiring to see
someone putting this into action.

