terrbear.org

For those of you who are under 5 (why are you reading this!?) or those who aren’t quite sure who the best basketball player of all time is, take a look at this:

The guy was more than just one of the most prolific scorers of all time. As soon as he got on the floor, everybody on his team was better. I think this is for several reasons, one of them being his teammates thinking “if I miss this shot, big deal, MJ will pick it up,” encouraging them to take bigger risks than they would if, say, it were Darko on their team.

When the final seconds of the game were ticking down, you wanted the ball in Jordan’s hands. He wasn’t going to miss the shot, and if anyone gave him any good defense, he’d show awe-inspiring offense.

When teammates screwed up or slacked off, he’d bark them back into line. He didn’t put up with slackers, demanded the best of his team, and won a lot of championships for it.

As long as we’re only talking about his basketball career, Jordan is arguably the best player of all time. There are other players who are better at individual facets of the game, but nobody was all around as dominant as he was. It’s in light of this that we should think how we can act like Jordan.

I think, in terms of software, this means as releases come up, you try to make the release as good as possible. It’s not just your features that embody a software release; it’s everyone’s. If your coworker’s features cause the project to blow up, nobody’s going to get to spend much time drooling on the code you wrote.

Accordingly, it becomes your job to make sure your team succeeds. Not just from a managerial perspective, but from a teammate perspective. If I’ve got free time, I need to not spend the extra day polishing my feature to perfection, but offering help to the other guy who’s falling behind. The same should be expected of the other guy.

We should be encouraging each other to grow in our careers. More than just “fucking google it,” (which teaches a lot on its own) but also “have you checked out this blog?” or “check this out, here’s a really effective way I do things.”

Finally, if able, we should be asking for the game ball at the close of the game. If there’s a bug or feature that was left off or discovered at the last minute, don’t push it off to the next guy. Get it done. It’s not to be a martyr; it’s to get your team in as good a shape as possible, because a good team reflects on everybody.

While this post might go against the agile tenet of not relying on hero developers, I think that’s ok. I think we shouldn’t be saying “don’t rely on hero developers,” but instead, “be a hero developer.” Note that this doesn’t mean working insane hours, it just means learning your code, your language, your framework, and best practices as well as possible.

So, the question you should probably be asking, is “what would Michael Jordan do?” (though I’m pretty sure slamming your coke can into your coworker’s trash can isn’t the most effective way of getting things done).