I patted three programmers on the shoulder and asked what they were working on. “I’m refactoring these methods,” was the first one’s reply. “I’m adding some parameters to this web operation,” said the second. The third one said, “I’m working on this use case.”
It may seem that the first two were absorbed in the details of their work, and only the third saw the bigger picture, and his approach was better. I asked when and what they were going to put in the repository, and then the picture changed dramatically. The first two clearly understood what files they would be, and were going to finish the work in about an hour. The third said, “I suppose I’ll finish in a few days. I’ll probably add some classes and somehow modify the services.”
It’s not that the two programmers didn’t have a complete picture of what was happening. They simply chose tasks on the board that, in their opinion, were heading in the right direction and could be completed in a couple of hours. Once they finished these tasks, they would pick a new feature or refactoring to work on. Thus, they wrote their code based on clearly defined tasks and had a small but realistic goal.
The third programmer was unable to decompose the task and worked on all directions at once. He had no idea what it would lead to and was essentially doing risky work in the hope that at some point he would have code to commit to the repository. Most likely, the code written at the start of this long endeavor turned out to be poorly suited for the solution that was ultimately achieved.
How would the first two programmers have acted if their tasks required more than two hours of work each? Realizing that they overestimated their abilities, they would most likely have abandoned the changes they made, chosen smaller tasks, and started all over again. If they continued working, there would have been a loss of focus, and questionable code would have ended up in the repository. It’s better to discard the changes made but retain an understanding of the essence.
The third programmer might continue their guessing and desperately try to stitch together the code from their patches that can be saved in the repository. After all, how can one throw away the changes made – it would mean that you worked in vain! Unfortunately, if such code is not discarded, a slightly odd code that does not solve a specific task ends up in the repository.
There are moments when even programmers who are focused on frequently saving code to the repository can’t find anything useful that they can tackle in a couple of hours. Then they switch to writing unreliable code and play around with it, but of course, they discard their changes when some insight brings them back on the right path. Even such seemingly pointless periods of work have a purpose: to better understand the code in order to identify a task whose solution will bring immediate benefits.
Determine what you will commit to the repository this time. If you can’t complete the task, remove your changes and define a new task based on the understanding you’ve gained. Engage in risky experiments if necessary, but be careful not to accidentally and imperceptibly slip into writing questionable code. Do not place the fruits of risky experiments in the repository.