On Repeat

Before I even officially started Flatiron’s coding bootcamp, I was given a series of pre-work to complete which went over the basics of programming to prepare me for the upcoming course. Among the first concepts taught in the pre-work was that of abstraction and the importance of “DRY” code. DRY stands for Don’t Repeat Yourself, and was, unironically, often repeated by may various instructors throughout the program. Being DRY was also carefully tied into the concept of abstraction.

One instance of abstraction that sticks out to me was in a code challenge review one of our instructors did. There were many impressed noises coming from us as our instructor took one particular concept we were struggling with and abstracted it into a general component that he passed various properties into, disguised as a common variable name.

The process went something like this. On our page, we needed a robot army to be displayed in one of two locations, either a section of recruits, or to be recruited. In the to be recruited section, we needed a button to recruit them, and in the recruited section, we needed a button to remove them. Our instructor made one single card component, using a method with a general name for the button press, along with general information about the robots. When he created the display card with the individual robot information, he named the variables with the same name, so that, if the robot was recruited, the method it passed along would be to remove the recruit, but if it was not yet recruited, the method it passed along would be to recruit the robot. It was simple and functional.

A lightbulb went off in my head when he did that, and suddenly I was looking for ways to make my work extremely abstract and extremely dry by the same process. In my next project, I used the process everywhere I could, and for the most part, it worked flawlessly. I was able to create very abstract information cards with generic information while keeping my methods specific to the card.

Then I got to my final project, where I had created a backend with a relational database with twenty-four different tables and a much more complex architecture. Now, more than ever, I wanted to keep things as DRY as possible. My code was going to be on a much larger scale already, avoiding repeats was going to save me a great deal on time and bugs.

But when I got into it, I quickly realized, the specific information I wanted to display, was too unique. I didn’t want to display all of my components the same way, with the same generic data. But this mantra, Don’t Repeat Yourself, abstract your data, was there in the back of my head, as my instructors’ voices. So I spent time researching and problem solving on how I could keep my code DRY when I had different things to display.

I ended up adding a ternary operator to one of my cards to solve the first problem. It worked pretty well. (A ternary operator asks the question, “is this thing true?” then outputs one thing if it is true, and another if it’s false) I ran into another card that I needed a ternary for. And another. Then I ran into a card where I needed two ternaries. Ok, no problem, I can just split them up into two components, one to check between the first two options, and one to check between the second two.

As I looked over my code, I was starting to become proud of how abstract I was able to get. Then I put it down for a couple days to work on another part of the project before coming back to it. When I came back to it, I was totally lost. What in the heck had I been doing? I had abstracted with so many ternaries, I was having trouble following my own code. And honestly, I hadn’t really reduced my code by all that much. Instead of making new components for the specific information I wanted, I was just writing the equivalent of two components in one.

Frustrated, I went back and duplicated some of my components, removing a couple of ternaries and repeating some of my code so I could get the result I wanted. But I felt like a failure. DRY had been in my head from the beginning of my coding experience. Abstraction was the key to great programming, but this just wasn’t working. I must not be that good of a programmer if I can’t figure this out.

I finished my project with several components with repeated lines of code, and while I liked the resulting product well enough, I was disappointed with both my lack of abstraction, and readability of my code. After graduation, I promised myself I would go back and refactor my code, clean it up, document it more so that, even if the abstraction was hard to follow, my documentation would help myself and others to follow along.

When I went back to refactor though, I was faced with the same problems and I started questioning why it was so important to keep this code DRY. I was conflicted in my learning, and what I wanted to do. I felt like I should be more explicit, regardless of how much code I ended up repeating. I refactored a little bit, but gave up with the promise to myself to once again return to it when I was a better programer.

Recently though, I came across an article on Medium from a more experienced dev that talked about the pitfalls of DRY programming. In the article, he talked specifically about using ternaries, and how bad they can be for scaling. What happens, he asked, when a new requirement is added to the project that changes how that component will act for only some things? A lot of rewriting and potentially trying to force your program to be optimized for something it isn’t built to do well is one possibility.

Another lightbulb went off reading that article. Being DRY in your code, and abstraction in and of itself is not bad, but it’s a matter of scalability. When writing components for the first time, I need to think to myself, what does this code need to do, and what are the current options it has for the future? If I had thought of this the first time through for my final project, I would have just reused some of my code in different components and moved on, saving me hours of abstraction, rewriting, and refactoring.

So, another week goes by and another lessened learn in my journey becoming a (better) programmer. When possible, Don’t Repeat Yourself, but when necessary, Repeat.