Programmer? Interrupted?

My friend Andrew Connell (@andrewconnell) posted a very interesting article called Programmer Interrupted to Facebook today, saying:

…all developers should share this with the one you love or non-developers you work with. Help them understand why you get so pissed when they come into your office to ask the simplest questions. Many times I feel like I’m holding a castle made of cards up with one finger, holding my breath when suddenly there’s this tiny puff of air that brings everything organized to complete chaos Smile

I do think that these effects vary considerably across individuals, and I don’t think it has to be a permanent condition.

When I was a young programmer (my second job in the mid-80s), I was in a highly interrupt-driven environment at Bain & Co., the management consulting company. I did a bunch of different things during my tenure there, but a lot of it was what we called “programming” at the time. Because I was interrupted extremely frequently – sometimes half a dozen times an hour, by my recollection – I simply learned to be better at it over the six years I was there.

At a later job around 1999-2002 at a company called ArsDigita, I was amazed at how defensive the young developers sometimes were with their time. They occasionally could be almost hostile at interruptions, which in a way ensured that they couldn’t learn to deal with them. I think the headphone thing actually made it worse, since an interruption was more jarring to their memory patterns, as it often required a physical incursion to get their attention. They interrupted each other, too, by the way; I’m not basing this just on my observations from interrupting them myself.

I can’t say that I’m great at managing interruptions, but I do think that I learned to be better at it than some people are. I don’t suggest that everyone embrace interruption – or even encourage it as I sometimes do – but I do suggest that everyone should consider how their work environment actually functions most of the time to consider how best to adapt. If you are likely to be interrupted, work to identify how you can best work inside that construct.

Techies often get a bad rap because they are too defensive and say no too often. Part of that bad rap can come from the impression of “my work right now is more important than whatever you are here for” that comes from reacting unpleasantly to interruptions from the very people for whom we are supposed to be doing the work.

Don’t just try to avoid interruption, treating it as an evil, but welcome it on some level so that you can be a better IT professional. You’ll have a happier user base, and you might just learn some new tricks.


Why Marketers Should Learn To Program – But Wait, There’s More

Vitruvian Man by Leonardo da Vinci, Galleria d...
Image via Wikipedia

A little while ago, Christian Buckley (@buckleyplanet) retweeted a link to an intriguing blog post from Scott Brinker (@chiefmartec) entitled Why marketers should learn how to program.  Scott’s main points center around the idea that for Marketers to be truly successful these days, they should learn at least the rudiments of software programming. This will give them new tools to succeed in an ever increasingly technology-driven discipline. I was motivated to comment on Scott’s post and wanted to capture and add to my comments here as well.

Understanding enough about the other disciplines related to succeeding at one’s own discipline shouldn’t be important just for Marketing folks. As the pace of innovation and change in the workplace continues to accelerate, it has become more and more important to have people available who can straddle many different disciplines.

In the past – perhaps way back in the 1990s or so – we were used to building teams that had one person representing each discipline. The teams had fairly long lifespans and knowledge areas were sacrosanct. Crossing the lines was frowned upon. Each team member was on the team because they were in a certain department, had a specific knowledge area, or needed to be on the team for political reasons.

Today all that is less often the case. We need teams to coalesce, accomplish, and dismantle in faster and faster cycle times. By building those teams with fewer people who have wider knowledge spans, we can reduce the communication requirements and accelerate accomplishment, thus innovation. Fewer team members with wider knowledge spans is simply a more efficient way to operate. This is especially true because those team members are increasingly likely to be spread widely across geographies and may even work for different organizations.

So, maybe Marketers should learn to program, but Developers should learn good design, Designers should learn basic accounting, Accountants should learn about organizational behavior, HR people should learn something about Marketing, and so forth.

It’s yet another time in history where the “Renaissance man” ought to be in high demand, and therefore should be able to call his (or her, of course) own shots.

Enhanced by Zemanta