
A tale of two programmers - vijaydev
http://jacquesmattheij.com/A+tale+of+two+programmers
======
giberson
I think Chris and Steve mirror the two phases of problem solving. The first
phase, the exciting creative process where the problem is a challenge. The
second phase, is when the creativity is done, and now its simply a matter of
following through the implementation.

I experienced these phases a lot in school, especially in math classes. I was
never a homework doer. I'd start, eagerly wanting to do it, but after the
first couple of problems I couldn't motivate myself to do the rest. Because I
just could not stand the repetition--the same formula over and over with
different values. I'd usually do the first problem in a section and call it
quits. Then rely on my test grades to pass the classes with a C average
typically.

I was afraid that trait of mine would affect me professionally in my
programming career, and it indeed started to. Some projects despite starting
out at race pace would quickly come to a slow down as I labored to finish up
tail end of the project.

However, luckily I ended up working with a colleague was a great compliment to
me. He was able to and enjoyed doing the implementation tasks--the portion of
coding that is done when you have the solution and its just a matter of
putting the pieces together. However, his shortcoming was the creative
process.

Together, we make an outstanding team.

Maybe we could officially categorize these two phases into new job positions.
Problem Solvers and Solution Implementors.

~~~
arctangent
This is completely true.

At a certain stage in your career as a "developer" you realise that your time
is better spent sketching out solutions for others to follow than it is in
seeing through all the work yourself.

Some people naturally gravitate towards seeing the whole solution (at the cost
of being impatient about the details) and some people gravitate towards
diligent completion of defined goals.

Projects tend to need both kinds of people.

~~~
tomkarlo
Disagree, somewhat.

Craftsmanship requires both broad vision and attention to detail during
execution. It's challenging, but there's no reason a someone can't do both,
even if they prefer one over the other. There are lots of great "one man band"
developers out there who clearly have to wear both hats. To me, this smells
like folks wanting to shirk their responsibility for the part of the job they
don't like.

~~~
usedtolurk
I agree it's important to practise a bit of both for personal development. But
why would you continually fight against the grain if you could be playing to
your natural strengths and delivering more value?

~~~
tomkarlo
Because every kind of work has components that you find pleasant and ones you
don't like as much. It's not realistic to just say "I'll try to avoid the part
I don't like", especially when there's usually some parts that _nobody_ likes.

~~~
MercuryCreative
Yes, that's very true. I believe the point here though is to play to your
strengths for the good of the project. If someone else is better at the detail
work then let them do it. The project as a whole will be better produced and
that's your end goal. We're not here to build character by completing
unwelcome tasks, we're here to build products.

------
ekidd
I once worked with two great interns. By themselves, they were better than the
average intern. But sit them down side-by-side at one terminal, and give them
a tiny amount of design advice, and they morphed into a good senior
programmer. They could follow a tricky refactoring through 20-year-old C++
code with only a vague roadmap, and turn a vile mess into nicely organized
code.

It only goes to show just how good Microsoft's recruiting used to be—we lost
the pair of them to Microsoft the next summer, just as we did the rest of our
very best interns.

------
donw
I'm going to be amazingly honest and come out as a Steve -- I love building up
a new project, or iterating over a prototype until it's actually something
that people can use, and then afterwards suffer from a critical deficiency of
steam/gumption/moxie.

It's like running flat-out into a brick wall, minus the reconstructive
surgery. At moxie-zero time, I can do anything else, but need to take a break
from the codebase.

Timeline seems to be at somewhere between thirty days and three months, and
I'm really curious to hear from other Steves what your personal run-time is.

Now, this is hell on a team, and double hell on a company that needs to ship
on a regular basis, but I've come up with a few coping techniques that really
seem to help:

1\. Comment copiously the _how_ and _why_ things are written (people can
usually figure out the _what_ on their own). I know that my code is going to
get handed off, and I don't want to inspire my successor to commit heinous
acts of violence.

2\. Build small, nearly independent projects that function as building-blocks
for bigger systems; e.g., build service-oriented architectures. You often
finish well before the steam runs out, and can then build something
technically 'new' on top of what you just finished.

3\. Develop another valuable skill that allows you to contribute even when
you're not writing code.

~~~
khafra
One reason I'm not an entrepreneur is that I haven't found a reliable,
enjoyable way to get past the precipitous drop in enthusiasm and energy that
occurs around 3 days to 1 week into a project, for me.

~~~
Stormbringer
Don't underestimate the value of having a partner-in-crime with a different
skill set than your own, e.g. Woz and Jobs, Allen and Gates.

There can be a tremendous synergy when you find someone you can work well
with, who has a different perspective than your own, who you still like even
while they are nagging you to finish feature X so that you can finally ship
product Y so as to be paid dollars Z.

------
Stormbringer
At my (failed) software company I tried this. I had two really talented guys
with complimentary skillsets. Moreover, like the article, one was a starter
and the other a finisher. Like in the article they had been long time friends.

The thing I could _not_ get them to do, was that I couldn't get the starter to
check in the code to the version control system so that the finisher could
pick it up and run with it. Whenever I pushed the issue, he would always fly
into a panic, and then seized by some mad other-worldy inspiration, delete all
his code and start over _only much better this time_.

Due to all sorts of psychological quirks that I suspect are more common in
programmers than the general population, the kind of synergy described in the
article is rarer than you might think.

~~~
fhars
The trick is called a version control system.

------
arjunnarayan
I found my pair-programing-soulmate.

I'm currently in grad school, and he's doing something else (following some
non-programming related time-limited dreams). But I do know that the day I
start a company, he's the first one on the hiring list. But our relationship
isn't like the Steve-Chris one in the link. I suppose every relationship is
different that way --- ours is more equal. I think it's more a discipline
thing. I've never found anybody else who was willing to document and unit test
as well, and was willing to think before coding. I've often considered the
possibility that I'm just really anally retentive and he's the only one
willing to tolerate those flaws. Where do you draw the line?

It really is a productivity multiplier (for both of us): and the biggest scare
I have is that time passes by and one of us gets locked into a career path
that excludes the other. It would be sad. I have no idea how to fix this
situation other than maintaining a somewhat decent rapport given the distance.

It's almost like working on a long distance relationship...

~~~
BobKabob
I'll tell you what NOT to do. Don't think of him as the first one on the
hiring list!

I had my pair programming soulmate as early as age 15, back in the very early
PC days (mid-to-late 70's). We ended up working together at a small software
company, and having a blast.

We went to different schools. I graduated before he did. I got a great job at
a fast-growing silicon valley computer company. The next year, I helped him
get hired. He even reported to me for a while, at what is today one of the
largest computer companies.

We always talked about starting our own business. Finally, after lengthy
successful corporate careers, we got a 3rd partner who was willing to quit to
launch a business, provided that "Chris and Steve" (me and my programming
soulmate) would join him, the other guy first, me second.

Unfortunately, wives and families got involved, complicating things. The other
guy never wanted to quit his safe and secure job at the large computer
company, and so he balked at his earlier agreement to be the first of us to
quit. So the 3rd partner turned to me in desperation, even though I was not
his first choice, and it wasn't what we had previously signed as an agreement.

I quit the cushy corporate job (I had the better of the two jobs), and helped
to launch the small business. We were making good money. Then the other guy
FINALLY joined us. Unfortunately, we never made any profits while he was
employed fulltime. There was too much stress and too many family issues.
Finally, the soulmate quit, taking one of our largest customers with him, and
tried to stiff the bank on the business loan, on the way out the door. He
didn't honor many of the signed papers, including shareholder buyback
agreements, loan documents, etc. Instead, through his lawyer, he said "I hope
the bank sues us", because he had falsified his asset statement to the bank,
claiming that he had no assets. He figured he was safe, and they'd come after
me.

The loan holder ended up suing him, and winning by default. Funny thing, when
you sign those loan documents, you sign away your rights to fight in court,
and you agree that the loan holder can sue and win without you even knowing
it. The loan holder aimed directly at him, not at me or the 3rd partner. He
got sued and lost.

Naturally, this pissed him off, but it was his own bad legal advice that got
him into the mess. He was unwilling to come to the table to negotiate a fair
settlement, and wanted to hold onto company ownership, but was not willing to
live up to company debt. Sorry, pal, it doesn't work that way.

So, I move on. The company never had a profitable year with him as a fulltime
employee, and never had a loss with him out. The business is doing fairly well
after 15 years. We don't speak to this day. Best friends from childhood and
programming soulmates, but it's NOT a way to start a business.

So forget about the idea that he's the first person that you'll hire. Bad
idea.

~~~
PakG1
I've admittedly heard more stories like this than success stories. But even
so, it seems to me that it just comes down to the fact that you often don't
know people as well as you think they do, you don't predict how they would
change as well as you think they would, and you don't know yourself as well as
you think you do. If not for that information asymmetry, I'd say that there
would be no reason to not go forward with something like that. After all,
there are success stories on that front too.

~~~
BobKabob
Very true.

And in fact, all things considered, I believe we are both doing pretty well
now, separately. So you could say that all's well that ends well.

My business with the 3rd partner has lasted far longer than the typical small
business. And I think my programming soulmate is doing OK. The latest
information I can find on him is that he left his next job (who was formerly a
large customer of ours), and I can also see that he subsequently sued them for
back pay. Those legal documents listed that he was owed over $100K from the
company he left (and there are certain other indications that he was
terminated abruptly).

If you end up in legal battles with your last two employers, that's not a good
sign. This supports your theory that I didn't know him as well as I thought I
did. On the other hand, I'm sure his side of the story is that I was a huge
ass in the process, but I honestly tried to live up to every agreement that we
made. Still, I carry guilt to this day.

I must have said to my lawyer and 3rd partner at least 100 times that I want
what's fair to my family, but no more than what's fair. I could see we were
going to be saddled with huge debt payments, and I sure as heck wasn't going
to put that burden on my family, to the benefit of the guy who was stiffing
us!

I know my soulmate kept saying over and over that he just wanted out. I
understand that the pressures were tremendous from his wife. All he had to do
was negotiate in good faith, and he would have saved himself about $100K in
settlement and legal bills.

If I didn't value friendships, I'd say "all's well that ends well". But
really, it caused a TON of stress and pain. My relationship with my current
business partner is exceptional, even though he's not a programmer-genius.
He's a sharp guy, but above all else, he's highly ethical.

Bottom line, be highly ethical, even if it costs you. And extreme talent
without ethics is not worth partnering with.

~~~
PakG1
1000x ethics. They're very underrated. Most people will be like, "Hey, I'm
ethical, nothing to worry about!" But most people will not have their ethics
put to the test until they're in a really tough situation, so talk is cheap.

------
guelo
I don't buy it. Maybe it worked for this specific pair, but normally pure
Steves are worthless. The creative part of programming is where all the fun
is, who would want to be the Chris? You can get yourself some Chris's if
you're in a position of authority, but no talented ambitious programmer would
want to be stuck in a Chris position, creating is where it's at!

The pure Steves of the world, are the unprofessional "rock star" programmers
that quickly whip up an unmaintainable undocumented solution and are gone by
the time their mess starts really hurting the project.

As professionals we have the obligation of being both Steve and Chris.

~~~
imajes
You forget, some people (not usually I) find a lot of pleasure in finding
order in code. simplifying, refactoring, reducing, straightening out --
whatever you want to call it, it's not a chore for all, and can be very
satisfying.

I've met plenty of programmers, however, who really dread the 'empty file'
problem and struggle to know how to solve the meta problem -- but when tasked
to fine tune perform a code path or refactor methods in a class, they are able
to excel and do awesome work.

~~~
grncdr
It could just be that I'm indiscriminate, but I love creating a new system out
of nothing, and I love cleaning up gnarly old legacy code.

The only programming problems I find demoralizing, (and the ones I think the
grandparent was equating with "Chris" work) are updates or bugfixes in gnarly
old legacy code, without having time allocated to give it the refactoring it
needs. It's the feeling that the code in question is never going to be
important enough to fix properly, and your name is going to be in the logs
adding those two lines in the middle of a 400 line function.

------
agentultra
This happens a lot in the art production world actually. You end up with
character designers and finishers. I think it's possible to learn to be both
(or at least enough of one to complement the other). But it's certainly most
efficient to play up your strengths if you have the man-power to complement
your short-comings.

~~~
technomancy
Walt and Roy Disney come to mind.

------
KaeseEs
Can I coin the term 'brogrammers' for this sort of code-soulmate, whole-far-
greater-than-sum-of-parts partnership?

~~~
leif
no

~~~
avdempsey
How about programhers?

------
Tycho
This reminds me of something I was pondering today. As we know, talent drain
can be a big problem for technology companies. The programmers in the original
team leave, after the IPO maybe, and eventually things just aint what they
were. How to solve this?

Well, in general terms, give the programmers a long-term _investment_ in the
company. But that happens already, right? Stay-on bonuses in the form of stock
in the company. People still leave. What about a rather different type of
investment...

How about, you get the person who's leaving to recruit their replacement, and
then you give the leaver some sort of derivitive based on the replacement's
performance (or the company's performance thereafter). They'll be motivated to
find someone who can genuinely do the job, _and_ to coach them.

I got the idea thinking about soccer contracts. Sometimes clubs put in a
'sell-on' clause so the NEXT time the player moves, the original club gets a
slice of the transfer fee. Just different ways of handling transfers and
contracts basically. Imagine a transfer market for developers.

~~~
Torn
There's currently no standard/expectation to do this, so I doubt departing
coders would spend the effort and would rather just move on.

I don't think the domains of coders and recruitment/hr would really overlap in
that way, I can't imagine having to - as well as continue my current job, get
ready for the move to the new company, knowledge transfer, etc - also try and
recruit a replacement.

~~~
Tycho
True enough, but conversely if such a system were already the norm, people
might say 'I can't imagine just leaving a job and severing all ties, not
caring who replaces me, keeping no stake in the future of the
workplace/company I put so much heart&soul into.'

------
pmjordan
Very cool. Curiously, in my projects past and present I can either recognise
Chris or Steve in me, depending on the project. There are projects where it
feels like I'm running into a wall to build even a prototype, but once it's
built (either with help from others or by raw determination) it's clear
sailing to tidy it up and extend it. Yet other functioning prototypes that
were built in a frenzy have languished in this embryonic state for a while
until I figured out how to structure them for production.

I _think_ it's related to whether the project lends itself to top-down or
bottom-up design. At some point I seem to hit a barrier in the middle. This
usually only happens on "hard" projects and even then I inevitably overcome it
eventually, sometimes with pair programming, but it's damn annoying. Having
Steve or Chris around would be damn handy.

------
s00pcan
Is there a reason every recent post on this guy's blog has been posted on HN?

~~~
sophacles
He's a guy who contributed greatly to the HN community. His blog posts have
consistently been featured on HN, but even more so lately since he "retired"
from HN and isn't doing nearly as much posting here.

Further, there are other people who's every bog post makes front page here.
It's how we roll. Stick around for a couple months, and you'll see it. There
are also cycles and waves of people, topics, etc.

~~~
radu_floricica
Maybe he's featured more lately because his break from HN gives him time and
energy to write better? Just saying...

~~~
DeusExMachina
Or maybe just write more. All his writings have always been excellent, in my
opinion (and also his comments here on HN).

------
zmitri
Now imagine taking those two out of the corporate environment and putting them
into a start up, working as co-founders. This is what I dream about...

~~~
BrandonM
Sweet! Now they can handle sales and invoicing and supply and logistics and
accounting and all the other things that neither of them knows anything about.

Contrary to popular opinion around here, there are good "corporate
environments," where the term is actually used to mean "companies big enough
to have several full-time non-founder employees." After all, some people just
want to code.

~~~
zmitri
My dream! Obviously not everyone can do it.

------
radu_floricica
I started as Steve (don't we all?) but I've recently been complimented on my
patience. Wonder if it comes from years of maintaining my own code, but I've
really grown to appreciate infrastructure work and making code aesthetically
pleasing.

------
alxp
I had this kind of relationship with a designer / photographer I worked on a
side project with a couple of years back. He'd have no idea how to implement
something if it required more than just hacking on already-existing code, but
he had a great eye for detail and was excellent at not letting something sit
unfinished. So I would talk out with him the various features we could add,
then we'd agree on what to pursue, I'd get it up and running and he'd clean up
parts, file bugs and be a good partner for getting the full widget out the
door. At my day job I'm usually the one re-architecting something-or-other on
the back end when I know I should be doing more mundane things more of the
time.

~~~
Isamu
Yes. I had a great working relationship with a UX designer. This is how it is
supposed to work - a give and take, and complementing each other's strengths.

Alan Cooper would have you think that the hacker cannot overrule the designer,
but in a respectful relationship with equals it can work well.

Alas I didn't realize how good I had it until it was over.

Ok, this is starting to sound like a tv drama.

------
va1en0k
Very cute.

By the way, I've seen several "programmers dating services" with a purpose of
finding mutual mentors

~~~
evanlh
Could you link to some? I was thinking about this just the other day, how I'd
like to have someone to work through exercises like CodeKata with. Either
mentoring or even just peer accountability would be really interesting.
Thanks!

~~~
va1en0k
sorry, haven't looked there for a while

everymentor.com maybe?

------
woan
I really enjoyed this story. I worked with a brilliant developer for a couple
years batting cleanup. I learned a lot and really enjoyed it though I was a
lead developer/architect before and after the experience. We just got tons
done...

------
alinajaf
I think every developer has elements of Steve/Chris in them. Sometimes you
want to punch out a project and other times you're concentrating on tidying up
the code and making it production ready. Unit testing has you alternating
really quickly between the two personas.

------
ThomPete
Steve and Chris where friends.

They had the one thing friends have, shared history.

So in the semi words of Wolfram.

"You have to run the program before you can know how it will evolve"

That does not mean that it wouldn't be good with a dating service but it's not
going to bring Steves and Chris together IMHO.

~~~
cturner
You're not bringing much creativity to hand before writing the idea off.*

Here's a two minute model. First - you steer people in the right direction via
a loose matching system a bit like they use on okcupid.

    
    
        When you need some boilerplate do you:
        - Type it all out manually at blistering speed on
          your expensive keyboard?
        - Press a button and watch your IDE nail it instantly?
        - Knock up some quick elisp macros?
        - Walk away in disgust?
    
        You're a bit rusty on use of a unix API call. What's
        the first place you look?
        - I've got a directory on my dev server full of
          carefully nurtured patterns. If I've seen on
          it before, it'll be there.
        - There's a copy of Stevens resting on my monitor
        - My mates on irc will point me in the right direction.
        - This is what the web is for! Google and stack
          overflow.
    

Then you match people for programming 'dates' over coffee. When you're both
there, you put a code into a website, and it gives you a sample problem to
talk about together.

A week later maybe nothing has happened. Or maybe you've both gelled and
knocked out an amazing project. Then you have an exit interview with the
website about the person you were matched to.

* We should go for coffee!

~~~
ThomPete
Sure I am just thinking that to actually get to that level the post talks
about requires far more than a couple of days.

------
bugsy
Good article. Relevant is Brook's Surgical Team:
[http://www.dfpug.de/loseblattsammlung/online/workshop/design...](http://www.dfpug.de/loseblattsammlung/online/workshop/design_patterns/sonstiges.htm)

Here, Steve is the Surgeon. The one that works his butt off in a prolonged
surgery session, assisted by others who have prepared the way, then he goes
and rests before the next surgery.

It makes sense to clear the way for the Steves. With Steve and Chris there is
one person that is clearing the way himself, but it makes even more sense to
build in support structurally. I find it amazing when I hear about a company
that has the engineers washing dishes, emptying their trash baskets, answering
phones, and other such tasks to "save money" when all it does is kill time
that the surgeon could have spent in the operating room.

What happens to the successful Steves nowadays when they can't find productive
environments is they eventually leave, form their own company and hire people
to complement their strengths.

------
zwieback
I think pair programming can be very effective even if both participants are
somewhere in the middle of the spectrum. In fact, the Chris/Steve example
sounds more like traditional division of labor than pair programming. If
memory serves me in classic Pair Programming the two partners work
concurrently at the same workstation, not sequentially.

------
archenemy
I find myself on both sides. I usually get a quick prototype started over a
few days, but then I can't bother finishing up, dealing with all posible
errors and polishing. But then, I love when I get to deal with a big, messy
codebase I can move forward while cleaning it up and shaping it.

------
bigohms
Thanks for sharing Jacquez post. I am relatively new here and find his
experience insightful. As such, im not aware of his full story but I hope his
issues with the community are recognized and integrated so that his
contributions are also recognized and retained.

------
budu3
I remember indy500 back in the heydays of DOS.

------
crizCraig
Related poll: Are you a Steve or a Chris?

<http://news.ycombinator.com/item?id=2307060>

