How to work with programmers

A couple years ago, I watched a reality home improvement show where an architect, who was very good at his job, decided that the worker bees were just drones who never did exactly what he designed.  He thought building stuff was the easy part.  His designs were great, and they just needed to build what was on the paper with the tools and parts he specified.  What he found was that building something wasn’t quite as easy as he thought.  That episode is the only one where I’ve seen a man actually cry during the build.  The good news for him is that he learned something, and he now has some respect for the builders.  Software architects should have the same respect for programmers.

I’m certainly not saying that construction workers and programmers are the same thing, because they are not.  I am saying that experienced programmers are much, much closer to architects than architects would like to believe.  This Wikipedia article goes into some nice detail about software architecture.  Note the section about the various opinions.  My opinion is just one of many, and it is that software architects should deal with the macroscopic system structure, and software developers should deal with the implementation details.  Here’s the catch though.  Neither can do their job well exclusive of each other, and, if the software system isn’t tiny, neither of them can do both jobs at the same time.

The Architecture / Programming Gap

I don’t like the separation of duties that has happened in the industry.  I think this separation is artificially wide in most cases.  Both functions need to happen, but they need to be much closer together.  If you’re an architect, you really do need to consider the idea that programmers are not mindless drones.  Well, hopefully they aren’t.

The gap is made of:

  • A lack of communication
  • An unwillingness to see the other persons point of view
  • Animosity

The gap begins when the architecture group doesn’t know what really happens in the development and support trenches, and it is fully formed when the development group doesn’t understand the strategic direction and the answer to the all-important question, “why?”.  When the teams begin to feel animosity toward each other, the gap will widen and solidify.

The result of the gap is two teams that do not respect each other or communicate with each other, and that’s just not good for business.  Throwing a design at programmers like it’s a hot-potato is not communication, and neither is building exactly what the architects wrote down without question, even when you know it isn’t right.

Bridging The Gap

I won’t lie to you.  If the condition of the architect / programmer relationship is already to the point where they despise each other, it’s going to be difficult.  Here are a couple of things you can do to start closing the gap.  It certainly isn’t a definitive list, but it’s a start.

  • Respect the developers.
    • They are your co-workers, not your underlings.
  • Try to befriend one of the more experienced programmers.
    • Listen to what he has to say.
    • Be open-minded.
  • Initiate a conversation with the development team.
    • Pull the developers into the discussion about new features early, and really get them involved.
    • Get in the trenches with them and try to understand their point of view.
    • Ask for their opinion.

I know what you’re thinking, but someone has to take the initiative, and the other needs to be receptive to it.  Exactly who starts doesn’t matter, but if nobody does, then you will remain in the same conflicted state.

If you work together as one team, there will be less stress for everyone, and you will build a better product.  Your users will benefit from it, and your management will certainly be happier.

Let’s take a look at who and what programmers are.

Programmers Are People Too

Programmers are not a commodity.  Don’t treat them like they are.  They are smart people who want to design and build elegant solutions to complex problems, and they care about what they do.  The great ones love the details, and they enjoy filling their heads with the system they are working on, its inner workings,  and the business and technical problems that need to be solved.  These same people don’t stop programming when the work day is done, they work on side-projects too, just for fun sometimes.

Programmers Are Problem Solvers

From the moment a programmer first hears about a problem or a new feature, his mind begins working on a solution.  The more experienced programmers who have an in-depth knowledge of the system, formulate possible solutions very quickly.  When the problem being considered is extremely complex, it can take a little longer.   For some programmers, there is a deep internal need to solve the puzzle.  Once they sink their teeth into the puzzle, they are compelled keep thinking about it until it is solved.  Solutions come during dinner, while sleeping, and at 4:00am when they’re in the zone.  To the people like this, programming isn’t just a job that they can turn off at 5:00pm… Believe me, I’ve tried.

Putting It All Together

If you want to work well with your programming co-workers, you really should try to look at things from their perspective every now and then.  The same thing could be said about them, and I’ve said it in another post.  It is vital that both teams try to work together, so you both need to work to find the common ground.  If you don’t, then nothing is going to improve.

There will still be debates and maybe even some heated discussions, but if architecture and development see each other as equals, they can work as a single team with common goals.  When this happens, together, they will become much more productive and everyone’s job will be more enjoyable.

Leave a Reply