How to Turn Into a Software Architect

In the early days of software, people turned into architects based on the number of years they spent in a company.

Now, this could be somewhat justified for product companies, where you have better insights into a product’s architecture after a few years. Surprisingly, agencies with shifting projects also followed this strategy. The reason? They could sell their billing time for higher rates. The clients would pay for an architect, but what they would (hopefully) get is a senior software engineer.

This was (and still is) quite disgusting. One simply doesn’t wake up as an architect after 5 years of software development. A programmer also doesn’t turn into one having worked in programming for (now debunked) 10000 hours, or the infamous 996 work culture (9 AM-9 PM, 6 days a week) of China.

One needs an approach to turn into an architect. That approach involves psychological metamorphosis.

Let’s start with the caterpillar.

The Caterpillar Story:

The most popular version goes like this: The caterpillar one day decides to turn itself into a butterfly. It begins with a hungry state.

Its DNA denies the direct conversion though. Unhappy at this outright denial (yet adamant on its goal), it abandons all food and wraps itself into leaves.

Despite no food intake, it starts becoming plumper (round shape). Then, it forms a cocoon. What happens then, though, is the most interesting part: It starts eating itself. It destroys some of its cells, to create the protein-rich enzyme soup. The cells that remain after form something called imaginal discs.

The set of proteins in the soup helps the discs multiply themselves via cell division. It gives birth to wings, antennae, legs, eyes, and other parts of the body.

In the story that I heard as a child, while this state is on, the caterpillar continually thinks about what it is about to become: a butterfly.

When this cell division completes, we get a full-fledged butterfly.

If you break the cocoon during the process, you will get the hotchpotch of soup and some discs. It obviously failed to transform into a butterfly due to your merciless disturbance.

That’s how one turns into a software architect: follow the caterpillar, step by step.

How to turn into a Software Architect:

A programmer must go through the same stages as the caterpillar to turn into an architect. Here they go.

#1: Be Hungry, Destroy Yourself

“A First Sign of the Beginning of Understanding is the Wish to Die.” ― Franz Kafka (Author, Metamorphosis)

As a programmer, you must start with destroying your old self, but only partly, just like a caterpillar does. You must combine this wish to die with infinite hunger for knowledge.

You must break the habit of thinking about: “How this code will look like?” That’s what a software engineer in you tries to do. You need to break free from that habit.

Instead, you must start thinking about: “How this code (or its result) will look to its user, who will mostly have its interface, not the implementation detail. Even if she has it, she wouldn’t want to delve into it. Even if she does, I don’t want it that way.”

You must partially kill the programmer in you, to begin with. An architect must be able to know how she would lift 1000kg weight, without lifting it herself, or mistakenly using a misfit forklift.

Caterpillar destroyed the cells to create the enzyme soup. It only retained cells that would be required to create the form of the butterfly.

That’s another lesson: Lose some things, but not everything. Forget about the code patterns of the most popular algorithms and data structures. You can get them with a few clicks. But do not forget their complexity (the Big O notation).

Create/download the most efficient algorithms, package them into libraries, then just remember those libraries.

Forget about the design pattern names, but remember the broad types of abstractions they provide. Things like below worry an architect every day, and it’s the worry he keeps closest to his heart:

• What separates the patterns from each other
• Why they all were needed in the first place?
• Today, why the industry is hell-bent on dumping them to adopt a functional paradigm?

This forgetting and remembering only key things is the essence of late binding. Just like machines, it benefits humans, too.

#2: The internal metamorphosis:

“I am a cage, in search of a bird.” ― Franz Kafka (Author, Metamorphosis)

In the caterpillar story I heard, they say it constantly thinks about turning into a butterfly.

Likewise, a programmer must keep thinking about turning into an architect. Now, this is not as simplistic as it sounds.

Many programmers start with some or other certification from a proprietory tech provider. Example: Just search for any public cloud, Salesforce, CRM certifications, and you will get dime a dozen programmers holding them. Many times, the certification holders do not even have any computer science education or even programming experience. Yet, they get hired. The reason behind this is big companies who buy per-user licenses for a technology. The non-programmers simply enjoy being on the right (pun intended) side of the rising demand vs short supply equation.

In reality, they aren’t butterflies. They are hiding under the “architect” labels, but aren’t real architects. They have never gone through the painful phase of transformation, nor do they know what it feels like to be a non-flying, ugly caterpillar. Still, until a huge industry shakeup happens, their careers are quite safe.

I am not saying having a certification makes you a bad programmer. What I am saying is that if it is a certification that started your architect role journey, let it remain a start, not an end in itself.

A programmer trying to mold herself into an architect must go through this (often painful) thought process.

• Are all our classes and modules decoupled enough?
• Are they abstracted in the right manner to serve our business objective?
• Are we able to add or modify any component without disrupting the rest of the machinery?

If the answer to any of these questions is No, a programmer thinks and rethinks. She weaves the cocoon of knowledge.

She reads books. She studies the fundamentals that form architects daily life:

• Meeting customer objectives in the most flexible way
• Security
• Performance
• Optimization

If any of the existing practices are not in line, a programmer is courageous enough (at least in thinking) to destroy the entire setup via refactoring and redefining pipelines.

When this solo brainstorming ends, the metamorphosis of a programmer is complete.

It is time to break the shell.

#3: Breaking the shell:

“Paths are made by walking” ― Franz Kafka (Author, Metamorphosis)

Breaking the shell doesn’t require much thinking. It requires courage to pursue and execute what’s thought out in the metamorphosis phase.

The how of breaking the shell requires some people skills, though. Organizations are steadfast. Architects mostly face a combination of two challenges:

• Adamant upper management above them
• Incompetent/incoherent programmers below them

To once again validate Murphy’s law: They are mostly co-existing. That’s what defeats most architects.

An architect’s job, then, is to:

• Assert her authority to the upper management: This must be done by virtue (“I am only advocating universal principles of great software that has value for our company. Give me/tech lead the resources + time, we will deliver these results.”)
• Provide support and means to continually learn to the developer team: This is often harder than even convincing the upper management. The junior team often doesn’t realize the luxury of inexperience + time + resources for experimentation. Like a butterfly, an architect must brandish her wings and beauty, showing to the newbie programmers what they could gain (freedom and authority) by learning under someone who was just like them a few years ago but has successfully transformed now. For most newbie programmers, there is no better incentive than a successful mentor.

There are very few architects in this world who could pull through this last crucial step. However, they have been amply rewarded: CXOs of many big tech companies (Microsoft, Google, Amazon, and many more — I do not want to idolize any single one) were architects once, and helped deliver their most flagship products under their supervision.

Conclusion:

Architects don’t exist. They become.

If you do not respect yourself as a programmer, do not even think about becoming an architect.

Your metamorphosis could be different from that of a caterpillar, but metamorphosis is necessary.

Being an architect is a necessary step towards technical leadership. It provides the best of both worlds: Living with technology and driving a company’s future.

Whether you pursue it to the apex is your choice. Even if you stop at the architect’s role, you could still enjoy being with tech your whole working life.

The pain? Maybe it’s worth it. After all, you only live once.

• If you want to be emailed any time Pen Magnet publishes, please click here.
• If you are not a Medium member yet and want to become one, click here. (A part of your subscription fee might be paid to Pen Magnet.)