1. Fear of screwing up infrastructure
- All developers review the code of every feature.
- We create lists of things that we can’t release the product without.
- After the release, we analyze what we might have missed. We describe in details what was done and what it resulted in so we could return to any task at any time and recall everything.
- We update our knowledge base, dedicate time to creating documentation for developers, and share our findings within the team.
- And the key thing. Any custom development made for a client shall be tested on the client’s equipment.
Once, we were adding the management of switch port aggregations for one of our clients. If we made a mistake, the client’s equipment in the data center would fail. Our client decided to come to the data center every night at 3 AM to make sure that everything was alright and get back to the previous version in case if something bad happened. You know, we might have lost the remote access to the equipment, which might have paralyzed the data center operations — this is not a joke. Happily, everything went fine.
2. Fear of losing a Q/A specialist
- We were able to look at our situation from the Q/A perspective. For some cases, we added more actions to make the life of Q/A easier, e.g. statistics generation.
- We confirmed that a developer cannot test himself/herself because simply won’t notice some things. You need to test somebody else’s code.
- We also confirmed that Q/A is really important because they’re responsible for the final quality.
3. Fear of joining another team
- We stayed as a team and didn’t depend on the BILLmanager team to minimize a potential stress from switching to another product.
- We picked tasks that had to be done yesterday but were not done earlier because of insufficient developer resources. Product managers discussed the tasks which were then translated to the team by me.
- BILLmanager developers were our mentors. The exception man was answering the questions while the teamlead was telling us how things must work.
- We had two standups. For one thing, we visited BILLmanager standups, for the other thing, we discussed our results inside our team.
- When you work with another product, you have to read the other code and understand the logic of the product. Our experience of working in the billing team was successful due to the help of their teamlead and the patience of the exception man: We learned new skills and helped implement new features faster.
- We had a glance at how things work in the other team. It may seem that every team is similar but that’s not true. The devil is in the details. We learned some things from them, such as their ways of using a scrum desk, their code style, etc.
4. Fear of becoming a mentor or losing a teamlead
- Give more context when explaining something. It might be clear and simple in your head but messy and difficult to catch in a real life.
- During the review, you need to understand what a developer wanted to solve with the code as opposed to understanding the code itself. It will help you better understand the logic and find mistakes.
- Share knowledge. This way, you learn how to form your ideas into words, prioritize things, and find better solutions.
5. Fear of lagging behind new technologies
- Don’t be afraid to look stupid. Always ask for help from your senior colleagues if you need it.
- Record everything to help newcomers without repeating the same things 10 times a day. Keep your knowledge base up-to-date.
- Just google it. If it doesn’t help, see 1.