How do you learn to architect software?

reddit.com/r/cscareerquestions/comments/c6t2kj/comment/esbvh5a

First of, I have to say I appreciate the time you took to write this. It's actually quite good.
Most of those points are also right for an Architect role at every kind of company.
But from what you've written, you sound like you work at a corporate giant. I'm going to
disagree with some of those points, and add others, when working in smaller companies
where the whole (technical) thing literally relies on you.

Discuss alternatives and risk of each major decision to the system as a whole.

This reeks of an endless streak of meetings - which is unavoidable in certain organizations.

Actually, I'll even agree this is a neccessury evil (that still needs to be mitigated as much as
possible) when there are multiple parts of the system that are owned by multiple people.
But when the only one above you is the CEO, and you have maybe 3-4 Junior/Mid
developers and a designer (which is often the team of medium-sized non-tech companies or
small startups) having such meetings is a huge waste of resources for very little gain (and
sometimes, even loss).
In this case, after you've thought about all the alternatives and risks yourself, you have to
gather the team and explain to them in detail your conclusions, then ask for comments.
Maybe adjust some things if anybody has good ideas, but long debates are in 99% of the
time not going to be worth the wasted time.
At best, have such a separate, longer debate with the 1-2 engineers who are actually closer
to your level before the one above (if your company could get those).

Pick your battles. You know the whole system but need to leave some decisions and design to the
team.

Yes. However, this is quite vague. To specify, the design decisions that you should take upon
yourself should always be the hardest, most complex ones.
Those you don't have time for should be given to your team members, generally in respect
to their skill level (however it's ok to give somebody a harder task as a change to prove
himself, if it's not a critical task).

Finally, one extremely important point:

You should know every part of the system you architect!
This does not just mean do some of the implementation work - this means, if you architect a
Web application, you should understand:

Design - At least basic understanding (I include CSS and other FrontEnd design here
here as well)

1/3
UI/UX - At least basic understanding

FrontEnd - At the very least know the fully capabilities of modern WebAPIs and your
chosen framework.

BackEnd (Server) - At the very least have deep understanding of your chosen
language, as well as chosen server(s) and their configurations. Oh, this includes
knowladge about various HTTP headers and their effects, too.
And about how to properly prepare the code for the infrastructure - be that VMs or
containers.
Oh, and this isn't nearly all on this end. You have to know understand all the potential
threats (SQL injections, XSS, XSRF,Timing Attacks, DOS Attacks, and much more), and
ensure proper protection against them at ALL the weak points - not a single user input
should be parsed before validation, not a single text should be stored in the DB before
it's confirmed to not contain valid SQL (or some rare charset fuckery, or a few other
things), and much much more. Oh, and of course, for every dependency you add you
must be check (or have somebody who can understand it to check) for CVEs.
If this wasn't enough, you obviously need to know how to properly structure the code
itself, at least the modules. You'll probably be the one writing the high level specs for
most of them, too.

BackEnd (DB) - You cannot build any modern application that I can think of from the
top of my head, without a DB. Chosing a DB, or sometimes even multiple DBs, will
largely very by your system requirements and other context.
For example, one might be tempted to use Postgres over MariaDB, due to its many
amazing features, until he realizes all the problems Postgres has when scaled high
enough (why not just implement proper index clustering? Here is a good explanation
why Uber ditched them).
And of course, I hope you do understand various basic things like types of indexes,
how they are actually stored (BTrees/Hashes/Etc), Partitioning, Clustering, Master-
Slave / Master-Master relationships, Functions/Procedures/Triggers, and much much
more. Cause many choices here rely directly on the requirements of the system, will
affect future salability, and might cost from tens to hundreds of thousands to fix
retroactively.

Infrastructure - You have to understand various things about VMs, Containers,

Monitoring, Automatic Health Checks / Recovery, how new nodes are created and
destroyed (this affects many parts of your server code), and other things that I'm a bit
too tired to write.

Business Needs - You need to fully understand the business needs, because ultimately
all this complex system you are creating only exists to serve those needs, as efficiently
as possible. You'll not only need to define the requirements, but also stay up-to-date
2/3
 with changes and update them on the fly.

And of course, most people in my life that I've seen and are the lone lead dev / Architect /
CTO of a small/medium company just focus on a few of those areas and neglect the others.
Which creates the following problems:

They have to make decisions about things they don't understand. While you will
probably learn all of the above from your own mistakes (if you do learn from
mistakes), but if you don't know enough of it at the start, the accumulated damage of
those mistakes will sink most companies way before you ran out of avoidable
mistakes to make.

They have to leave decisions to people who maybe understand those things good
enough, but neither see the whole picture, nor have a similar interest in the
company's success.

Those above 2 problems are also why so many Startups fail, and why so many companies
manage to have 1 month of progress in a year (if you don't count refactoring and bug fixing
pre-release as progress).

3/3