P1080917.JPG on Flickr.
This might be a little old (2004) but it is still good.
(via Code Editor Learning Curves - Steve Rowe’s Blog - Site Home - MSDN Blogs)
How to Do What You Love, Paul Graham
Great article by Paul Graham. I go back and read this every once in a while. Some parts I like:
“Always produce” is also a heuristic for finding the work you love. If you subject yourself to that constraint, it will automatically push you away from things you think you’re supposed to work on, toward things you actually like. “Always produce” will discover your life’s work the way water, with the aid of gravity, finds the hole in your roof.
“(A) line you often hear is that not everyone can do work they love—that someone has to do the unpleasant jobs. Really? How do you make them? In the US the only mechanism for forcing people to do unpleasant jobs is the draft, and that hasn’t been invoked for over 30 years.”
“Life tends to get more expensive as you get older, so it’s easy to get sucked into working longer than you expected at the money job. Worse still, anything you work on changes you. If you work too long on tedious stuff, it will rot your brain. And the best paying jobs are most dangerous, because they require your full attention.”
“When you’re young, you’re given the impression that you’ll get enough information to make each choice before you need to make it. But this is certainly not so with work. When you’re deciding what to do, you have to operate on ridiculously incomplete information.”
“…a plan that promises freedom at the expense of knowing what to do with it may not be as good as it seems.”
“Finding work you love is very difficult. Most people fail. Even if you succeed, it’s rare to be free to work on what you want till your thirties or forties. But if you have the destination in sight you’ll be more likely to arrive at it. If you know you can love work, you’re in the home stretch, and if you know what work you love, you’re practically there.”
P050111PS-0522 by The White House on Flickr.
Via Flickr:
President Barack Obama listens during one in a series of meetings discussing the mission against Osama bin Laden, in the Situation Room of the White House, May 1, 2011. (Official White House Photo by Pete Souza)
This official White House photograph is being made available only for publication by news organizations and/or for personal use printing by the subject(s) of the photograph. The photograph may not be manipulated in any way and may not be used in commercial or political materials, advertisements, emails, products, promotions that in any way suggests approval or endorsement of the President, the First Family, or the White House.
tnoc_Attractor_Duotone_vM500 from sspboyd on Vimeo.
Identificazione (by (]N[) De Nigris Daniele)
Coloured Boxes Image Sampling 10 from sspboyd on Vimeo.
This goes with the image from the previous post.
Video from a Processing.org sketch that reads the colours in an image and represents them as rectangles. The width is based on the brightness levels.
Choosing Descriptive Variable Names: Code !is English
When starting a new project I often find one of the hardest parts is choosing accurate, descriptive variable names for the objects and variables I’m working with. I’m sure this isn’t a new observation but it is striking me now as I try to sort through the best way to structure a Class in Java that generates a histogram of some colour data in an array (PImage ints in Processing).
This has nothing really to do with programming but with finding the right words in english to describe what I think I’m trying to do as I work through the code. My sense is that the trouble stems from the fact I’m trying to use one structured communication mode (english) to describe what’s going on in another structured communication mode, Processing/Java code. Not surprisingly, there isn’t a 1:1 relationship there.
I’m no where near competent enough to understand 99% of what Donald Knuth writes, but this quote in “Literate Programming” seems to speak to this difficulty:
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means.
Edit: Thanks to Derek Watson for sending me the the exact quote I was looking for:
“There are only two hard things in Computer Science: cache invalidation and naming things” - Phil Karlton




![3 Steps To Hilarious [PIC]](http://25.media.tumblr.com/tumblr_l328t20B2O1qz4fwwo1_1280.jpg)





![wowgreat:
Identificazione (by (]N[) De Nigris Daniele)](http://24.media.tumblr.com/tumblr_lilqx2Y04y1qzg58bo1_500.jpg)

