Repeat, Repeat, Remember! Design Patterns
28 Apr 2022Struggle Once, Thank Yourself Later
In many cases, tasks can be daunting at times. So much to the point where there is not productive part of your body and you just feel like taking the shortest route to do what you need to do. For homework, it can feel so easy to look it up on the internet. At these times it can be hard to want to deal with the struggle of sitting down for a few hours to try to comprehend the topic. Especially in the heat of the moment, anything will always seem better than doing homework.
Imagine for the moment that due to your busy life of procrastinating, you forgot that an important assignment is due. I might be projecting here. Anyways, this super very important assignment is actually based on a significant part of the class, but at the moment of panic and stress, that doesn’t matter. What matters is getting the assignment done, and so you look it up, or you ask a friend to do it for you. Phew, the problem is now gone. At least you thought. Now on the day of the test, you have no idea how to deal with problems similar, but the professor mentioned that it should be similar to the homework. You hold your head low in shame, because now you have to take even more time to relearn that same topic. It’s a feeling all too familiar, but I’ve been working over the years to break this habit, and by understanding design patterns is how I’m able to curate the energy to get things down sooner, so that I can replicate results for future problems.
Repetition: Design
Design patterns are a concept first coined by Christopher Alexander, an architect who defines the term as “a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Although it can be translated and interpreted toward software engineering specifically, it is the broadness of the concept that makes it both versatile for different situations as well as easier to comprehend personally.
In the most general sense, there are so many problems that one person might face over and over again. Conversely, there might be many people who face the same problem. By recognizing the patterns and repetition in these problems, then it is possible to create general guides to solve similar problems in the future.
Repetition: Patterns
The best example of these patterns would be homework for a class as mentioned before. Practice makes perfect! Not only that, but practice creates multiple scenarios of the same problem and so it gives the person multiple attempts to solve these problems. Eventually once you get the homework understood, then the tests don’t seem as bad. I hope the bells are ringing because I had to type this out just so that I could understand the concept.
Each problem has a general premise that needs to be understood in order to solve future problems. It’s not as easily done that said however. That’s why in my current software engineering class, the experiences and screencasts are my introduction to certain problems. I see them, and although I don’t understand them at first, I look over it again. I take the time to reattempt the problem. I repeat, and repeat, and repeat until I can understand what code I am typing and it’s meaning. By building up this comprehension and repetition, the next time I see a problem similar, I can immediately think, “REMEMBER, DO NOT DO WHAT YOU DID LAST TIME OR YOU WILL SIT HERE FOR HOURS FOR THE SAME MISTAKE.” Yeah, something like that.
Repetition Then, Efficiency later
My personal anecdotes are more of a muscle memory ideal when it comes to design patterns, but the literal design patterns have been in use all throughout my software engineering class as well as in the real world. Of the design patterns specified by the Gang of Four, I can easily say that once I sat through initially learning factory design patterns and other techniques to implement a meteor application, my time spent on coding each page was cut in half more and more times when I worked on a similar problem.
There are subtleties to the concept of design patterns, and although understanding it in a small scope of designing a software, I already can appreciate the generalized guidance made by my past self or others who have similar issues in order to making future problems easier. For the future, I definitely will keep these repeated and reusuable processes in mind for both future problems as well as when asked about it so I don’t have to waste time redoing redundant work.