Ask HN: How many YoE are enough to gradually get into software architecture?

[dondraper36]

It makes all the sense in the world that being a software/system architect is chronologically after being a decent software engineer.

The question is, however, how many years of experience are required to slowly start preparing oneself for this big jump.

Even now, with around 3 years of experience, I already feel a deep interest in system design and architecture, but it's still very frustrating.

Tell your story please. Probably, you could also share how you learned the skill, what your your first steps were

[gregjor]

I think the question comes from a mistaken premise. You assume that titles like "software architect" describe specific skills and abilities inherent to the programmer (or architect if you prefer). Actually every programmer who isn't just typing code from detailed instructions does software design or architecture. We just do it at different scales, and at some point we can do it reliably at a scale that justifies adopting the title "software architect" if we think that will mean something.

In the software industry titles mean next to nothing. Some companies have official titles tied to pay scales -- SWE II corresponds to a range of salaries, for example (a model familiar to anyone who works in government or the military). Mostly titles reflect what the manager or employer lets you get away with. Just like grade inflation in schools, some industries suffer from title inflation, so everyone at Goldman-Sachs gets the title Vice President, and every programmer at Facebook gets called an engineer. In truth the software industry does not have standard or agreed-up titles or levels of career progression. Over time you gain experience, hone your skills, expand your domain expertise, and cultivate people skills that let you cooperate, persuade, and lead.

Studies of software projects show that individual personalities and interpersonal dynamics play a large part in project success or failure -- a much larger part than memorizing what "the visitor pattern" means, or mastering any particular programming language or tool. That means skills and experience have more or less value and impact depending on the company, the team, and the project. A person may perform at senior or "architect" level in one context but not in another. In some teams and projects I clearly have more relevant and useful experience and expertise than the other team members, so the team and my manager may call me "senior" or "architect" or "analyst." In another context I may not play the same role -- I may work with people more senior and capable in that project and team context.

I have 40 years experience, still call myself a programmer, but I frequently do high-level architecture and systems design work, and system administration. I stopped caring about titles a long time ago, I focus on keeping my skills relevant and delivering value to my customers and employers.

[DevKoala]

You need to start building your own systems on the side, learn by doing. If you wait for a company to give you those responsibilities gradually, you will depend on their focus and objectives rather than your skill.

I had architect responsibility from the get go at a company I was a founder of. Then I was at a full time job for 3 years during which I was only getting small features, so I jumped to a startup to get architectural responsibilities again. Now I am beyond that level at a large public company; mixed feelings about progressing beyond architecture.

[mplewis]

You can start now. Many devops/infra people I know learned that before they learned software engineering.