How to find a common language with the customer, create vital unit tests and make your thorny path from being a junior developer to heading several teams more comfortable.

My name is Ivan Melnichuk. I am a head of programming department at Nexteum.

I have been a developer for 11 years. I do my best to make our work with developers more productive.

For over 4 years, I’ve been working with a highload product. Therefore, everything in my article is connected with this experience.

We will review the life path of a developer in a company. From a junior developer to a team leader. And the development of one of his most important skills — to understand the customer and find a common language with him.

First of all, I’ll give a few words about the customer and what the project is in his understanding. I’ll also tell about the team and everything connected with it.

A customer is a person who is investing money in you to get a product and profit from you. He is interested in the profitability of the project, its development and the cost of maintaining the development process.

In the customer’s mind, a project is a set of functionality and features that should be profitable. The more features, the more profit. For example, if you need a customer to buy development with unit tests, you must prove the necessity and profit of this method, give guarantees. Most often this is the job of a team leader and CTO.

A team is a particular number of people required to develop and support a project of a certain scale.

The larger the project, the larger the team is needed. In rare cases, a couple of people are enough for a large project, they iteratively finish some features, and at the same time, they have a small percentage of problems after the release. But, given the characteristics of highload projects, they often have a large number of employees.

The size of the team also depends on the customer’s financial opportunities. Therefore, you need to find a balance between the possibilities, the number of staff and the cost of additional features that should bring profit.

Additionally, I want to highlight the team marketing. Without a smart formulation of the requirements for the toolkit, as well as a detailed calculation of what it will bring to the customer, you will fail. When you speak directly about what you require, argue the need for unit tests, you already have a 50% chance that you will sell your additional tool.

Importance of efficiency and quality

The more features you release, the more profit you will get.

Don’t forget about quality. Usually, the customer doesn’t pay attention to the quality until the production starts failing. A poor-quality product is the loss of the customer’s money.

Next, we will consider the main sets of developer tools, depending on his “location” in the company.

A one-man army

This is one developer. A simple guy with sparkling eyes, but then he becomes sad because he’s tired 🙂 Let’s talk about him.

You have a project that needs to be done quickly, and it should be inexpensive. And it will be inexpensive since one developer doesn’t need much. What is required for development in this case?

He needs IDE for development, PHPStorm and Git in case of emergency. Code analyzer is optional because it affects the speed of feature release. Also, sometimes Docker may be needed.

The cost of these tools

The approximate “cost” of a developer is $500-3000 depending on his level. There are also equipment expenses and minor expenses on the project. There is no need for special argumentation, it’s simple — the customer pays for the person and his code.

My team and I

Now our developer works in a team of 2 to 5 people.

What’s changing?

When we work in a team, we know that we have a local environment. It all can be different. But it’s necessary to unite and Docker or Vagrant should finally appear. It’s relatively free for the customer.

But a dev-zone is also needed, at least for the database. Because it’s good to store data in dockers, but the base will fall if the docker crashes. Some database must be on an external resource so that developers could be able not to transfer database dumps between each other and not to suffer from migrations.

The team will need code analyzers for solving the problem of code quality. Differences in code writing habits lead to unnecessary discussions. A team needs standards.

A big plus of PHPStorm and all plugins is that they exist 🙂 For instance, PHP Code Sniffer, PHPMD, PHPStan’s, etc. It solves many problems on code review.

This “toolbox” can cost almost nothing for the customer, except for $100 for a resource for a common database.

So, for a team of this size it’s expedient to use:

Code analyzers: PHPStorm, Code Sniffer, PHPMD, PHPStan;

Environment: Docker, Vagrant;

Git: GitLab, GitHub, Bitbucket.

My team and I, the code of which I can’t see anymore

What changes when a developer becomes a leader of several teams?

He doesn’t track the code of each member of his team, he looks at the result and suggests architecture.

The problem is that code review is no longer possible. He can’t guarantee the quality of the product his team is developing. Therefore, the developer needs tools that will help him to control people and confirm that the code that is written is good.

The human factor and its possible mistakes are always a minus.

Another problem is that everything that has been written before will most likely have bugs after the changes.

After the appearance of the team in the life of the developer, it may happen that no one will understand what has been done before, no one will get the main idea.

The developer can come up with architecture, but the team will take over the implementation. He can monitor each implementation, but then he won’t have time to add and promote new features. Therefore, we need automation.

Next, I want to talk about other important aspects that a team leader needs to take into account in team development. Business cost control, PHPUnit, monoliths and microservices.

The developer’s priorities have changed. What is he worried about now and what does his team need?

Business costs

The team leader needs to keep track of the bug cost for the business, keep statistics on his department and statistics on bugs. This problem can be solved by testing.

PHPUnit testing 

A senior who is working on a feature and a developer who is working on unit testing will work at the same speed. This means that developing unit tests doesn’t take much time. And it’s more profitable than QA, because a person grows and develops. A junior developer is hired for unit testing, and after three months he will write code. Thus, the problem of resources is also solved.

What do some tests guarantee?

The team of our developer writes unit tests and the work is standardized, but only to certain limits. In addition to standards, the team needs tools that control it.

GitLab is the first solution in the automation of quality control. It can do everything that the developer needs in this case for free. Strictly prescribed pipelines will not allow a poor quality product to go into production.

And here I created a small basic assembly, which is required if you don’t have a CI/CD, but you are going to make it.

What will help in this case:

  • you have developers;
  • you need code analysis. I really like SonarQube, because if the new code isn’t covered by more than 80%, it won’t get into production. This is a big plus of SonarQube;
  • PHPUnit for launches;
  • Deploy.

When we talk about CI/CD, we talk about spending money. And this is the biggest price for integrating something new. Because it’s difficult and expensive to configure GitLab and combine it with the sets from the previous image.

Monoliths vs Microservices

The monoliths appear as the company grows. Unit tests are fast, but their support becomes problematic because there are too many of them.

The legacy appears, the development costs increase, and the speed of feature production decreases. And the leader has to make a choice between monoliths or microservices.

In my opinion, monoliths are good as a first step, but then they should be divided into microservices.

Each service is covered by its own set of tests. If the team leader changes something in a small service, he will need to test only this service and the integration in another related service. Therefore, here is a big plus, because it accelerates the speed of features development. It solves legacy problem and many others.

Any experiments always overcharge the highload. Therefore, the team leader should have mandatory custom-made monitoring. It has to be custom-made because you can’t have a guarantee that a particular piece of code will work correctly all the time. There are urgent things whose timings can be controversial.

Lastly, what’s important to remember.

A team without a KPI is always a new team, meaning new exploration of the tools stack, extra cost for training. Therefore, if you want people to feel comfortable during work, they need to understand what is “good and bad” in the context of your company.

The list of tools that are described above, especially for team of more than 3 people, can help in creating the first metrics that can show how people follow the rules, write code, and what problems a particular person has. But it’s important that all these metrics shouldn’t turn into total demoralizing control.

And the most important thing in a KPI is to measure and describe problem solving ways, and not to leave everything to chance.

In conclusion, in order to avoid frequent replacement of people, it’s worth to have a KPI.