5 fears of developers that we have overcome
Halloween is a time to talk about fears. I work as a product manager in an IT company, so I’ll talk about developer nightmares. But not ordinary, but those that appear in times of change.
When a company develops, it changes the approach to development, creates new products and expands the possibilities of current ones, accepts dozens of employees, those who have worked as before, it can be difficult to restructure. We rejoice at changes, but sometimes, what to hide, we are afraid of them. I have been working as a product manager for a year now and during that time I have been confronted with five major fears of my team. Today I will talk about these fears and how we managed to overcome them.
Testing is a sure way to release a product without bugs. But sometimes there is no equipment to check the code.
We make DCImanager , a panel for managing servers and data centers, and it is often impossible to create conditions in which the code will work in a virtual environment. For example, we add support for a new model of a switch, router or PDU to the control panel, and there is no such equipment on the test bench.
In some cases, testing is acceptable to neglect, but not in ours. The error is expensive. You do not initialize only one variable, and in half of the cases the operating system will cease to be installed. You will make a mistake in a couple of lines of code - and the data center will fall. As you understand, no one wants to be responsible for the "fallen" data center, so on my team this fear comes first (although it is not related to changes in the company).
How to overcome the fear of dropping everything
Our developers are writing unit tests, and some people are involved in manual testing. But once there was a force majeure, and the team was left without a manual tester. We couldn’t release the features, so the developers had to check each other.
It was a blow to the ego. It so happened that all the programmers of my team came out of the testers (manual and auto). Return to manual testing for them - take a step back. The guys were afraid that if they did it themselves, testers would not be returned to them. But the fear was groundless, after a couple of sprints, the tester took his place in the team, and from the experience we learned a lot of useful things.
What profit brought cross-testing
DCImanager was released in 2013. For six years, technology has changed, it's time to make a new version, we decided to do it from scratch. We drew prototypes, defined MVP, set priorities. The development of the old version was frozen, but they could not start the new one - two new products were already being prepared for release, all forces were thrown at them, it was necessary to wait a bit. For a lull, my developers had to become the project team of BILLmanager , our other product for hosting automation.
And here one more fear appeared. Engineering developers in every sense of the word product were afraid to take on billing. It seemed to them that this was not their area, that it was not interesting to understand the pile of accounts. I worried that it demotivates my developers. Unlike us, the billing team was happy with the unloading.
We went to work on BILLmanager for several sprints, and this experience was also useful.
Briefly about how the implementation took place
What benefits did developers get from deploying to another team?
A company needs as many strong programmers as possible, so when a developer takes on hard skills and moves to the Middle level, training newbies becomes his responsibility. But in general, mentoring usually lies on the Timlide. So it was in our team, until the experience of the leading developer was urgently needed in another product. Programmers left without a tmlide had to take on the training of both beginners and each other.
Being a mentor is scary. You need to be distracted from your tasks, tune in to another person, explain what you yourself sometimes understand at the level of intuition and explain in such a way that you will be understood. If the Padawan did not understand - this is your problem. If he made a mistake, and you did not notice - you answer.
I will not give advice on how to become a good mentor, this is a topic for a separate article. But we managed, and from this rather stressful experience we learned the following:
When the lull is over, it's time to start a new version of the DCImanager product. It would seem that here is the long-awaited moment. Now, with a team full of ambitious people, we will start everything from scratch - without looking at old bugs and historically formed strange dependencies in the code. But here, there was a place for fear.
For several years, technology has gone far ahead. We wrote the old version in C ++ 11 and using make, we chose C ++ 17, CMake, Conan and Docker for the new one. The team needs to learn all this and learn how to apply. The next way out of the comfort zone, the challenge and the thought “what if I can't and will be worse than the others”, “what if there are more problems waiting for me, I won't figure it out and they'll kick me out”. We are still mastering new technologies and the struggle with this fear is still in the process.
How to quickly master new technologies
I see experiments as an opportunity to learn new things, to become better, and I try to make my team look at their fears as well. I think that the mood of the guys depends on me. When you believe in the product and in the developers, listen to them on the stand-ups and sort out the problems in retrospectives, support them in a mess and explain the need for change, then it is easier for them to overcome fears.
But let's be honest, we still have a couple of undefeated phobias in stock. Fear of deadlines, for example, or the fear of not getting along with newcomers. While it seems that nothing can be done with them - just accept it. But maybe over time our opinion will change.
What are you afraid of?
PS If you want to be the first to see the demo version of DCImanager - send your contacts to bizdev@ispsystem.com with the subject “I want to look at the new DCImanager”. When it is ready, we will write to you. Or if you need a product to manage servers, but the current DCImanager is not suitable for some reason and there is no suitable solution on the market, write your wishes for such software, perhaps we will include something in the development plan.
When a company develops, it changes the approach to development, creates new products and expands the possibilities of current ones, accepts dozens of employees, those who have worked as before, it can be difficult to restructure. We rejoice at changes, but sometimes, what to hide, we are afraid of them. I have been working as a product manager for a year now and during that time I have been confronted with five major fears of my team. Today I will talk about these fears and how we managed to overcome them.
1. Fear of dropping everything
Testing is a sure way to release a product without bugs. But sometimes there is no equipment to check the code.
We make DCImanager , a panel for managing servers and data centers, and it is often impossible to create conditions in which the code will work in a virtual environment. For example, we add support for a new model of a switch, router or PDU to the control panel, and there is no such equipment on the test bench.
In some cases, testing is acceptable to neglect, but not in ours. The error is expensive. You do not initialize only one variable, and in half of the cases the operating system will cease to be installed. You will make a mistake in a couple of lines of code - and the data center will fall. As you understand, no one wants to be responsible for the "fallen" data center, so on my team this fear comes first (although it is not related to changes in the company).
How to overcome the fear of dropping everything
- All team developers make code review of each feature.
- We keep lists of those without which the task cannot be released.
- After the release of developments, we analyze what we did not take into account. We describe in detail what was done and what behavior was observed, so that at any moment you could return to the task and restore everything to memory.
- Constantly updating the knowledge base. We allocate time for documentation for developers, we share knowledge among themselves on those. studies and stand-ups.
- And finally, the main thing. We test custom developments for clients with them on the provided equipment.
Once, we added port aggregation control for switches that are already running. If an error occurred, the operation of network equipment in the data center would be completely stopped. The client came to his data center at three o'clock in the morning and controlled the situation in order to quickly roll back to the old version and resume operation of the equipment. We could lose remote access, and the work of the data center would be paralyzed.
2. Fear of being without a tester
Our developers are writing unit tests, and some people are involved in manual testing. But once there was a force majeure, and the team was left without a manual tester. We couldn’t release the features, so the developers had to check each other.
It was a blow to the ego. It so happened that all the programmers of my team came out of the testers (manual and auto). Return to manual testing for them - take a step back. The guys were afraid that if they did it themselves, testers would not be returned to them. But the fear was groundless, after a couple of sprints, the tester took his place in the team, and from the experience we learned a lot of useful things.
What profit brought cross-testing
- They remembered the "youth" and again looked at the tester for development. In some cases, they began to add additional actions to make life easier for the tester. For example, generating statistics for verification.
- A well-known fact was confirmed that the developer cannot test his code, since he closes his eyes to some things. Therefore, the guys tested the code of each other.
- Once again, we were convinced that testers are an important link in the team. They are responsible for the quality of the release feature.
3. Fear of hitting another team
DCImanager was released in 2013. For six years, technology has changed, it's time to make a new version, we decided to do it from scratch. We drew prototypes, defined MVP, set priorities. The development of the old version was frozen, but they could not start the new one - two new products were already being prepared for release, all forces were thrown at them, it was necessary to wait a bit. For a lull, my developers had to become the project team of BILLmanager , our other product for hosting automation.
And here one more fear appeared. Engineering developers in every sense of the word product were afraid to take on billing. It seemed to them that this was not their area, that it was not interesting to understand the pile of accounts. I worried that it demotivates my developers. Unlike us, the billing team was happy with the unloading.
We went to work on BILLmanager for several sprints, and this experience was also useful.
Briefly about how the implementation took place
- To minimize the stress of switching to another product, the team remained a team and did not depend on the guys from BILLmanager.
- The tasks were chosen according to the principle “it is necessary to do it yesterday, but there are not enough hands”. The tasks were discussed by productologists, then when planning the next sprint I transmitted them to the team.
- BILLmanager developers were our mentors. Exception-man answered all the questions, and the timlid told what should work and how
- We had two stands. First we went to the billing, then we discussed the results within our team.
What benefits did developers get from deploying to another team?
- Another product is someone else's code that needs to be sorted out; plus another work logic to understand. Thanks to the mentlating of the team leader and the patience of the Exception-man, we successfully mastered the billing, pumped new skills and fairly quickly sawed through improvements.
- Of course, we saw how some things are arranged within the other team. It may seem that everything is the same for everyone, but as if not so. The differences lie in the details. They took the best and most convenient for themselves as a rule (for example, they looked at it and, changing it a little for themselves, began to use a scram-board, adopted some code style moments, etc.).
4. Fear of becoming a mentor / left without timlid
A company needs as many strong programmers as possible, so when a developer takes on hard skills and moves to the Middle level, training newbies becomes his responsibility. But in general, mentoring usually lies on the Timlide. So it was in our team, until the experience of the leading developer was urgently needed in another product. Programmers left without a tmlide had to take on the training of both beginners and each other.
Being a mentor is scary. You need to be distracted from your tasks, tune in to another person, explain what you yourself sometimes understand at the level of intuition and explain in such a way that you will be understood. If the Padawan did not understand - this is your problem. If he made a mistake, and you did not notice - you answer.
I will not give advice on how to become a good mentor, this is a topic for a separate article. But we managed, and from this rather stressful experience we learned the following:
- Explaining, we must give more context. In my head everything is beautiful, and when you tell, it turns out torn and incomprehensible.
- On the review, you should not just watch the code, but understand what the person tried to solve with this code. Then it is easier to understand its logic and find errors.
- Sharing knowledge is useful: you learn to formulate thoughts; you put everything on the shelves in your head; while you explain, you find the best solution to the problem.
5. Fear of not mastering new technologies.
When the lull is over, it's time to start a new version of the DCImanager product. It would seem that here is the long-awaited moment. Now, with a team full of ambitious people, we will start everything from scratch - without looking at old bugs and historically formed strange dependencies in the code. But here, there was a place for fear.
For several years, technology has gone far ahead. We wrote the old version in C ++ 11 and using make, we chose C ++ 17, CMake, Conan and Docker for the new one. The team needs to learn all this and learn how to apply. The next way out of the comfort zone, the challenge and the thought “what if I can't and will be worse than the others”, “what if there are more problems waiting for me, I won't figure it out and they'll kick me out”. We are still mastering new technologies and the struggle with this fear is still in the process.
How to quickly master new technologies
- Do not hesitate to ask senior and experienced colleagues, do not be afraid to seem silly.
- Document to speed up the process of diving new ones and not tell 10,000 times the same thing. Maintain a knowledge base.
- "Okay-Google" is always to help. If it does not work, see item 1.
Not fear, but challenges
I see experiments as an opportunity to learn new things, to become better, and I try to make my team look at their fears as well. I think that the mood of the guys depends on me. When you believe in the product and in the developers, listen to them on the stand-ups and sort out the problems in retrospectives, support them in a mess and explain the need for change, then it is easier for them to overcome fears.
But let's be honest, we still have a couple of undefeated phobias in stock. Fear of deadlines, for example, or the fear of not getting along with newcomers. While it seems that nothing can be done with them - just accept it. But maybe over time our opinion will change.
What are you afraid of?
PS If you want to be the first to see the demo version of DCImanager - send your contacts to bizdev@ispsystem.com with the subject “I want to look at the new DCImanager”. When it is ready, we will write to you. Or if you need a product to manage servers, but the current DCImanager is not suitable for some reason and there is no suitable solution on the market, write your wishes for such software, perhaps we will include something in the development plan.