ninlabs research

It is not unreasonable to speculate on what the future of software engineering will look like in the next 50 years. Software engineering is still a young discipline, with almost half a century since the coining of “software engineering”. Although we could claim some sort of success by simply pointing out the software underlying almost every facet of today’s world, that success has not been consistently repeatable nor teachable. As we become dependent on trillions of lines of code in the next 50 years, there is little comfort we still have no fundamental scientific understanding of how to create software.

Software development isn’t just about the code we write. It also spans the many situations, experiences, and new knowledge we encounter when we write code.

Continuing my series of posts on cognitive neuroscience of memory. In this post, I first give an overview of attentive memory, some examples of attentive memory failures, and then end with some thoughts on how we might want to support attentive memory in our design of interfaces and tools.

Why are we still using ideas about memory from the 60’s to build programming tools?

My best guess is that developer’s have a love/hate relationship with tabs. They’re great when they work, but many times they get cluttered, and developers have to go nuclear on them (Close All Tabs).

Tasks, for the purpose of this post, are assigned units of work. In practice, this may be a “story” or “defect” from an iteration in the agile world, or a “work item” in TFS land, or even a “feature” in trackers such as trac. There are many names given to tasks, but for the programmer, ultimately they are externally assigned responsibilities.

This is my second attempt at a software-related comic, but this time it is completely hand drawn.

I have seen many papers justifying how much effort debugging or testing costs by saying something like:

Ever since google released a comic describing the design of the chrome browser, I’ve been fascinated by the idea using comics to communicate software design. There is something compelling about distilling down your concepts into a simple narrative. This is no easy task — here is my first attempt, an illustration describing how the concept of code history can change how programmers work: (see the pdf version here: [pdf])