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.
Too much excitement? _why was generally a cool guy, but why (no pun intended) would you get yourself excited over his return? He's just a person, just another developer, not the messiah or anything.
Oh, but he's part of the lore and the canon, so even though the sixth patriarch tells you to stare at the moon and not the fingers pointing the moon, on HN there's a lot of finger-worship going on.
> 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.
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.
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.
Most people don't have the courage to try and fail. The fear of failure holds them back from their true potential. Having courage advocates trying even though you will likely fail the first time and probably the next. The point is you keep pushing forward and learning. Through failure comes learning and finally success.
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.
If you write anything of any consequence whatsoever, it will be employed by thousands or even millions of people, run for hundreds of thousands of hours, do many dollars worth of work. It will likely outlive you.
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...
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.
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.
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.
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.
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.
Why The Lucky Stiff is a mercurial enigma wrapped in a riddle shrouded in mystery. He wrote these crazy awesome ebooks on Ruby, among other things, put it all out on the Internet, then when it got popular he tried to retract and delete it all and disappear. He only succeeded at the latter though, his books live on. But people still wonder where he went, and hope that one day he'll resurface. This post title implied he has, but alas, it's misleading.
That's not entirely true. why was happy to remain in the public eye long after he and his book gained notoriety. What you don't mention is his prolific open source work, including the html/xml parser hpricot. why's disappearance seemed to happen just as nokogiri, a technically superior parser, became prominent, though why's motives will never be known for sure. why's last tweets include:
"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 don't know much about _why but as I read all the stories about his disappearing I can't help but think he had serious problems in his life. To take it personally and go away only because your code is getting old and slow while other learned from it and wrote something better is IMO wrong! You should also learn from libraries and go on write something new and challenge yourself again. Giving up because of a loses match is just not ok.
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.
He was "unmasked" at one point. Last I heard - shortly after his disappearance - he was alive and employed. My take on his disappearance is that he just wanted to bow out of the limelight. Fair enough, IMO.
People started digging too deep, trying to unmask him, so he pulled the plug. I admire the people who do know his identity but kept it under wraps: kind of like a geek code of omerta.
Bingo, this is, as an acquaintance of _why, the main reason. Though I think it is more complicated than just one thing. Before when he got outed he was able to talk to the person and get them to respect his anonymity, but this time around the person wouldn't budge. He wanted his artwork to stand on its own, and has his reasons and I respected them so that's as far as it went.
Some people have jobs where it's discouraged to stand-out or draw attention outside of work. Doing so is looked-down upon and may lead to reprimand or termination. I have no idea if this was the case for _why, I just want to point that out.
Yeah can imagine there are jobs where it is required to stay "hidden". I think it is very interesting cause most times you can make a name in communities when good and at the same time popular people from the community are working for your company.
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.
I think _why left because he didn't want to do it anymore, it's that simple. Being _why must have taken up a load of time and one day he just wanted to spend it some other way - I'd suggest that it shows he was far more balanced than the average "rockstar" programmer, he may really just have left to spend more time with his family.
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.
As well as the books, he also wrote a few fairly-widely-used Ruby libraries, often with quirks. (eg. Camping, the web framework whose goal is to always have its codebase stay under 4kB)
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.
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 ;-)
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.
why (with an underscore) was a cool pseudonymous Ruby programmer / writer, who completely disappeared. He's like the Bobby Fisher of programming, without the crazy. (OK, he sounds a little ... artistic, but that's not really crazy).
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.
I like to think of _why today living a quiet, reclusive life in Pennsylvania with his wife and children, peacefully working on his own projects and art.
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.
'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.
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.
> 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.
That's okay, but he is also indirectly encouraging a beginner to not care about the quality of the code he produces. That's bad. You should be afraid to write crappy or unsafe code. Writing clean and safe code is a mandatory skill for any programmer and beginners (especially beginners) should practise it.
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.
You don't internalize what is bad about bad code until you've written a lot of it. I've written all kinds of terrible code, but I had the good fortune of starting early and learning a lot of valuable lessons before I inflicted too much of my bad code on other people.
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).
If you want to be a programmer and write code for other people, then yes, cleaner code is easier to hand over.
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.
I didn't check "Why"'s code but if he is a real good writer and coder, as many seem to think, his code will be clean even against his own claims. It is only when you have the greatest maestria that you can dismiss the rules. Only after 20 years of violin will you be able to play "out of tune" (without people jumping through the windows). So I take Why's advices as very elitist, and necessary, but not to be followed too closely in a normal environement (where you have peers, where your code will have to be modified, etc.)
It is funny that you get downvoted in this thread as soon as you show some slight disagreement with "Why". At least, felipemnoa cared to explain: "the best way to learn is to make a lot of mistakes, in everything". I don't care that much about karma (would "Why" care? I doubt) so I will say here why I don't agree.
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.
>>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?
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.
Yes, but that is not the point. The point is, best practices should be taught as early as possible, so that people don't acquire bad programming habits.
I know this might be an unpopular opinion, but nobody really _learns_ good practices just by having somebody tell them. They might _use_ them, but _learning_ requires something more. It is important for programmers to think by themselves!
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 they never make mistakes on their own, what are they really learning? Also, why are you so sure your "best practices" will remain best practices a couple years from now?
> Also, why are you so sure your "best practices" will remain best practices a couple years from now?
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.
"Best practices" are neither a hard science nor immutable. They are derived from observations about what works and what doesn't and are, therefore, subject to change over time as technology evolves. It's important to remember science, as in "what we understand about the world" also changes. What doesn't is the scientific method.
> "Best practices" are neither a hard science nor immutable
Yes. So what? Does it mean we don't have to study and apply them just because they are going to become obsolete eventually?
And I did read that text. In fact, I had read it earlier.
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.
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.
I doubt that building LEGO's has anything to do with building actual houses out of concrete and glass. That's my point. You can't build a real house out of legos and playing with them will not teach you anything about how actual houses are built. Same with programming - you can't learn to build good software by just mucking around aimlessly (unless you are some sort of genius). You have to learn how high-quality software is built.
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 :-)
It has very much. I played with LEGO my entire childhood, and I can see it becoming useful for building things in a creative way - but without having to think much becuase I think it's so obvious how it can be solved. With this in mind it's important to try to build things in other ways of course, and that was _why's point - but only if you think it's fun though. In short - as mentioned in many comments now: Try to do things that you find enjoyful, then this play might become very valuable for you or for others in one or many ways.
Not every programmer aspires to write enterprise-level software. Some people like to tinker and try new things. This is exactly what he is advocating. Leave it to the sterile corporate developers to immediately assume all programming is on 500 KLOC Spring/Hibernate applications.
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.
_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.
I learned to make computer games by making below average computer games. What's wrong with someone learning to make programming langauges by making below average programming langauges?
