Welcome back to the Software Architecture series. I know at least a few people from my team are following, and that’s a great encouragement.

For today’s post, let’s focus on learning from a very popular and commonly used open-source project called Redis. To the developers, Redis is a dead simple key-value store with a super simple API as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ set today 'Thursday'
OK

$ get today
Thursday

$ set temp 20
OK

$ incr temp
21

$ incrby temp 3
24

$ get temp
24

Of course Redis has more advanced features, but not too many. I think Redis is a delightful system. It’s fun to use and has a reputation for being incredibly fast and scalable. I’m going to recommend you to spend some time on Redis architecture and see if you understand the concepts to confidently answer the following questions:

1. Why is Redis so fast?
2. What can you do to prevent data loss when using Redis?
3. How does Redis distribute its data to multiple nodes?
4. What happens when you add a new node to a Redis cluster?
5. What happens when you remove a node from a Redis cluster?
6. How does Redis allow you to have an even distribution of the data in your cluster?
7. How can you build resilience using Redis when a whole datacenter fails?
8. How does a Redis client discover which Redis server to go to?
9. How do you know if you have enough capacity in your Redis cluster?
10. How does Redis provide end-to-end encryption?
11. If a Redis cluster dies, how can you restore it?
12. What metrics would you use to monitor if your Redis cluster is healthy?

My plan is to introduce you to a bunch of open-source systems like Redis and ask similar questions. The idea is, after going through a few of these systems, you’ll start to see patterns and trade-offs for each. Being familiar with real-world systems and seeing the patterns in use, I hope you’ll be able pick and choose the patterns that best fit your system requirements, environment, and people.

Happy learning!

In my current role at Microsoft, I’m working on a UI SDK product. I hear this concern from some of my team members. More specifically, here’s a paraphrased version of what I hear:

“I talked to my friends in software and they told me it’s better to work on the backend or full-stack to have a fast-tracked career.”

First, I do agree that there are generally more full-stack or backend engineering jobs than purely frontend jobs. I also agree that there’s a general perception that frontend is easy / bunch of scripts / not real engineering, yada yada…

However, I think it’s a short-sighted view. Let me make my point here.

Let’s imagine the UI and UX of a familiar product, Google Maps. You can use Google Maps on your browser or natively on the phone. You can embed Google Maps within your own app on these platforms as well. You can ask Google Maps to give you navigation direction for walking, biking, driving, or ask it to show realtime transit and traffic infomation. If you take a detour, it’ll show you new directions on the fly. You can see the map view, or the 3D view, or a camera view of a location. At night, you can see the dark-mode. It’ll show you how many lanes you have on a road, and how fast you can legally go, in realtime. It’ll let you share your location in realtime with your buddy. You can search using your voice and it’ll also give you turn by turn voice guidance. Let’s not mention avoiding toll-free roads, u-turns, etc.

I hope you see the engineering challenge I see in the above paragraph. Very few engineers I know can architect a system such as Google Maps. Since a lot of the engineers choose the path of backend engineering, it’s incredibly hard to find frontend engineers who can pull high impact projects. If you consider yourself above average, and you probably are if you’re reading this blog, you should not follow the path of the average. Instead, if you like building visual products and obsessing about delighting millions or billions of users, you can have a very rewarding and fast-paced career in frontend engineering.

Most of your engineering knowledge is transferrable, irrespective of what part of the stack you work on. After all, you’ll learn to work with people, delight customers, build systems that are robust, scalable, secure, compliant, testable… So, you can move into a different part of the stack at will as long as your foundation is strong.

Modern frontend engineering is complex, but it’s powered by innovative tools. Most of the tooling is open-source and the community is vibrant with lots of conferences and meetups around the world. As a frontend engineer, you can create an outsized impact and differentiate yourself from the masses.

An architect first needs to write for herself, and then for her team. Let me explain a bit.

An architect takes the trio of requirements, people, and environment, and does her research to design the most delightful system. In her research process, she uses her past experience as well as the experience of others. Even a moderately complex system design involves a lot of trade-offs without clear winners. For example, given that there are tens of different databases one can choose, how can she recommend a specific one? Only a clear mind can produce a logically sound write-up. So, in the process of writing and rewriting her design rationale, an architect can strengthen the soundness of her own logic behind the choices made. This is also known as covering one’s ass.

Secondly, an architect is a busy person and can’t scale her time if she has to personally explain her design rationale to everyone. In fact, as she’s designing the system and making certain assumptions, she must seek feedback from the team to help her find alternatives or blind-spots. Writing scales infinitely (e.g. J.K. Rowling), and after all, an architect must use a scalable system for herself, right?

In this episode, I have two all time great books to recommend, The Elements of Style and On Writing Well. If you want to learn to write with a fascinating biographic story, I loved On Writing (A Memoir of the Craft) by Stephen King. Do yourself a favor and get these books. Even if you are a native English speaker, I recommend you reading these books to make your writing interesting. As you can imagine, these books on writing are fun read, it’d be quite an irony otherwise.

As promised before, this is my last soft-skills related post in the software architecture series. Only a few senior engineers will break the glass ceiling and become an architect. Fewer will become a great architect. All the great ones I’ve met had exemplary soft-skills.

First, working with good people for a good purpose. Then, moving fast and delivering incrementally. Then, a good business case. And finally, a reasonably modern tech-stack.

Other things, such as pay, promotion and prestige are important, but it doesn’t drive me like the above.

This content is suitable for a Twitter post, but putting it here for long term retention. I want to look back after a few years to see how timeless this drivers are for me.

To be an architect, you’ll have to be a leader. And, to be a leader, you’ll have to be able to understand people and create an influence on them. So, focusing on the people involved with a system is a pre-requisite for designing systems that delight them.

Photo credits to Alan O’Rourke

For this topic, I want you to read and internalize the ideas from the book How to Win Friends and Influence People by Dale Carnegie. Honestly, it’s a fun read for anyone, not just for the aspiring architect. But an architect must be able to listen with empathy and clearly share her ideas. She needs to truly appreciate diverse opinion because it’s common that a delightful system can be designed in many ways, and she’s likely to have her blind spots. Moreover, she needs exceptional conflict-resolution skills to create a safe space so the best ideas win irrespective of where it comes from.

I know some of you may be getting impatient because you want to learn hardcore software architecture and I’m not talking anything technical yet. If you can hold your patience and bear with me, we’ll get there soon enough. I have what I think an exciting curriculum where I’ll be teaching hardcore software design topics using many well-known open-source products. My goal is to set you up for success as an architect, and these softcore topics are of the highest priority in my curriculum. The small number of great architects I’ve enjoyed working with have won me over by their people skills. All the other architects may have been technically genius, but lacked people skills to appreciate the essence of a delightful system, let alone designing one.

“I want to be an architect” - is a common career goal I hear during one:one meetings and annual reviews with my team members. Honestly, I’m writing this series of blog posts to bring some clarity and structure into my own thoughts, and hopefully to scale my time. You can even say, I’m open-sourcing my mentorship on the topic of software archtecture. My sincere hope is, this series helps my team or anyone who wants to systematically learn and improve their software design skills.

My mental model of a software architect as a system is as follows:

                 _________
                |         |
Requirements -> |         |
                |         |
 Environment -> |Architect| -> "Delightful" System Design
                |         |
      People -> |         |
                |_________|

That is, they produce the most delightful system design as the output from three inputs: business requirements, the environment that surrounds the system, and the people that are involved with the system. The main phrase to remember is “the most delightful” - because this is what makes the architect’s job so much fun and appealing.

First, I recommend reading the book The Design of Everyday Things to learn how design impacts us everyday. It’s a fun and must read for anyone involved in any kind of design.

Next, I recommend reading the book Don’t Make Me Think to learn about how to know if your design is delightful.

I prefer the word delightfulness over usability or customer obsession because the former sets a high bar. I hope you also internalize the goal of designing the most delightful systems and settle for nothing less, why should you?

This card is a parting gift from my beloved team. (Catherine, I know you made it)

This post is dedicated to my team at Cisco. I put a lot of my passion and care into building and being part of a great team during my time at Cisco, eight amazing years between 2012 to 2020. It was the privilege of a lifetime to be able to learn from and mentor an amazing group of people while building a product together.

Our memories work in a fascinating way. At Cisco, I put most of my working hours on actual work such as understanding and sharing project scope, designing and building solutions, responding to customer support requests, interviewing, presenting, etc. But just after four months, now that I think about my time at Cisco, none of the actual work takes the centre stage in my memory. Instead, the memory is filled with incredible life stories I heard during the short walks I took at the park for one:one meetings, or relaxed and often-long Friday lunches, or giving someone a safe space when they felt vulnerable. It’s a reminder that when it’s all done and dusted - what remains is the people and relationships we build with them. I’m so glad to get this card in the mail after I left and I’ll forever remember this kind gesture.

What better can a man wish for than being “unfrogettable”?

Good design is obvious. Great design is transparent. — Joe Sparano

Ruby on Rails delighted me all through my career. The community is one with a taste for art, thanks to DHH’s ability to write well. He set a high bar and the community also lives up to it. One API that absolutely blows my mind is how delightful it is to work with date and time in Ruby on Rails. Here are a few example use cases:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Schedule a report to run at the beginning of next week
report.run_at = 1.week.from_now.beginning_of_week

#.. or first Friday of next month
report.run_at = report.run_at.next_occurring(:friday) unless report.run_at.friday?

#.. or beginning of next month
report.run_at = 1.month.from_now.beginning_of_month

#.. or mid-day tomorrow
report.run_at = 1.day.from_now.at_midday

# Is today a weekday?
Time.now.on_weekday?

#.. or a weekend?
Time.now.on_weekend?

# Book a calendar event for a whole day
time_off.duration = Time.now.all_day

#.. or find sales in the current quarter
Sale.where(created_at: Time.now.all_quarter)...

A lot of time related code I’ve seen in real projects is finding a point in time relative to now. Ruby on Rails makes it an absolute joy traveling time by adding time related methods straight into the Integer class, where the code looks just like how we think about time. Sure, Rails uses complex classes such as TimeWithZone, Duration, etc. under the hood, but I’ve almost never seen those used directly. This is such a stark contrast with many other platforms where you have to use pedantic concepts such as TimeSpan, Calendar, GregorianCalendar, etc. The true elegance of time travel API in Ruby on Rails lies in how invisible it is.

Image source: Show and tell - explaining the rain game

I started my developer career 15 years ago at the onset of agile and Scrum. From my early career, I worked on short sprints where we demoed our work to collect feedback towards the end of each sprint. So, after thousands of demos, I’ve seen enough great ones that I developed a taste for it. I can no longer go back to soulless demos. This post is about a few observations I have about great demos.

Presenters of great demos always tell a story. The presenter herself had a lot of fun and she has to share her excitement with everyone. It’s contagious, we can’t help but listen. She shows what her team had done and why it matters. She fondly shares what was fun and what was a pain the butt. Her passion drives us to pay attention and take part actively.

Great demos have a memorable punchline. The presenter lays out the demo in a way that neatly converges to her punchline we can’t forget.

Great demos allow everyone to immerse into the demo. The presenter takes a pause so the audience can focus on the work of art, and shares her narrative when the audience can truly focus on listening.

Great demos are inclusive. The presenter remains humble, acknowledges her team’s effort, and curiously seeks feedback from everyone.

Great demos feel short.

Now, treat yourself with this captivating storytelling of Nick Means even if you don’t have 40 minutes of free time. You’ll thank me. I know sprint demos are only 5-10 mins, but you can still put your soul into it. We’ll surely care.

When talking to people, I’m always interested to know how they learn. This image above shows a view of how I personally learn. Here’s some context about the items on the diagram:

1. Online-courses: I love O’Reilly learning. Their video courses are split into 5 minute lectures. For example, I took their Kotlin course to learn the language.
2. Books: Books are great for curated content, but it takes dedicated time. Most of the time, I have one book that I read. Current interest is on leadership and business.
3. Hands-on: A lot of people learn by doing. I do the same, but mostly at a hello world level instead of going too deep into new things.
4. Podcasts: This is my most passive form of learning, mostly when I’m walking or driving.
5. People: I keep in touch with people and ask them about what they are learning.
6. Twitter: I admit, I spend too much time on Twitter. But occasionally, people share interesting things.
7. YouTube videos: I watch conference talks such as InfoQ, DotNet, Rails, Ruby, Goto, and AWS.
8. News: I follow Hacker News mostly for tech and business news. And then there’s following stock market news about new business innovations.
9. Interviews: I watch inteview shows on YouTube as I’m a big fan of biographical content.
10. Open-source: I follow a bunch of open-source projects or just read code from time to time to learn about how the passionate and expert developers craft code.