The architect mindset.My example of how to embrace a technical challenge

From newbie to experienced .NET developer and all the way to .NET Architect, this is my 14-year long career at Levi9. In some cases, I’m even called an expert. These are big words; I know, but I see myself more as a person who has a huge curiosity for understanding how things work and how I can use them to craft solutions.

Slowly but surely, I have turned my knowledge and experience into the mindset that defines me today, that helps me come up with answers, and fuels my professional growth. Technical challenges feed a developer’s mind. Let me share with you how I learned to deal with the pressure of finding a solution that could change the entire course of your project.

By the way, I’m Ionut and in this article, I summed up my path of growing and excelling as a .Net Architect at Levi9. Take the best out of my examples of how my teammates and I succeeded in overcoming a technical challenge under strict deadlines.

At the beginning of my career, I focused all my efforts into mastering the platform I was coding against, .NET. Later, I was intrigued by other platforms which could help me as a .NET developer.

After a couple of years, I started to realize that programming languages are just simple tools. More meaningful and useful for my career was the understanding of abstract technical concepts. No matter if we are talking about a simple concept, like a design pattern or the reason why we have value type or reference type, to some of the heavy ones, like how web servers function or how the internet works nowadays.

Understanding and relying more on concepts and techniques enabled me to adapt faster to such a dynamic and agile domain like software development. Besides that, I learned to never overlook or overpass a line of code, a concept, or a pattern I do not understand at first. We have to question everything, to understand how it functions and impacts the overall project.

Small hint: if I do not have time to do this on spot, I will make a note of it and revisit it later. This is one of the most helpful tricks I discovered along the way.

In the last 2 years, we entered the growth and expansion phase of the project. Our platform got stable. The lockdown and the new world created by the pandemic times put a lot of stress on e-commerce websites, including ours.

And here is the jackpot! All the hard work from the past years paid off, and we were able to sustain the huge traffic. If the previous phase was all about experimenting and learning, this one was all about being faster and stable at the same time. Everything we build now reaches millions of users, so it must be agile and robust.

I had my fair share of technical challenges. Such as the ones described above, which required the knowledge and efforts of each member of our team. Another one I can recall was pretty recent, and I had fun designing it.

Our product managers asked us to transform a PDF into a flipbook catalog. Seems easy but the challenge came from the fact that we had a short period of time to deliver it; without involving specialized developers or spending too much money on customization, since we weren’t sure about its business outcome.

So, the main idea was to reuse, integrate, and aggregate the already existing infrastructure into the project so that we can keep the costs low and respect the tight deadline.

We broke the problem into exact steps:

Once we had all those steps defined, we started to look for ways to obtain them based on what we have already. For transforming the PDF into a website, the bespoke option was out of the question since the time to market would have been a deal-breaker.

So why not find a partner that can do it for us? If you Google it, you can see that there are plenty of options. Based on our needs, we pick one provider, and the first checkmark was ticked. We got ourselves a nice html5 website based on a PDF and a credit card.

Our internal services are mainly running in Docker, in a Mesos/Marathon platform setup. Although the setup is stable and scalable for most of the daily needs, it wasn’t the best option for this task. We still had to provide the right monitoring, alerting, scalability.

We looked further, and we agreed that we need to go serverless. Our final pick was serving the static website from Cloudflare workers. Mainly because the setup for Cloudflare was easier to adjust for receiving live traffic on a specific custom URL.

The only problem we still had was to fix is the CI/CD pipeline. And here we had our first doubt that we will make it in time.

Since the current CI/CD pipeline was all about Jenkins, Docker images, and custom Python scripts, adjusting it would cause big trouble for our development budget and time to market. We started looking at a different way of doing it and our salvation came in the format of GitHub Actions and the Cloudflare Wrangler CLI tool. So, with just a commit we were able to trigger an entire deployment.

With minimum development effort, without impacting the regular business development funnel, we delivered a fully-functional feature. One that the customer can experiment with, and decide what are the next steps.

Technical challenges like these have kept my developer’s spirit alive over the years. They have shaped my career path in a way I couldn’t have planned better myself.

I’m well aware that my knowledge and decisions impact businesses worldwide. It can be pretty frightening sometimes. But when I see the consequences of my actions in real-time, resulting in the success of our customers, it gives me the courage to keep exploring and experimenting.