
Coding and drawing - danso
https://statmodeling.stat.columbia.edu/2020/08/08/coding-and-drawing/
======
dopu
One way in which I've found the two to be incredibly similar: they're both
very good at throwing me into the flow zone. And I love being there, which is
why my full time job is basically programming all day long.

They're different because you're solving pretty different problems when you're
doing them. Drawing well requires honing the particular set of fine motor
skills which allow you to set down lines smoothly. It also requires you to be
able to visualize shapes well, and to develop a good aesthetic sense. These
things are for the most part nonverbal, and require a long time to master.
When I'm drawing, I'm not really thinking as explicitly about what I'm trying
to do as when I'm programming. It's more seat of the pants, because you can't
put a line down 100% in the way you'd like to. And you're not really trying to
anyway. You adjust here and there, but ultimately "right" is just a subjective
feeling. Programming isn't fuzzy like that -- there are particular bounds to
what the the compiler is going to let you do, and there is often a well
defined "correct" behavior. The problems you're solving in programming are
much more easily verbalized.

~~~
kasool
I agree with the difference you describe. A lot of people who are "naturally
gifted" at drawing just have an intuitive sense of what is right, and just are
able to draw without thinking too hard. When master artists are sketching the
layout of their scene, they're not necessarily explicitly thinking about
vanishing points and perspective. With practice, this stuff becomes completely
intuitive. Unfortunately this often means that the best drawers are not
necessarily the best teachers : )

For the record though, I think pretty much anyone can learn to draw "well".

------
tmountain
The author says he finds drawing to be very difficult, and I hear a lot of
folks say this. Someone who sits down at the piano occasionally would likely
say that they find the instrument difficult, or that they're "no good at
piano". The difference from my perspective is that culturally we tend to
accept that most people can become reasonably proficient at the piano with
practice (even without innate musical ability). Playing the piano is a
mechanical process. You hit the right notes at the right times, and it works.
The same people that accept the piano as something learnable often think
drawing is something you have to be innately good at, and I don't think this
is true at all. Almost everyone has the necessary muscle control (if you're
using the right parts of your hand/arm). If that weren't the case, people
would not be good at tracing over images and rendering them true to the
original. Once you accept that fact, the other primary requirement is building
up objects from primitives. You can render a human standing in almost any
posture just using ovals, rectangles, trapezoids, etc. The point I'm trying to
make is that drawing is a learned skill, and almost anyone can draw whatever
they want if they practice properly and consistently (focus on drawing ONE
thing well before you move on to the next). It's not magical, and it doesn't
require some innate talent to reach an acceptable level of competency. That
said, there is a huge divide between "masters" and mere mortals, but the same
could be said about programming, music, or any other discipline.

~~~
eigenhombre
> Once you accept that fact, the other primary requirement is building up
> objects from primitives. You can render a human standing in almost any
> posture just using ovals, rectangles, trapezoids, etc.

There are neat examples[1] of this in art history, and the highly regarded
drawing instructor Robert Beverly Hale wrote books[2] emphasizing simple
volumes as the basis for understanding and communicating the forms of the
human figure.

There are a few other basic systems that are involved in "classical" drawing;
perspective is one of these; organizing values is another. Basic artistic
anatomy goes a long way if you're going to draw faces and figures. But the
bottom line is, yes, drawing _is_ a teachable skill. And, like programming, it
takes years to learn well (I have been programming and drawing most days for
the last thirty years and am definitely still learning).

[1] Cambiaso, is a classic example, e.g. [http://www.blockprojekt.de/cubic-
drawing-by-luca-cambiaso](http://www.blockprojekt.de/cubic-drawing-by-luca-
cambiaso) [2] See, for example, his "Drawing Lessons from the Great Masters"

------
powersnail
> I have an idea in my mind of what I want the drawing to look like, but my
> pencil does not follow my orders.

From my very short learning of sketching, I had a feeling that there's a
precursor step before the pencil touches the paper: a mental rasterization
process. Our brain wants to see things in a symbolic form, a dog, a yard, a
tree. To draw, however, we must force our brain to see the imagery data: the
highlights, the shadows, the gradients.

My drawing education was only a few months long, so I could be drawing a far-
fetched conclusion here. I'd love to hear what experienced artists think of
their own mental process before actually putting down the image.

~~~
ljp_206
This is the thought behind Drawing on the Right Side of the Brain[0], which
I've always meant to get more in to after purchasing the book in college. One
simpler way of saying what you said is that when asked to draw a person, many
draw a stick figure, and yet, that is not what people /look/ like, or rather,
are /seen like/. The five components listed on [0] reinforce what you've
suggested ("imagery data") are required for true sight-to-paper 'drawing.'

0: [https://www.drawright.com/theory](https://www.drawright.com/theory)

~~~
cyberdrunk
This book has rather mixed reputation among the art professionals. It's
attractive to beginners because it allows you to fairly quickly become a human
camera/xerox machine - you will be able to exactly copy what you see. However,
it does nothing for your drawing from imagination skills, incl. making even
minor modifications in the copied image. So, it's a great book if you want to
just copy. However, if you want to create, you need much richer skills.

~~~
ljp_206
Indeed - something I appreciate about the book is that it suggests that
learning to draw is impossible to unlearn once you learn it, like riding a
bike. It definitely tracks with the idea that there's more to learn after you
get up and figure out the basics.

------
codingdave
I have a degree in Fine Arts and spent a couple decades as a coder. They are
more similar than people might think, but you need to abstract the process out
a bit to see it:

If you are starting a new coding project, you don't typically just start
writing the final details for one feature, and then finish it and go to the
next feature. You set yourself up for features by choosing a tech stack,
setting up an IDE, databases, maybe some boilerplate starter code. You get a
UI started, at least a blank page rendering that you'll code a feature onto.
And then you start writing a feature. You code out the broad strokes of what
it will do, and then work down to the details.

Drawing is the same. You choose your media, the surface on which it will go.
You think out where it will fit on the page, where each piece of the drawing
will land. You literally draw out the broad strokes, and then fill in more
detail as you go.

If you approach drawing as a process, just like you code, it becomes much more
manageable.

~~~
mattmanser
Isn't that true of virtually any endeavour?

~~~
codingdave
True, good point. Perhaps people just don't have an awareness of the process
when they are new to drawing because we see people put pencil to paper and a
drawing comes out - the process is completely internal to the artist, not
visible to an audience.

------
idlewords
If you want a quick and kind of neat insight into your visual brain, find a
photo of a face and try to draw it by eye (without tracing or measuring). Then
turn it upside down and try again.

There's a whole bunch of image processing steps your brain turns off when you
aren't recognizably looking at an object you know (especially a human face),
and most untrained people will find they can draw a human face much better
upside down.

------
Pamar
One thing (that worked well for me) is to practice some sort of artistic
endeavour that is not meant to be "figurative".

Specifically, I started practicing ShoDo (Japanese calligraphy) ~12 years ago
- here is a sample of my best works from 2019: [http://pa-
mar.net/Study/ShoDo/2019inShoDo.html](http://pa-
mar.net/Study/ShoDo/2019inShoDo.html)

In reality I always liked drawing, I do sketch stuff during meetings and
really like visual tools to reason about stuff. But for some reason I never
really found the time to improve my drawing abilities.

More recently I did start drawing in the traditional sense, and this is
something I do enjoy a lot (and yes, I experience something close to being "in
the zone", too). Assuming you can find a bit of time in your day I think that
any kind of drawing practice, even just doodles, can be fun, relaxing and
possibly provide other benefits too (like going for a walk helps you work on
problems in the back of your mind).

------
egfx
I was harping about how else to describe simple programming constructs
yesterday and came to the idea that you can essentially think of types in the
same way you can think about primitives in 3D design. In 3D design primitives
like cubes and cylinders are the basis of all kinds of more complex objects.
And in programming you have simple types like strings and numbers. This is the
opposite of the authors problem. But it would help an artist who wants to
understand how to code. ;)

------
pcmaffey
The key difference for me in the process of making code vs making art is error
handling. When drawing, knowing you made a mistake is entirely up to you,
which adds extra cognitive load.

I wrote about this a bit: [https://www.pcmaffey.com/debugging-your-
art](https://www.pcmaffey.com/debugging-your-art)

------
082349872349872
The distinction between hard, soft, and lost edges[1] from drawing also works
for coding.

In code, a _hard edge_ is a crisp representation change between two layers of
code ("object-relational mapper"), a _soft edge_ is a gradual representation
change over multiple layers or libraries ("ravioli code"), and a _lost edge_
is when one manages to interpret the same data differently without even
bothering to explicitly change its representation (0x5F3759DF).

[1]
[https://news.ycombinator.com/item?id=23437889](https://news.ycombinator.com/item?id=23437889)

------
Daub
Unlike most of you fellows, my coding skills are akin to those of a dog.
However, I can draw like an angel. From this experience, I can say that they
both manifest as complex syntax, and this syntax can be elegant or clunky,
succinct or elaborate, effective or ineffective.

The key difference seems to be the different ways that they can fail. Code can
break in ways that are beyond argument. Certainly a drawing can break, but it
is always possible to claim that it has not (e.g. 'I drew one foot larger than
the other on purpose').

~~~
suprfnk
> (e.g. 'I drew one foot larger than the other on purpose').

"It's a feature, not a bug"? ;-)

------
imgabe
I like coding and I've always been terrible at drawing. Granted, I never
worked very hard at, but I was pretty abysmal to start with.

What I do like is _drafting_ as in with AutoCAD or similar software. It's one
thing to try to hand draw a line that accurately represents the outline of a
human face. It's quite another to just say "Ok, this should be 16 cm long in
the horizontal direction then turn 45 degrees with curve that has a radius of
1cm..." and so on.

The latter makes a lot more sense to me a produces much better results.

------
f0rfun
There is nothing here imho. It's just mastery of crafts, how often/much you
practice (not just rote learning) and I guess to a smaller extent, natural
proclivity/talent.

------
hairofadog
I'm a self-taught programmer, but my degree is in visual art. I'm not sure
this is true for everyone, but I very much think about programming visually:
how everything ties together, how things are scoped, which objects are
subclasses or instances of other objects, etcetera. I can't really grok
anything until I have a visual metaphor for it. While it can sometimes be
helpful, I also worry it holds me back in areas that may not translate well to
visual metaphors.

~~~
NateEag
As an aphantasiac who programs for a living, I know that I do not think about
code in visual metaphors.

~~~
hairofadog
I hope this doesn’t sound insensitive, but I find that condition fascinating
(if “condition” is even the right word - seems more like just a different mode
of thinking) because I can’t even begin to imagine what it would be like.

~~~
NateEag
Not insensitive at all. I only realised mental images exist for anyone a few
years ago, so I don't think of it as a disability, really (though obviously
some things are way easier if you can visualize, like mental math).

I am not purely aphantasiac - I do on rare occasions get very blurry,
ephemeral flashes of imagery. It's like seeing an impressionist watercolor on
a ragged piece of flash paper that ignites the instant I look at it.

Pluses of the condition:

\- disturbing images are gone the instant I look away.

\- I cannot get lost in a daydream. This roots me in reality and the moment in
a way I think few people are.

\- probably contributes to my native ability to speedread (if you can't
visualize you do not spend any time doing it, and I think that makes me
faster)

\- I'm not limited to visual modes of thought. Someone has speculated in the
past that maybe aphantasiacs are better at abstract concepts and thoughts
since we are not tied to the idea of visualizing as part of understanding.

Minuses:

\- probably contributes to my poor memory

\- makes it hard to understand most peoples' experience of life

\- makes certain thinking and reasoning tasks massively harder than they are
for neurotypicals

\- makes empathy harder, IMO. I cannot "put myself in your shoes" the way many
people can.

------
justanothersys
I've been doing a lot of scored drawing pieces, where I draw the same marks in
a certain order within a certain timeframe:
[https://www.youtube.com/watch?v=j6n4FpHbqZs](https://www.youtube.com/watch?v=j6n4FpHbqZs)

This is a sentiment close to my heart.

~~~
lsinger
Wrong link? That’s a Japanese music album. Lovely but probably not what you
meant?

------
mike_n
perhaps OP has aphantasia? Seems fairly common among engineers (and even some
artists) --
[https://www.theguardian.com/lifeandstyle/shortcuts/2019/apr/...](https://www.theguardian.com/lifeandstyle/shortcuts/2019/apr/10/aphantasia-
why-a-disney-animator-draws-a-blank-on-his-own-creations)

------
sporkologist
I think of coding as being more commonly associated with playing an
instrument, but there may be something here too.

------
MikeTaylor
Who else saw the title of this and immediately thought _Hackers and Painters_?

------
mauritzio
A prerequisite of drawing is knowing the thing you draw p.e. the human anatomy
and knowing the perception tricks your brain does with the visual input and
being able to master the physical use of a drawing tool in its variety. Then
you compose with a goal in mind and observe very open, patiently and detailed
while you make suggestive visual marks such that some details will work
together to form a whole unity, and the whole supports the natural detailed
variety. Playfully arranging paths for the eye of the viewer, such that while
it travels over the drawing the perception meeting the viewers inner mental
model of the world triggers an emotional response. Each of these things can be
trained, and even non gifted can achieve reasonable results. You can use
simplest tools and as long as human brains do no change too much they can
relate to drawings which are 2000 years old.

For coding you must know how a program statement works, how hardware and
virtual resources are working and ideally have a systematic analytical
approach to construct and to define, identify and resolve misbehaviors. Have a
mental goal how all peaces should work together, how they form a rigid stable
architecture of unity, while also allowing a variety in further desirable
transformations. Envision all possible desirable state and machine changes
during runtime and later system extension and avoiding unwanted ones. At this
point it leaves the right/wrong world view. Cutting an architecture out of the
solution space of all possibilities, growing from bare bones, little peaces to
a complete system. Each of these things can be trained, and even non gifted
can achieve reasonable results.

While we can learn from good drawings it is not so easy to learn from good
programming examples.

The problem with code is that while we are often working with same principles
like imperative functions and stack machines since 50 years, the technical
application environment is still constantly scaling up and while it is
conceptually never new it keeps working only during short periods, so no long
term solution are envisioned. Further more the result is not open to an easy
perception or naive judgement (besides app rating maybe) and the result is
often unlinked to the creator. An envisioned whole system is no longer needed
as we have monopolized systems, wich updates we all follow frightened to
'reduce' risk. Resources like memory are scaled up without limits, the number
of programmers rises and we are told to work in teams achieving very well paid
very mediocre short living results. So the art of coding is on decline and
while the 'management' of churning out buttons on 'app' screens, pasting stuff
and fiddling in frameworks called consulting is on the rise. In absolute
numbers maybe good programming examples where never as easy accessible as
today, but is often buried below all the noise and not very rewarded. Probably
the result of the economical success of the applied art of coding.

So for an coding artist fiddling with a pencil and paper to make something out
of nothing can be again very rewarding... or maybe fiddling with vi and
compilers etc. :-D

