Our team uses five programming languages at once: PHP, Go, Typescript, Java and Kotlin. When I first heard about this at an interview, I thought it was impossible to work like that – everything is too different. But after a year my opinion changed dramatically, and I found many advantages in this approach.

In this article I will tell you:

  • how we live with such a variety of technologies;
  • how we plan to work on diverse tasks;
  • how we grow our expertise in a fullstack team and expand our direction.

Why fullstack?

We often hear about fullstack – it’s a well-established concept, even a hackneyed one. It implies that one person can cut both the back-end and the front-end – all in one bottle.

  • DataMatrix is ​​a product labeling system. The marking contains information about who produced this product, who imported it into the country, when it went on sale. This helps to understand how much legal thing lies in front of us.
  • The Express system is installed at every point of issue of orders and in all transit warehouses. It is written entirely from scratch. At the moment, the entire delivery system is built on Express.
  • The XDC system interacts with external delivery services.

We try to standardize all systems. For example, if we write something in PHP, we do it the same way: we use the same frameworks and libraries. But there are tasks that need to be solved in other ways. And in this case, the approach that everything can be written in one programming language does not work. As a rule, this is not always justified and can lead to surprises. Ready-made developments or other technologies already exist for different tasks.

Apache Camel is a great example. It is an integration framework in Java that, roughly speaking, “shifts” data from one place to another. In this case, this technology provides interaction with external courier services: the team receives order data from the API, transforms it and sends it to the courier service. It is possible to write this task in PHP, but it would be unreasonable, because Apache Camel is already created for this purpose. This approach makes it easier to adapt new services and new APIs, and spend less time converting a request from Json to XML. This is an adapted technology: if one team has learned how to “cook” it, we share the knowledge with colleagues. Apache Camel is currently used in four commands.

Role allocation, poker planning and growing expertise

Previously, it seemed that there was a rigid division by systems. For example, five people are engaged in one system, another five are engaged in another and simply interact with each other. But this is not an axiom. Each engineer on the team can modify any system.

For example, there is a task – to make a convenient return form. To control the technical side of this project, we assign a technical lead, which can be any engineer from the team. Already in advance, he understands that for this goal he will have to touch on two systems: Express and XDC.

The diagram shows that Express and XDC also have tech leads. Express even has two of them – it’s a very large system. Thus, the technical lead of the project informs the technical leads of the systems about the necessary improvements, composes and decomposes tasks, and makes sure that the work goes on consistently.

At the same time, a system architect is working in all directions. He is a serious specialist who helps the entire development move in a single direction.

Planning and evaluating tasks on multiple systems at once is quite difficult, because the result can be inaccurate. In our approach, we live in two-week sprints. We meet at general meetings – at grooming and planning sessions – and use poker planning for team assessment of tasks according to the system. Each person evaluates all tasks based on their own experience and expertise. Thus, we get average estimates of the completion of all tasks, which reflect the real time frame.

As we said earlier, any engineer can modify each of the systems. Let’s say a person started working with only one of them – most often with Express, since all systems and processes are somehow connected with delivery. It is not enough for a beginner to understand it technically, you need to know the subject area and understand the processes that take place there. Thus, it will be much easier for a person who has studied one system to work on tasks to refine another. The threshold for entering something new becomes much lower.

Here are some examples of this approach to work:

  • Previously, there were often situations where there is a separate team for the backend and API of a mobile application, and another team is finalizing the application itself. This requires the formalization of all processes and tasks. We have the same person in one sprint finalizing the backend and API of the mobile application, and the mobile application itself. And these are not different tasks, but one project for general changes. And this allows you to move faster.
  • Another example is about proximity to infrastructure. Our case uses K8s and Atlassian. All scripts for deploying new servers or deploying an application are also created within the team. Any of the engineers can fix the deployment script or write something in Ansible to deploy a new server. Thanks to this, improvements are made faster.
  • There are also services written in Go, but exclusively utilities. It often happens that you need to request a million Data matrix from an external API. In this case, writing big stories in PHP is not profitable, because Go was created for this purpose. This would complicate things if the engineer is completely unfamiliar with third-party APIs and our processes. But guys can write the required utility in the right language. Go is adapted to the case.

Practice shows that full-stack work can be managed and this approach significantly develops expertise in the team.

Results of the year of work: how to expand a fullstack team

A fullstack programmer is more expensive than the rest. The HR department will look at you with bewilderment when you ask to find a specialist who knows Go, Java, Kotlin and knows PHP very well.

There are three ways to grow a team:

1. Take from the side. You don’t need to know all five languages ​​to get on the team. At the start, most were not familiar with them. It is enough to know PHP and SQL and not be afraid of working with other technologies and languages.

A well-structured onboarding process also works – it lasts 3 months. Every newbie gets a blueprint from a set of technical challenges that collectively cover all of our systems and technologies. For example, first a PHP developer begins to get acquainted with the Express system, and then he can choose other tasks based on his interests: someone is more interested in Kotlin, someone already has Go expertise. There is also a gradual immersion in the team’s processes: on duty, getting to know the monitoring system, performing support tasks.

2. Grow inside. The process started on onboarding does not end in exactly 3 months. The person continues to immerse himself in the processes, and his technological expertise is growing. Over time, he can take on the role of a tech lead. To do this, the engineer first gets acquainted with the system, then with the business requirements for it, and over time realizes that the business requirements are too great for one task. In this case, he can become the technical lead of this project or system. Immersion in such work occurs only through practice.

Newbies are given exclusively technical tasks that do not greatly affect the business components. Therefore, there are no burning deadlines, and no one will rush a person who has only recently begun to understand a new field of knowledge. It is important to understand that if an employee sees the system and this technology for the first time, the immersion will take some time. As the engagement of the engineer grows, the business component of these tasks and the employee’s expertise grows.

In this approach, it is important to understand that a developer is an engineer. And an engineer is a person who continues to learn, look for something new and understand which technologies are best suited for solving a specific problem. It is important for him to constantly develop without focusing on one thing. It’s great when a team has several projects that you can switch between and try different things. It will not let you get bored.

3. Change of technologies. This is also a great way of development. Some people start with PHP, and it seems like you can do absolutely anything with it. But now it will be strange to write permanent workers in PHP. You can use other languages ​​for this. Or, for example, when you get to know Go, it seemed cool, but something was missing, knowing the number of ready-made libraries for Java. New tools help you better understand the ones you already own.