The Monk and The Rockstar

I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great passion of mine, close to my heart and even to my identity or just id function if we think about functional programming :-). I have mentored and coached many architects during the last two decades. Today, I want to share some thoughts on something that represents the complexity and duality of the software architect role. Being an architect is not easy, it requires a lot of sound judgment, trade-offs analysis, design skills, research, requirements extraction, trend prediction, futurology, and lots of non-obvious skills. Architects must code, be practical, and make very good calls, resulting in better positioning for the future. Doing such a task is not easy and requires a lot of hard work; it's demanding and requires constant improvement and attention to detail. What is essential to extrapolate an architect's non-obvious antagonistic skill set, which the architect must master? Let's dive into it!

The Monk and the Rockstar

A software architect, it's a Monk? Or is it a Rockstart? Actually, it needs to be both. It needs to operate under a very different and antagonistic spectrum of skills and non-obvious activities.

                                        The Monk and The Rockstar - 2 Personas in 1 Person

The Monk: The monk is the slow and solitary persona of a software architect. The monk is slow, reflexive, and thinks deeply about thinks, you need to be a monk to do:
  • Software Design
  • Tradeoffs
  • Deep Research (I'm not talking about LLM Reasonbing, but Deep Work book).
  • Make complex and important decisions.
The monks need solitude and time away from meetings. They need time to do pocs, research the industry, and thoroughly consider the consequences of trade-offs. Complex problems aren't solved with just meetings; they require homework, time to think, analysis, thinking, drawing, and imagination from the Monk.

The Rockstar: The Rockstar has a lot of charisma, can drive people, can influence and flock engineering to go in a specific direction, solution, framework, or even avoid some direction, i.e., clean code. The Rockstar is the opposite of the Monk; he is dynamic, fast, and collaborative. It's a salesman, and such a persona is needed for the following:
  • Requirements Extraction: Requirements are decisions, but nowadays, most decisions are made via UX in a Figma board; a good rockstar needs to translate that into frontend and backend decisions, but before it must extract needs from UI mockups. Rockstar simplifies requirements, challenges decisions, does pushbacks and proposes better solutions.
  • Tech Leadership: The Rockstar needs to influence, teach, and lead developers; to do that, it must be a salesman who can have good arguments but make momentum a tool to deliver constant value. In order to do so, it needs to sell, communicate, and drive teams and people.
Rockstars need more meetings, constant comunication with people, and close collaboration with the business. As you can see, you need the opposite of the monk. A software architect needs to be both. It's hard to develop both skill sets, but you will be a great software architect if you do have it. 

How to Get Started

You can start with any persona but must develop both skillsets. Some people are monks, and others are rock stars. Some are good with code, and others are good with relationships. Here is some guidance for each persona to get started.

The Monk
  • Make multiple Drawings: Instead of one solution, draw 6-8 solutions and compare the pros and cons. Drawing is cheaper than coding and even implementing it.
  • Make Wiki pages: Create a simple wiki page with a simple overall diagram and steps explaining what the code does. Do a second diagram on how it could be and list the new steps. This is simple but enables thinking and better comunication.
  • Do multiple POCs: Instead of one person, do three to five and play with different options and flavors. This exploration will help you consider the pros and cons of different approaches.
In order to enable the monk you need solitude, make book 2-3 hours in your agenda where you will not goto meetings and you will have time to think? Another option is to do this before/after work in your alone/study time.

How to Get Better

Now, going over more advanced concepts of how we can further grow the two personas, here are some more advanced ideas to play with:

The Monk
  • Read the Source Code: Go read Linux kernel code, go read Java JDK code, and Go read NodeJs source code. Go Read React code; when you read hardcode codebases, you learn a lot. 
  • Hardcore Debugging: Don't stop reading code; debug hardcore components like the JVM, Chrome source code, React source code, etc.
  • Seek for Arguments: Read advanced forums to see what the arguments are, and ask people's opinions to learn from their arguments and ways of thinking. I bet you a beer you dont take 1% out of your workmates; go extract knowledge from them.
The Rockstar
  • Go look at Figma. The more you look at Figma, the more you talk to UX and the business, and the more you learn about needs. Don't take needs as "AS-IS." Remember the five whys; needs are often hidden, and you need to extract them. Nobody will tell you the requirements nowadays, so you need to learn how to extract them.
  • Do Pitch parties: Try to sell ideas or proposals to your workmates. This could even be an internal event. This helps to improve your selling and influencing skills.
  • Socialize: Ask for others' opinions. Seeking views does not mean you must do everything people tell you, but knowing perspectives always adds value. Socialize designs and PRs and ask for feedback.

People often think they can only learn to be architects by being architects with proper titles, but that's not true; you can learn even without the title. Any engineer can develop such skills. Lack of experience can always be supplemented with study, and when you have experience and study, you become solid and seasoned.

IF you like what you read here, pls give it a shot to my last book, Continuous Modernization, which covers the mindset, practices, and shift to better work data with teams dealing with feedback and other soft skills in complex, distributed systems at scale.

Cheers,
Diego Pacheco

Popular posts from this blog

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »