About a year ago, I wrote a post about why I don't like pair programming (and why I left Pivotal). This is the flip side.
I've been working for the California Academy of Sciences for the past five months. I'm creating an NSF-funded website for ant taxonomists: antcat.org.
It's the best job I've ever had in 25 years as a programmer.
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, on a greenfield application in Rails, for an intelligent and easy-going boss, for an audience of scientists, in Golden Gate Park, ten minutes from my house. The pay is "only" 100K, which is less than I've made in quite a few years. But there's health insurance, and I get to work the tidepool exhibit a couple of times a week.
But the #1 plus is that I work alone.
I'm not proud of enjoying this so much. I'd much prefer it if I liked being part of a vibrant and innovative team - even pairing with them. But I don't.
Quite simply, at this job I get to do things the way I want. That means 95% test-driven. It means agile - doing the simplest thing that could possibly work. It means adding Solr when I want. It means really learning Javascript for the first time. It means applying the lessons learned over a quarter of a century of experience in my field. And it means not having to argue about it.
Maybe it's just been my bad luck, but I've never seemed to have worked with people who share my views on lean development, agile methodology, OOP, database design, or even structured programming. Views I've learned from reading people like Martin Fowler and Kent Beck. Obvious things that these guys just take for granted, like avoiding premature optimization, or following the single responsiblity principle.
So my interaction with my fellow developers has always seemed to involve a lot of arguing. I've become much more diplomatic and polite over the years, and I'm much quicker to concede a point (after all, I might be wrong). But there comes a point where you get tired of being the OOP "purist" (I'm not). You just want to do it right.
Now, I'm very aware of what I'm missing out on by working alone. My way may not in fact be right. I might not learn about other ways that I would end up embracing. I no doubt create more bugs. I sometimes make bad design decisions that cost me time. All these things would be tempered by working in a team, including pairing. And as far as pairing is concerned, I know for a fact that I'm not as productive as when I pair-programmed at Pivotal. We got some amazing results, just chugging through the feature list. The only problem is that I hated it.
I also know that I seem to be arguing for the "cowboy coder" style of development. These guys are a real pain to deal with on a team. But what if there's no team?
I know too that you'll hear this argument more frequently from members of my generation than the young pups who grew up on agile methods. All I can say is that I do tend to embrace the more leading-edge ideas - OOP in 1989, TDD in 2000, lean today. That's been the cause of many of my disagreements!
When it comes down to it, I believe that the only intelligent criterion for behavior is happiness. The only reason for a person to do something is because it makes them happy (in the long or short term).
The bottom line is that this way makes me happy.
FOLLOWUP: There are a couple of things I mentioned in the original post that might have been missed if you just read this one: 1) I think pair programming is a great way of doing software development (just not for me), and 2) Pivotal Labs is an awesome place to work.
Subscribe to:
Post Comments (Atom)
19 comments:
Congratulations on finding the job that's best for you, Mark, and thanks for the reminder that I haven't even visited the new Academy yet! My wife has worked a desk job at the SF Zoo for the last year, and loves the similar fringe benefits the setting provides.
Regarding some of what you're "missing out on," there's always your extended network of former co-workers to bounce things off of. (Feel free to ask me any javascript questions!) If you've got the time and inclination, contributing to some open source project might help with discovering new methods and tech., too.
I've recently moved on from a job with a lack of autonomy and I know what you mean.
Sometimes pairing with someone works wonders when you have good rappor and on an even footing. Other times it can feel like you're being watched or monitored (like pairing with your boss)
Right now I've started in a very small team (of three), with a crazy amount of autonomy. We're just too busy to 'manage' each other and instead trust each other to do the right thing. It is great but very early days.
It sounds like it isn't working in a team, or pairing that is the root of the problem here. But trust and autonomy within your job. By working alone you have ensured them, though at a cost.
I think it comes down to the fact that there are many different types of coders, each with different personalities and temperaments. I believe that some people may be more suited to pair programming than others. I occasionally get value from sitting with another developer and coding with them, but most of the time I prefer to code by myself. I think that sometimes I "write" my best code when I am not even at the keyboard, but thinking about a problem.
I think that any methodology that does not take individual personalities and temperaments into account is at risk of not offering the best potential of the individuals that use it.
You had me at "solo" :)
I love it when I work alone on something. Gives me freedom to do what I want and learn from my mistakes.
I feel much the same way. For me the main reason is: If I do a good job I should get the benefits, not some newbie just out of school who almost destroyed the project. You say the TEAM should get the benefits. What that often means though is that the company who hires the team is trying to get the benefits and not acknowledge the contributions of the main contributors. It's a bit like communism, the owners of the society get luxury beach-houses while everyone else is a "team-player".
I think I could like pair-programming with someone like you who detests it as much as you do. But we would need to be 50-50 partners.
The Pair-programming is a big Myth. It makes it look like everyone's equal - except those who own the fruits of your labors.
I mean, why doesn't the company also involve everybody as pair-CFOs, pair-CEOs, pair-HR -managers on a rotating basis?
There must be a reason, right?
Why don't we all take turns in being pairs as the project-manager every other "sprint"? Why?
Why should programming be so different from other intellectually challenging tasks within the company?
Sounds like a good deal for you. I also generally like working in similar modes, though there are so few opportunities like that in general out there.
I can't even imagine what pair programming would be like. What is the point? Does someone literally read over your shoulder? How could you possibly get anything done that way?
I would never be able to work like that. You can't ignore someone reading over your shoulder and focus. There's a fundamental law of something that prohibits it. It's like pointing your finger at your siblings face just far enough away that you're not touching. It just sounds horrible!
Geez I read "ant taxidermists", was wondering how that was done until I read it again!
Good for you. Live and die by your own decisions. I've been working in a team heavy environment for the past 5 years and have recently switched to basically working on my own stuff, or at most with one other person. It is great. Not having to discuss, justify, and get buy-in is a refreshing change. I'm sure that will change back at some point, but for now, I'm doing what I want.
That last part was the key... you are happy!
you sound like someone that mus be cool to work with :)
btw, you may be the only coder, but you still are part of a team, and be it only a cool boss.
Pair-programming sucks in Brazil too.
This style is a myth.
3 Words: Lowest Common Denominator
As something of a control freak and introvert, I couldn't agree more. I interviewed with a great company that practiced pair programming; the idea of working full-time with such a lack of privacy and ownership made me feel queasy.
Co-workers are invaluable, but give me my own space and my own piece to work on.
Thanks for the post.
A good pair programming experience sounds intriguing!
I feel like I'm reading a post written by myself. I'm something of an old dog too, and most of the tools, like TDD, XP, pair programming are things we just *did* as part of the development process. A lot of younger teams are dogmatic about being 'agile' or user 'agile' to mean 'speed' at the cost of cutting corners or producing sloppy designs.
I love pair programing - but only where it works, and when it works. Most companies I've worked at have done it wrong.
In one position, we divided it up so that I was responsible for X, and my partner was responsible for Y, we'd review each other's stuff at least once a day or so, and chat about general direction.
good to read about the (your) other side - and I am glad you are not stuck in parallel cataloging...
Post a Comment