Coding and drawing - <AUTHOR> https://statmodeling.stat.columbia.edu/2020/08/08/coding-and-drawing/ <comment><USER2> 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.

<comment><USER3> 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".

</comment></comment><comment><USER4> 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.

<comment><USER5> > 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"

</comment></comment><comment><USER6> > 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.

<comment><USER7> 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)

<comment><USER8> 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.

<comment><USER7> 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.

</comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> Isn't that true of virtually any endeavour?

<comment><USER9> 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.

</comment></comment></comment><comment><USER11> 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.

</comment><comment><USER12> 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).

</comment><comment><USER13> 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. ;)

</comment><comment><USER14> 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)

</comment><comment><USER15> 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)

</comment><comment><USER16> 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').

<comment><USER17> > (e.g. 'I drew one foot larger than the other on purpose').

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

</comment></comment><comment><USER18> 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.

</comment><comment><USER19> 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.

</comment><comment><USER20> 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.

<comment><USER21> As an aphantasiac who programs for a living, I know that I do not think about code in visual metaphors.

<comment><USER20> 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.

<comment><USER21> 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.

</comment></comment></comment></comment><comment><USER22> 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.

<comment><USER23> Wrong link? That's a Japanese music album. Lovely but probably not what you meant?

</comment></comment><comment><USER24> 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)

</comment><comment><USER25> I think of coding as being more commonly associated with playing an instrument, but there may be something here too.

</comment><comment><USER26> Who else saw the title of this and immediately thought _Hackers and Painters_?

</comment><comment><USER27> 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</comment>


The only proven thing helmets protect us from are fines - <AUTHOR> http://www.guardian.co.uk/environment/bike-blog/2012/nov/13/helmets-australia <comment><USER2> Stop this. It's really dumb that there is a group of bicyclist insisting helmets don't protect your head. There is a similar group of motorcycle enthusiasts and every day there are a few less of them. Hit your head on the cement with and then without a helmet on and you will see. They work without question.</comment>


Incredible xkcd Money Chart - <AUTHOR> http://xkcd.com/980/

<comment><USER2> Two hours shopping and prep for a dinner of pinto beans and rice? The smallest bag of rice at the grocery store should suffice for a couple of meals for four, and while you're at it, why not throw in a second bag of beans. And if you are counting in the cooking time as continuous, why not also the overnight soaking of the beans? That should make Outback Steakhouse much more economical.

</comment><comment><USER3> I cannot begin to imagine the intensive research that went into this infographic, and props to Randall for the work.

But for the life of me, navigating this thing in tile form is beyond me.

</comment><comment><USER4> Can someone explain <http://screencast.com/t/CFzp8f8Dx9> this section to me? I assume it was supposed to be "Typical 1965 CEO pay for the same period" on the left and "Typical 2007 CEO pay for the same period" on the right, but I also might just not be grasping the point.

<comment><AUTHOR> I imagine the comparison is supposed to be based on adjusted for inflation wages, 1965 to 2007.

This article has similar numbers: <http://www.kyklosproductions.com/articles/wages.html>

Also includes this quote. "As one source has put it, "in 2000 a CEO earned more in one workday (there are 260 in a year) than what the average worker earned in 52 weeks. In 1965, by contrast, it took a CEO two weeks to earn a worker's annual pay"."

</comment></comment><comment><USER5> Sadly, top center, a typo: 'Saudi Aramco' (not 'Armaco').

I mention it here because it's not exactly easy to contact RM...

</comment><comment><USER6> Where could I download this as one huge stiched image, please?

<comment><USER7> <http://imgs.xkcd.com/comics/money_huge.png></comment></comment>