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?

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.

“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.

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.

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.

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.

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: 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. Books: Books are great for curated content, but it takes dedicated time. Most of the time, I have one book that I read.

Photo credits to GotCredit Here’s a personal story about getting a feedback. For context, English is my second language. I grew up speaking Bangla as my primary language. I learned reading and writing English in school - grammar first. I had only started speaking English much later in my life, in my mid-twenties. So, I often struggle with the informal form of the language. With this context, here’s an excerpt of a one:one chat conversation at work (from memory):

This summer I was interviewing for a new job. This was the first time I was interviewing for an engineering manager role. Soon I realized these interviews were wildly different from interviews for developer roles. During typical developer interviews, I solved coding and system design problems and discussed personal aspirations in behavioral interviews. In contrast, leadership interview qeustions were really open-ended. Honestly, I found it very hard to answer these questions concisely.