tips and real stories. Part 2. To be responsible for the result

tips and real stories. Part 2. To be responsible for the result

Greeting! Mitya Kozhevnikov and Yura Sokolov from Mindbox are in touch, and this is the second part of the guide on software for juniors. In the first part, we talked about what it means to “bring benefit” in development, and in this part we will talk about result orientation.

About the guide. This guide is an internal document of Mindbox developers. It was written for more than one year, based on the mistakes of those who long ago became middlemen and seniors. And although Mindbox is a product company with a special culture, most of the tips from the guide are suitable for working in other teams.

Some of the advice may sound obvious: for example, we have a clause to “keep promises” – it is clear that no one is usually going to type tasks and watch them burn. But often such simple advice is difficult to follow. Therefore, in the article, we “earthed” them with real stories, so that the reader can learn about the situation if he encounters it himself, and apply our guide.

To whom to read. This guide is for juniors who want to make software their competitive advantage. If Jun does his work responsibly, knows how to study on his own and does not pass by shit, they are ready to tear him off with his hands, even if he lacks knowledge. In addition, the advice from this guide will help you to establish yourself in the team and grow faster. Use it!

What is the result?

The result is a change that is beneficial to the user.

It is important that the change takes place on time and meets the requirements of the client of the task. For example, if the button appeared, but does not do what was intended, the user’s task is not solved. With the same success, it was possible not to write all the code for it.

Not the result


Idle request pool

In the production admin, the client pressed the button, and it worked as expected

+1000 lines of code

10 hours of work

New button that doesn’t work as intended

A new button, but not now, but in a month

Responsibility for the result lies with the executor – the one who writes the code. There are three tips that will help you be responsible for the result.

Tip 1. Fulfill promises

At the start, it seems that everyone expects speed and the ability to solve complex tasks, but predictability is more important than that. This is a key skill for working in a team: if a colleague consistently fulfills his promises, he does not need to be monitored and insured.

To be predictable, it is important to think about exactly what you promise to do, when and to whom.

Remember the deadlines

When tasks are given, deadlines are asked — this helps to form the right expectations of clients or to plan work. For example, you are working on a feature that the client is waiting for – the deadline you name will be given to him by the manager. Or you write code that will be used by a colleague – based on your deadlines, he plans his work.

If you do not have time, notify everyone who is interested in the result as early as possible. Postponement is always painful. But if it happens in advance, it is easier to orientate and lay down straws. For example, a manager can inform a client about a delay, but doing so at the last moment is much more painful, because it will require the client to change his plans quickly and under stress.

Developers often find themselves in the “tomorrow will be ready” situation: it seems that there is very little left – and the task will be done, but at the last moment problems are revealed that postpone the delivery. If these situations are repeated, the team loses confidence in the developer and the terms he calls.

Usually, the “tomorrow will be ready” situation occurs when the task is not thought through. In such situations, we recommend using a time box: take a limited amount of time for independent excavations and enlist help if the problem cannot be solved. More experienced colleagues will tell you which rakes are lying on the road.

*Tomorrow we will replace it with a normal illustration*

Think about implementation

Sometimes you want to make a promise that is not certain. For example, the team asks to do a task in a short time, and you have no idea how to solve it, but you do it.

Two questions help to understand that your promise can really be fulfilled.

– How to solve the task? In the first part of the guide, we talked about how to plan the solution in more detail.

– Where is the risk? What are the concerns? At the start, it is difficult to determine the risk, so you can turn to a mentor for help – he will tell you where to put the straw. For example, refactoring will be needed, performance will have to be optimized, or a new technology or domain will need to be learned.

Sometimes the task is confusing and needs to be researched. If you do not know what term to call, then take time to understand the problem: assemble a prototype and test hypotheses or consult with colleagues. And immediately warn your colleagues about it – this way you will form the right expectations. For example, if a task is burning, it can be assigned to someone else or given someone to help. And if there is time, you can agree on a time box: “We set aside five days for research, if there is no progress, we hand over the task to a more experienced person.”

Mitya Kozhevnikov

Jun took on the task of porting the AB test calculation algorithm to the new infrastructure. The mentor mentioned: “It is necessary to revise the tests for this area to beauty.” The team highlighted that there could be an ambush in this phrase.

On the second day, June realized that a large-scale ambush cannot be done “beautifully”. There is a risk of delaying the launch of the AB test at the client. So he didn’t bother to dig in any further, he called the team for help. The guys couldn’t immediately come up with a solution for June and decided together that it was necessary to push the transfer to the new infrastructure, and to transfer the refactoring to the next task and do it in a pair mode together with the mentor.

As a result, it was possible to transfer the calculation, and to redo the tests, and no one died on the way. All thanks to the fact that June sounded the alarm in time.

Yura Sokolov

Somehow I took on a task, the solution of which I presented only approximately. He named the term – five days.

In the process, I discovered many pitfalls, had to deal with new technology and test hypotheses. I gradually moved the deadline and each time promised to bring the result tomorrow. On the tenth day, the guys from the team felt unwell and explained that it is impossible to work with expectations like this. But since no one could intercept the task, I continued to work on it.

As a result, the decision took 20 days instead of the planned 5. Due to the fact that I delayed the task, we did not have time to publicly update the SLA – we had to wait six months until the next one. The team remained dissatisfied, and I forever learned to be careful about the promises I make.

Tip 2. Don’t wait for someone to give, take it yourself

Proactive newcomers who need more than others usually grow faster. At least because it is more pleasant to invest energy and time in someone who accepts them eagerly and gratefully.

Interest is manifested in small things:

  • Call for help. Spend no more than a few hours on independent excavations – then get help. In the worst case, nothing will change, in the best case, they will help you with advice or you will figure it out yourself as long as you explain the problem. But you should not wait for someone to come and solve the problem for you – no one will do it, but everyone will help if there is a request.


Don’t miss team meetings and events where you can discuss live and solve problems quickly.

  • Crucify everyone to complete the challenge. If something stops the work, be persistent. For example, the deadlines are burning, but the reviewer does not come: write in the chat, ask for a deadline, negotiate for it, this is normal.

  • Ask for feedback. Don’t wait to be praised or scolded, ask the team and the host yourself what they think about your results. Ask until it is clear in detail what exactly is going well and what could be improved.

  • There are no tasks – ask the team. You don’t have to wait for someone to bring you work. Ask the host or write in the chat team, suddenly someone needs help. Or independently formulate a task valuable for the product, but be sure to consult with senior colleagues.

  • If you disagree, discuss. Even if you disagree with someone far more experienced than you. It is quite possible that you will highlight some lost detail. And even if you are wrong, you will learn how to do it right.

Not waiting means hurrying. Try to show the results to colleagues more often and ask for feedback on them: you have understood the task – tell the product or analyst about your understanding of the task, come up with a solution – show the “plan on a napkin” to a more experienced developer (about how to make a plan at the stage of studying the task, told in the previous article). Colleagues will tell you where you are accelerating fairly, and where you are accelerating too much.

Yura Sokolov

There is a vivid example when my haste turned into a problem for several people.

I finished the task on Friday near the end of the work day. I was well aware that it was not worth teaching anything at this time, but I was in a great hurry to see the result as soon as possible. Rolled out the update and broke the metric.

Panicked, tried to find the problem, but found nothing. Rolled back the changes – it didn’t help. I enlisted the help of a colleague who was about to leave — he couldn’t decide either. I had to call a super colleague: he came, scolded us, but helped to repair.

It was so embarrassing that because of my haste, one colleague had to be late at work, and the other had to miss the weekend. I never want to repeat this experience again.

Tip 3. Be demanding

Developers have unspoken rules of good tone. If you follow them, colleagues see you as “theirs” and value you more.

Keep promises and demand the same from others. If someone sees that a team member has violated someone’s expectations, they will discuss it with them. For example, if a colleague promised to finish the review on Monday, you can ping him in the general chat in the evening of the same day.

Write robust and understandable code:

  • Review your code — check for clarity, correct business logic, corner cases, and performance.

  • Do not leave the ToDo and commented code in the final version. If they appear during operation, this is normal. But after completion, it is important to put things in order: move the ToDo to cards or the team’s inbox, and delete the commented code.

  • Immediately write tests. This is a guarantee that all the written code solves the problem and there is nothing superfluous.

Do not pass by the mess. You can’t take anything for granted – everyone can make mistakes, and that’s normal. If something seems stupid, unnecessary, strange or unclear, you need to share the problem with the host or the team.

Yura Sokolov

When I first started working at Mindbox, we were preparing to publish a feature to replace the old one. Everything was ready, it remained to press the button and roll out the changes.

I noticed that the old functionality is not hidden. Maybe it was intended that way, but I decided to write about it to the product and the architect. It turned out to be a mistake. I took on the task: postponed the planned tasks and corrected everything in 3-4 hours.

As a result, the release was rolled out on time, the guys praised me for not just reporting the problem, but for volunteering and fixing it myself – such initiative is important in teamwork.

Checklist to check responsibility for the result

Ask yourself or discuss with your host a few questions:

  1. When was the last time I didn’t do what I promised? Why? What did I do to prevent this from happening again?

  2. How many times a month did I postpone the deadlines? When has anyone been hurt because of this?

  3. If I run into a problem, do I call for help? How long have I been trying to figure it out on my own?

  4. When was the last time I received feedback on my assignment? What did you change at work? Did you ask for a re-OS after the changes?

  5. Was I unhappy with the work of another, but remained silent?

This article is in three parts. You read the second one. The first can be found on the Mindbox blog on Habra. The last one will appear later – follow the publications.

Bonus: what to read to improve soft skills

In order to organize work on tasks and not to confuse deadlines, we recommend reading:

– The book “Getting things done” by David Allen.

– The book “Jedi techniques. How to raise your monkey, empty your inbox and save fuel for thought” by Maksym Dorofeev.

– IT-Agency article “Jedi training plan”.

Related posts