Alex J. Leppäkoski

My Values

Value Driven Thinking

Goals and the value that they imply should be measured, this can be quantitative or qualitative data. With data-driven and measurable goals we know what has to be done in order to get where we want to be, instead of guessing and walking in the dark.

Both the problem and the solution have to be defined before taking action, and only then refining. Refining is best to start with the exploration of things where much can be done little.

Agility

Build what is actually needed, not what it was envisioned to be.

The development starts with an MVP, this helps us to explore what was wrong, missing or actually not needed within minimal effort. From there we keep iterating, during which we collect feedback. The flow works as the compass and helps us readjust our direction towards the actual end product. This way we do not base the whole development process on guesswork where we might have to scrap most of the work done just to reiterate again.

Automation

Kill the monkey. Monkey work is the repetitive, tedious and error-prone manual work that could be used in more fulfilling and innovative ways. Automating these wasteful points reallocates resources into what actually requires human attention, and allows people to take on real challenges.

Use the Right Tool

When it comes to software architecture, I aim to build the right solutions for the right problems, nothing more nothing less. This can be from a simple static website to global, scalable and highly available services.

Taking shortcuts gives you an unreadable, unmaintainable, base for further development and your developers end up playing Jenga with often the most crucial part of the business.

Own Your Mistakes

Ownership is crucial for growth, we have success, and we also have failures, we are human. From mistakes, we grow and take action. Acknowledging shortcomings is helpful to the business and the team, it allows reflection. Owning your mistakes helps you work on them in order to deliver a reliable service.

Clean Code

Aiming to write code that follows basic principles, taking understandable approaches and making them as simple as it can be while still delivering the result.

This means that the building blocks of the solutions are predictable, understandable and allows development on a well-established base, even when teams change.

Skillset

Frontend

I have been working with great designers along the years, and they have inspired me to deliver accessible and good-looking layouts, perfect to the pixel. It still surprises me that this has helped me to develop an eye for design where I notice misalignments or slight changes in designs where before I wouldn’t have noticed them.

I use React as my go-to frontend solution when there is a need to have a control on the state of the UI which is changing reactively and otherwise would lead to a mess of events and snippets. On not so demanding frontends I have used jQuery to assist the user experience to take care of the things that pure HTML and CSS are not able to accommodate.

Backend

I have years of focus on the backend systems. I am most used to the MVC (Model-View-Controller) approach, and I use services and middlewares to abstract away the boilerplate so that the gist of what the code does is understandable with a glance. Within the OOP style I practice dependency injection patterns and aim to keep the layers of inheritance down in order to avoid unnecessary complexity.

I advocate microservice architecture when possible, but with smaller teams it is often reality to start with a monolithic solution, but keeping modularity in mind. In order to decouple the code, I use message queues and in-memory data structure stores.

CI / CD

In order to make the development process as smooth as possible, I aim to build an automated process as soon as possible in order to make a continuous and reliable way to deliver. This is automatically testing the business crucial parts of the application with integration and unit tests, using static analysis, taking advantage of the latest AI powered review capabilities, building processes, containerization, and automatically deploying the solution. The development process is a pipeline, where the things that absolutely need to be done by humans are, and everything else is automated.

Infrastructure

Why I think a solid hand in infrastructure is important is because once your business grows you are going to hit the ceiling at some point. You want to provide reliable service regardless of how many people are using it at the same time, so you have to switch your way of thinking. This is why I have been practising cloud related services for some years now.

Let’s say that instead of that one server you have three identical ones. Now in theory you could serve three times more requests, but they are all still going to the original server so you set up a load balancer. But during the peak time you’d actually like to have 10 times the servers and during low traffic, because running servers cost money, you’d be just fine with two. This is where autoscaling comes in.

With this kind of thinking I am able to deliver highly available services, which are durable against traffic spikes, local disasters and power cuts. It just depends on where the audience is located, what kind of service it is, and what regions should be covered.

I have been using Kubernetes to create and manage clusters, and it helped me to see applications as building blocks that can be duplicated, servers as nodes in a network, it has helped me to think with concepts of statefulness and statelessness, and to ensure zero downtime for end-users during updates to mention a few.

Ultimately configuring your own kubernetes cluster is something that companies do not always have the time for, which is why I think cloud providers like AWS are very useful and it keeps a lot of the difficulty and responsibilities abstracted away. It also allows us to build services globally with relative ease compared to setting things up by hand.