Mark Mzyk | January 14, 2008
The world would be a better place if all programmers did one thing:
Signed their work.
I truly believe this.
You should too.
There’s a reason this is the the final tip in The Pragmatic Programmer. It’s so important a point that it ends the book. It was chosen to leave the lasting impression.
So exactly why is it that important?
The Artistry of it All
In various places I’ve read the notion that programming isn’t mechanical, but that it’s a craft. Its takes brains to do this stuff. If it didn’t, there wouldn’t be a need for programmers and we’d all have been replaced by machines. It also takes brains to create art. If it didn’t, then things like the sign to my apartment complex would be considered art. Artists sign their work. There are, I believe, several reasons for this.
They want you to know they created it.
They are proud of their work.
They take responsibility for their work.
It’s for these same reasons that programmers should sign their work.
The List of Signs
Sign your work to say you created it. You want the world to know what you’ve created right? If not, then why don’t you? If I don’t know that you created something, how can I then give credit to you for it? You have no right to blame me if I end up giving someone else credit for your work because you didn’t sign it.
Sign your work for pride. If you don’t have pride in your work, why not? If it’s the case that you are programming but don’t have pride, then why are you programming? You can complain that you have a terrible job with impossible constraints, but that’s not an excuse. Try to excel in the constraints placed before you. Then sign your name. If your work ends up being average, then I’ll forget it. If it’s great, especially considering the cards you’ve been dealt, your name will end up etched in my memory.
Sign your work to claim responsibility. If I’m the programmer coming after you, I want to see your name burning there before me so I have a tangible person to direct my rancor and hate toward when I come across your horrid code. I want a name to spew my obscenities at. Trust me, once this is done, I’ll feel much better. It will then allow me to get on with my own coding while I fix the mess you left behind. Perhaps, if you still work at the company, I may come find you and ask why you wrote the code the way you did. Your answer might surprise me and be so ingenious that the venom leaves me and I feel like an idiot. If your name isn’t there, then instead I might harbor ill will towards a nameless person. When I find out six months later that it was you who wrote the code, I’m just going to internalize the anger and you’ll never get a chance to redeem yourself. Childish? Of course it is. That doesn’t change that it happens. Yet if you sign your name to your work, then when I come across your name attached to a beautiful piece of code, I can properly adjust my view of you, and forgive you for the garbage you left before.
There are other benefits to signing your name.
It’s a marker left behind. You can go back and find old code you have worked on. You will have a road map of how you’ve improved over time.
When it’s time for your review, you can sit your boss in front of your computer and grep the code base and let him see what you’ve contributed in the past year. It gives him tangible evidence of your work, work that might not be obvious from the surface of the application. Doing this might be the difference between getting or not getting an extra percentage point raise. Although you may need to also add a date with your signature for this to be most effective, that way the horrid code you wrote from two years ago doesn’t come back to haunt you.
There’s also a benefit to of when you start to curse a piece of code and then stumble upon your name as the author. It’s a humbling experience. We could all use those from time to time.
It’s About Trust
Signing your work also has one other huge effect: it will cause others to confer trust in you. For all the reasons already listed, once people can identify you with your work and see that you standby it, your reputation will grow. Others will look to you. You’ll find that you gain responsibility and authority.
It all leads to a world where we can trust others and their code. And ultimately, isn’t that what we all want?
The Fine Print
I do admit there are some nebulous areas. If you fix a bug in someone’s code, should you sign it? If it’s a minor bug, likely not. A major one? Go ahead.
What if you do an extensive refactoring job? Sign the code, but leave the original author’s name as well. Let the history of the authorship show.
Use your best judgment on whether to sign something or not. You’ll probably make the right choice.
So sign your work.
I’m looking forward to being able to curse your name with your code, and, at times, admitting when you’ve written something better than anything I could have.
– Mark Mzyk