Judging Code

Sam Stephenson of 37 Signals wrote this post on December 13th, 2012 – You Are Not Your Code.

I didn’t realize he was one of the authors of the Prototype framework or even that he worked at 37 signals (until the bottom of the post). The other point I wanted to make is that I don’t think this is specific to “open-source” work either.

Developers working together to build shared infrastructure: it’s the fundamental tenet of open-source software. Any motivated programmer with an idea and the ability to implement it can solve a common problem, share the solution with the world, and reap the rewards of future improvements by peer review.”

It’s not just open-source software – it’s ANY software. Every product or project you work on typically involves working together, even if it’s by simply pitting your own crazy ideas against each other. You solve a problem and then you get reviewed, whether it be by peers, superiors or, far worse, the purchasing public.

When building software, you make trade-offs. On a recent project, we had to move the prototype quickly into production because it was clear that it would take too much time to recreate it from scratch. For another client, work that was supposed to last for four years (while waiting for a new product) has lasted over fifteen. When you look back at your old code, you likely cringe at some decisions were made – but that was then, this is now.

I can feel his pain though  –

“The reality is that Prototype helped lots of people despite its flawed foundation. But its time had come and gone, and I eventually realized it was time to move on.
It was hard not to take Prototype’s failure personally. Critical blog posts felt like a full assault on my values. And seeing friends use other libraries made me feel like my work was a waste.”

It’s a great read – and as he notes :

… you are not your code. A critique of your project is not tantamount to a personal attack…. It is simply the result of a regenerative process, driven by an unending desire to improve the status quo.”

As I noted above, I don’t believe this is exclusive to the open-source world or software. Sure, companies are judged based on their products; but more importantly, they are based on their service to customers. But as individual developers, your code should always be open to criticism, by yourself or by others.

What is an example of a perfect line of code? Is it:

print “Hello World”

(why are you using double quotes, why do I need to say Print, why is it in proper case?)

Hey, Kevin Ragsdale has a series of posts on how ugly FoxPro is — I would expect that none of the Fox team takes offense to his posts. They created a canvas – what you do with it is your business.

Ayn Rand once said “Judge and prepare to be judged”

It’s how you react to that judgement or criticism that shows your character.

Thanks Sam – great post.

1 thought on “Judging Code”

  1. Great post Andrew. But I must not fully agree with last paragrahp: The posts of Kevin Ragsdale that you mention doesn't talk about how ugly FoxPro is, they talk about how many ugly *apps* made in FoxPro are all around, that is not the same thing.
    FoxPro is a beautiful language and you can do beautiful apps with it, and you can do uglys apps in any languaje.

    Part of the problem of this perceived uglyness was motivated because VFP is an easy RAD language, so people without proper programming knowledge can just go and program with it, getting working code in almost no time, without taking care of design. Letting the app without an icon just show de Fox icon… so users confuse any Fox app with FoxPro language and the word spread.

    But there is no ofense, really, is just a common mistake people do because our design faults! 😉

    Best regards!

Comments are closed.