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.

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):

Catherine: Sohan, I have a question when you have time.
Me: Shoot me.
Catherine: Haha. It’s not “shoot me”. I think you mean just “shoot”. When you say “shoot me” it means…

In this case, Catherine genuinely cared and had the courage to share this feedback about my improper use of English. I love getting such direct and timely feedback.

Here, I’m sharing links to some content that I found to be high quality resources to learn about feedback. Hope you’ll enjoy.

1. Radical Candor Talk - The Surprising Secret to Being a Good Boss
2. Podcast: How to Get Feedback From Your Boss
3. Podcast: Take Feedback Like A Boss
4. Podcast: How to Give Feedback To Your Boss
5. Book chapter: Max up Candor: A Circle of Feedback

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. Often I could form a crisp answer to these questions only after the interview had finished :-( Here are some example questions:

1. What is your management philosophy?
2. Tell me when you had to deal with uncertainty.
3. Tell me about when you had to motivate a team even though you personally disagreed with the project.
4. Tell me when you innovated as a manager.

I did poorly in my first few interviews because how unprepared I was to answer these questions. I got truly frustrated. So, I started looking at YouTube to see how today’s inspiring leaders answer these questions. Here’s a list of YouTube channels that I found to be very resourceful.

1. David Rubnstein Show: 25 minute very high quality interviews with present and former leaders in business and technology.
2. View From the Top - Stanford: Hour long interview sessions with renowned leaders.
3. Technology Enabled Blitzscaling: Hour long interview sessions focusing on technology and startup leadership.

Watching these videos I developed some strategies for concisely answering leadership related questions with authenticity. I’d so love to do a formal research and write up on this topic some time. But for now, here’s the raw data for your enjoyment.

Go ahead and watch!