An Atom toolbar to help you achieve flow state (aka “the Zone”) and stay there through interruptions.

Why flozone

As found by Parnin:

Episodic memory is the recollection of past events.

Software developers continually encounter new learning experiences about their craft. Retaining and making use of those 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 the blog post that was used for implementing a part of the task.

flozone takes this idea to the simplest manifestation - a toolbar that uses the familiar media player metaphor to help you remember what you’re doing and help you tide through interruptions

Github: https://github.com/groktools/flozone

Atom Package: https://atom.io/packages/flozone

Record your explorations of code

Recorder is the idea that you should record your interactions with the code you’re trying to understand so that you can replay it later for recall or to share with others.

Why Recorder

As found by Maalej et al (page 12):

3 Developers interact with the application user interface to test whether the application behaves as expected and to find starting points for further inspection..

The idea, therefore, is to make it easy to record and replay developer interactions with the system under study to make comprehension easier.

The dream record/replay tool

Ideally, there would be a single tool that would allow you to record and replay. One can imagine a tool that works like so:

./record --context="Booking ticket" --all-input -o booking_ticket.log

…which could be played back like so:

./replay booking_ticket.log

However, things are not that easy in the real world: * Privacy/Security concerns:Features such as Keyboard and mouse logging are typically fraught with privacy and security concerns. OSs therefore lock these down, rightfully. * OS constraints: Since these are typically low level features, each OS implements access to them differently, making integration and abstraction difficult. * Brittle Solution: Assuming we get past these hurdles, we’re still left with a very brittle solution: recorded data are vey specific to the conditions at the time recording and perfect replay requires a perfect recreation of those conditions. * Aide comprehension: Assuming we’re able to make a flexible solution, it must still enable comprehension for it to be of use to the developer.

Check out the github repo for more information.

Github: https://github.com/groktools/recorder

A userspace tracker for everything you do on your computer while you code.

Why lilbro

As found by Maalej et al (page 25):

…we asked developers whether they would share knowledge if their development environments would automatically capture it. … Overall, respondents are rather willing to share knowledge automatically. More than 85% of respondents would share the context of an encountered problem and actions performed to solve it. About 75% agreed to share other knowledge such as the goal of changing a particular piece of code or sources consulted while solving a particular problem. This kind of knowledge would facilitate program comprehension tasks.

lilbro takes this idea to the simplest and extreme manifestation - a tracker for everything that you could do on a computer so that you can review it later, reflect on it and potentially share it.

Github: https://github.com/groktools/lilbro

Store your thoughts about code - in the code!

journal is a simple tool to track your thoughts as you code. It allows you to write memos to yourself (and potentially other team members) to explain the concepts that go into your code better. Or maybe its just notes that dont fit anywhere else or maybe they’re high level todos. You decide!

Why journal

As found by Maalej et al (page 27, emphasis mine):

Context information also seems to play an important role when supplying the knowledge needs of developers in program comprehension scenarios. For instance, the context of the task in which the program was developed, including the rationale, the developer’s intention when writing the code, and the intended usage of the program, seems to be frequently needed by developers (see Finding 4, Finding 20, Finding 23 and Figure 3). Unfortunately, our findings reveal that context information is typically implicit and not captured. For example, respondents rated missing context of documented knowledge about programs as one of the most frequent knowledge access barriers. Similarly, context switching overhead was rated as one of the most frequent knowledge sharing barriers.

One possible strategy to overcome these barriers is an integrated, context-aware tool support for knowledge exchange: enabling a (semi-) automatically capturing and sharing of knowledge with its context by observing developers’ interactions [Maalej et al. 2014]. Moreover, insights about the work patterns of developers from this and other studies (e.g., Murphy et al. [2006]; Parnin and Rugaber [2009]) can be used to build personalized tools that are aligned to the workflow of developers. For example a tool that detects the current high-level activity of developers from low-level actions can be used to provide only information that is relevant for the current problem [Roehm and Maalej 2012].

This tool latches onto the idea of a context-aware tool that captures and stores the knowledge of the developer as the code is built for use by both the primary author and others later.

Github: https://github.com/groktools/journal

Atom Package: https://atom.io/packages/journal

git-authors is a simple addition to your editor - it displays the authors for a file so that you can contact them if required. Their % contributions are also shown.

Why git-authors

As found by Maalej et al (page 20):

The more people developers know, the easier they can identify which ex- perience is worth sharing, with whom, and how.

A simple Atom plugin bridges this gap by displaying the list of authors along with their percentage contribution to the file by line.

Github: https://github.com/groktools/git-authors

Atom Package: https://atom.io/packages/git-authors

Add a reason for your change in the commit message

Introduction

whycommit is a simple addition to your git workflow - it adds a template for your commit messages that helps you to guide future readers so that they understand your change better.

As found by Maalej et al (page 19):

More than half of respondents agreed that they encounter problems at least weekly due to missing knowledge about “why was this code implemented this way”, “what was the developer’s intention when writing this code”.

whyCommit helps to bridge this gap and includes:

• A commit message template (whycommit-template.txt) that requires the author of the change to answer this question for future readers to grok.
• A bash/bat shell script to install the message template for one repo or for all of them.
• A bash/bat shell script to install a pre-commit hook preventing commits without a Why section (with an escape hatch for “small” commits detailed below).

Github: https://github.com/groktools/whycommit