Thought Leadership presented by Sequoia Holdings.
Many hours of my childhood was spent playing with LEGOs. I would build model after model, only to tear them apart and rebuild something new.
My family had two large tubs filled to the brim with them. Some of them were inherited from as far back as my dad’s childhood, while others had been slowly accumulated from years of buying, building and tearing down LEGO sets.
Age eventually caught up with me, and my interest in LEGOs dwindled. But now, years later, I have three children of my own, and my oldest son is developing the same healthy fascination with the plastic blocks that I had.
One night, as we dumped out our own LEGO bin onto the floor (a big one which we had had inherited from my parents — some of these LEGOs are now third generation), old patterns and memories from early childhood started to filter back.
As we built, I started to realize that many of the same principles that had emerged from building with LEGOs as a kid were foundational to the software engineer that I had become as an adult.
So, with the seeds of a blog post planted, I started writing down those principals that underpinned my LEGO construction and identifying how they drove my experiences as a software engineer.
I share those with you as a fun way to look at software engineering and hope that you find this a useful and entertaining perspective!
Start with the right piece
Whenever I sat down to build a LEGO model, I would always start with a base piece — an inspiration; a platform to express the model on. Often that would be how the model would come to mind in the first place. I would see a starting piece and think “Oh! I could put these on that. Add this. Put those there,” and off I was to a new LEGO model.
In software engineering, the parallel is to evaluating a problem and fitting it to an initial design and technology platform. As a software engineer I see an initial problem and have an “Oh! I can start with this design pattern. And add this template. And use this library,” and off it goes.
Your choice of an initial platform or technology shapes the subsequent software. You have to evaluate the problem and make sure you are making the right choice to start building it on. It is really hard to correct from a bad first choice.
Build a library of pieces
Both as a kid and as an adult, whenever I start working on a model, I comb through the pile of LEGOs and start picking out pieces that I think might be useful. I usually have a theme and a color scheme in mind, so I only choose blocks that match that scheme. I find decorative pieces that match my theme. At this point, I do not always have a clear plan for the final model (other than inspiration from my starting piece).
As I would build, I could draw on this pool of pieces to grow the model, and not just rely on the luck of the draw or search through the LEGO mound to get what I wanted.
In software engineering, I liken this to your personal growth as a developer. Over time, you should develop your own set of techniques and patterns. You should squirrel away useful code from previous projects, or copy good code snippets others have written.
Later, you can draw on this reservoir for future projects and use the bits the fit the best to improve future projects.
Find the right pieces
As I was building, I followed the standard brick work “overlap” method to ensure my models were strong. (In fact, I used to drop test them on the kitchen floor when I was done with a model, much to the annoyance of my mom.)
I learned it was important to use the right pieces. If you had a 4-by-2 space left, search for a 4-by-2 brick. Don’t use two, 2-by-2 bricks or some other off-kilter combination. It would weaken the structure and later might force design compromises. Searching for the right piece was worth the effort in the long run.
I liken this to software engineering and the “broken window” theorem. Write your code right the first time, even if it takes longer. The extra effort to refactor some code or incorporate a good use of a design pattern instead of a quick hack is worth the investment to maintain the structure of your code.
Like searching for the right brick, engineering the right solution takes time up front, but saves time in the long run by giving you a solid base to build from.