
A letter from _why - fakelvis
http://aberant.tumblr.com/post/167375099/a-letter-from-why
======
aaronbrethorst
_Please_ add [2005] to the title. You had my hopes up there for a moment.

~~~
bilalhusain
Though it would be stupid, but I still wait for the resurrection.

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.

~~~
tomlin
Sadly, I felt the same. Foolish now, isn't it?

------
paganel
> I admire programmers who take risks. They aren’t afraid to write dangerous
> or "crappy" code.

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.

~~~
d0m
Mind to elaborate a little bit on this?

~~~
chipsy
I know exactly what he speaks of. Even in a project dealing with life-or-death
problems, you have room to iterate and test and review, so it's OK to screw up
on the first pass, as long as you're trying your best! Thus - you have nothing
to fear, and yet fear is a big problem in programming!

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.

~~~
j_baker
_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._

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.

------
jarin
My favorite _why-ism was how he would hand write and scan code snippets for
his blog (often without any explanation of what it did). Then, when lazy
people started OCR-ing the images, he would post code as animated GIFs.

It was not only fun to look at, you actually had to type out the code yourself
to find out what it did.

~~~
avree
Which is a really, really, really awesome way to force people to learn code.

~~~
5plic3r
as demonstrated by <http://learnpythonthehardway.org/>

------
ISeemToBeAVerb
As a beginner at programming, I find _Why to be a breath of fresh air. I
realize that experienced coders may berate him for advocating writing sloppy
code, but for someone (like me) who is just getting into this deep rabbit
hole, I find his thoughts to be encouraging. I fully agree with some of the
comments here that mention writing bad code is the only path to writing clean
and safe code. I wish more experienced hackers could recall a day that, they
too, wrote bad code. As a beginner, I'm positive that much of my code would
make people here cringe, but hey, at least I'm learning! Ultimately, I think
that was Why's point. Kids and beginners shouldn't worry if their code is
"correct", they should just write code and keep learning. I think that's a
noble endeavor and a great legacy.

~~~
oinksoft
There's a balance though. In your free time, you should be the mad scientist,
but on the job, correctness and maintainability is crucial in your final
product. You can even play the mad scientist at work, but production-quality
code has to be clean and professional, and that should be your code's final
form.

~~~
joeyespo
Yes, this is so true. Too often someone wants to learn a new technique and
throws it in production code without fully understanding it. Others get stuck
maintaining it, also without fully understanding the technique, and because a
full refactor is usually too expensive to justify.

It's great for learning on your own time, but hurts so many others when doing
it professionally.

------
gnufied
Those who think somehow _why is advocating writing bad code aren't paying
attention:

>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.

------
jessedhillon
Can someone write an explanation for _why_ this is important? Who is this
person?

~~~
pygy_
He's a top notch high and low-level programmer with excellent taste for API
design (and a language geek). He's also a talented poet/writer,
painter/cartoonist/web designer and composer/singer/musician.

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%...](http://s3.amazonaws.com/mislav.baconfile.com/poignant-
guide%2Fchapter-2-this-book-is-made.mp3)

\- The parts of Ruby / Chunky Bacon :
[http://s3.amazonaws.com/mislav.baconfile.com/poignant-
guide%...](http://s3.amazonaws.com/mislav.baconfile.com/poignant-
guide%2Fchapter-3-chunky-bacon.mp3)

.

.

I just found out that it was still possible to buy Chunky Bacon t-shirts:
<http://www.cafepress.co.uk/blixytees>

~~~
patrickg
I once bought a printed Shoes manual from Lulu.com and it is the absolute best
manual (from a 'I love to read this book' point of view). Extremely
impressive. Guess it is already worth a few bucks today ;-)

~~~
jmlane
I may eventually investigate a way to get it printed and bound in a classy
hardcover with a dust jacket, similar to the photo of the book from _Why's
guide site. This is one of few programming/tech books that I feel deserve such
treatment.

------
api
"Until an asteroid,"

By far the best byline I have ever read.

~~~
misuba
And an apt title for his biography.

------
jeff_5nines
'Until an asteroid' is probably one of the best sign-off ever. It's true that
we really don't know what's coming down the pipe for us, so code and be happy,
or whatever you do, but be excited and motivated about it.

------
signa11
From yosfek's site: Risk aversion is innovation aversion...

------
itsnotvalid
Just remember that there are many ways to become successful. However without
even trying, there is no way to learn anything.

------
hrabago
First, you have to learn the rules. Then you have to master the rules. You
have to really know what they're for, how they make things better. Then,
finally, you can start breaking the rules.

~~~
erikpukinskis
Disagree. Do all of those things in any order you fancy.

~~~
superbobry
That would probably ruin all the fun of _rule-breaking_.

------
javadyan
> They aren’t afraid to write dangerous or “crappy” code. If you worry too
> much about being clean and tidy, you can’t push the boundaries.

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.

~~~
grimen
Example: Do you paint and/or build because you feel like it, or because it
pays your bills? I doubt a child got bills to pay, so why do they paint and/or
build LEGO? Code can be art and play too.

~~~
officemonkey
I'll go even further. If you're a kid and coding isn't fun, then please stop
doing it. The last thing you need is to sacrifice your career to something you
don't like doing.

~~~
raganwald
I'll go further. Drop the "kid" qualifier, or allow for the possibility that
we're all kids:

 _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._

------
oceanician
Ahh I thought this was a letter from 'beyong the grave' rather than a
historical one. Oh well. Imagine he's out there doing something clever
somewhere.

------
billmcneale
"I do not write tests for my code. I do not write very many comments. "

and then:

"I admire programmer who take risks"

Denial much?

By the way: this was written in 2005.

------
figital
newfound respect. thanks very much for posting this.

------
bh42222
_why is not an average programmer. His advise is good for masters of
programming. He is also a super nice guy and sounds like he thinks anyone
could become a super programmer.

I don't think so. And I fear his advice will be taken most to hart by below
average programmers.

~~~
mibbit
One of the worst thing about this industry is the constant idolization of
programmers, and languages by below average programmers.

~~~
superbobry
Any industry for that matter; just replace programmer with <musician> (for
example).

