Reviewing > Testing > Copying > Writing

Rarely anymore do I sit down and type code out at a keyboard. Most of the typing I do happens on my iPhone or iPad via SMS or email. Typing new things at a computer is not particularly effective for me, and it’s generally not directly related to whatever task is currently at hand.

When I do need to type, it’s usually code of the PHP, JS, or CSS varieties, which means more reviewing and testing than it does actually typing things out. Lots of thought, then copying code I know does something similar, iterating on it, testing it, reviewing it, and committing to the result.

More often than not (let’s say 80% of the time) I copy and paste most of the code that I write. The original code comes from some other functionally proven, correctly working method that I either wrote myself or I’m already familiar with from some another project I’m involved in, and it gets iterated on over time to become something else.

The argument for this, is we avoid human typing mistakes and reinventing proverbial wheels.

The argument against this, is we run the risk of copying an existing, potentially hidden bug.

It’s more important to review and test existing code, than it is to write new code. Before writing something from scratch, be sure to budget time according to a ratio of: reviewing, to testing, to time spent actually coding. My rough guess is that the code review and application hardening processes should take at least 10 times longer than the time it took to write new code, and about half that for code that’s been copied from existing trusted and known-working sources. Maybe longer, exponentially so if this new masterpiece is a large addition to an existing project.

By copying existing code, you automatically inherit the labor that went into forging it to begin with. Each time a new file is created and code is written from scratch, potentially thousands of costly man hours are being completely disregarded. It’s an arrogant way to get things done, and a method/mindset usually better avoided in most circumstances.

There will be times where it’s nose down, neck deep, headphones in, write-new-code-mode. When that rare opportunity arises, be sure to budget the appropriate time to reviewing and testing it.