How not to knock the developer out of the “flow” state
/ photo Rachel Johnson CC
Developer's time is an invaluable resource that is constantly in short supply. We at IT-GRAD are very attentive to this issue.
This is also known to professional programmers who have learned to “tame” time and negotiate with it. The secret of their success lies in the fact that they try to get the most out of each “working” minute, so they don’t really like when their terms of the “deal” with the time continuum are violated.
In this regard, we would like to give some advice for company leaders and project managers that will allow us to work and interact with the development team as efficiently as possible.
“Don't starve” developer ideas ...
Ideas are like little shy kittens. If they scare them, they will stop coming.
Therefore, any new idea requires evaluation - no need to rush.
If the bright thought that has visited your head is not directly related to the problem solved by the programmer, then report it, but do not require a momentary answer. A good developer will write down a thought and return to it later.
This is necessary so as not to knock a person out of the “stream”, since it takes about 15 minutes to return to a state of concentration.
Lucy Jo Palladino talks about the issues of maintaining concentration and working mood quite readily in his book “Maximum Concentration”.
... and do not overload with your "ideas"
Respect for ideas is excellent, but you do not need to load the developer with an endless stream of new ideas. Try to express your thoughts on paper, and then cross out the excess from there - carefully define the essence.
You will be surprised how much this will improve the quality of communication.
It is also worth considering what you will say to the developers. Most recently on Habré discussed this topic.
Do not turn the work into a puzzle of 32,256 elements
It is necessary to find something in between the short-term ideas and "multi-ton" projects.
Break tasks into small pieces and distribute them so as to get the most out of a specific situation. The main thing is not to make people “jump” from one task to another - and so they “drop out” of the state of concentration.
Focus on creating the conditions for self-improvement. The professional growth of a specialist will only positively affect his success: he will gain new skills, study new technologies more deeply, and begin to offer creative solutions.
Build their work according to rule 80/15/5 . The developer will spend 80% of the time on his main work. 15% of the time to devote to more complex tasks, and the remaining 5% of the time - to satisfy their own curiosity.
This approach will create the conditions for working on interesting tasks.
No need to chase the result
It sounds really strange, but in this rush the reason for many failures at the finish line lies. The time it takes to get the code neat is really worth it.
Refactoring and additional efforts to optimize the UI are necessary so that all the greatness of the functions does not turn into one big mess.
May be interesting: literature on creating interfaces on Stack Exchange.
Not everyone "dances at the pace of a waltz"
People work in different rhythms. Each programmer chooses the moment to work on certain tasks, so as not to waste extra energy and avoid confusion.
It is worth considering that people have declines in activity when any work will be ineffective. Be patient, they are necessarily replaced by periods of decisive action.
Sometimes it’s worth allotting time to think about the situation so that the developer can understand in which direction he should move in order to avoid a dead end. The main secret of saving time is to do everything efficiently and the first time.
PS A few materials on the topic of time and project management.
- How to Stay A Great Leader In Crisis: 7 Tips
- Little "dirty" secret of project managers
- 25 blogs on project management
- Project Management: Operational vs. project approach
- Time management is really easy
- How to manage time: 10 practical tips
- How to Manage Time Effectively: Jedi Techniques
What else are we writing on the IT-GRAD blog :