Coding and drawing(statmodeling.stat.columbia.edu)
statmodeling.stat.columbia.edu
Coding and drawing
https://statmodeling.stat.columbia.edu/2020/08/08/coding-and-drawing/
42 comments
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".
For the record though, I think pretty much anyone can learn to draw "well".
> 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.
You are onto something here. I wouldn't exactly call myself a coder, but I do draw for a living and would agree this is the essential similarity between the two. Another similitude is that both involve a sense of building and play; who knows, that is perhaps the key to flow.
You are onto something here. I wouldn't exactly call myself a coder, but I do draw for a living and would agree this is the essential similarity between the two. Another similitude is that both involve a sense of building and play; who knows, that is perhaps the key to flow.
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.
> 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 [2] See, for example, his "Drawing Lessons from the Great Masters"
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 [2] See, for example, his "Drawing Lessons from the Great Masters"
> 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.
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.
If you can not imagine, can not make a mental picture, you can not draw. It's called Aphantasia[1].
[1] https://www.facebook.com/notes/blake-ross/aphantasia-how-it-...
[1] https://www.facebook.com/notes/blake-ross/aphantasia-how-it-...
If you're drawing something you can see, I don't see why you would need visual imagination.
Even if you're not drawing from something you can see, you can have a procedural memory of how to draw the thing, and you can see what you've already put on the page, and experiment if necessary using an eraser.
I don't have complete aphantasia, but my visual imagination is pretty weak, and I can still draw.
Even if you're not drawing from something you can see, you can have a procedural memory of how to draw the thing, and you can see what you've already put on the page, and experiment if necessary using an eraser.
I don't have complete aphantasia, but my visual imagination is pretty weak, and I can still draw.
I didn't mean to say you have aphantasia, sorry. I was just trying to give an FYI. The story I linked was an eye opener the way he explained how it works in his head was amazing.
Yes, that is correct. Learning to draw things realistically is done by purging your mental symbolism and trying to see the scene in two dimensions. You also need to unlearn what colours you think things are and actually look.
Slightly disagree. In drawing, we also refer to mental templates. These are derived from long experience of looking at other people's drawing.
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
0: https://www.drawright.com/theory
Really liked this book, and agree that you must draw what you see, not what you know - e.g for an eye, areas of light and dark and their relative positions, not an ellipse with a circle in it. That said, it is worth understanding some basic anatomical rules - e.g. that a persons eyes are halfway up their head, not near the top.
This is why drawing people is such a good test. If you draw a house or a tree, you can get proportions wrong and it can still look credible. But the same types of error stand out glaringly in a picture of a person.
This is why drawing people is such a good test. If you draw a house or a tree, you can get proportions wrong and it can still look credible. But the same types of error stand out glaringly in a picture of a person.
Came here to mention that book. It's fantastic, and was a total game-changer for me when I went through it.
Interestingly, I went through it while taking a drawing class by someone who was not a fantastic teacher, and occasionally taught things directly contrary to how DotRSotB taught them. And wow, did the other students fail trying to follow what he said! It was amazing.
So yeah, go through the book, BUT make sure you ACTIVELY work through it, doing everything she says to do at each step... in fact, I think she recommends that you don't read ahead. It's worth doing it in conjunction with a class.
Interestingly, I went through it while taking a drawing class by someone who was not a fantastic teacher, and occasionally taught things directly contrary to how DotRSotB taught them. And wow, did the other students fail trying to follow what he said! It was amazing.
So yeah, go through the book, BUT make sure you ACTIVELY work through it, doing everything she says to do at each step... in fact, I think she recommends that you don't read ahead. It's worth doing it in conjunction with a class.
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.
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.
A drawing teacher put it like this: "Draw what's there, not set-pieces". (meaning the reusable furniture components in theaters)
Thanks for the recommendation. That's great information.
Yes, this is also what I learned in my drawing studio. Our brains already have a preconception of what, for example, a human face looks like: Eyes, nose, ears, mouth. We think this way because it allows us to quickly recognize what distinguishes a human face from a chair.
But really, as you said, drawing is about SLOWING DOWN and noticing the parts that make up the eyes, nose, ears, mouth. In my own drawing education I've found that the description I'd give of drawing is the "study of shapes", not symbols.
But really, as you said, drawing is about SLOWING DOWN and noticing the parts that make up the eyes, nose, ears, mouth. In my own drawing education I've found that the description I'd give of drawing is the "study of shapes", not symbols.
I think it's similar to coding in that the more you code the more you get used to the type of abstract thinking that coding involves and you can keep more complicated patterns and structures in your mind at once. Drawing is very similar in that people who just start out can just keep in their minds the symbolic representation of an eye or tree instead of the 3d forms + lights and shadows, texture, stylization, etc. Drawing has of course a muscle memory component but the process of learning both coding and drawing is very similar i think, even if the type of thinking required is not the same.
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.
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.
Isn't that true of virtually any endeavour?
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.
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.
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.
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
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).
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
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).
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. ;)
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
I wrote about this a bit: https://www.pcmaffey.com/debugging-your-art
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
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
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').
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').
> (e.g. 'I drew one foot larger than the other on purpose').
"It's a feature, not a bug"? ;-)
"It's a feature, not a bug"? ;-)
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.
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.
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.
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.
As an aphantasiac who programs for a living, I know that I do not think about code in visual metaphors.
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.
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.
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.
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
This is a sentiment close to my heart.
This is a sentiment close to my heart.
Wrong link? That’s a Japanese music album. Lovely but probably not what you meant?
perhaps OP has aphantasia? Seems fairly common among engineers (and even some artists) -- https://www.theguardian.com/lifeandstyle/shortcuts/2019/apr/...
I think of coding as being more commonly associated with playing an instrument, but there may be something here too.
Who else saw the title of this and immediately thought Hackers and Painters?
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
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
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.