Don’t Be Afraid of Imperfection

Marco Arment’s post about being “addicted to PHP” talked about fear involved in switching languages:

Whichever language I choose to replace PHP will have its own problems that will take me years to master, but by the time I know whether I chose the “right” language, I’ll have invested far too much time in it to practically switch any meaningfully sized project to another language: exactly the situation I’m in now with PHP.

The fear of making the “wrong” choice actually makes the familiar, mastered PHP more attractive. That’s the problem Jeff’s identifying, and it’s very real. If you can get PHP programmers to agree that they need to stop using it, the first question that comes up is what to use instead, and they’re met with a barrage of difficult choices and wildly different opinions and recommendations.

I’d like to respond to that by saying “it’s not that hard.” More specifically, I think that these kinds of fears are blown out of proportion out of some misguided drive for perfection.

Web apps are not driven by perfection; this isn’t kernel code that has to be as optimized as possible. It’s not an electronic voting machine where governmental inspectors are going to be poring over each line of code to check it for legitimacy. No, web apps are driven by making things that work. To make things that work in a given language, you don’t have to be a “master” of that language. You don’t have to know the intricacies of how MRO works in Python to write a web app. If you want to write SQLAlchemy? Sure, then knowing how MRO works might be useful to write the best code for something that’s going to be used by tons of people – but most things you write aren’t going to be SQLAlchemy.

Essentially, people like Marco are letting the perfect become the enemy of the good. They’re so focused on “mastering such-and-such language” that they don’t realize that mastery isn’t required to reap the benefits of choosing a different language. You don’t have to be as respected as Guido in the Python community to create good things with Python. Heck, you don’t even have to follow PEP8 or any of the other “pythonic” idioms to create good things with Python. Sure, another Python coder looking at your code will think you’re a bit weird, but weird code is not the same as broken code. Weird code can be refactored as desired as you learn more about the language and what’s considered standard in the Python ecosystem.

So the next time you go to start a personal project, Marco, I’d suggest this: try stepping outside of the comfort zone,  trying something new, and not worrying about it being perfect. If you “pick wrong” it’s not actually that bad; you can make a different choice with the next project. The only reason it seems like a huge investment is because your goalpost is set unreasonably high.

Posted on June 29, 2012, in Software Development and tagged , . Bookmark the permalink. 6 Comments.

  1. It’s especially worth it when PHP is the language you’re afraid of leaving–a programmer with even middling knowledge of Python (or Ruby/Rails, or ANY sane, modern language) is going to be much more productive than a PHP expert, especially when a codebase gets large, simply because PHP is such a terrible language.

  2. While I agree with the main message of this post in that I think language agnosticism is something to strive for, there are two things I wholeheartedly disagree with:

    > You don’t have to know the intricacies of how MRO works in Python to write a web app.

    Depending on the complexity of the application you are building, you better _do_ understand how the language in use works. Even if you’re “just building a web app”, your code is going to be used/exercised by a lot of people — your customers that use the web app. (Although dealing with multiple inheritance will probably not be among the things you’ll regularly be confronted with.)

    Knowing/understanding how your tool chain works is paramount to troubleshoot and subsequently fix the problems that arise rather sooner than later.

    And while a web app is not code for a life support system, any interesting one involves handling of potentially confidential user data…

    > Sure, another Python coder looking at your code will think you’re a bit weird, but weird code is not the same as broken code.

    Weird code is broken code — otherwise there was no need to refactor it in the first place.

    Weird code is a common theme when writing Objective-C for a living: Most programmers here tend to come from Java-Land, and the core libraries differ greatly in style and substance (sometimes, I find it hard to imagine that java.lang is said to be modeled to mimic NextStep foundation to a certain degree).

    Even if weird code originally works as intended by its creator, give it another collaborator or just two months sitting idle: The brokenness starts becoming obvious when that other feature needs to be added or existing functionality needs to be changed, and bugs start popping up left and right because the code behaves in unexpected ways.

    Besides, I have yet to work at a place where code routinely gets refactored even after shipping.
    Although that may well be a disease that mostly plagues us in native iOS development — at the very least, all the ruby-ists I know and worked with were far more concerned with such matters.

    • Understanding a language, however, is not the same as mastering it – hence the example I gave of the MRO in Python. There are plenty of perfectly good Python web developers who if you ask them how the MRO works, they won’t be able to tell you. That doesn’t stop them from writing perfectly fine web apps.

      I disagree with the blanket statement “weird code is broken code” – that’s basically buying into the exact premise I’m arguing against. If your definition of “broken” is “not perfect” then that’s going to put a lot of damping on experimentation. Obviously, different circumstances can tolerate different amounts of imperfection, and personal projects are usually a better place to experiment because of this – but framing things in that kind of an absolute statement isn’t helpful.

      • Point taken with regard to the distinction between understanding and mastering.

        Whereas I think we have a different concept of “weird”:
        To me weird means counter to established conventions, code where method/class names imply one thing/behavior following the conventions, while in fact doing something else entirely (that’s the simple case) or what you’d expect…and then have a ton of weird side-effects.

        That’s the kind of code that I call weird, and the reason why I say that it’s broken.

    • > Besides, I have yet to work at a place where code routinely gets refactored even after shipping.
      This is a problem whether you’ve mastered a language or not. I’ve been programming Python for nigh on eight years at this point, and I still write code that’s inflexible and poorly laid out. Sometimes I need to toss that code out and rewrite it if I need to implement a new feature or expand on it in some way. That’s just how it works; nobody writes 100% perfect code all the time.

  1. Pingback: 5 Development Tips for You - Curiosita Labs


Get every new post delivered to your Inbox.

Join 377 other followers