Tomasz Zielichowski

I returned to the EV charging network business. This time to a company with a very strong market position and high-quality hardware.
Because of my experience, I joined the roaming team. The domain is very familiar to me, so I didn’t need much time to adapt. However, it’s fascinating to see how, in theory, the same requirements, can be implemented by other people in a completely different way.

We are constantly evolving our solution by integrating with new partners and expanding the network of available charging points.

From a technical point of view, we are working with technologies:
– Kotlin
– Spring boot
– AWS
– Postgres
– Redis
– Grafana

I joined the company as a freelancer for a 6-month contract. It was eventually extended for an additional 1.5 months.

During this time I was developing microservices architecture handling 20 million concurrent users in peak. That required high-scalable, multi-level of caching of content through database, in-memory cache and CDN. Also, my cooperation took place during the World Cup in Qatar. I had the opportunity to develop a solution that presents live match results. What a treat for a football fan.

The technologies used were mainly:
Kotlin, spring-boot, Redis, RestApi, Postgres, Kubernetes, Aws, Datadog.

I joined the young startup, which at the time had about 10 people. This was my first meeting with the domain of charging network for electric vehicles.

I was delegated to an area called roaming with a mission to implement OCPI standard.. As I was a one-man team, you could say that I juggled many roles there: software engineer, architect, team leader, PO… It was a very intense period.

From a software architecture perspective, I had to consider many factors:
– Functional requirements. The main one was compatibility of the implementation with the OCPI standard
– Quality Attributes.
– Scalability of the solution was an important aspect, as the traffic handled by the service was expected to grow exponentially over time.
– Extensibility and maintainability played a very important role. At first phase, Monta was to focus on the role of the so-called emsp (emobility service provider), but very soon the solution was to support the role of CPO (charge point operator). In addition, the OCPI standard exists in many versions and our long-term goal was to support each of the market leading version

– Business Constraints. The time to go live was quite short. We assumed that within 6 months the solution should be production ready and handling the first charging sessions.

– Architectural Patterns and Styles. I had to weigh all the pros and cons and decide whether a layered application architecture or perhaps a so-called hexagonal architecture was better suited for the solution. In the end, I decided on the one hand to bind the domain logic to the underlying entity, and on the other hand to make strong use of interfaces to abstract the external world and use modularization on package level. Considering all the circumstances at the time, I think it was a wise compromise which ensured rapid development, as well as the ability to easily split into microservices in the future.

– Technology Stack. After considering all the requirements, I decided to use proven solutions, while still using modern technologies: -Micronaut, Postgres), Grafana, Redis, AWS, Kotlin, Docker, K8S.

As a software developer, I had to take care of the implementation of the solution. I paid a lot of attention to testing, both unit and integration. Eventually, in order to integrate with external systems called Hubs, I had to go through a certification process. It went through it successfully, and thanks to it I was sure that the solution met all the requirements.

As a (semi) product owner, I had to plan my work and schedule to fit into a certain time frame. I was responsible for meetings at the technical level, but also attended those of a more business-like nature, where I presented Monta’s capabilities as a charging station management platform.

I certainly had a great time. The job required critical thinking, problem-solving skills and making snap decisions. After about half a year, the solution I prepared reached production stage and the first charging sessions using roaming were successful. That was a great part, where I could actually see the fruit of my individual work.

Although I really enjoyed facing the challenges and fast pace, I left the company after my one-year contract expired. It was due to a very unfair treatment regarding financial issues.

In Visa I had the opportunity to expand my knowledge of the payment domain. This time it concerned the processing of card payments using payment terminals installed directly in the so-called POS. I learned what PCI DSS is and what obligations it implies.
In addition, I had the opportunity to work with a number of teams, thanks to which I expanded my knowledge of programming for Android devices, although my main focus was still the backend.
Although here we had a separate IT-OPS team, there was still a very strong emphasis on autonomy and full responsibility of the team producing the code.

The technology stack was very similar to that of the previous company, meaning there was room for Java, Spring-boot, AWS, terraform, CosmosDB, PostgreSQL, Grafans. Some microservices or parts of them were written in Kotlin, and this was the first time I had the opportunity to work in this language.

I continued to share knowledge and best practices, so, among other things, I prepared a short document with an explanation of why it makes sense to implement the hexagonal architecture approach instead of layered architecture in certain areas.

I joined a newly established startup. Our task was to build a highly scalable payment gateway completely from scratch. This was the first time I encountered an approach in which the team working on the solution was fully responsible for it. Writing the code, implementation, monitoring and maintenance – all this was handled by us as a team. We placed a very strong emphasis on full automation. Deployment and release to the production environment took place with complete omission of manual steps. We did not have a dedicated team of testers/QA .I would say it was quite modern software delivery approach.

At that time, our stack was very cutting-edge. We were using AWS cloud, (we migrated to Azure over time), infrastructure as a code approach using terraform, true continuous delivery, docker, kubernetes and a whole lot of latest infrastructure related features. Of course, the solution was based on microservices architecture and there was a REST Api among others buzzwords.

Unfortunately, it began to show that the team had split views. I tried to put a slightly different perspective on our solution by proposing an approach based on Domain Driven Design and hexagonal architecture. I also saw potential for event sourcing in certain areas of our payment gateway. My colleague and I organized an event storming session. However, we failed to convince the rest of the team. With hindsight, I believe it was due to our poor soft skills. It was a valuable lesson for me from which I draw important conclusions.

Eventually, I decided to leave the company. We were in a period of some financial instability, and also the atmosphere in the team had fallen badly. At the same time I was approached by an old friend offering to join his current employer Visa. The stability of the company, practically doubled earnings and an old colleague, sealed the decision to quit.

After the adventure with a corporation, I decided to join a newly established oursourcing company. Its rapid expansion in the Polish market resulted in opening offices in every major city in the country, and so I became the first Java developer in the Poznan office.
The first project was related to a platform for managing insurance products. I had the opportunity to get to know the industry a little closer and for the first time seriously work with a “classic” business application written in Java. Consequently, there was no way to miss spring-boot, Hibernate, SQL database ( MySql), Docker, etc..
Another project, although it dealt with different domain, was based on the same technology stack. In the third project I was able to familiarize myself with Scala and learn more of functional programming.

Over time, the company ran into trouble at the senior management level, so I took the opportunity and decided to take on the next challenge in my career.

I started this job full of hope and enthusiasm. This was my first encounter with a corporation. A big plus was the opportunity to work in an international environment, to learn all the processes, the way decisions are made, the management hierarchy, the corporate bureaucracy in general.

My responsibilities included the development of a Java application based on the Adobe AEM platform. After a few months, I realized that this was not the area in which I wanted to grow, and each successive month would compound my dissatisfaction. I made a quick decision to change jobs.

It was my first serious job right after college. I will always remember it fondly.
I started as a C/C++ programmer working on a map rendering software, using mapnik, boost and others c++ libraries. Over time, I began to work in the Java area, focusing on route planning algorithms. I became deeply familiar with the Dijkstra, A*, Arc Flags, Contraction Hierarchies, Transit Node Routing algorithms. Furthermore, I had a chance to implement our own quadtree or cache. Working here I gained a more practical understanding of how algorithms and data structures work internally.

I am still amazed at how great things we were implementing! Every day at work brought a new challenge.

The excellent working atmosphere will always remain in my memory. The team consisted mostly of young people in their early 30s, who were happy to spend time with each other even after working hours.

In retrospect, I conclude that I left the company far too early, attracted by the vision of a great career in a multinational corporation..