Cover image for What should I know to be a software architect?

What should I know to be a software architect?

stereobooster profile image stereobooster ・2 min read

From time to time I read articles or tweets or watch talks from @hillelogram or @pressron or @sebmarkbage (in no particular order) and realize that those people have much deeper understanding. They are not stuck in one paradigm or one programming language, they can bring paradigms from different languages to current languages.

For example, @hillelogram talks about inheritance at the whole new level I used inheritance for many years, yet never thought about it from this angle, never questioned it. Or for example, @sebmarkbage brought the idea of algebraic effects to JavaScript, yes in limited form, yes only for React, yet this idea started to spread across different frameworks, and it is quite intuitive and powerful. Or for example, how @pressron explains that imperative paradigm has its pros (people typically prise functional paradigm and not often otherwise).

Even more, they not just understand it, but also able to make it accessible for others. They are able to explain it - which proves again dipper understanding.

Dr. Hoenikker used to say that any scientist who couldn't explain to an
eight-year-old what he was doing was a charlatan

from Kurt Vonnegut's novel Cat's Cradle

I guess they have been exposed to many different programming paradigms, or maybe they studied some arcane, but very clever programming languages or they had pretty good CS education (not all degrees are the same).

Recently I stumbled on this quote:

If you don't know how compilers work, then you don't know how computers work.

-- Steve Yegge

And this made me think: are there specific topics in CS which will significantly improve understanding of CS in general? Should I write my own Lisp, or should I learn E programming language, or should I learn about branch prediction, should I read Types and Programming Languages or SICP, should I know answers to Entscheidungsproblem?

What are the most effective ways to gain real deep understanding? What is the required knowledge?

Photo by Samuel Zeller on Unsplash

Posted on by:

stereobooster profile



Hello, I'm a full stack web developer. Follow me on Twitter!


Editor guide

How to be a good software architect?



Software architecture is social work. It's not rare the software architect is also the project in chief, and it could also be a CTO.

We, as an architect, we must be able to answer 3 questions: what? how? and with what?

  • A software architect must understand what the requirement is. So, how we know this?. Talking, we talk with the product owner / who request the project and talk with all parts, including the team.

  • Then, the software architect must evaluate the resources. For example, the goal is to build a Facebook in a year, but we have 3 developers juniors. So, is it possible?. No, without extra resources, so let's talk with the guys of HR if we are able to hire new developers, or let's say if we could increase the time or lower the requirements.

  • About resources, let's say it is a startup and the company hasn't picked a technology, so, we should choose a technology based on the resources (developers, licenses, server if any) and start marking a roadmap. For example, if the team is aligned with Visual Basic 6 and it is enough to work, then go ahead, and we will develop with VB6. However, if we are a startup (there is not technology or team), then we could pick the best technology for the job.

  • And finally, we create the database model, screen mockup, use-case (if any), UML (usually they are useless trash, but some people love it) and such. Then, can we start?. NOPE. We should talk (again) with the product-owner, we should show the mockup, the use-case (or workflows if any) and the product-owner could ask changes.


I would say this is not quite the definition of software architect

A software architect must understand what the requirement is.

Yes, but as well as many other people like a business analysts, managing developer, tech lead, product manager. This is not unique to architect, this is not a distinctive feature.

Then, the software architect must evaluate the resources

Well this is sounds like a manger or tech lead or director of engineering or CTO to me.

And finally, we create the database model, screen mockup, use-case (if any)

Sounds like business analysts or managing developer or architect.

I mean those all are good and valuable things, but they don't give you any deep insight, for example how functional paradigm and OOP can be viewed as two sides of the same coin. RIght? I mean at which point of talking to product owner about requirements you pause and "Ah now I see how Y-combinator relates to McCarthy's eval".

UPD Maybe title is a bit confusing, but I extended actual question in the text. I asked more about how to get deep understanding.

Thank you for the answer. This is for sure good career advice. But I would say this is not quite an answer to my question about deep insight.


I agree with Jorge Castro in this point of view. Even you have the deepest knowledge of coding and software architecture, without those you cannot be a good software architect.

As a software architect (Martin Fowler for example, not about any job role), you must understand requirement in order to match you solution. Over engineering or under engineering is both not good.

In a small team, software architect is the same as CTO in a big company. CTO cannot decide everything for every team. Even if you are just developer in that team, knowing your teammates capabilities will help you give more properly suggestions.

In the modern engineering methodology, evolution design is the top choice as it improves agility of the project. Every developer has to know how to model the business, why software project failed (to not repeat it), why we should do this and not do that...


I like your answer, even though stereobooster had something different in mind. Your answer matches pretty good what the role of a software architect is about in the company I work. It's not a software company. This is probably the major reason for the focus on mediating between business and IT.


What the fk, that isn't an architect at all. Architects aren't people who who write up diagrams and talk to product owners. At least, the dozen I've met look nothing like that.


Experience is the main thing you need to be an software architect. You must have the battle scars of being in the office at 3am trying to fix a solution that has been broken all day. You need to know both good and bad solutions. And you have to take ownership of a project that is failing due to your architecture.


To answer this I need to define what is "experience" first. Oxford dictionary defines it as - the knowledge or skill acquired by a period of practical experience of something, especially that gained in a particular profession.

Experience is not measured in time. Some people tend to say phrases like, "I have more than 10 years of experience in the industry" (guilty myself). In reality, it doesn't matter how much time is spent, what matters is how this time spent. People with 2 years of experience can be more knowledgable than people with 10 if they spent it doing active research, right?

Like in cooking temperature and time matters, the higher the temperature the smaller time you need to cook the thing. The more productive you spend time the less time you need to gain experience.

So my question is how to gain experience most effectively? How to spend as less as possible time and gain as much as possible experience.


Build stuff is how to gain experience. Read articles and observe the opinion of others. You will become a architect when others recognize you as one.

Sounds like a lottery - buy a ticket every day and eventually you will win.

I'm not blaming, I did it myself in the past (and maybe doing it right now), but this is not the most effective way from my POV. If I have no idea how to achieve something I would ask for advice, search mentor, try to do something else to "reset" my brain and maybe then I can come up with a plan.

Honestly, I think achieving architect status means that you've earned the right amongst your peers. Or you've earned the title by proving yourself within a job interview.

I don't think its winning the lottery. And to be honest, I don't think having the title "architect" really means anything either. I think as a developer,

  • you should be doing the best work you can do.
  • always try to achieve getting better.
  • Stay humble and realize you can always learn something new even from someone who has way less experience than you.

Let me ask you this, why is it important for you to be an architect?

I guess we get confused somewhere in the middle. My question never was about a title. I asked how to gain knowledge (or experience) in most effective way and what kind of knowledge people consider to be most valuable (in sense of giving most insight).

Build stuff my friend. That’s it. Gain the knowledge by building stuff and leading teams. See what works and what doesn’t.

Seems like you want a simple answer like, if you read book X or blog post Y, it will tell you how to be a software architect. It takes real experience in the field of software development. You cannot skip all the hard work it takes to earn the badge.


Software architects usually interact with the clients and stakeholders of a project. They - ideally - will need to be involved in figuring out exactly what kinds of requirements the client is looking for, being able to make sure the requirements are business requirements and not just "make this page have a floating top menu bar."

Total aside: Yes, I've been on a project where we literally spent hours of meetings with CEOs of two large insurance companies just to decide whether to use a floating top menu on the web site 😜. It happens...

Anyways, the architect needs to make sure that the technical direction of the project is viable/feasible give the business needs.

So there are two primary parts:

  • You need to know tech really well (system design and knowing what problems specific tech solves)
  • You need to be able to communicate well with non-technical people and convert business needs into software systems/designs that will allow the business to achieve those goals and yet allow flexibility of the system to change over time.

Knowing multiple programming languages, paradigms, etc. as mentioned in the "question" of this post are helpful because every language and paradigm solve specific and different kinds of problems.

If you have a business, for example, who needs a system that will be developed and maintained by hundreds of developers, then you need to know that there are specific patterns for building these kinds of systems (DDD, Microservices, etc.)

Imagine the need for an e-commerce site which needs to keep the data of all user interaction with the site (via products ordered, products added to cart, products removed for cart, etc.) so they can do analytics in the future (I.e. predictive analysis, etc.). Knowing that Event Sourcing can solve that problem would be applicable here.

So, a big part of being a good architect means your knowledge is broad enough that you at the very least know what technologies are available to solve which problems. And you can figure out what business problems map to which technological problems and solutions.


Much of being a software architect (and especially CTO) is the ability to slap nontechnical stakeholders (up to and including your own CEO) back to reality, in a way they they respect you for. I can give an example from my time with a startup whose CEO had ADHD (and ultimately was a cheapskate and a BS artist, which is why I'm not around to build the product), and lost a major client by flying off the rails with ideas unrelated to what we were doing.

Basically, we were trying to stir up interest from potential corporate customers in running product pilots. He got an exec from a major big box electronics retailer (yes, that one) on a pitch call by himself, after I had already told him he should get me involved to keep the discussion technologically grounded in reality (rather than the all-too-typical sales routine of making promises on which we couldn't deliver without significant additional work and eaten costs). His pitch went swimmingly, but then the exec asked him what our 5 year plan was re: market saturation, expanding into new verticals, etc. This is where he went off the aforementioned rails, throwing out ideas which had absolutely nothing to do with our current core product and no conceivable (or attractive) way to integrate them: VR, facial recognition, and other buzzwords.

When he told me, I reiterated that this was why I should have been involved. The answer was easy: Since we would already need to integrate with the APIs of customers' existing systems from other vendors, we could study their strengths and weaknesses while doing so and eventually offer competing products more tightly integrated with the core product.


Given there is more stuff you could learn than you will ever have time to, you'll need to prioritise, so I would look at the types of "hard" software problems you need to constantly deal with, because architecture is all about making decisions on hard problems.

These problems could come in the shape of:

  • data modelling
  • integration
  • deployment
  • operations
  • testing
  • balancing technical consistency versus team autonomy

Pick any/all of these and look broadly at how other people/teams/organisations are solving these problems. Try to move between technical and problem domains frequently (several each year) to build up good broad experience, to compliment your existing deep experience.

p.s Architectural skill does not necessarily imply deeper knowledge


are there specific topics in CS which will significantly improve understanding of CS in general?

Yes and no. Things that help you have a holistic view of things help, things that deepen your knowledge about something specific will just help with that topic.

I always recommend aosabook.org/en/index.html rather than some specific tech or technique although any would also help expanding your knowledge.


It's good to first know what you're asking for. A "software architect" position usually refers to the job in an enterprise setting. This clarification may be useful.

What you're describing as examples is more about people who are actively engaged with the programming community, present and past, with a very specific set of questions:

  1. Will this change in how I think improve some aspect of how I write software?
  2. Will it break some other aspect?
  3. What led the people who did this to do so?

So once you have been through this many times you look at a new library, framework, or language, and can quickly categorize most of it. Usually you can categorize all of it, in which case it's interesting only insofar as you may have to use it to get paying work done. Sometimes it remains interesting because of interactions that you haven't seen tried before (e.g., Scala trying to wed the Java type system with Hindley-Milner type systems, and experiment that I feel was a failure). Occasionally there's an interesting piece of something and you spend a few hours or a few days beating on it, trying to find what's there.

When you're just starting out, you can flail at the usual suspects and get a lot of mileage. A short list of things that I guarantee will not be a waste of your time:

  • Ullman's Elements of Standard ML. Then go look at the ML language family and read the papers of people who designed the various members and what drove them.
  • Leo Brodie's Starting Forth and Thinking Forth, then go mess with Pygmy Forth and read about what Charles Moore has done with colorForth.
  • Spend some time working with Pharo or Self, and learn what it's like not to have a separation of a system into programs, shell, etc. Then go read the literature of people who worked on these systems and find out about the problems with them.
  • Learn to write Prolog.
  • Read a bunch of Dijkstra's EWDs, especially the late ones, and get into his ideas on calculational mathematics. And read a bunch of Alan Kay's work. These two couldn't stand each other's work, and being able to switch back and forth between their perspectives is a diabolically valuable ability.

SICP is a wonderful book. If you enjoy it, go to it. Branch prediction is worth understanding. If you know probability, it should take you about half an hour to understand how it's supposed to work. There's no reason to understand it at a silicon level unless you're designing chips or fighting with truly bizarre performance problems. Likewise, Types and Programming Languages is more machinery than you probably need right now. If you find yourself building type systems or programming languages, then you will read it cover to cover and it will seem like the most wonderful, applied advice ever. If you aren't in that game, you're better off getting the basics down so you can understand how various type systems differ and what the experts mean when they argue about them, and then moving on to something else. Remember, your time is finite.


Yeah, I guess title is confusing, that is why I also wrote extended body to explain the question. I wasn't able to pick better title, like "how to gain deep insight in development" or "how to become @hillelogram". So I decided to name those people architects and explain question in the text.

I like your explanation (of my question) you got it right. And thanks for suggestions 🦄


At MIT, (the school I went to), there is a class called 6.033 Computer Systems Engineering.


It is basically a sophmore level introduction class for knowledge/skills for software architect.

  • Software Design principals in general.
  • Distributed Systems
  • Security (how to design secure systems, and tool kits available.).
  • Networks
  • Databases.

Wow! OS, Networking, DIstributed systems, Security. This indeed looks quite insightful. Thanks


Yep. If you want to have a structured course, this is one the best, there is no text book, but I believe course materials (lecture notes, recommended readings, homework and assignments) are all online.
After this class, there is classes that goes into each topic in more depth, but this is course that tells you how things fit together. Given it has a lot of topics already, so it can't cover everything. I would recommend understand database also, how database works, and differences between some key databases designs such as sql vs nosql.


Software architect is a job title, meaning if you want to become one: start acting like one!

Someone already mentioned knowing the requirements and doing business related conversations but that's part of the software architect role.

There are many other important stuff as well:

  1. An end-to-end knowledge about building/testing/deploying systems.

  2. Given point #1, you will be the focal point in your team, so you will help the others with anything that comes up.
    By anything, I do mean it literally; it could be designing the database, or could be fixing a deployment pipeline, or even showing a frontend dev how to fix a UI bug.

  3. Knowing various programming languages, programming paradigms, design patterns, software design approaches (ddd, tdd, bdd... all kind of D's), and a handful of architectural styles and patterns.

  4. Practical knowledge of distributed systems and its related parts, like: networking, service oriented architecture, and caching.

  5. Willing to learn all the above on a daily basis!

I believe CS courses won't really help as much as learning from exceptional devs, some names that come up to my mind: Martin Fowler, Uncle Bob, Greg Young, and Udi Dahan.


First, read books, blog, articles. Depends on your field, find some reviews to know which book you should read. Code Complete is definitely one you have to read first.

Knowledge without practice is the dead knowledge. Just practice everyday, apply your knowledge in your work, your hobby project,...

Practice without observing is like driving a car without knowing where to go. Observe your result, people’s results, learn from them.

Doing all those things alone is like a silo. Everyone has his/her own point of view. People talk differently about the same subject. Talking, discussing with open mindset help you to see things different ways and understand the nature of things. Do not object other views too soon, which will make you a big silo.


I once heard a quote about being a software architect (sadly I can't recall by whom):

True software architects are developers, and not just any developers, they are the best of the best. You can't become a good architect without being an outstanding developer first. You need to be present at the team, you need to be open, supportive, willing to teach others and never stop improving. That's what being a good software architect is all about.

I could not agree more.


Yeah, the question as well could be "how to become outstanding developer", it was about knowledge and deep understanding. I wasn't able to find better title at the moment of writing.


No worries. My point was only that nobody should start their career as a Software Architect. You start as developer and collect lots of experience first. How to become a good developer... have a project (reading alone will get you nowhere without practice), read all the books you can get your hands on, listen to talks on Youtube, visit conferences and meetups, share your knowledge, have a blog, and bring tons of patience.


What I'm doing are two things:

  • Reading good books. Clean Architecture & The Pragmatic Programmer, for instance.📚
  • Starting now to "study" open source code and learn good architectural practices from them. Some of the most brilliant minds are coding in public there. 💡
  • Remembering that what makes me a better software developer is by writing better code today in comparison to what I wrote yesterday. In order to be good, I don't have to be THE best. This way I keep my ego out of my learning path. :simple_smile:

Useful discussion you started, by the way, thanks. 😉



It depends on where you want to head to. Pure software architect or enterprise architect ?

Being myself an IT senior architect, I can tell that some concepts or insights can only be acquired by experience.

My advice is to not focus only on computer languages. During my MD's degree in computer science, I learned how to build a compiler, to code in Pascal or Lisp, but also Topology and Numerical Analysis. Those fields I didn't use a lot during my career.

Then at work, I studied CPU architectures, C language, IBM mainframes, Oracle & Sybase DBMSs, Linux, networks, Windows but also SOA architecture, enterprise bus, software engineering etc. Being a good architect means a lot of IT techniques to master, a vision to acquire, and fields to comprehend.

So explore and read, experiment, learn.

Hope this helps ;-)


If you see this diagram from TOGAF - pubs.opengroup.org/architecture/to...

These are the steps required to be performed while setting up Enterprise Architecture (EA). So there comes the first architect - Enterprise Architect.

An EA might not be able to perform all the steps. He takes help of Business Architect- They mostly have complete understanding of the business domain and the how the business functions.

Information Systems Architect - The level which helps in Blue printing your applications. They have two flavors here - Data Architect and Application Architect.

Technical Architect - This is where it comes to actual implementation level, where the person in an expert in the technology.

Solutions Architect - This is where, architect focuses on developing solutions using their tools and software for client problems. This is not under TOGAF.

Change Management Architect - This is where an Architect uses his Change Management skills. More details you can find here - iasaglobal.org/itabok/capability-d...

So apart from coding or knowledge in specific software an Enterprise Architect is required to have skills in all these areas.


I think if you only one Programming paradigm, that's a great place to start. I've never met a good architect who only knew one.


You mean to learn all of them? Something like this info.ucl.ac.be/~pvr/VanRoyChapter.pdf?


Actually @hillelogram kind of answers this question in this thread