Taking a page from Wes Felter, I split my blogshares.

I wanted to write a bit more about Hackers and Painters. It took me a long while to realize that I'm a hacker -- in the sense of being a maker. All of the topics that interested me as a graduate student were the ones that I actually wanted to use myself. This quote captured it almost perfectly for me:

But for the hackers this label is a problem. If what they're doing is called science, it makes them feel they ought to be acting scientific. So instead of doing what they really want to do, which is to design beautiful software, hackers in universities and research labs feel they ought to be writing research papers.

After graduate school, I went to work in Silicon Valley, and found that another of Graham's conclusions was true:

Universities and research labs force hackers to be scientists, and companies force them to be engineers.

I didn't really mind being an engineer, and I was pretty good at it. But I wasn't burning with fire on the inside about it. We moved to Seattle to be closer to family and try the startup thing -- that had the promise of more freedom, but once again, Graham was on the money:

One is that in a startup you have to do so much besides write software.

...

The other problem with startups is that there is not much overlap between the kind of software that makes money and the kind that's interesting to write.

Which brings us to the present, which Graham's essay has accurately foretold:

I think the answer to this problem, in the case of software, is a concept known to nearly all makers: the day job. This phrase began with musicians, who perform at night. More generally, it means that you have one kind of work you do for money, and another for love.

This is what Sauria Associates is all about. It's my day job. I count it a blessing that of my day jobs have been related in some way to the open source / emerging technogy work that I was doing at IBM. I am doing work for love.

When I say that the answer is for hackers to have day jobs, and work on beautiful software on the side, I'm not proposing this as a new idea. This is what open-source hacking is all about. What I'm saying is that open-source is probably the right model, because it has been independently confirmed by all the other makers.

That's what the ASF and pyblosxom are all about.

There were so many other quotes that I identified with -- here's one more:

In hacking, like painting, work comes in cycles. Sometimes you get excited about some new project and you want to work sixteen hours a day on it. Other times nothing seems interesting.

I find the whole section on empathy to be dead on.

It's a blessing then, that I live on Bainbridge Island which has vibrant fine arts community. It turns out that a good friend of mine here on the island is a painter. Looks like I should be spending some time in his garage. I was really amazed at how well this essay captured my experience. All that Paul Graham has to do to top this off is to ship Arc.

I've mentioned Common Lisp and Dylan as languages which allow a programmer to add type constraints to your program. What I haven't discussed is the idea of having tools that can put the types in for you, or show you (as part of the IDE, what it thinks the types should be). This is just a different way to use type inference. I think that we can have dynamically typed languages with tools that can show us static constraints like types, so when we read programs we can benefit from that information, and when we write we still have the ability to change the program quickly and easily. Check out the work that the PLT Scheme folks are doing, in particular, MrSpidey and MrFlow.

I think that we can have both. We're not there yet, but we're getting closer.