Gamasutra: The Art & Business of Making Gamesspacer
Programmer, Interrupted

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 24, 2014
arrowPress Releases
April 24, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Programmer, Interrupted

April 22, 2013 Article Start Previous Page 4 of 4
 

Conceptual memory

Conceptual memory is a continuum between perceptions and abstractions. How does the brain remember objects such as a hammer and concepts such as "tool"? Well, it first learns basic features of encountered stimuli, such as the wood grains and metal curves of a hammer, and then organizes those features into progressively higher levels of abstraction.

Developers are expected to maintain expertise in their craft throughout their careers. Unfortunately, the path to becoming an expert is not easily walked: For a novice, evidence suggests this can be a 10-year journey. Furthermore, for experts trying to become experts in new domains, like the desktop developer becoming a web developer, there are many concepts that must be put aside and new ones learned.

Studies examining the difference between an expert and novice find that performance differences arise from differences in brain activity. Not only do experts require less brain activity than novices, they also use different parts of their brains: Experts use conceptual memory whereas novices use attentive memory. That is, experts are able to exploit abstractions in conceptual memory, whereas novices must hold primitive representations in attentive memory.

Sketchlet (alpha) is a software tool designed to help a programmer form and prime concepts by supporting abstraction and reviewing concepts that need to be refreshed. You can try it for yourself at sketchlet.sourceforge.net.

By expanding the programming environment to tablets, sketchlets on a "Code Pad" can provide extra mental space to build and remember concepts about code. 

References

For a full list of citations and references, read the original post here.

A diary study of task switching and interruptions (Czerwinski)

No task left behind?: examining the nature of fragmented work (Mark)

Resumption strategies for interrupted programming tasks (Parnin, Rugaber)

Subvocalization - Toward Hearing the Inner Thoughts of Developers (Parnin)

Task-evoked pupillary response to mental workload in HCI (Iqbal) 


Article Start Previous Page 4 of 4

Related Jobs

Turbine Inc.
Turbine Inc. — Needham, Massachusetts, United States
[04.23.14]

Director, Analytics Platform Development
Gameloft Toronto
Gameloft Toronto — Toronto, Ontario, Canada
[04.23.14]

Technical Artist
Muti Labs
Muti Labs — Santa Monica, California, United States
[04.23.14]

Senior Game Engineer
Digital Extremes
Digital Extremes — London, Ontario, Canada
[04.23.14]

Programmers






Comments


David Amador
profile image
Well, I just interrupted my work to read an article about not interrupting work so...
Anyway good article :)

Dolgion Chuluunbaatar
profile image
Pfffffffff this just shows how inefficient human beings are at programming. We clearly need to focus on building AIs that can program programs things for us.

Ruslan Shestopalyuk
profile image
Humans would probably have built it long time ago, if they weren't interrupted all the time.

Yama Habib
profile image
I don't know about you, but my IDE's already write most of my code for me. I give it another decade before it learns to not need my input at all.

Marcin kossowski
profile image
Great article.

Though I'm sad to hear that people leave full control of their code to IDE's....

Tylor Reynolds
profile image
Great article, I am interested in the touch points you mentioned. I was hoping you could explain further how they would work on a more detailed level and if you know of any IDE's/editors that support this feature.

Joe McGinn
profile image
The worst offender for interrupting programmers has to be the open plan office. Not suggesting a return to Mad Men, but small quiet semi-private rooms with 3-4 programmers in it can work wonders for concentration. I'm convinced that 20 years from now people are going to look back at current office design and just shake their heads with how inefficient and unhealthy they are.

Aaron Haaf
profile image
As much as I hate having other people bothering me, I can also appreciate the immediacy of problems being sorted out, which may be better overall for the team.

However, I do have a sign saying "DO NOT INTERRUPT UNLESS CAKE OR DEATH" somewhere when I really need to sort something crazy out.

Maybe a vacation room or two for "task-forces" or as a reward for good behavior.

James Carroll
profile image
@Joe ... I agree - prefer pod like environments for teams of devs that work closely together

Kelly A
profile image
Oh my goodness yes! We recently moved offices, but moved into a temp space while our new one was being reno'd. We were in an old college classroom, and it was quiet, and myself (an artist) sat with the programmers, and we got SO MUCH DONE.
Fast-forward to now, with an open-concept room - we have people walking behind us, people interrupting us, and it's so quiet you can hear a cricket fart, which is not a healthy work environment.
I understand the idealized notion that we'll all magically collaborate, but that just doesn't happen.

Ken Nakai
profile image
I agree. Cubicles with high walls that don't open to a traffic path (hallway, path to the kitchen) or groups of offices are good. At the same time, I think people need to learn to focus as well. You're never going to get an environment where someone isn't moving around at some point. I remember a developer who effectively needed to be locked away because every little thing interrupted him. I'm sorry but if you can't deal with people and the slight swoosh of someone walking six feet away from you or more, may I suggest what a college friend of mine used to do during summer: become a park ranger in the middle of nowhere.

I definitely agree that open offices where there are just no barriers at all are dumb. I believe in collaboration and keeping people together (thus not a fan of individual offices for everyone if that's feasible in a particular space). Just need to still enable people to be able to focus on their work (and I suspect it's going to get harder with the younger generation coming to the table wanting instant gratification--no patience--and used to the idea of being constantly distracted--texts, Twitter, all sorts of input--rather than focussed on a single task.

Nick Harris
profile image
Put the entire programming staff on their own floor several flights of stairs down from where the managers reside. Have no direct lift access between them forcing the managers to walk UP many stairs to "pop in for a quick chat". Have no IM, or email, or telephones in the programming area.

The only interruption should be the Fire Alarm.

Joe McGinn
profile image
Agree Aaron, that's why I'm suggesting office pods (nice term James!) of people who work in a similar area. And as Kelly says, in the context of game development they don't all need to have one job, I'd put designer/coder/artist who work together in one pod.

Nathan Mates
profile image
Joel On Software recommends that all programmers have a door. That's not feasible on most offices/budgets, but from personal experience, most office buildings allow for rooms of 2-4 people and a door, which work great. You can set that up as small pods of a task-oriented group (cross-discipline as needed), or a few programmers on a related area together.

Look at the articles on the design of Pixar's offices - they deliberately tried to make people meet, same as open plan offices. But, they did not try and make people meet at their desks. They made common areas (bathrooms, hallways) a common target to mix people. If you're already up and away from your desk for another purpose, a meeting doesn't take a programmer out of the zone. That's the kind of compromise that office makers need to make. Not this "let's make a giant mosh pit and hope that hearing two cow-orkers sixty feet away yap about something unrelated to work will spark communication and collaboration" nonsense. Peopleware (how many decades old is it now?) has the same point.

Worst part of being on an open-floor plan: hearing two associate producers. On speakerphone. To each other. I was located in an area between them, so I heard each of them twice (original and speakerphone).

Rakesh Raparla
profile image
Nice article i think i am sure i am the very best example for this one :D

Travis Martin
profile image
Ooh, this is really relevant to my interests! We work just two of us in my home office, and it's a point of contention that the non-programmer (hehe) interrupts me to great loss of productivity. We have developed a system, though, where if she has a problem she'll write it down, and we'll look over the list at the end of a specific time period.

It's great to know I'm not alone in this O_O;

Gregory Booth
profile image
Nice Article!

As someone working from home this is *really* relevant!

:D


none
 
Comment: