Code Fearlessly

http://cam.ly/blog/2010/12/code-fearlessly/

by heyrhett • 16 years ago

161 24 16 years ago

lifto• 16 years ago

Beautiful

BigZaphod• 16 years ago

I code like this. It wasn't always the case, but at some point I had the realization that everything I do can be undone, reset, restarted, or otherwise restored and no longer have any fear about digging in and utterly gutting a piece of code if I can imagine a way to make it better.

This philosophy now has a name - and I like it.

scorchin• 16 years ago

"everything I do can be undone, reset, restarted, or otherwise restored"

This is so key.

Software companies in general need to emphasise this so that builds are easy, CI is a given and continuous deploys are a no-brainer.

dabent• 16 years ago

> This philosophy now has a name

I worked with someone who went into what he called "samurai coder" mode. He'd get his digital sword out and start chopping up the enemy (bad code). We were in an environment where everything could be undone, reset, restarted, or otherwise restored, so his swordplay worked.

Tycho• 16 years ago

My favourite bit:

When Thomas Massie was a child, he was fortunate enough that his parents bought a computer, and he desperately wanted to start making robots with it. However, he was smart enough to know that it was a bad idea to start sticking wires into the family computer that cost thousands of dollars. So, Thomas hatched a plan. He figured out that he could scotch-tape photo sensors to the computer screen and write programs that turned portions of the screen either on full brightness or full darkness. That way, he could write programs that controlled motors, without electrically connecting anything to the computer itself.

hugs• 16 years ago

There's an iOS/Android app (+ Arduino kit) just waiting to be created there...

sanj• 16 years ago

Oh this bit made me so happy too! My high school science fair project involved controlling stepper motors off a parallel port. I really didn't want to fry the port -- I needed it to print out papers.

So I used a collection of optocouplers to glue it all together. Good times.

Aaronontheweb• 16 years ago

I struggle with perfectionism, which is a major productivity killer for developers and a death knell for startups.

I've adopted a specific mindset in order to push my perfectionistic tendencies aside - I call it "ship shit" - which means the focus is on shipping something out the door even if it is complete and utter shit; ship it with the understanding that you can make it better later.

nlawalker• 16 years ago

Yeah, that's where I'm headed too. I'm starting to see the value of a "get it done" mentality. I need to find my satisfaction from shipping stuff that solves problems, even if it isn't necessarily a picturesque masterpiece of patterns and design.

dholowiski• 16 years ago

"ship shit" I'm going to add this to my bucket of phrases like "don't worry be crappy" , "fail fast and often" etc.

xtrycatchx• 16 years ago

yeah, as long as everything's in a version control mechanism, there's nothing to fear.. except for that old old-school engineer sitting next to your cube who is also committing on the same code you're working on..

moron4hire• 16 years ago

Absolutely. Your code is a delusion. You think it does one thing. It does another. Do not care about what the code actually is. Care about what it does. If the code does not meet your needs, then the code is dead (long live the code). Delete it without fear.

It's one thing that drives me nuts about working on teams: coming in to a version-controlled section of code that has had bug fix work done on it with large sections of old code commented out. "This didn't work, so here is the new stuff." So why keep the old stuff? "Well, I was worried I'd forget XYZ". Then address it when you find it. Throw away that old code.

I would even go so far as to say that out-of-version-controlled code should be discarded with great haste. If you can't rewrite the code from scratch, then you don't understand it. Code lies, cheats, and steals. How do I know it's the code that is at fault? Because it's not the person, and people have needs, and those needs still need to be filled, regardless of whether or not the code does what it says it does.

Retric• 16 years ago

I often leave in old code that does not work because of an API issue, along with the API issue. Something like

/* the above is a workaround; Unfortunately _code_ causes a segfault due to bug 123 see:... */

guille• 16 years ago

When I first started coding I had a huge fear of breaking something as I got more experience and got more comfortable that fear went away, its always a little there but nothing to stop me. Now I struggle with the "beauty" of my code. Will people think that my code is ugly. I will add "Code Fearlessly" to my arsenal of things to repeat when I am scared...the other one I like is "there’s almost no code worse than no code." by Nathaniel Talbott.

waratuman• 16 years ago

This would mean more if it came from Dane. Saying "I said two words to Dane that changed him forever" isn't cutting it for me.

danecjensen• 16 years ago

I encouraged Rhett to write it. I hope it helps other people.

siddhant• 16 years ago

So essentially, its git at work. If you're using svn, then each and every commit of yours gets pushed to the main repository. That, is not feasible if you're working on a big feature. With git, you can just continue working on your local machine, and push a series of commits at once.

Thats really nifty, for you to "code fearlessly", especially (or maybe only so) if you've got huge changesets. :-)

SoftwareMaven• 16 years ago

I've been doing this since long before git was a twinkle in Linus' eye. The tools may make it easier or harder, but the attitude is all inside the programmer.

Of course, while I'm happy to code fearlessly (there has never been a code module I've been afraid to jump into), it scares me to death to see some others do it. "Hmm, maybe Hank should just take baby steps..."

spc476• 16 years ago

git makes it painless. At work, we use svn, which I've found makes it harder to try those crazy ideas, so I don't even bother (or if I do, I have to checkout the entire project in another directory, which takes forever due to the sheer size of the project, so again, I'm relunctant to do even that).

swah• 16 years ago

Pretty much the opposite that Rich Hickey advocated on this talk: http://news.ycombinator.com/item?id=1962051.

One thing that makes me like his way is RSI.

rapind• 16 years ago

I'm with Rich. Thanks for the link.

barrkel• 16 years ago

It depends on how much other code is depending on the code you're changing. The more that depends on it, the higher the stakes for making large modifications on it, and the higher the degree of implicit assumptions which are very hard to fully capture in tests and specifications.

But if you have solid tests and spec for the area, I fully agree: be bold (I wrote earlier: http://blog.barrkel.com/2008/07/be-bold.html). But it's not always possible, and you need balance when the issue requires more responsibility.

Code Fearlessly

Related Stories