Ok, I’m a junior, how do I start driving? / Hebrew

Ok, I’m a junior, how do I start driving? / Hebrew

When I first came to the world of IT, for me, as well as for you, there was a lot that was unclear and unexplored. It was the bridge of my motivation that kept me in this industry, but as you tie all your accumulated knowledge into a knot, there is a confidence in some stability, and therefore a new question.

And what now?

Well, now you are, as it were, a full-fledged cog of the middle link, the so-called middle developer, now you want to grow even higher, to the leaders -> architects -> CTO.

And the problem is actually that even though you now have confidence in how to write some functions, build REST applications, you are not sure if you are doing it right from the ground up or if your code is clean enough to manage other developers. If you have asked the same questions or faced the same problem, then in this article I will try to briefly describe some of the things that helped me figure it out.

Create a system

And this even applies to a few technical parts – forget about the code for now – create a summary of the rules by which you work. Remember: it’s in the details.

  • For example, organize a certain instruction on how to work with Git, a certain branching system of the type feature/bug/hotfix — the name of the product in the name of the branch; if there are several of them, a separate writing style is required (camel case or snake). In Bitbucket, for example, you can easily filter branches if the name has feature etc, so you can quickly collect statistics. The branch name is also much more important than the commit description, because it’s pretty obvious to the whole team what task someone was working on.

  • In addition to the names of branches in git, you can organize a lot of things from above, for example, merge rules, restrictions on flags, conflict resolution rules, and a little later we will get to actions.

  • Next, develop a style of writing features: here everything is more about the project’s architecture and, of course, first of all its simplicity: everything should be intuitive; isolate your entity into a folder along with controllers, services, repositories, and other things that belong to it. And then determine step by step how the developer should write the feature, starting from creating a branch to a pile request. Disseminate this instruction to the developers and ensure that it is strictly followed.

Imagine: you collected the base from the previous points and even wrote something with the team.

And now a new developer has arrived, he will, of course, later integrate into the project, but to facilitate his tasks and teams in general, describe the project, create documentation: what steps are needed to launch the project and what needs to be done to start work.

Build everything succinctly and clearly: how to work with custom elements on the front, diagrams of how your backend works, how and what interacts with what, if services are connected and have complex logic. For this, use the necessary tools that are already on the network, spend a little of your time searching for them. I understand that these tasks seem trivial in the early stages of a project compared to the huge number of real-world tasks, but such things are fundamental to the operation of the project and to your personal comfort as a lead developer.

Work on tasks

Clearly organize work with tasks, use tools such as Jira, Git Board, Notion and other boards. It is very important to correctly organize the columns, to correctly explain when, what and where it moves.

Your columns may have different names and contents, but I will explain with the following examples:

  • Analysis

  • To Do

  • Development

  • Block

  • Development Done

  • Testing

  • Testing Done

  • Production

At this stage, you may cross paths with other professionals, such as a manager or analyst. But remember that the board is a tool for your work, so make sure that you and your team are comfortable. I would pay special attention to the column BlockWhich task falls into when it is affected by external circumstances independent of the developer.

In order to put a task in this block, you need to explain the circumstances, mark the responsible person, if there is such a person, note the date and time of the block, which can later remove the responsibility from the developer and save your nerves as the person responsible for completing the tasks.

Of course, it is worth paying attention to the appearance of tasks in the blog and their assessment, but this is an extremely extensive topic with an individual approach, so I will limit myself to a couple of tips:

  • Formation of tasks by managers and their detailed description.

  • Placing tasks in the backlog when they are understandable to any programmer.

  • After that, tasks are distributed to developers in a block Analysisthey must be appointed.

  • All tasks that have entered the Analysis block must be evaluated by the developers, after which they should be moved to the block To Do.

  • The developer looks at the criticality of the task by priority and drags the hottest ones into the block Development. If the priorities of all tasks are the same, the developer sorts the tasks at his own discretion.

It’s critical to give developers multiple tasks at once so they can switch between them as needed or if their current task falls into Block.

Tasks can also be linked, so a developer can start Task 1, move to Task 2, and return to Task 1.

Programming, Analysis, Control

Program, Analyze, Control

You’ve already done quite a bit of work on the processes; now that you have a system with instructions and specific actions, it’s time to analyze and monitor. Of course, the situations are different, the projects and the device of the company are different, so it is impossible to adjust one system for everything, but it is possible to create a base for it. Once it’s set up, just observe, collect problems and fix them, make changes, adjust your system to suit you.

Quality control

Well, now it’s a matter of your technical capabilities, the soft skills of a mentor and the ability to work in a team.

When the task is complete, the developer should open the PR and you should train it to work on your system. I am not talking now about the optimality of the solution, but about the style of writing the project, certain rules of the code that you are used to seeing it: simple, clear, clean.

You don’t necessarily have to check the PR, most likely it can be the person who is most competent in this or that part of the code.


It doesn’t matter whether you’re a junior or an ice hockey player. Start implementing process improvements in your work and life will become a little easier.

Related posts