Technical architects should write code more often

Jul 1, 2023

When I got promoted to Associate Frontend Architect, I was given few goals.

  1. Help with the foundation of the new product.
  2. Build a component library that will be used across all of our products.
  3. Make the current product better.

1 and 2 were refreshing challenges, setting up the right practices, and building the right way (there is no one right way).

So that's exactly what I did. After working together with the team to set up the base, everything was handed over to the team and I moved on to other tasks. Few of the things covered in the initial process were,

  1. Spent time to understand how to build quality components.
  2. How to structure the project/code in a scalable way.
  3. What libraries to use, keeping long term in mind.
  4. Rigorous PR review to make sure we stick to the patterns.

Everything turned out well, or at least that's what I thought.


After few months, I had to do minimal changes to the code, and I realized, there are some drawbacks to the laid-out approach in certain areas. To be fair, this looked good on paper and in the PR review, but when I had to work on it, few approaches were limited, error-prone, and complex.

That gave me a new realization. Even though some implementations look good from a theoretical point of view or on small scale, as the app grows, these could create bottlenecks. It does not matter how strict the PR reviews are, certain things will be overlooked.

I decided to implement features in the app now and then. Considering I have to contribute to multiple applications, I should make sure my tasks,

  1. Does not create bottlenecks in the delivery process.
  2. Have enough time to implement. This will ensure that I don't fall behind even if my attention is moved to some other project for a while.
  3. Complex enough to work with different modules.

The above measures helped me to stay updated with the codebase, improve the PR reviews, and improve the system, constantly.