'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.
A letter from _why
61–70 of 104 posts
Re: A letter from _why
#62Please add [2005] to the title. You had my hopes up there for a moment.
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.
Sadly, I felt the same. Foolish now, isn't it?
Re: A letter from _why
#63First, 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.
[deleted]
Re: A letter from _why
#64"Until an asteroid,"
By far the best byline I have ever read.
Re: A letter from _why
#65> 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…
Mind to elaborate a little bit on this?
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...
Re: A letter from _why
#66_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.
Re: A letter from _why
#67As 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 hac…
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.
Re: A letter from _why
#68Earlier quoted context omitted.
At the risk of being terse: http://en.wikipedia.org/wiki/Why_the_lucky_stiff
http://www.vimeo.com/5047563
Re: A letter from _why
#69_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.
One of the worst thing about this industry is the constant idolization of programmers, and languages by below average programmers.
Re: A letter from _why
#70Earlier quoted context omitted.
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.
> 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.
Did you read the text I pointed you to?