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.
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.
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.
The first phase is really fast-paced uber-productive (as you assemble all the bits from past experiences), and the second phase really slows down as you deal with the nitty gritty of implementation and attention to detail. Just doing the first phase is the equivalent of being an ideas guy. I.e. useless without the implementation.
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?
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.
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.
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.
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.
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.
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.
What I find helps me to keep going through the lame part of a project is working on pet projects. It keeps me fresh and motivated enough to be able to at least moderately focus on the now boring codebase.
I cope with this with #3, I guess - not programming as a career.
I can then do crazy prototypes and hackathons in my spare time and work on the general big-picture, product vision stuff that I really enjoy in my actual job as a product manager. My workplace isn't reliant on my shipping great code (and we'd all be worse off if it were!).
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.
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...
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.
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.
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.
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.
I would say that he was Steve, I was Chris. Although one of those names is actually one of our names, and incorrectly assigned.
He is the best pure software developer I have seen ever. He could crank code like no one I have ever seen. But we were even better as a team. Until we weren't.
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.
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.
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.
I was tempted to say "Spoken like a true Chris", but then I realized that no true Chris would really say something like that. Here's what I think you didn't get from the OP's story: there's a hell of a lot of creativity in what Chris does. Steve and Chris work on different levels, that's all.
Yes, Steve's job is flashier, it makes spectators go "whoa" and "ooh" and "aah". But all the fine touches and important details that make the final solution so great are Chris's work. And if you think there's no creativity involved in finding those solutions, you've got another think coming...
Steve's are a dime a dozen, however a good Steve is priceless. A lot of big decisions are made by the Steve's and if they are the wrong ones being made it turns into a nightmare for the Chris'.
I'm usually only willing be my own Chris and not someone elses unless I know the Steve involved and respect his work.
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.
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.
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.
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.'
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.
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.
He was a well respected member of the community who commented a ton (he's still 3rd in karma: http://news.ycombinator.com/leaders) but decided to step away. That's part of it. The other part is that his blog posts are often interesting, insightful, and useful.
sophacles and pmjordan had already given enough info on Jacques. One thing I can say about his posts (having recently posted a couple of them to HN myself) is that they are simple, clear and thoughtful and very much in line with the wavelength of people here at HN.
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.
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.
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.
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!
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.
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.
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.
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 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.