It's important because you get a different perspective on a "story" from the artist's side, and it gives you an idea of how to communicate: there are moments of "drawing the reader along" with a causal sequence, and "moments of reflection" where you pause and say "here's why you care about this."
If you think about writing a good tutorial, I think everybody understands that it should be incremental knowledge, that you should build upon whatever your students already know. But lots of tutorials are confusing precisely because they lack the other bits. Some tutorials look more like API documentation -- a bunch of disconnected things; no causal narrative goes between them. Other tutorials -- especially in functional programming! -- link together a whole lot of great ideas incrementally, and it's a killer story... and it's never really for anything.
Contrast this with SICP for example, that famous realization which many of us had where you're halfway through this Lisp course and suddenly, out of nowhere, the authors say, "okay, let's introduce the assignment statement." And you have this moment of reflection -- "wait, assignment statements aren't necessary?! ... huh! I guess they weren't! I did a lot of stuff without them already!".
Even if it's a tiny little moment where you mention, "okay, so here's an example of what you were writing before, here's why it's ugly, here's how this new technique does better" -- that sort of short intermezzo can be so amazingly helpful for learning programming that it startles me how often it's missing from tutorials. I think a good understanding of storytelling can help inform how we present information in general. (This especially holds when you draw a distinction between new ideas and news, as Alan Kay does in the SRII 2011 keynote: http://vimeo.com/22463791 .)
There are a couple of stories that comes to mind when reading this. The first one has to do with with Picasso while the second one has to do with Golf (well professional sports).
1) The story goes that Picasso was sitting in a Paris café when an admirer approached and asked if he would do a quick sketch on a paper napkin. Picasso politely agreed, swiftly executed the work, and handed back the napkin — but not before asking for a rather significant amount of money. The admirer was shocked: “How can you ask for so much? It took you a minute to draw this!” “No”, Picasso replied, “It took me 40 years”
2) I was watching Golf the other day and saw how huge the purse was. I think Tiger Woods won over $1million dollars for 4 days worth of work. A lot of people would say that its not fair and that its way too much money. But think about it for a second. This guy started playing golf since he was a kid. Has been playing it every day, hours on end for 35+ more years. He lives, breaths, sleeps Golf. He his Mr. Golf. That $1mil payday is just the embodiment of years of "sacrifice" and enthusiasm for mastering a craft.
I wrote a bit, but the point is exactly what this comic is about. Its not about the money, but about working towards a goal. To find out what the goal is, you have to have "good taste" and know that what you're doing isn't satisfactory. I'm that way with a lot of things, but I'll stick to coding on this one. When I finish writing a module, I stare back at it as if I'm a painter looking at his masterpiece. I scrutinize it and eventually come to a conclusion of whether or not its worthy of pushing to production. Some of my work gets pushed because its "good enough" to do the job to my dismay. Others (a few) are masterpieces to me. Even though the user or project manager doesn't see it, I know that I wrote something special. I guess that's what's drives me forward.
I know I'm not the greatest developer. I don't work at a fortune 500 company. Until recently, I didn't even know what great code looks like, let along UI design. Everyday, I do strive forward because I know that it will drive me crazy if I don't at least "try" to reach that level.
Unfortunately, in this industry (like in most), you can get by being mediocre.
Creating a great product needs time and hard work. This story beautifully illustrates that.
Earlier I used to spend so much time worrying about being perfect that many times I wouldn't even start. It's only now I realize the importance of creating good work every day, even though it may not be the best one.
I guess you could say I'm one of those weird programmer/designer hybrids. One thing I find fascinating is when I get into a long programming stint just how difficult it is to get back into the design mindset. I usually have to spend a few days producing, what I consider complete garbage, to get back into the groove. After that the creativity starts to flow naturally again.
It is almost seems like a muscle that atrophies without use. I wonder if that is why you see benefit in creating works each day? And why programmers are stereotypically said to be not be able to design, even though I see a lot of overlap.
I find my problem relating to this is the ladder up against the wrong tree/building problem, it seems an absolute bugger to work out. The good news is, I know when I do I have the tenacity and work ethic to constantly get better
Zen Pencils has several entries that do an outstanding job of capturing the quotes being illustrated. It's a shame they get classified as "derivative" works, because they all have quite an amount of original effort and thought put into them that, in my mind, separate them from the original works. However, there are still some that can be ordered as prints.
I can totally attest to this, but for me the story played out a bit differently. My v1 designs for the company I'm working on now look like trash, but at the time, I tried to convince myself that I liked them a lot. Deep down, I know they weren't fantastic, and people told me this, but I equated the quality of the work with the number of hours I'd spent.
Turns out, a lot of what I spent time on was learning specific UX techniques from different places that looked pretty ugly when they were all smashed together. I think it's analogous to programming (when you learn a concept, you kind of want to force it into the project you're working on, even if there is little to no relevance).
All in all, I agree with the message. Becoming a great designer takes a lot of patience, hard work, and iteration. You have to be okay with throwing entire pieces away in pursuit of something better.
I was at a Startup Weekend a couple weeks ago and had the opportunity to talk to one of the speakers about the UI I'd put together (his speech was on U(I/X)). I knew my landing page didn't look modern, but couldn't put my finger on the reason why. He asked some excellent questions that forced me to understand the principles and the site looked a lot better after a few tweaks.
It's easy to be a critic (especially of yourself), but it's so much more important to answer the question 'Why is this bad?'. It's difficult. I'm not aware of any AI that can do this. It's what separates us from the machines... for now :P
We get into it because we [think we] have good taste.
Sometimes "making it" does just take working long and hard enough to get to the point that our output matches our taste--and then everyone else can see how great it is too, and wants to buy it. Success!
Less talked-about is that sometimes its turns out that we actually didn't have such great taste after all. Our output matches our taste but it still doesn't sell in enough volume to make a living.
Or sometimes it turns out that our taste is derivative. A Batman fan who makes a new superhero that simply mimics Batman might not be very successful with it. It's harder to make something original that matches the taste for Batman.
The crappy part is that there is no way to tell in advance who is going to make it or not. So we encourage everyone. The ones who make it will benefit us all...the ones who don't will fade into obscurity. It's a hard truth but it is what it is.
Thanks to all HN users who upvoted this story. I don't remember seeing comic strips on HN frontpage, and wasn't sure about sharing this post. But I found it really good, and am glad you all found it useful.
the 10,000 times criteria is as old as the chinese saying, that supposedly is its origin. But since then, till now, we have been living under a near non-existent form of communication, it was the advent of TV, Internet, and stuff, that helped ideas cross traditional borders freely. As that happens, people will become better and better, I feel that 12500 times/hours is the next 10,000. Lets just cut our obsession with the round 10, easy for arithmetic.
Perhaps I'm getting all external-locus-of-control here, but I actually think most people get it when it comes to creation being hard. I give them credit on that. I don't think there's actually an epidemic of people who fail to thrive because they struggle in the intermediate creative stages. I think people understand that it's a part of the process everyone has to go through. It's intellectually demanding, but if you can enjoy the small victories, you can get through it happily (and then will remember those times fondly.)
The problem is That Work Shit. No, I don't mean that people are averse to working hard. The contrary is true. Ever see a programmer blow up on his jackass-interrupter boss, because he wanted to keep working done rather than deal with an impromptu status ping? People like to work. They do. Leave them alone and most people will be productive. At least, most people whose efforts will be worth anything will be productive. Who cares if the bottom 20% use freedom and autonomy to slack off? They won't deliver much value no matter how hard you beat them.
Unfortunately, most of us are stuck in this corporate matrix where even cognitive 1-percenters have to sell themselves to middlemen called "managers" who take all the credit, and to take subordinate roles because a bunch of rent-seeking assholes have (in most settings) taken everything important or interesting for themselves. The result is a culture where there's no improvement and where motivation dies, usually around age 30. (People have kids, then decide that their creative existences are over and commence living vicariously through miniature creatures genetically similar to themselves, then find themselves chagrined when most of those turn out to be separate people with their own agendas.) We see this in the shitpile that is 95% of software engineering, where improvement never happens and horrible code gets written and dumbasses make all the decisions.
I don't think people get burned out in the intermediate stages because they're lazy or because they have a childish need for praise. I think they get to a point where they realize they're still not getting enough back to compensate for the obscene (artificially high, due to phony scarcities and corrupt) costs of living so they cut off and go back to their boring paid work.
https://www.youtube.com/watch?v=loxJ3FtCJJA&playnext=1&#...
It's important because you get a different perspective on a "story" from the artist's side, and it gives you an idea of how to communicate: there are moments of "drawing the reader along" with a causal sequence, and "moments of reflection" where you pause and say "here's why you care about this."
If you think about writing a good tutorial, I think everybody understands that it should be incremental knowledge, that you should build upon whatever your students already know. But lots of tutorials are confusing precisely because they lack the other bits. Some tutorials look more like API documentation -- a bunch of disconnected things; no causal narrative goes between them. Other tutorials -- especially in functional programming! -- link together a whole lot of great ideas incrementally, and it's a killer story... and it's never really for anything.
Contrast this with SICP for example, that famous realization which many of us had where you're halfway through this Lisp course and suddenly, out of nowhere, the authors say, "okay, let's introduce the assignment statement." And you have this moment of reflection -- "wait, assignment statements aren't necessary?! ... huh! I guess they weren't! I did a lot of stuff without them already!".
Even if it's a tiny little moment where you mention, "okay, so here's an example of what you were writing before, here's why it's ugly, here's how this new technique does better" -- that sort of short intermezzo can be so amazingly helpful for learning programming that it startles me how often it's missing from tutorials. I think a good understanding of storytelling can help inform how we present information in general. (This especially holds when you draw a distinction between new ideas and news, as Alan Kay does in the SRII 2011 keynote: http://vimeo.com/22463791 .)