About printing code…

I resisted authoring this one for as long as I could… but here I am.

Printing code in a professional setting for code review purposes is dumb for a few reasons. Let me enumerate the top three reasons:

#3: Scale… for the amount of code even a moderately sized project contains, reams of paper and barrels of ink will fall short when that code base is printed on physical paper. This is certainly true for software companies with 100s of engineers working on large code bases — consider that they are not doing anything else. The amount of code that churns even in an active repo on GitHub… in a single day will make any printer struggle.

#2: Authorship … it is not uncommon for engineers to change a single line of code in a (multi-A4-paper) source code file. Are they supposed to print that whole file with all its pages? That single line change will make little sense without some context (not to mention without other related files.. but I digress).

It is also not uncommon for a single line to have parts contributed by multiple engineers.

There is a reason why code is viewed digitally. It’s authorship is often complex (in a professional setting) and best understood in detailed context. Physical printouts make no sense. None.

#1: Security… are you ducking insane? Printing your proprietary source code? On paper? Flying around? Are you sure you don’t have any secret keys that were accidentally added to the source code? Or some sensitive procedure or algorithm that would be best kept within the confines of the corporate premises and/or servers? Some internal architectural secret sauce that shows how things don’t meltdown? Or some embarrassing bug notes or code comments that you rather not share publicly?

If anyone asks you to print your code, report them to HR and then to Legal. It is a stupid practice and reeks of professional malpractice, not to mention incompetence, on the part of the person making the request.

— vijay,

#microblogging from a rocking chair