Do you remember how you got your start in programming?The first articles/books with obscure constructions, the first 'Hello, world!'?..

Since the first steps in profession and until reaching the status of respected developer, your formal task is to have knowledge, the knowledge of frameworks/technologies/languages. But does it really reflect all the requirements for a specialist? Does an average developer have full control over his professional tools - the keyboard and an IDE?

A beginner musician on the way to the heights of mastery spends a huge amount of time on practical exercises. Over and over again, reproducing classical melodies, he perfects his playing technique, level by level learns the meanings and techniques embedded in a melody. Only years later he will come to such automatism and ease of playing, that he would be capable of full-fledged improvisation, creating of music 'on the fly'.

But what's going on in our sphere in comparison with the musician? A lead shows notes to a junior, explains how to find Do and... go ahead, write a company's hymn for a client; just google, if you have some problems) Should we be surprised that the code comes out disgusting mediocre, and approaches and templates, that were put into mind, in the beginning of the career, echo in dubious code even the at nth year of working? The code quality suffers, the speed of writing suffers, all colleagues suffer...

Sure, nothing can change the fact, that developers 'train' every day by creating code as part of a workflow. But how often you have faced situations in your life, when you didn't just perform a statement, but set the task of bringing a certain piece of functionality to an ideal state? Do you know exactly your speed of typing? When was it when you, after writing some code, thought 'I could do it a bit faster' and... deleted everything you wrote and started again with a timer? Absurd? During the work time, definitely - no one would pay you money for such tricks in the workplace)

Does it mean that neither the speed, nor the code quality, is insignificant? Not at all, but there is an opinion, that they appear by themselves... But how many of your colleagues you would name as really strong developers that everyone should look up to?

As a solution of this problem, the kata appeared - the exercises designed to shift the paradigm of coding from 'what am I writing' to 'how am I writing'.

Work tasks are a bad coach

The main thing is that the requirements are met?

The whole job of programmers is to fulfill the requirements of the business - code a functionality/implement a design. Everything is focused on the application functionality and fulfilling of requirements. That is why the main, and often the single one, criteria of evaluation is passing of the acceptance testing. Sometimes we can face teams, which are very enthusiastic about the code review mechanisms, but most of the time you can write a method of 50 lines long and no one would beat you for it. That means that the code quality is on your own conscience. And here is the main question: is it acceptable for you, as a developer, to write things like these? The answers like 'lack of time'/'that is not so bad' are not accepted) You either stick to ideas of code conciseness or not. There are no circumstances, that don't allow dividing a 50 lines method into smaller ones. There is only one explanation here - the developer is ok with such a mess, the app works and that's it.

Kata, for their part, are conscript to take away this argument and make you think about the code, and it's quality) Doing small tasks with a known solution, you no longer have to worry about the app's workability. It becomes the most important to organize the code in the best way as possible, and polish it to a shine. Gradually, such an approach becomes a part of the coding process and is transferred to the workplace.

Speed doesn't matter to anyone

Of course, business wants tasks to be done quickly, but what does it mean? With what measure do we approach evaluation? 'I'll make this button in 5 hours'? And what is going on during those five hours? Are there smaller tasks within this one? And most importantly for your growth: do you know how much faster you did this task a year ago?

It's silly to say, 'I write code faster than a year ago'. How much faster? In order to measure that, you need to know the initial and the final states and have the same conditions of the problem. Only in this way an objective evaluation appears - 'there were 40 minutes, and now it is 20, the total speed increased by 100%'. But you can never measure this way at work - the tasks are always different.

Kata force you to keep track of time, there is a measurable result of work that can be objectively measured; and the presence of feedback stimulates development.

Setting the task of increasing of the speed of writing code, the developer begins to look for opportunities. For example, some developers are crazy enough to rename variables using the mouse. That is, literally, you need to: remove your hand from the keyboard, take the mouse, move it to a position, right click, search in the menu, click, return to the keyboard, enter a name. In severe cases, 'Ok' is also clickable. Isn't it easier to press F2, enter a name and press Enter? Faster for sure. A trifle, just a few seconds of difference? At a particular moment, yes, but the laws of large numbers are inexorable - over a long distance, such little things turn into hours.

How to train?

Find an appropriate task ([examples can be found here] (https://artstesh.ru/articles/4), the section will be replenished from time to time).

Find time for regular praxis. A standard session lasts 30 minutes. Depending on your aspirations, you can practice every day or once a week. But, of course, the more training, the better the result.

Always set goals for the next praxis. At first, it will be ok to just complete all the items in the allotted time. You shouldn't stop there. Look at the key map of your IDE, find combinations that will be useful to you while writing code. At some point, give up the mouse at all... challenge!)

With each iteration, try to make your code cleaner, more concise, more efficient.

Never exceed the time limit. After 30 minutes, you should finish writing the code. Did you manage to complete only 3 out of 7 points? There will be an incentive to try better tomorrow)