Repeat - Don't Repeat Yourself!

I am reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas and I'm sharing my thoughts, questions, confusions and insights as I continue to read the book.

I have folders on my computer with same books, music, software, photos at more than one location. I routinely copy things (my idea of backup) and then would forget about it. Even my Linqpad queries (which I write to test and learn new code) are at more than one place (office, home, usb, Dropbox) and I can bet they are all different. When working on a active project I knew things start looking bad when I start repeating the same logic at more than one place. Now I have repeated myself a lot of times to make it clear that I do repeat things :)

I did attended object-oriented analysis and design classes in my uni days where you learned how to reuse code and good design principles. But, hey, no one told me to... well... not repeat myself! At least not in plain english. No one told me "DRY—Don't Repeat Yourself" when writing programs as that would have been a better advice.

At work the number one reason of repeating some things would be "Impatient Duplication" - time pressures - forcing us to take shortcuts. But, then again, I have spent many hours correcting something which could have been avoided by not repeating it. 

This is one of the first tips which seems to have influenced me. I did cleaned my PC today of duplicated folders. For stuff where I think I need history, I am making use of Subversion. Eliminating all duplication would be a hard task, but I am on it. Now repeat 10 times "DRY—Don't Repeat Yourself", as you know, repetition is the mother of learning!

This is what we do

I am reading  The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas and the very first page strikes a chord with me. I hope to learn and share few things as I read the book.

Programming is a craft.

At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do).

As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice.

You try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock.

You work small miracles every day.

It's a difficult job.