It’s no secret that the best way to learn how to do something well is through constant practice. The same is true for grading work on a project. But it’s not enough to just grade. You need to then track the actual result, analyze it and make conclusions, so that your evaluation methodology is constantly improving. Without this important component, you will never learn how to grade well. But what if you could find a way to practice assessments "on cats"? As often and as intensively as possible. This article will talk about this method…
Some time ago I. wrote an article about how you can use proper organization of your time and the Pomodoro technique to significantly improve your grading skills. Now we are going to talk more about a completely unrelated area of life for most of us – moving around town. We all do it one way or another, some by public transport, some by car. And at least a couple of times a day. Why not use your commutes to practice your grades?
Every time you are going to go somewhere, you ask yourself the question: "How long before I get there? To answer this question, you activate the evaluation mechanisms: you remember your past trips, look at the traffic jams on the map, analyze the condition of the car and other factors. As a result, you have a kind of estimate. Is it accurate? Unfortunately, people are divided into punctual and not very punctual. At the punctual, this estimate will be more accurate, perhaps in addition laid a buffer for various risks. Therefore, they most often arrive on time and they are a pleasure to deal with.
So, the method is very simple :
- Before another trip, give a time estimate;
- check it against reality as you go along, and try to change your plan on the fly to fit into this estimate;
- remember the circumstances that interfered with you and how exactly they affected your estimate;
- on arrival, summarize and draw conclusions.
I saw a lot of similarities in moving around town and developing software.
First, it seems that the purpose and scope of work are clear and transparent – you know the exact address and you have a map. But exactly how the road situation will look like and what problems will arise you can not predict. It’s the same in development – it seems like everything is clear, but as the work progresses there can be a lot of things that can’t be easily predicted.
Second, a lot depends on external factors – other drivers, accidents, traffic lights, etc. There are also testers, analysts, customer, manager and other roles in development, which can significantly affect the timing of the work. And then there’s the technical side of things – new tools and frameworks, bugs in other people’s code, hardware… All that depends on you very little, but the impact on your work has a very big impact.
Thirdly, a large part of success depends on the skill and knowledge of the driver. Which route to choose, which lane to change into, where to cheat and bypass the traffic jam. In development, the individual qualities of performers are just as important – experienced developers know how to vary the solution and look for workarounds.
What does such a method of evaluation provide? After all, its results and lessons learned are not applicable to the field of development.
First of all, you learn to be much more more realistic. and kill the developer’s optimism, which has already been talked about more than once wrote Failed assessments force you to work on your mistakes and consider various factors and put in time buffers for all sorts of risks. The second benefit is working with these very risks You analyze them and assess their impact on your grades. This forces you to ask yourself questions later on when evaluating other work: "what could go wrong? what are the risks and how will they affect turnaround time? what can I do to protect myself?". This is a very useful quality for the developer, which allows him to work more predictably and reliably. Finally, you start to realize that it’s not the plan itself that’s important, but the planning process You ask yourself a lot of useful questions as you try to give an estimate, you think through the basic strategy, the alternative scenarios. And that’s what’s most important. After all, with so many external factors, any plan is a very fragile construct. But the willingness and ability to adapt to the prevailing conditions without derailing estimates is a very competitive advantage for the developer.
Although software development is a very complex and difficult to predict area, find similar models in other areas and practice on them. Learn from your mistakes and don’t repeat them in the future! And good luck on the roads…