A letter from _why
aberant.tumblr.com
aberant.tumblr.com
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 is true, but deceptive in my opinion. Sure, the vast majority of your code may be "sweat" code if you look at it on a strictly line-by-line basis. But the "clever" code is where you really add business value. It's oftentimes your secret sauce that gives customers a reason to use you versus one of your competitors. It's usually the code you spend the most time worrying about.
Granted, this isn't true of all businesses. Some companies make their living writing CRUD software that wins due to brilliant design. These firms rarely need programmers to add much business value beyond their time and energy, which is fine. But I wouldn't say that's representative of all or even most software businesses.
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.
"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."
I also find it pretty odd that no-one seems to know what he is doing now. What about all of his friends? Do they also don't where he is? But I think if someone puts so much energy in hidden himself he shouldn't be found anyway.
On the other side there are plenty of people who did or still do a lot to be popular in the community.
Last but not least I think the guy has earned some rest.
He gave a lot to the community, far more in the short time he was around than most people produce in their lifetime, and we should be/are thankful for it.
... or any sufficiently large and financially important enterprise code, really. :-(
No. Enterprise (and enterprisey) code is born dead. With huge amount of effort, it may be coerced into walking. It also eats brains.
This strikes me as all of:
1. wrong
2. unsupported
3. inflammatory
4. of no value to the conversation.
Would you care to support / substantiate that claim somehow?
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.
The only difference is they didn't make a movie about _why.
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.
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.
I think _why had a lot of great ideas about pedagogy, and experimentation is a great way to internalize "best practices" because you truly understand why they are good (not just because somebody else told you so).
But, when I first started coding, I wrote it for myself and because it was fun! Why was it fun? Because the code made things happen! Not because it was clean.
Clean code makes writing large projects by yourself and with other people easier. It doesn't necessarily make coding more fun.
Mistakes are good, to some extent, but not in everything. Would you tell someone that unsafe sex is ok, and that one should learn its danger by doing the mistake, catching a STD, and then not doing it again? Would you tell someone that building a bridge without double checking pressure contraints and simic conditions is ok, that one will learn by one's mistakes when the bridge will fall apart? Hmm, so there are some limits to this "learn by your mistakes" thing, right?
In coding, the same. It is ok "to write dangerous or “crappy” code" (Why quote) in personal projects, not in those where life are at stake, eg. airport traffic control or medical software. It is ethically not ok to write dangerous code in these case, and I would say it is the same when your code will have to be read, used, debugged by others. I admire people taking risks, too, like I admire someone eating 50 eggs in 1 hour, but I would not always advise my friends and relatives or coworkers to take those risks. Sometime, most of the time, the reward is not good enough.
I appreciate "Why" writting skills, he is or was an impressive guy, but taking to the letter every of his tweets should not be mandatory on HN, I believe.
Thanks for explaining why and where I'm wrong, if it is the case.
Your example is a little bit over the top. I might have generalized too much but I think that in the context of the discussion you get the point I was trying to convey. There are always exceptions to every rule, of course. I believe my comment still stands, most of the time.
You shouldn't learn to write maintainable software by rote. You just mechanically learn what to type, and how to type it, without ever learning why. Which is important. Knowing why certain constructs are hard to understand prevent you from doing the same spaghetti in perfectly-sanctioned style. Knowing how people read unfamiliar code is important, and teaches you which parts of the style-guide-mandated documentation are best kept short (for someone scanning your file to see what-does-what) and which parts long (to describe the edge cases).
Honestly, the best way I've found to write software is to start with a complete proof-of-concept mess. That way there's minimal friction during the get-it-right phase. Then I factor out the actual 'hard work' code from there into a reusable component, and turn the rest into the start of my test harness.
You really should not be using (or maintaining) code written by beginners, should you?
Give http://www.paulgraham.com/icad.html a read and come back enlightened.
It's the same as saying "but why are you so sure your science will remain science a couple years from now?". Sure, there is constant progress and change, but we have to know what is at our disposal right here, right now.
Did you read the text I pointed you to?
And I did read that text. In fact, I had read it earlier.
Getting beginners to experiment with their own code is a very natural way of teaching them what is good and what is bad, and why exactly it is good/bad - since they're the ones who'll have to maintain it.
Also, unrelated, but "having fun" is an amazing metric for good code. If some coding activity is boring as hell you're probably 1) on the wrong job or 2) using the wrong abstractions.
If coding isn't fun, please stop doing it. The last thing you need is to sacrifice your career to something you don't like doing.
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.