A tale of two programmers
jacquesmattheij.com
jacquesmattheij.com
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.
Projects tend to need both kinds of people.
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.
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.
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.
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.
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.
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!).
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 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.
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.
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.
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.
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...
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.
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'm usually only willing be my own Chris and not someone elses unless I know the Steve involved and respect his work.
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.
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.
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.
Many HNers follow his blog (which tends to be of consistently high quality) and/or twitter stream.
HN profile: http://news.ycombinator.com/user?id=jacquesm
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.
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.
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.
By the way, I've seen several "programmers dating services" with a purpose of finding mutual mentors
everymentor.com maybe?
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.
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.
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!
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.