A tale of two programmers

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.<p>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.<p>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.<p>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.<p>Together, we make an outstanding team.<p>Maybe we could officially categorize these two phases into new job positions. Problem Solvers and Solution Implementors.

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.<p>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.

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.<p>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.<p>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.<p>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:<p>1. Comment copiously the <i>how</i> and <i>why</i> things are written (people can usually figure out the <i>what</i> 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.<p>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.<p>3. Develop another valuable skill that allows you to contribute even when you're not writing code.

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.<p>The thing I could <i>not</i> 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 <i>only much better this time</i>.<p>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.

I found my pair-programing-soulmate.<p>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?<p>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.<p>It's almost like working on a long distance relationship...

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!<p>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.<p>As professionals we have the obligation of being both Steve and Chris.

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.

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

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?<p>Well, in general terms, give the programmers a long-term <i>investment</i> 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...<p>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, <i>and</i> to coach them.<p>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.

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.<p>I <i>think</i> 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.

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

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...

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.

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.

Very cute.<p>By the way, I've seen several "programmers dating services" with a purpose of finding mutual mentors

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...

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.

Steve and Chris where friends.<p>They had the one thing friends have, shared history.<p>So in the semi words of Wolfram.<p>"You have to run the program before you can know how it will evolve"<p>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.

Good article. Relevant is Brook's Surgical Team: <a href="http://www.dfpug.de/loseblattsammlung/online/workshop/design_patterns/sonstiges.htm" rel="nofollow">http://www.dfpug.de/loseblattsammlung/online/workshop/design...</a><p>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.<p>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.<p>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.

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.

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.

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.

I remember indy500 back in the heydays of DOS.

Related poll: Are you a Steve or a Chris?<p><a href="http://news.ycombinator.com/item?id=2307060" rel="nofollow">http://news.ycombinator.com/item?id=2307060</a>