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