I learnt about _why in 2006 when I came across tryruby. I considered him pretentious and was jealous of his achievements and persona... but grew a much softer side after his disappearance.
I can still remember the advice a guy at least 10 times smarter than me gave me at the start of my programming career: "One of the most important things for a programmer to have is courage". At that time I couldn't fully understand what he really meant, I was thinking that REST vs. SOAP or PHP vs. Java or OO vs. Functional Programming were way more important for a programmer to get right compared to just having "courage". But as I grow older I realize how wrong was I.
Programming literature is rife with "thou shalt not" commandments, which produces an image of having to be some genius who always gets these things right the first time; but actually trying to follow all of them all the time will make you a scared and confused programmer, overarchitecting in various ways to push problems away from the surface, which - most of the time - only ends up adding brittleness and doesn't solve the actual problem. Similarly, there's always some uncertainty about trying any new technique or technology, which can only be resolved by putting it into practice.
Most applications today need mostly "sweat" code(UI, all the various feature behaviors, integration of outside assets and APIs) and a tiny amount of "clever" stuff. Serious problems with architecture or performance tend to only reveal themselves once you've integrated a sizable number of features and they start tripping over each other. So the best way to actually reach the real problems tends to be to code like a madman until the problem finally reveals itself, at which point you can stop to think about it and do the necessary maintenance to set things right. Once you've done this enough, you gain domain knowledge and can actually plan farther in advance. Until then you are kidding yourself.
This same attitude is seen in those who are elite in any discipline. Athletes who want the ball at the end of the game, do not do so because they never fail. They do so because they have the courage to give it their best and still come up short. Michael Jordan said it best:
I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times, I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed.
You are also likely to find yourself, one day, in possession of a machine that, if it doesn't work correctly, will destroy your company's value and get all of your friends laid off. [1] You and your colleagues will have built that machine, partly from scratch and partly from stuff you found lying around on the Internet, and you will be handed the button and told to turn it on.
---
[1] Mind you, these are minor consequences. Really important engineered things have much more severe consequences when they break: Patients die, soldiers die, hundreds of airline passengers die, entire towns fill with water, a few thousand square kilometers become uninhabitable for centuries, an entire regional ecosystem dies...
It was not only fun to look at, you actually had to type out the code yourself to find out what it did.
Or think.
It's great for learning on your own time, but hurts so many others when doing it professionally.
Then I fix it and it's great.
>Twenty lines here and there and soon people will be beating you up and you’ll be scrambling to build on to those scripts and figure our your style and newer innovations and so on.
The point I think is, write (possibly bad) code and evolve. Break stuff, innovate and evolve.
From ~2002 to 2009, he released a tremendous amount of material (dozens of code projects, thousands of blog posts), then disappeared abruptly, deleting almost everything he had ever published. His blog posts were humorous yet insightful. His libraries were excellent, some of his snippets were completely baffling. The libraries were always artfully and pedagogically documented.
He wrote in 2005 an essay lamenting the high barier of entry to programming for children in the 2000's whereas Basic was available in every 8/16bit computers when he was a kid. From then on, he tried to improve the situation: first by writing his Poignant guide to Ruby, then by writing http://http://tryruby.org/, the first online REPL, wrapped in an interactive tutorial. At last, he started the Hackety Hack project: an development environment to teach programming to children.
Extremely creative, he (used to?) consider programming to be an art in and of itself, but frequently mixed genres too. His programming book is illustrated with cartoons, fantastic stories and has a sound track that illustrates either the code, the stories, or the book writing process itself. The "This book is made (of rabbits and lemonade)" and "The parts of Ruby/Chunky Bacon" songs gives you a good sample of what his overall production felt like (see below).
He was also excellent at promoting his works, but was ambivalent regarding his own fame.
He also sometimes displayed a darker side (like in the Poignant Guide where he jokingly predicted that he was going to burn out and shoot himself in the head).
Watching him was at the same time entertaining and enlightening, and more, and I definitely wasn't the only person to deeply enjoy what he was doing... When he disappeared people went to no end to recover his works.
Most of his deleted work has been restored from backups (git forks and RSS feeds helped with this). Some of his code projects have been taken over by others, and all are archived here: http://viewsourcecode.org/why/
While active, he was admired. When he disappeared, he became a legend. It's a pity he left so many things unfinished.
--
The Poignant Guid to Ruby: http://mislav.uniqpath.com/poignant-guide/
--
The Redhanded blog, covering all things Ruby: http://viewsourcecode.org/why/redhanded/
Hackety.org, his next blog on artful programming: http://viewsourcecode.org/why/hackety.org/
--
The SoundTrack of the Poignant Guide: http://mislav.uniqpath.com/poignant-guide/soundtrack/
Recommended:
- This book is made (of rabbits and lemonade): http://s3.amazonaws.com/mislav.baconfile.com/poignant-guide%...
- The parts of Ruby / Chunky Bacon : http://s3.amazonaws.com/mislav.baconfile.com/poignant-guide%...
.
.
I just found out that it was still possible to buy Chunky Bacon t-shirts: http://www.cafepress.co.uk/blixytees
I realize that ending the description in such a bitter way misses the big picture.
He offered a slew of free/libre programs and art, and more. Bickering over a few abandoned projects is ridiculous.
_why, if you happen to read this: it was fun while it lasted. Thanks a lot for the ride, and best wishes for your current and future endeavors.
"caller asks, “should i use hpricot or nokogiri?” if you’re NOT me: use nokogiri. and if you’re me: well cut it out, stop being me."
"if you program and want any longevity to your work, make a game. all else recycles, but people rewrite architectures to keep games alive."
And interesting libraries and tools (Camping, Hpricot, Redcloth, Syck, Shoes, unHoly — a Ruby to Python compiler, TryRuby and Hackety Hack).
He also looks like the old Jack Black (with hair and beard, Tenacious-D Era)
Some people say he stopped writing because he was in danger of being "outed" by people trying to find his identity. Or maybe he got sick of Ruby, and wanted to do something else (without the burden of fame). Or he's still working under another identity and persona.
The whole mystery thing is typical of him - he likes bringing a bit of wonder into the world.
W H A T!? How is _why in any way the Bobby Fisher of programming? Bobby Fischer was a famous, amazing chess player. _why is a person that writes code and some people (some Ruby developers, rather) look up to. They're not comparable in any way.
Some people worship him for reasons i find myself unable to fathom.
By far the best byline I have ever read.
Yes, of course. You push the boundaries, move on, and at the end of the day, we have to maintain the stinking pile of "experiments" you left us with. Ugh.
After all, if you want to be a programmer, eventually you will have to write code that will be used by other people, and if it's a PITA to maintain (because when writing it you didn't care about cleanness and safety and were just having fun), it's worthless.
Or maybe it just seems so to me, because I'm really really stupid and have to work hard to grasp even the easiest concepts :-)
and then:
"I admire programmer who take risks"
Denial much?
By the way: this was written in 2005.
I don't think so. And I fear his advice will be taken most to hart by below average programmers.
