Hey, I'm Cristian Cună

NetRom Software Academy

In my 2nd year of faculty I found out about Netrom's Software Academy. The purpose of the academy was to introduce people with zero professional experience to the most popular technologies. For an aspiring developer like me, this was a gold mine. I applied and passed the admission exam that was meant to select 15-20 people from the 200+ applicants (I found out years later while working there that I had the 2nd highest score from that year).

During the academy I got the chance to see what developing apps in .Net, Java, php or Javascript meant and spend a whole day (shadow day) alongside a developer while she was doing her usual work. From the technologies presented I've started to really grow into .Net. The fact that I got to stay alongside a developer using this technology during the shadow day cemented my decision to become a .Net developer. At this point, the academy participation met its goal, I've got a technology that "clicked" for me.

About 1 week after the academy ended, I got an email from the company's CTO mentioning that I've shown potential and offered an opportunity to collaborate with the company to improve my skills.

The opportunity consisted first in me munching as many .Net skills as possible in 1 month (the one including the Christmas holidays and New Year's Eve 🎄). Then, I was going to take a test, and based on it the company would create a plan to improve my skills.

One month of binge-watching tutorials and building tiny apps later, I've taken the test. It consisted of 2 days at the company's office where I had to build a small app, answer technical questions, and solve various challenges. If you're wondering what kind of challenges, let's say that one of the best ways to judge how someone debugs code is to make him look the other way, break his code and then watch him as he's working on fixing it 😄.

When the test concluded I found out that I landed a software developer job 😅. As expected I agreed to join the company (both, professional experience & a salary were veeery welcomed by the 20 years old me).

NetRom

For the first 3 months, I worked on some short-term projects within the company as a trial period. After the 3 months have passed I joined the project which I was going to work on for nearly 4 years. This project was a web application to manage private pension contracts with some background routines in a windows service. I've started working on this project as a solo developer but over time the team size varied between 2-3 developers.

The nearly 4 years that I've worked on this project saw me evolve from a junior developer to a team leader.

Libra Internet Bank

After 4 years of working on the same project, I felt I need to switch the project to continue to improve so I made a job change and joined Libra Internet Bank.

At Libra, I designed and kickstarted the migration from a SQL-based architecture with all the logic in stored procedures to a microservices-based architecture. As a fun fact, the company had so many stored procedures that expanding their folder without applying a filter was crashing my pc to the point I had to turn it off and on again.

During this period I've begun playing with various Javascript SPA frameworks in my spare time. I've gone from building apps in Angular to passing the interview process from www.toptal.com by building a Vue.js app to finally settling on React. Being highly unopinionated I felt that React was giving me more freedom in terms of architecture and design. I started to like frontend development more and more so I've decided to make a job change that would allow me to focus on React.

Digitall (ex Bulpros Consulting)

Being determined to build frontend apps, once again, I've made a job change and joined Digitall in the summer of 2020 as a frontend developer. In terms of "seniority", even though I had no professional experience using React, my overall experience and the job & client interviews qualified me as a "senior developer".

I was assigned to a project composed of a Team Lead and 2 other junior developers with about 1-2 years of frontend experience. My responsibilities in this project were to take technical decisions about the architecture together with the team lead, help with the development itself, and coach & help the junior developers. So yeah, I had to help people with more professional experience than me 😅 (if you ever felt the impostor syndrome, well, this is it on steroids).

This impostor syndrome feeling made me learn and grow at an incredible speed because I wanted to always be able to help someone when that someone reached out to me. On a more general note, this is one more example of the benefits of the right amount of stress.

Things turned out great and in a few months, I've taken full responsibility for leading the development while the team lead was getting dragged into other projects.

After about 1 year at Digitall I had an opportunity to join Tokero, one of the largest cryptocurrency exchanges from Romania that was based in my city. Tokero finished an investment round and was looking to build a development team whose immediate goal was to rewrite the existing application, an MVP, because it could no longer handle the increasing number of customers. Previously, the developer team consisted of only 1 man, one of the co-founders.

Tokero Crypto Exchange

I joined the Tokero team in the earliest stages of the rewrite and participated in all the technical decisions. The currently live app was running on ASP.Net MVC and after some discussions, we've decided to go for a SPA frontend and a backend API. As the current application was already using ASP.NET it was the natural choice to go for .NET Core. For the frontend app, we've moved forward with React (the most popular SPA framework at that time) and upgraded very soon to Next.js because we needed server-side rendering.

Like Digitall, I've joined the team as a senior developer and over time grew into a team lead & architect. The team size fluctuated, but the average size was about 6 developers and 2 QAs.

One thing I especially enjoyed here is that being a startup company with its own product I had the chance to be involved in many areas like marketing and accounting — the company was offering financial services after all —, besides the development itself.

As the time passed, I've come to appreciate Javascript frameworks and Typescript more and more. At the same time, writing C# code started to seem burdensome because it was too lengthy and stiff. This eventually led me to desire to switch completely from a .Net to a Typescript-only backend.

Although we had a sizable number of nodejs api endpoints at Tokero, the majority of the backend was still in .Net. From a number of perspectives, it was not practical to rewrite the .Net backend in nodejs, thus I've started looking for new opportunities.

Arnia

One such chance came from the outsourcing firm Arnia. As they were rapidly scaling up, one of their clients was looking to add several full-stack Javascript developers to their team. I was one of the new developers who joined the company, and this was a fantastic match. The engineering crew was large, consisting of many squads totaling between 70 and 80 persons. I've joined the team that was mostly in charge of managing things like roles, permissions, and accounts.

One of the things that stood out for me here was the onboarding process. After going through a few docs about the way of working and high-level structure of the application I was assigned a larger task which I had to pair-program together with another teammate. Initially this seemed like a daunting task because not only it was touching multiple components but this was also the first time I was going to do pair-programming at this level — until this point, I've only pair-programmed when another developer was blocked and needed help. Oh, and have I mentioned that this task was also our sprint goal? No pressure! 😅

This pair programming session turned out to be a brilliant idea a week later. I rapidly gained a good grasp of the codebase, got to know my teammate better, and developed a solid understanding of the team's working style and culture. Even though I initially felt like I was going very slowly, we were able to finish the task a few days earlier than anticipated. In retrospect, if there is time, I would suggest that any team onboarding a new team member follow this approach.

Time went on and I was enjoying the project more and more. Having a such large development team the code, even if largely consistent, was built with multiple different perspectives in mind. It was a real pleasure checking how things are done and afterwards comparing with how I would have done them — needless to say, I learned a lot.

Unfortunately, after about three weeks, I learned that the client had scaled back the project because of the state of the world economy, and I would be leaving the project along with several other people in a month. I can understand the choice given that, among the Arnia developers who were a part of the client's team, I was the one who had joined the group most recently. In the end, even though I was only a temporary member of the team, I am thankful for the chance and pleased that I was able to pick up a lot of knowledge quickly.

Arnia - Part 2

In the last days of my first project at Arnia, an HR representative approached me and inquired about my interest in taking on a new project. I was informed that the project was intended for a potential client who gotten in touch with Arnia and a few other outsourcing firms searching for a new full-stack engineer to join their team. Following the completion of a home assignment and the technical interview, the customer decided to move forward with Arnia, and I was given the opportunity to join their team.

The project was a B2B web application that served as a BMS (Brand Management System) solution for the client's customers. This web application was used to manage things like the items and the organizations involved in the manufacturing of the products. The client's domain was counterfeit protection.

Work on changing the application from a monolithic design to a microservices one had already begun when I joined the team. Because the monolith app was rather large, the team chose to rewrite it one module at a time to avoid having to wait too long to add new features. In terms of technology, .Net Core was used to build the monolith, and NestJS and React were used to build the microservices. A few modules had already been moved over to the microservices architecture by the team, but much more work needed to be done before the app could be made available for public release.

I can't say that I'm a fan of microservices architectures in general because they're usually just a pretext for making an application more complex than it needs to be. But in this instance, it really was a fix for a genuine issue. Even though they all started from the same codebase, the client developed and deployed distinct instances of the application for each of their clients, each of which was extensively tailored to the client's requirements. As new features were introduced and bugs were resolved, the monolithic app got harder and harder to maintain because it had to be updated across all instances. This issue was resolved by the microservices architecture, which allowed for module customizations that were restricted to the specific module in question and had no impact on the remainder of the app.

Implementing a new products module, which would be launched shortly after the first version was completed, was my first task. This was a fantastic chance to familiarize myself with the team's workflow and the codebase. Additionally, I was able to have a solid understanding of the domain and the client's customer's usage of the application.

I began working on all the other application modules as soon as I finished the new products module, adding functionality that were lacking and resolving problems. During this process, I also used the chance to make several major architectural enhancements. The React microfrontends were laborious and prone to errors when they were first developed since they used Javascript. After some discussions, I manged to persuade the team to switch the microfrontends over to Typescript. In addition, I made some enhancements to Webpack and the module federation configuration overall, which resulted in the microfrontends bundle size being reduced from well over 2 MB to only a few hundred KB.

The emphasis on stress testing the apps to ensure that they provide a positive user experience even when there are a lot of data was one aspect of this project that really caught my attention. The monolithic application took a long time to process the massive amount of data, and there were customers who already had millions of records in their database. Therefore, every single module in the microservices architecture has to be stress tested with millions of records in order to avoid such problems.

The care the team was giving to the documentation also caught my interest, as each module and feature had to have comprehensive documentation before they could be deemed complete. I had a great opportunity to hone my technical writing abilities and get a lot of knowledge about how to write quality documentation because of this.

As of this writing, after almost a year of development, an initial version utilizing multiple microservices is just a few weeks away. The performance and maintainability of the application in production is incredibly exciting me, and I'm interested to see how it develops further.

Looking forward

I'm the kind of guy that always appreciates picking up new skills and has a strong interest in the Javascript community. I'm constantly looking for new opportunities to develop my skills and making an effort to do so. So, yes, this is my journey thus far. Who knows what the future will bring?