
Ask HN: How do you visualize code in your head? - matth
I just realized something a little weird. When I think about code, I see the code itself. I picture the text, line breaks, the structure of the file, etc.<p>What about you? Do you see colors? Shapes? Objects? Do things move or is the picture static?
======
nix
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.

------
kateray
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.

------
tonyarkles
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?

------
Cur8or88
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).

------
sundar22in
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.

------
tcneyland
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.

------
pavelludiq
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.

------
SHOwnsYou
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.

------
Zev
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.

------
TamDenholm
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.

------
barrydahlberg
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.

------
ndl
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.

------
cmykgrayscale
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.

------
keefe
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.

------
damoncali
I see a haze of confusion and anxiety, usually.

------
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?

