97 Things Every Programmer Should Know

(Chris Devlin) #1

(^186) 97 Things Every Programmer Should Know


Write Code As If You


Had to Support It for


the Rest of Your Life


Yuriy Zubarev


YOULDOU C ASK 97 PEOPLE what every programmer should know and do,
and you might get 97 distinct answers. This could be both overwhelming and
intimidating at the same time. All advice is good, all principles are sound, and
all stories are compelling, but where do you start? More important, once you
have started, how do you keep up with all the best practices you’ve learned,
and how do you make them an integral part of your programming practice?


I think the answer lies in your frame of mind or, more plainly, in your atti-
tude. If you don’t care about your fellow developers, testers, managers, sales
and marketing people, and end users, then you will not be driven to employ
test-driven development or write clear comments in your code, for example.
I think there is a simple way to adjust your attitude and always be driven to
deliver the best quality products:


Write code as if you had to support it for the rest of your life.

That’s it. If you accept this notion, many wonderful things will happen. If you
were to accept that any of your previous or current employers had the right
to call you in the middle of the night, asking you to explain the choices you
made while writing the fooBar method, you would gradually improve toward
becoming an expert programmer. You would naturally want to come up with
better variable and method names. You would stay away from blocks of code
comprising hundreds of lines. You would seek, learn, and use design patterns.
You would write comments, test your code, and refactor continually. Support-
ing all the code you’d ever written for the rest of your life should also be a
scalable endeavor. You would therefore have no choice but to become better,
smarter, and more efficient.

Free download pdf