In the comic book world, the origin story is the back-story of how a person became a superhero. They learn to harness their new powers, discover their purpose while making a few mistakes along the way.
Learning to code is a lot like gaining a superpower. One that lets you transform and build solutions in this software dominated age. Each year brings you more power at your finger tips. You can do more with less.
And like those superheroes (or supervillains if that’s your thing!), you have your own origin story. Did you start coding in college? Or was it a hobby you picked up? For example, I learned to code Logo in an after school program in elementary school.
You might share some elements of it with others like learning to code with WordPress. In the end though, most of that story is your own.
A common trial
There’s a common element to every origin story though. The trial. The superhero has to prove himself through adversity. It’s by going through that crucible that they cement their sense of purpose and morality. At least until the next reboot or retcon!
Lucky for you, you don’t need to lose your parents to learn to code (thank god!). That said, there’s still a learning period for everyone. You’ll wander a bit aimlessly trying to find your way.
There’s a common theme with a lot of successful developers I know. They found their way when they embraced the concept of “Don’t repeat yourself” known as DRY. Taken literally, it means that you should avoid duplicating code as much as possible.
DRY gives you a moral compass
Don’t Repeat Yourself is like holy water to programmers and mostly for good reason. In general, it’s no good to repeat the same code in two places.
While avoiding code duplication is a noble goal, it ignores the larger picture. Embracing DRY gives you a larger purpose. It forces you to look for ways to avoid that code duplication. The same way superheroes are always trying to not kill their enemies. Just cripple them badly!
Why is it bad?
What’s so wrong about duplicate code? Why should you strive to avoid it in the first place? Bugs. It prevent bugs. Especially the regression kind. That’s because you have the same piece of code in several places. This creates a vulnerability.
If you fix a bug in one location, you have to remember to do it everywhere else. Otherwise, the bug will surface somewhere else. You’ll have to chase it down in the rest of your code. This wastes your time and can even costs you money.
DRY goes beyond your code
It’s also useful to see the importance of DRY beyond your code. Duplication happens everywhere. Let’s discuss some other areas that can have a lot of duplication.
Stylesheets are probably the worse offenders of duplication. Luckily, this is less (ha!) of an issue since CSS preprocessors (like Less and Sass) were created. They allow you to define styles that can be re-used through out your stylesheet.
You’d need to ensure that your code keeps all the information up to date throughout the database. Otherwise, you’ll end up with data anomalies and corruption.
Depending on your project, your documentation can be found in several locations. If you have a documentation website, it’s important to have the tools in place to automate the generation of that website.
This allows you to have one authoritative source for that documentation. It also helps prevent the documentation from getting out of date.
Configuring servers and workstations has always been full of duplication. You’d work with Windows or Mac OS, but the server was Ubuntu. You’d need to copy and adapt your configuration between environments. Or just do everything manually.
That’s why developers invented tools like vagrant. You can then combine it with configuration management tools like Puppet or Chef. This allows you to have a single representation of your environment which is usable by everyone working with you.
Learn the limits of DRY
When you start applying it everywhere, you start doing more than just preventing bugs. You start saving time and money (lots of it). That said, it’s important to not unleash your inner anti-vilain!
People can take DRY too far. Sometimes, it’s worth being pragmatic about things. Taking a hard line against duplication can paint you into a corner. That’s something you’ll learn through practice. There isn’t always a clear rule for you to follow.
How you can strive for DRY-ness
Speaking of practice. What can you do every day to help you stick with that philosophy?
Become an expert in your programming language
You should always be trying to improve your knowledge of the programming language you’re using. There’s sometimes easier ways to do things. They just use more obscure functions that you might not have known about. These can often eliminate duplications in your code.
Learn object-oriented programming
Object-oriented programming is all about helping you reuse code. That’s why it never clicked for me (or other developers I know) until I learned about DRY.
There’s nothing like a principle you strongly believe in to make you take the time to learn something.
Add tools to your belt
You should always be looking at improving your development toolkit. For example, you could switch to an IDE or a powerful text editor. These make it trivial to generate blocks of code using macros.
This article already mentioned quite a few. It’s important to always be on the lookout. Everything changes quickly in the tech world.
Automate repetitive tasks
This is somewhat related to tools. Automating repetitive tasks is a useful way of eliminating possible duplication errors. Tools like grunt are great for that.
That said, it’s important not to get carried away. That’s why this xkcd comic is always relevant if you want to know if it’s worth your time.
The rest is your story
This is where your story branches out again. I hope this post encourages to experiment and improve yourself. We all need that guiding principle to get us to do a little more every day.
That’s what DRY helps you with.