Skip to main content

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.

Comments

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!

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing. If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site.  If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area. But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements. ...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...