jerryr

I'm definitely a visual-thinker. My code visualizations are largely influenced by standard representations of software (UML diagrams, state machine diagrams, block diagrams, etc.), but my mind's eye wanders all over the place depending upon what I'm doing. If I'm coming up to speed on an existing code base, I immediately begin forming a mental block diagram--simple blocks of varying sizes with little arrows indicating hierarchy. If I’m navigating any form of state, I see a state machine--generally a big blob that grows with the complexity of the machine, but with the states I’m currently inspecting in focus. When dealing with threading issues, I frequently see each thread as a square container with an animation of shared resources being passed from container to container. This is supplemented by something I can only describe as an animated timing diagram. I’m an embedded firmware engineer, working mostly in C. When thinking about anything that interfaces with the physical world, I tend to see a classic diagram--a temperature curve, motion path, timing diagram, etc. For timing diagrams, I’ll visualize code snippets overlaid along the diagram itself--they’re wrapped in small blocks whose size indicates my perceived latency of the code (to be updated as proven).

Reverse-engineering automotive ECU firmware for an engine-tuning company provided an interesting visualization experience. The task involved manual, static analysis of thousands of lines of uncommented assembly. I was using DataRescue’s IDA Pro, which does a good job of visually separating functions and indicates code flow with lines and arrows in the left-hand gutter. It also keeps a color-coded, linear map of the entire codebase at the top of the screen--if you haven’t seen it, it looks a bit like a typical visualization of hard drive fragmentation. I found myself navigating the code largely by keeping a map of blocks and a mental stack of my moves. The blocks were the outlines of left-justified disassembly text whose sizes corresponded to the size of a function. I started to quickly identify functions by their sizes and the vertical "cityscape" that the disassembly text defined. During this time, DataRescue introduced a new IDA Pro feature that visualized the code in a flowchart form. Sequential, non-branching statements were arranged in squares that were connected with arrows to indicate where their terminating branching statements could lead. It is a spectacular feature, but it obliterated the visual cues I’d been mentally mapping & greatly slowed down my navigation. So, I’d shut it off and navigate the "cityscapes" to find a function of interest, and then enable it to inspect the function in more detail.

I love this question & have repeatedly asked it of friends/colleagues. The answers feel like a peek into someone’s brain, though honestly I’m not sure what I’m looking at. In any case, I’m considering adding it to our list of interview questions because it can spark great discussions about code structure and illustrate depth of experience. But I’d love to hear from non-visual thinkers how the wording would be best modified to accommodate you as well. How do you think about code?