Hey! How are you doing?
In the previous Mektup, I talked about the role of a software architect and promised to explain the technical breadth, mentality, and knowledge styles that architects should seek. Now let’s talk a bit about it.
Mark Richards and Neil Ford use the knowledge pyramid to explain the difference.
On the top layer, we have the stuff we know: our knowledge and expertise. In the mid-layer, we have the things we know that we don’t know: the things we know exist, we’ve heard them or used them, but we don’t have any expertise. The last but the most significant portion of our knowledge is the stuff we even don’t know exists; we simply are not aware of them.
Developers spend their life whetting their expert skills by growing their knowledge on the subject, a.k.a. the top layer in the pyramid—technical depth. The bigger the top layer, the more expert the developer is. For architects, the second layer is more important than the top. Here the technical breadth comes in; how much the middle layer expands into the bottom layer defines the breadth. Both top and mid-layers are essential for an architect, but they sacrifice some parts of their expertise to expand their portfolio. They learn new things but don’t get any deep knowledge of them. Because in the architect role, it’s more beneficial to have a broader understanding of various technologies than to have expertise in one or two.
The transition in knowledge acquirement is where most developers struggle while becoming architects because they don’t want to leave their expertise behind. The case is that the stuff you know is also the stuff you maintain, and architects have no time to broaden their knowledge and keep their expertise. They can still have expertise in one or two languages or frameworks, but these technologies mostly stay at the hobby level. Architects need to acquire knowledge about system design, architectural characteristics, and architectural styles, but not how to implement user authentication in NodeJS. They might still learn it; it’s okay to have deep knowledge of one or two topics. But it’s not required.
The technical breadth vs. technical depth is only one small part of the architectural thinking and software architect’s job. I’m preparing more detailed stuff for architectural thinking (either a podcast episode or a blog post). Before letting you wait for that, I want to share a sneak peek with you. Here you can find out the work-in-progress mind map I am using for the preparation of Architectural Thinking. You will see that technical breadth is only one part of it.
That’s it. If you think I missed something in the mind map or would love to share your thoughts, you know how to reach me: just hit the reply button below.
— Candost
P.S. I’m a fan of Farnam Street.
The Best Thing I Read In the Last Two Weeks
The Availability Bias: How to Overcome a Common Cognitive Distortion
“The availability heuristic explains why winning an award makes you more likely to win another award. It explains why we sometimes avoid one thing out of fear and end up doing something else that’s objectively riskier. … It explains why the five people closest to you have a big impact on your worldview. … And it explains why bad publicity can still be beneficial in the long run.”
The article reminded me (and also mentions) of the availability heuristic that Daniel Kahneman mentions in Thinking, Fast, and Slow. The book is fantastic, but it’s hard-read. On the other hand, the article is excellent and full of explanations and recommendations.
