Ask HN: How do you visualize code in your head?

Depends on the type of code, for GUI related I visualize the interface as if it was in my IDEs GUI builder, where I mentally can double click a component to be switched to the relevant section of code.

I almost visualize flying through the GUI components to see code revealed underneath. I don't actually see lines of code (I guess my mental-visual resolution is too low) instead I sort of sense whats needed. I can 'feel' the code. What event listeners will be notified, what classes are needed, how the code flows, how it will mesh together.

But thats for when I am in design mode, when incurring technical debt and pushing towards a deadline my thinking is extremely non-visual, more auditory in nature as I verbally think though the problems in my head.

UML has influenced me into thinking of methods and objects as black boxes and focusing on the relationships between them as opposed to their implementation. A slightly abstracted view gives some much needed perspective and keeps it clean(er).

I don't, really. Its just in my head, and comes out when it needs to. If that makes any sense.

Maybe a blob of unformatted information, if I had to pick something.

I dreamed in code last night. It was the actual code, in different colors against a black background. I don't think that means anything, but it probably has a lot to do with staring at TextMate for 10-12 hours a day.

I'm actually going to implement the ideas I came up with in my dream, they were pretty good.

Lots of moving shapes, especially if there are threads. Usually they are visual-kinesthetic representations of how the data structures fit together, what they do (as movements), and what it looks like when there's a bug.

The word "visualize" makes this a somewhat leading question (though personally my process is visual/tactile).

The best book I know of about this is Jacques Hadamard's The Psychology of Invention in the Mathematical Field. He asked this same question of the important mathematicians of his day - and because he was Jacques Hadamard, they answered. Einstein's response in particular is fascinating. Although math is published in symbolic form, nearly all the mathematicians surveyed reported that they thought in images, sounds, or movements. Only Polya believed that his creative process involved symbol manipulation.

Seymour Papert's Mindstorms is good reading too - the Logo turtle was very deliberately designed to transfer physical expertise into programming skill.

Im not a very visual thinker, but I've been getting better at visualizing things. Since i mostly write lisp code i see it as it is, like a tree of expressions, instead of as a sequence of characters. I see my data structures and see the way they get manipulated as trees as well. I've been playing with graph algorithms, a DFS is remarkably beautiful to see, in ones head. You can see it as water spilled on the graph, and the vertices are like grooves the water flows through.

When I code I have sort of a mental list I keep in my head for what I'm currently building. So I'll have textbox, textarea, submit button, trigger on submit, validation, database, sterilisation, etc etc. I just kind of work through the list in my head and often add to it as I think of something else.

Visualization is a key part in understanding the code. IMO if you can't visualize it then you do not have a proper understanding.

Visualization for me is at 1000 feet and i do not see all the details. I try to think and visualize each as objects and abstract out the details. I do not see colors and whenever possible i relate it to realworld object OR Object which we see in screen.

While working on a existing code, the Visualization is not complete. I do not try to visualize all the code in one day, i build it incrementally over a period of time. But before starting with the project/code I get a highlevel overview before getting into details.

I believe it is analogous to a Map, I create a mental map of things in code and use it as a reference, build it, improve it. Map is NOT a terrain, it just gives an overview of things.

It depends what it is but typically no, my thoughts are much more abstract than pictures. It took me a while to realise that many people, often my clients, do not work like this and need to see things visually before it clicks.

very carefully?

I don't think it's really visual, it's just like metavisual thinking without engaging the phonological loop.

I visualize graphs most of the time, sometimes with colors or textures but usually fairly simple planar graphs.

I see a haze of confusion and anxiety, usually.

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?

This came up over breakfast this morning, coincidentally.

I start out with a mainly visual representation like a graph, with modules as nodes and edges as interconnections. I'm possibly strange in this regard, but my perception changes as things get more complicated. Once this graph gets sufficiently complicated that it's difficult to represent it as a planar graph (too much edge overlap), I lose the visual representation but can continue to reason about it. What's left isn't particularly visual, nor is it textual... I'm not sure how to explain it really. I end up manipulating this abstract "thing" in my mind, which I can translate (on paper or in code) to a concrete representation after the fact.

Anyone else have similar experiences?

I don't usually see code, but I see the architecture in flowcharts. For the parts which I've not completely worked out, the chart just fades to an ominous fog.

I've kept an eye on this thread trying to think of how I think of code.

This is the best explanation I have -- I don't think in/visualize code at all.

I think of the individual parts that make up what I am trying to build.

This starts in the broadest sense (application requirements) to the more in depth needs (specifically what function ideas (what is going in, what is coming out) and in what order they will need to be in).

By the time I finish this architecture layout in my head, actually coding everything becomes very straightforward.