|
Associative memory
Associative memory holds a set of nonconscious links between manifestations of co-occurring stimuli.
Developers commonly experience disorientation when navigating to unfamiliar code. The disorientation stems from associative memory failures that arise when a developer must recall information about the places of code they are viewing or what to view next. Researchers believe the lack of rich and stable environmental cues in interface elements, such as document tabs, prevent devs from recalling associative memories.
The presence of multiple modalities in a stimulus increases the ability to form an associative memory. In this sense, a modality refers to a distinct type of perception that is processed by distinct regions of the brain, such as auditory or visual pathways. Examples of different modalities and corresponding stimuli include: visual (error underline bars, highlighting code), lexical (name of file), spatial (position of scroll bar or tab), operational (edit/search/debug step action on file), and structural (logical position of file in hierarchy).
When multiple modalities are present in the same stimulus, more pathways are activated, thus increasing the chance of forming an associative memory. In contrast, a monotonous stimulus with a single modality is less likely to form an associative memory.
An associative link helps a programmer by situating information of multiple modalities with a program element; observations of developers suggest that they frequently rely on associations with environmental cues, such as tabs and scrollbars, for maintaining context during navigation. However, these cues are often insufficient: The act of navigation often disturbs the state of the cues, and the paucity of interface elements such as tabs, which often contain only a file name, starves associability. By improving navigating document tabs, which in default configurations are especially spartan, often showing just the name of the document, we could see increased recall from associative memory.

Two tabs adorned with cues of different modalities: such as error lines (visual) and edit icons (operational).
Episodic memory
Episodic memory is the recollection of past events. Software developers continually encounter new learning experiences about their craft. Retaining and making use of such acquired knowledge requires that developers are able to recollect those experiences from their episodic memory.
When recalling from episodic memory, developers commonly experience failures that limit their ability to recall essential details or recollect the key events. For example, a developer may forget the changes they performed for a programming task, or forget details such as a blog post that was used for implementing part of the task.
A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity. Different types of narratives can be supported; for example, a review mode for high-level recall of events and a share mode for publishing a coding task for others.

A timeline of programming activities can help you or your teammates remember how you did a task and the resources you used. Click for larger version.
For more on code narratives, check out this blog, which is shared and published semiautomatically via a code narrative. (Note that as of this writing, the blog hasn't been updated recently.)
|
Anyway good article :)
Though I'm sad to hear that people leave full control of their code to IDE's....
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.
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.
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.
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).
It's great to know I'm not alone in this O_O;
As someone working from home this is *really* relevant!
:D
Valuable read...