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

[angrycoder]

He is encouraging a beginner to have fun and experiment, not write enterprise software.

[javadyan]

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.

[enneff]

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

[tristanstraub]

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.

[gbog]

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

[felipemnoa]

You are really missing the point. One of the best ways to learn is to make a lot of mistakes, in everything.

[javadyan]

Yeah, it's important to correct those mistakes, though. And ensure that the mistakes don't go unnoticed.

[lallysingh]

I disagree.

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.

[rbanffy]

> That's okay, but he is also indirectly encouraging a beginner to not care about the quality of the code he produces

You really should not be using (or maintaining) code written by beginners, should you?

[javadyan]

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.

[glassx]

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.

[rbanffy]

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?

Give http://www.paulgraham.com/icad.html a read and come back enlightened.

[javadyan]

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

[rbanffy]

"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?

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

[javadyan]

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 :-)

[grimen]

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.

[ascendant]

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.