Puzzle Pieces
25 Apr 2024
Opening the Box
Before I ever start a puzzle, before I even look at it, I have a habit of shaking the box. I like to hear all the little pieces inside rattling around, ready to be put together. The sound is intimidating, but it also fills me with anticipation. I get more excited sifting through the chaos than I do about completing the final product. Before I start to put any pieces together, I always go through every one, and sort them out. I put the corners and edges together and the middle pieces go into neat color-coded piles before any piece is connected with another. Then I always begin with the frame, the backbone of the puzzle. All the edges and corners must be laid down before I start with the middle pieces. Then finally, I put together the full picture.
Surprisingly, I have found a lot in common with the way I solve puzzles and the way I tackle software engineering. Like my puzzle pieces, I like to work on my programming projects by organizing things into smaller tasks, creating a simple framework, and then filling in the details and fun bits of the code last. An exceedingly important part of making this process work is knowing how to effectively utilize design patterns. In software engineering, design patterns offer tried-and-tested solutions to common design challenges faced during development processes. They allow us to solve recurring challenges with a replicable solution so we don’t have to solve each problem individually over and over again. There are many different types of design patterns sorted just like my piles of colors into groups of unique functions that solve different parts of the puzzle that is software engineering. These design patterns serve as the building blocks, the puzzle pieces, of any program for software engineers.
Piece by Piece
The piece or design pattern I have enjoyed using the most so far has been module design. Just like I like to sort my puzzle into small groups before I solve the bigger picture, I enjoy being able to make smaller, reusable modules of a program and use them like puzzle pieces to build my code. This might be one of the most basic design patterns to learn but I believe it is a foundational skill for a reason. As your program grows, it becomes increasingly important to keep your code organized and maintainable. The best way to do this is through module design. A good example of this is our use of modules in our meteor applications. Our apps are filled with modules such as the individual pages, components, and collections. The template meteor application we use is a framework built from these many modules that we can replicate to create our own application. Without the separation allowed by module design, our app building would be extremely difficult, impractical, and very hard to replicate. Module design has been, by far, the most important piece of my puzzle.
Building my Picture
Learning how to recognize and use design patterns has been a long and taxing experience. In the beginning, just like hearing all those little pieces rattling in the puzzle box, seeing the large number of unfamiliar design patterns I had yet to learn was incredibly intimidating. However, I have found that opening the box was the hardest part. Now I am elbow deep in the pieces and as time goes on I pick up the puzzle, piece by piece, pattern by pattern, and build my picture, learning new things every day. The ever evolving nature of computer science means that my puzzle will grow infinitely with new technology, concepts, and design patterns - new pieces - being added to my box constantly. It used to scare me but now, a never ending puzzle sounds like the perfect thing for me.