Code Fearlessly(cam.ly)
cam.ly
Code Fearlessly
http://cam.ly/blog/2010/12/code-fearlessly/
12 comments
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:... */
/* the above is a workaround; Unfortunately _code_ causes a segfault due to bug 123 see:... */
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.
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.
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.
So I used a collection of optocouplers to glue it all together. Good times.
There's an iOS/Android app (+ Arduino kit) just waiting to be created there...
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.
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.
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.
"ship shit" I'm going to add this to my bucket of phrases like "don't worry be crappy" , "fail fast and often" etc.
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.
This philosophy now has a name - and I like it.
"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.
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.
> 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.
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.
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. :-)
Thats really nifty, for you to "code fearlessly", especially (or maybe only so) if you've got huge changesets. :-)
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..."
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..."
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).
You can also do a server-side svn copy to create a branch of trunk (which is relatively instantaneous), then use svn switch to selectively swap out the directories in your working copy relevant to your change. I usually wrap this up in small bash scripts at the root directory that "toggle" the switches. I call it "poor man's dvcs."
Have you tried git-svn? The initial checkout can take a while, but it gives you many of the features of git, while still using svn.
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.
I encouraged Rhett to write it. I hope it helps other people.
[deleted]
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.
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.
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.
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.
One thing that makes me like his way is RSI.
I'm with Rich. Thanks for the link.
Beautiful
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..
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.