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

[matwood]

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.

[mechanical_fish]

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