Hi, I’m Son (ソン), software engineer @ Startup Studio, CEO Office. As a title, I will share the story of my first chance of being a speaker at a tech panel discussion.

Context

This march, our CTO Nakade was looking for a speaker for the webinar about How should engineers utilize design patterns effectively which was co-organized by Money Forward and Mekari. Even though I’m definitely not an expert in that field, I believe I have some valuable perspectives to offer, therefore I have voluntarily registered. To be honest, that topic can be challenging for experienced engineers. This is not the kind of knowledge that you can absorb overnight but requires a certain degree of experience in the software industry. I personally did some public speaking before in both Vietnamese and English, but never in the QA or Panel discussion, where speakers usually have a ton of expertise. Actually, except me, all other speakers attending that event are already the Tech Lead or Engineering Manager. In addition, I had only one week for preparation from the day I told our CTO I’m going to the stage to give a speech.

Preparation

Individually, things I did for preparation

Read 23 patterns of OOP: https://refactoring.guru/design-patterns/catalog
Review the patterns that I have implemented
Research more software patterns outside of the patterns that used at the coding layer
Practice English pronunciation with my colleagues and try to explain Design Patterns in a simple way

Actually, I was overwhelmed by the vastness of information on Design Patterns. So in the end, I decided to talk about the things that I am already familiar with and the patterns that I used in the past.

One day before the event, all speakers had a pre-meeting to discuss what we are going to talk about that day. Should we only talk about Design Patterns (DP) in OOP? Should we talk more about coding patterns such as Dependency Injection besides OOP? Or should we talk about DP in engineering in general, including patterns in architect, networking, database? Finally, we all agreed that talking about design patterns in software engineering is more interesting and also helps participants gain more knowledge and new aspects of design patterns.

Go Live

Looking back, some of my answers were lengthy and confusing due to my English accent and I wish those could be simpler. But overall, I’m still proud of what I’ve done. There were some pretty intriguing questions from a moderator and participants that I want to share here (all my answers).

Q: What are design patterns and where do they come from? For me, a design pattern is a set of principles or rules, or best practice to solve the problems/issues of software engineering It was born to solve engineering problems so obviously they came from software engineers Actually, if we have any problems, and we are able to provide a good enough solution for these problems, then name that solution to a Pattern. If lucky, other engineers can adapt the pattern that we created. Why not?

Q: Example of using design patterns? Since other speakers already talked about coding design patterns such as Dependency Injection, Adapter, Decorator…etc. I decided to talk about a pattern that I’m currently using, called Single Table Pattern in NoSQL. By giving the participants an example of the pattern at the Database layer, hopefully, they can’t understand there are various types of patterns in software engineering.

To explain more about Single Table Pattern, the relational database was born around 30 years ago when storage was costly. So normalizations (1NF 2NF 3NF…) are usually applied in order to separate data into multiple tables to avoid duplicated data (Storage optimization). The downside is, you have to join many tables to get the data that you want, which is expensive. Therefore, to improve the read query performance when data volume is exponential, we actually can do the pre-join process by putting all data inside one table (No join query).

But adopting a pattern will usually come with a trade-off, especially when it is used at a scope that affects the whole project. In this case, I must know the access patterns first in order to make a well-optimized table, and pagination, aggregation…etc on that table are not well supported as relational DB. Q: Should I learn all of the design patterns? Short answer: No. Long answer: Recently, I’m learning cooking because of the coronavirus, and I realized the common thing between cooking and coding is about recipes. When you want to make Ramen, without seeing any receipt for the first time, and you don’t have much cooking experience, you will probably fail. or end up with a terrible Ramen bowl. That idea is the same in coding. If you're a junior IT engineer, and try to code, design architect without following any practices or principles, you are going to end up with a mess in the near future when your application scales up. So, I always think of design patterns as recipes for cooking. We should follow the recipes and hopefully one day, we can create our own recipe. Back to the question, if you want to be a master chef, should you learn all of the cooking recipes?. In my opinion, it’s not necessary. Just learn some basic recipes first, then practice practice, and practice. You will adapt new recipes on the journey of becoming a master chef.

Software always evolves, so do the design patterns (my additional opinion) In the past, the software was usually monolithic and had hundreds of thousands of lines of code. So the problems at the coding layer were born. For example, how to create a complex object (Factory Pattern, Builder Pattern…etc), how to communicate between objects effectively (Observer Pattern…etc).

However, thanks to cloud computing, containerization technologies, the services tend to break into many smaller services (aka microservice). The problem will be moved from the coding layer to a higher level such as architect, networking. So the new patterns will be created to solve new engineering problems. (Of course, there are still many patterns/problems at the coding layer)

Conclusion

Discussing an interesting engineering topic with other knowledgeable speakers was definitely exciting but also challenging. I’m glad that I made a jump. Meanwhile, I have to sharpen my engineering skills as well as my English for the next opportunity.

By the way, this tech event was co-organized by Mekari and Money Forward to promote a coding competition called Indonesia Young Coders League in Indonesia which via that competition, Money Forward is able to recruit top talented engineers from Indonesia. The more talented people come to Money Forward, the better product we can deliver to our users.