Register your Account

Sign Up with us and enjoy!

A password will be e-mailed to you.

Code Fearlessly

Posted December 2, 2010 in

When Dane Jensen first started to work on Cam.ly, he dove right into things and wanted to learn how everything worked. It was no small feat, considering that our system already used (in addition to others) Ruby on Rails, Haml / Sass, Javascript, Java, shell, c, and c++.

After a few days, he was ready for a task, and I gave him some tough problems that we had to solve. We had some great brainstorming sessions, and decided that there were a few potential ways that we could approach solving some of our major problems, which he would work on. A few days later, I came back to see how he was doing, and noticed that he had apparently lost a lot of his initial energy. I asked him how his work was going on the big problems and he explained that he was intimidated and didn’t want to break anything. Then I said two words to Dane that changed him forever:

“Code Fearlessly”

All of the code he was working on was versioned in git. He was working entirely on development machines (not production). There was absolutely no way for him to break anything.

I decided that “Coding Fearlessly” was critical to being an extremely productive programmer by watching Nat Friedman. Nat is one of the best programmers I know, and he truly loves working on software.

Fearlesss Nat, staring down some code

One day I watched Nat deleting and changing a lot of code that people had obviously spent a lot of time writing. Some people might feel scared to even save the file after deleting so much code. Nat didn’t hesitate at all. He said, “Ok, well this is all in git,” and just started deleting. He was right. There was nothing he could do that would set back anyone else’s work, and even if he pushed to a development server (not likely unless he was sure it was a good commit), it would probably only take someone a few minutes to roll things back to the way things were.

There has been a lot of excitement, hype, and potentially disappointment when software development processes such as, XP (eXtreme Programming), TDD (Test Driven Development), or BDD (Behavior Driven Development), work really well for some teams, but not others. A huge benefit of TDD is that in some teams, on some projects, it creates a safety net where people are able to code fearlessly, and as long as all of the tests pass, they can push code. The benefits from having developers who work fearlessly without disrupting each other are enormous on any project.

Thinking about it further, I realized that this also reminded me of a story that the inventor, roboticist, and entrepreneur, Thomas Massie, once told me. When he 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.

Young Thomas Massie, and his robot arm

Many years later, at MIT, Thomas realized that as young child, he had re-invented the Opto-isolator, a device that gave him the freedom to work fearlessly with a computer.

While the benefits of “Coding Fearlessly” are clear to me, I think it’s important to make the distinction from “Coding Recklessly.” To truly code fearlessly, an environment must be created where there is truly nothing for the coder to fear. We developers are fortunate to finally have, as of the past few years, tools that can allow this for all developers cost effectively. Distributed version control (git, mercurial), virtual machines locally or in the cloud, laptops powerful enough to run databases, smartphone emulators, and many other pieces of technology (hardware or software), can all be used to put together development environments for software engineers that are very much unlike the days of the past.

Whoever is setting up the development environment for any project, whether your team is 1 person or 100 people, it doesn’t matter if you choose “agile” or “waterfall.” Your primary concern should be to create an environment where you developers can code fearlessly.

Discussion

26 Comments
  1. Fear is the mind killer.

  2. Assuming that there is a good regression test suite. Yes! Code Fearlessly is the mantra. But what if there are no tests. I worked at a pretty successful large web company which had no tests at all. Moreover, they were dealing with payments. Unless you have nerves of steel changing code, committing it means risking tens of thousands of lost revenue. That is not something everyone can do.

  3. Tss … version control systems are for girls! Either you code or you don’t. There’s no half-assed “I can roll it back”.

    Grow some balls, girls!

    • @Leon Go work in a company where the project your working on is very important and you have a very limited time frame to code something quite difficult. Then when your partners start breaking things and you don’t know how to fix them come crying back to git.

    • @Leon: Why do you think that girls can’t program? If you find that you have to frequently use your testicles while coding, I humbly submit that you’re doing it wrong. (If you are curious why your co-workers are giving you odd looks all the time, congratulations, now you know: frequently manipulating your genitals while you work and also not using version control are both considered rude.)

      • @Leon, you don’t know what your talking about. Being able to roll back to a point in time saves jobs.

        I’m sure we all make coding mistakes.

        you might have the balls to code without rollback method, but that just means you have no brain to know you have to have a rollback method.

    • I think Leon is “taking the Michael” as we say over here :)

      I agree with the general principle of the post. I would add that it doesn’t require git or another dvcs to do this – most version control systems are fine. If necessary you work on a private or task branch.

      As for testing – yes this is vital. The lack of tests saps the confidence I find.

    • Depends on the project… for my pet projects – ones I know every nook and cranny – or where it’s jump in the fire with my own system… SURE!

      Client systems? Work for Clients? I like SOMETHING… Backups, SVN, GIT… SOMETHING… ( GIT is something We’re moving to internally but we’re not chucking SVN either – it’s not going anywhere soon.)

    • @Leon: Don’t sweat the haters; their humor detection routines were coded fearlessly. The post is clearly just a joke, people. Lighten up.

      • As to the post, no joke, As to lightening up I agree, code fearlessley, have fun doing it, and yeah the code is probably not perfect, so let your colleagues check it out, get feedback, and if you are humble enough you will actually learn something, or maybe not :-)

  4. Fear leads one to the dark side of the Force. Fear not.

  5. When working with C or C++, I always fear that some mistake with pointers can ruin my system and I may have to re-install my OS. Doing this in virtual machines may be safer. Is there any other way?

    • I spent some time research operating systems from the path of a casual programmer wondering how things worked thru writing my own… intel, and I’m sure other architectures have mechanisms to allow software to indicate how much ram a process is given, what memory it may write to, read from, where code can jump to, jump from, what resources it can access…

      Essentially applications in some ways are virtual machines running within the operating system and the operating system does have mechanisms in place to protect it self. this is not to say writing a defrag program on your main c drive would be a good idea nor writing code that does registry cleaning … you get the drift… in general.. the CPU has information about what any given process has concerning its run level, allocated memory, etc.. if you application runs afoul – the CPU calls a function determined by the operating system that allows the operating system to wake up in an instant an hande the breach… often in windows its the “This application has caused an exception” or “…performed an illegal operation…” LOL

      so… don’t fear pointers and pointer math – that’s where some real speed can be obtained for some problems that without pointers.. well.. SLOW! ;)

    • If you are afraid that a pointer mistake with C or C++ may make you reinstall your OS, might I recommend a real OS? Windows XP or later (although NT and 2K also work), or any version of Mac OSX or Linux should do nicely.

      VMs are great for fearless anything, though.

  6. Xander: Buffy, this is all about fear. It’s understandable, but you can’t let it control you. ‘Fear leads to anger. Anger leads to hate. Hate leads to anger.’ No wait, hold on. ‘Fear leads to hate. Hate leads to the dark side.’ Hold on, no, umm, ‘First you get the women, then you get the money, then you…’ okay, can we forget that?
    Buffy: Thanks for the Dadaist pep talk, I feel much more abstract now.

  7. i would rather code carefully.

  8. Sounds cool in principle. Too bad only the most trivial applications (or the most disciplined teams) have sufficiently rigorous test suites to accommodate such bravery. Even the fabled 100% coverage doesn’t validate every potential use case. Never mind that the tests themselves require modification after a serious refactoring. Or that the really fun bugs aren’t discovered until months after you’ve checked in. Or that management punishes the authors of new bugs without rewarding those who successfully pay down technical debt. No wonder it’s an uphill battle to combat the ‘IBGYBG’ mindset. My more ambitious efforts tend to end up like so: http://www.opencurly.com/dev/confessions-of-a-samurai-coder.

  9. @Ram: Committing some set of changes made fearlessly doesn’t mean deploying them, or even exposing other developers to them. That’s what makes distributed version control so great. You can checkpoint your work, without that meaning anything else to the rest of the world.

    Maybe some small change from the big set will actually be desirable, so you cherry-pick it into the mainline. That says nothing about what you do with the whole mass of changes. Use the available tools well, and coding fearlessly carries minimal risk.

    • @Phil: I don’t see how the distributed nature of the version control system makes any difference. With a non-distributed system I can shelve my changes and so have them stored in source control but not visible to other developers.

      Version control systems of all stripes ease fear by ensuring that deleted data can be retrieved and newly added data can be rolled back.

  10. @Leon: Never mind the anti-professional attitude, quit being a sexist pig!

  11. It’s true. The reason so many programmers suck is not because any part of programming is hard at all. The reason is they’re fucking cowards.

    Even the weird shit, lambdas, AI, graph theory, it’s not hard. Two big, simple secrets make all that shit easy as hell: 1) mathematical notation is code written in a deliberately arcane style designed to intimidate the uninitiated; 2) first figure it out, then hack.

    You take those two key principles, you add time and effort, and you’re set. Now you can do absolutely anything with a computer that anybody else can do.

    • Digg you Moxie – Bummer is you can’t just put in some effort and know it all – in this gig – it’s non stop – “need” must fill… find out best way (research whatever could fit) pick best scenario all things considered – then… what you said… more energy, study..trial error.. bang head.. fight..win! :)

      –Jason

  12. Is it weird that the main message I got from this article was to backup often?

  13. As a generalization, your talking about the ability to embrace change. Which can be culturally ingrained (for or against) in an organization. Cultivate a culture that is fearless my programming brothers! Such organization for me have been the most rewarding places to work. On the other side of the coin, I’ve been in too many places where folks shy away from any deep change to the comfort they feel in their Big Ball of Mud. They simply apply yet another layer because they feared what would happen if someone was fearless. From my experience even if such a change needs to be backed out what is learned is of high value. I’ve not seen too many that required direct roll back. Typically the change made needs to be modified, matured or rolled back in favor of another fearless change.
    Don’t abuse this. It is a mistake to abuse such fearlessness in the face of a trivial change. You need to understand when problem you are tackling requires a revolution born of fearlessness.

    Note that metaphorically, any gender can grow a pair. I’ve seen plenty coder eunuchs of both genders the professionals I know are all well endowed.

    Thanks for the read.

  14. This really is the biggest advantage of git: it allows you to code fearlessly.

    95% of the time, I never rollback any of the stuff I delete. But I wouldn’t have deleted anything if I didn’t know it was all still there in git.

  15. Shameless plug here but for fearless devops take a look at http://vagrantup.com.

    If you don’t like what you’ve done to your development environment, just destroy it and create a new one :D

Leave a Response

If you have a question or comment, or just need to get in touch, please use the form below.