I recently had a bit of thought about making a team work. Maybe it’s about being personally vested in the project and having leadership champion that cause. Today, I’m reading about some things Warren Buffet’s said to students. Specifically the classmate game. What if you were offered 10% of the lifetime earnings of a classmate. Who would you choose? And also, what if you could short the lifetime earnings of a classmate, or make money from their failures?

This is clever, because the students aren’t being asked to rate themselves, or rank themselves, or justify their own thoughts and behaviors. They’re just trying to recognize which qualities they think are generally the most and least effective.

Turning that lens on software developers, it’s kind of an interesting way to begin seeing what we’re about.

There are, for example, people who have developed a critical mind. They challenge assumptions and ask people to think deeper. They can be difficult to work with because they put me on my toes. They can also be insightful and committed to producing the best possible solutions. People like this are developing a deep reservoir of knowledge and technology hacks. They’re the type that will find the intermittent bugs nobody else can find. They’re the type that will steer a team away from the hype and build something that could last. They might not be the best team lead, but sometimes the best technical lead.

There are the good implementers. They understand the best technologies and can apply them quickly on a project. They are work horses and resemble the mythical 10x programmer more than anything I’ve met in my career.

There are the optimizers. They understand how to ferret out inefficiencies and see the system as a whole. They are the Donald Knuths amongst us that truly enjoy a good algorithm for the grace and creativity they present. They also seem to have deeper wells of patience and tenacity. They won’t always release the fastest, but they release beautiful things when they do.

There are the pragmatists that ship “good enough” quickly and refactor gracefully when they have to. There are the pair programmers that develop deep and loyal friends as well as incredible code. There are the architects that can keep more patterns and details in their minds while they work. There are the get-alongs, the cheerleaders, the commanders, the worryers, the organizers, the rage coders, the deep concentrators, the brogrammers, the savants, the pioneers, the cleaners, the leaders and followers.

At times we are asked to be all of these things. When the rest of a business understands the kind of intellectual and emotional gamut we’re working with, developers are given a lot more slack when things go wrong.

Over their lifetimes, I might think I could predict how well others might do. This isn’t a very sure bet though, I don’t think. Developers often find their happy place and do incredible work, whatever they’re bringing to the table. The exercise might be more useful to see the strengths and weaknesses that apply to me the most.

Beyond coder styles, there are still qualities that I think are hard for me to recognize in the drama of the day. Kindness, optimism, punctuality, respect, openness, even honesty are things I can lose in the savage race to meet deadlines or get a system running again.

Honesty is a particularly tricky one for me. It’s not that I start lying to get ahead. It’s that I don’t want people to see me struggle with a problem so I hide that I’m stuck. Or, I don’t step back to think whether my perspective is convenient or insightful. Or the toughest one of them all, trying to guess when a feature will be delivered. That’s a challenge to any developer trying to be honest.

In business school, we used to talk about Career Limiting Moves. The idea was to try to never flub up so bad that our career as a manager and eventual executive would be permanently damaged.

Fortunately for software developers, we rarely have these. If we have a deep technical knowledge and want to deliver working systems, there are near limitless opportunities for us to start over on a different project. Put another way, some managers use a shallow and fuzzy skill set and still progress in their career. Coders need to develop a deep and sharp practical knowledge that is put to the test by compilers, working systems and users every moment of the day. If a coder can get things figured out, they’ll be valuable no matter what their coding style.

Or, here’s a funny anecdote. Once upon a time I was called out of a movie with my girlfriend to be chewed out by the owner of the company that employed me. He was raging that I had brought his system down and that customers were being affected. I rushed to the nearest Internet connection to find out what I had done (this sounds quaint today–who doesn’t have constant Internet access all the time?). It turns out I had done nothing wrong. His son, a manager at the company with commit access had pushed out an untested bit of code to production and left for the evening without even checking that the deploy finished. That person soon left the company and made profane amounts of money in management and sales (over $500K a year) but couldn’t be trusted with the most-junior software development tasks.

This still leaves me with figuring out what kind of coder I can be on a particular project. It still means coders often hop around to find their happy place. It still means that we’re going to be sometimes short on patience with each other. But, our ultimate success is really a measure of our dedication to the craft. We’re not getting ahead because we belong to the right clubs, have the right haircut, or are liked by the right people. If I had to bet which of my colleagues will do the best, it would be the ones that keep at it.