Skip to main content

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He will sometimes disassemble and rebuild the entire engine to make it work the way he wants it to.  Your boss agrees that his way is best, because he is fast.  So you have learned to live with his way of doing it.  Sometimes it works well, sometimes it doesn't, but that's just how things go.

You like working with Bob.  Your cars are done fast and you get productivity bonuses.  Bob is fun to talk to because he's so smart anyway.  But one day Bob does something different from how you're used to.  It has happened before--he'll come up with some trick to be slightly more efficient and you have to learn from it--but this time it's different.  This time, it's a big change.  On top of that, just as you're trying to figure out what changed, a new guy, Tom, joins the team.  Your manager sees potential in Tom and sticks him in your position, moving you to work on a different part of the car.

Tom doesn't understand the new thing Bob is doing either.  But it's worse than that.  Bob does a LOT of unique things.  You are able to explain a few things you've learned about Bob's style with Tom on your lunch break each day, but even after several weeks he still hasn't picked up on all the different little tweaks.  Your boss is frustrated because Tom is making Bob look bad by slowing down the completion of his cars, and lowering the quality as well.

Tom even figures out the new big thing that Bob did, but he's struggling a lot.  Just as he gets into the swing of things, Bob changes something again.  The manager gets fed up and puts you back in place of Tom.  You have spent weeks doing things the normal way and have forgotten many of the tricks that you're used to doing with Bob.  It takes you some time to get back into the swing of things.  Moreover, you never learned about the big thing that Bob had changed before you left, let alone all the other new tweaks he's made since you changed roles.

You try and get a rundown from Tom, but he's not really great at explaining things.  His skill is with cars, not people.  You are at a loss and you struggle for several weeks as well.  Overall, the factory loses months of productivity before one of you figures Bob out enough to get caught up.

Now, imagine that's software development.

Because it is.

Don't be Bob.

Document your changes.  Work to fit existing patterns of the team.  Agree on big changes so EVERYONE benefits from efficiency increases.

If Bob rebuilt the alternator, he needs to remember to keep the mounting brackets in the same place so it still fits in the car.  This is contract programming.  Keep your inputs and outputs the same even as you improve things in individual functions.  Use inputs and outputs rather than events so that your code can be followed and understood easily.


Popular posts from this blog

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …