Programmer Interrupted

Slashdot runs a thread on “Are Remote Software Teams More Productive?“.  The original post links to a few research references that, unsurprisingly, show how expensive interruptions are to programmers, and how unprepared we are, as an industry, to deal with this problem.  I particularly liked a rather in-depth look at the issue in “Programmer Interrupted” article.

Like you, I am programmer, interrupted. Unfortunately, our understanding of interruption and remedies for them are not too far from homeopathic cures and bloodletting leeches.

Here are a few points, if the article is too long for you to handle:

Based on a analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10), we found:

  • A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
  • When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
  • A programmer is likely to get just one uninterrupted 2-hour session in a day

And also this bit on the worst time to interrupt a programmer:

If an interrupted person is allowed to suspend their working state or reach a “good breakpoint”, then the impact of the interruption can be reduced (Trafton:03). However, programmers often need at least 7 minutes before they transition from a high memory state to low memory state (Iqbal:07). An experiment evaluating which state a programmer less desired an interruption found these states to be especially problematic (Fogarty:05):

  • During an edit, especially with concurrent edits in multiple locations.
  • Navigation and search activities.
  • Comprehending data flow and control flow in code.
  • IDE window is out of focus.

Overall, not surprising at all, but it’s nice to have some numbers and research papers to point to…

Incident pit

I came across the Wikipedia page for incident pit, which was a concept derived from analyzing multiple incident reports in diving:

The diagram shown is something that has evolved from studying many incident reports. It is important to realize that the shape of the “Pit” is in no way connected with the depth of water and that all stages can occur in very shallow water or even on the surface.

The basic concept is that as an incident develops it becomes progressively harder to extract yourself or your companion from a worsening situation. In other words the farther you become “dragged” into the pit the steeper the sides become and a return to the “normal” situation is correspondingly more difficult.

Underwater swimming may be considered to be an activity where, due to the environment and equipment plus human nature, there is a continuing process of minor incidents – illustrated by the top area of the pit.

When one of these minor incidents becomes difficult to cope with, or is further complicated by other problems usually arriving all at the same time, the situation tends to become an emergency and the first feelings of fear begin to appear – illustrated by the next layer of the pit. If the emergency is not controlled at this early stage then panic, the diver’s worst enemy, leads to almost total lack of control and the emergency becomes a serious problem – illustrated by the third layer of the pit. Progression through to the final stage of the pit from the panic situation is usually very rapid and extremely difficult to reverse and a fatality may be inevitable – illustrated by the final black stage of the pit.

The time for an incident to evolve in this way can be as short as 30 seconds or less, illustrated by the straight line passing directly through all the stages in the centre of the pit, or it may be more a slower process building up over a period of one minute or more [maybe a week!] – illustrated by the curving lines running from the [top] extremities of the pit. In this later case it represents the slowly evolving incident when the diver or group may not be aware that a serious situation is in fact developing. Between 30 seconds and about 1 minute is representative of the time required to take the necessary decisions and actions when it becomes obvious that an incident is about to happen.

The final conclusion is simple: never allow incidents to develop beyond the top normal layer of activity. If you find yourself being drawn into the second stage – the emergency – then use all of your training skill and experience to extract yourself and your companions from the pit before the sides become too steep!

I don’t think is applicable to diving only.  Similar incident pits exist in other areas of human activity (technology, business, politics, healthcare, and others come to mind) which involve crisis management.  The circumstances and the time frames might be slightly different, but overall, I think, it’s pretty similar.

 

 

Software Engineering at Google

Fergus Henderson, who has been a software engineer at Google for 10 years, published the PDF document entitled “Software Engineering at Google“, where he collects and describes key software engineering practices the company is using.

It covers the following:

  • software development – version control, build system, code review, testing, bug tracking, programming languages, debugging and profiling tools, release engineering, launch approval, post-mortems, and frequent rewrites.
  • project management – 20% time, objectives and key results (OKRs), project approval, and corporate reorganizations.
  • people management – roles, facilities, training, transfers, performance appraisal and rewards.

Some of these practices are widely known, some not so much.  There are not a lot of details, but the overall summaries should provide enough food for thought for anyone who works in the software development company or is involved in management.

 

Maintainers Don’t Scale

Daniel Vetter, one of the Linux kernel maintainers, shares some thoughts on why maintainers don’t scale, what it takes to do the job, what has changed recently and what needs to change in the future.

This reminded me of this infographic, which depicts a year (even though back in 2012 – probably much busier these days) for another kernel maintainer – Greg Kroah-Hartman.  Note that the number of emails does not include the messages on the Linux kernel mailing list (LKML), which is in its own category of busy:

The Linux kernel mailing list (LKML) is the main electronic mailing list for Linux kernel development, where the majority of the announcements, discussions, debates, and flame wars over the kernel take place. Many other mailing lists exist to discuss the different subsystems and ports of the Linux kernel, but LKML is the principal communication channel among Linux kernel developers. It is a very high-volume list, usually receiving about 1,000 messages each day, most of which are kernel code patches.

The Three Machines

It’s amazing how well-timed this article is for the things that go on around me right now.  But even if you are not spending most of your days, nights, and weekends building a company at this moment, have a go at it anyway.   Here’s a bit to get you started:

My current hypothesis is that if you are a CEO, focus your organization on the three machines. Product, Customer, and Company. Then, have a direct report own one of them. If you have a sub-scale leadership team (e.g. you are three founders and four other employees), as CEO you can own one, but not more than one. As you get bigger (probably greater than 20 employees), hopefully now you have enough leadership to have one person own each, but recognize that if someone is being ineffective as a leader of one of the machines, you will have to replace them in that role (either by firing them or re-assigning them).

 

Is It Worth the Time?

I’ve seen this chart before, but completely forgot where it was from.  Tried to find it a couple of times in a hurry of a conversation, but couldn’t.  Thanks to this SysAdvent blog post, I now have it permanently engraved into the archives of my blog.

xkcd figured out how long can you work on making a routine task more efficient before you’re spending more time than you save.  The crossing of how much time you shave off and how often you do the task gets progressively less obvious when move from the top left corner of this char to the bottom right corner.

Why Some People Get Promoted (And Others Don’t)

I enjoyed reading the article “Why Some People Get Promoted (And Others Don’t)“.  Unlike many other in this domain, it is simple, direct, and to the point.  TLDR version:

  1. Do great things.
  2. Tell people.

There are quite a few links to external resources, with research and insightful quotes.  Here are a couple of my favorite bits:

‘[S]ent does not mean received’ is a profound thing. Half of your job in this studio is doing your work, the other half of your job is communicating that it’s been done. Because if you do it, and I don’t hear about it, how do I know what’s going on? I’m not trying to control everything, but in an intimate work environment, where we’re really trying to develop something complex, a nod, saying, ‘I got it,’ helps move things along.

And this part, which resonates with my inner blogger:

Asking for help is part of getting better at your job.

3. Work where people can see you.

Gaining visibility might require going outside your office. Maybe you have a side project, or maybe your work culture isn’t a healthy environment to pursue visibility.

Promoting yourself doesn’t have to be on someone else’s terms. Write a book, start a blog, make a side-project, collaborate with new people outside of work, or speak at panels and conferences. Tell people about what you’ve done, what you’re doing, why it’s important, and how you did it. Give talks, teach others, raise your hand for new projects.

How To Keep Your Best Programmers

I really liked this article – How To Keep Your Best Programmers.  It’s not your average three paragraphs and a link, I admit. It’s somewhat of a long read.  But it does a good job of explaining why people in general, and good developers in particular choose to leave or stay in the company.

It’s difficult to quote as it flows continuously, but if I had to choose, I’d use this as a teaser:

For some background, check out this video from RSA Animate. The video is great watching, but if you haven’t the time, the gist of it is that humans are not motivated economically toward self-actualization (as widely believed) but are instead driven by these three motivating factors: the desire to control one’s own work, the desire to get better at things, and the desire to work toward some goal beyond showing up for 40 hours per week and collecting a paycheck.

Frustration with organizational stupidity is usually the result of a lack of autonomy and the perception of no discernible purpose.

Not that I am a good programmer, but it helped me understand some of my own career jumps…