About the question whether doing a task is only about getting it done, and why there is no such thing as no progress.
At work we plan tasks. We plan tasks and then we do those tasks. The quicker the better. Well, actually the better the better. And after one task comes the next. Often we feel we are behind in time. Often this is because we are, according to our timeline. But then the timeline gets extended. But how often we do that and which results we were able to achieve, that gets recognized by our coworkers, and our bosses, most likely. And this has other implications. In the best case we gain some credibility. We gain respect. Or we learn. Or both.
But when we feel behind, when we are fighting that uphill battle. When the UI doesnt work. When the UX doesnt work. When the docs dont work. Or when we dont read the docs. It can seam that all that matters is to get the task done, no matter how. And in low quality environments this is the case. And this is where then the inevitable firefighting happens. And people burn out. So we dont talk about those.
This is about those tasks that need to be done reasonably well. With good measure.
For those done tasks, for those things that are done reasonably well, a certain amount of engineering went into those tasks. The magic is going on in the back, while for the user it works automagically. For this complexity to work in the back, it needs certain pieces to work together. And actually working on the tasks is trying a bunch of different options, tweaking it, shaking it, kicking it, replacing it, until it does the thing it is supposed to do.
So experientially, we feel like we are constantly failing. It doesnt work. It doesnt work. It doesnt work. And then it worked half way. And then again it didnt work. And then we started over. And then it didnt work. But then suddenly - a blessed moment. It finally works - and then we move on to the next thing. Looking back it was so easy. Maybe it should have taken less time.
But this is the key, this is the trick. Solving a problem is not only about finding the right path. It is also about finding the wrong paths. To find all those many options which dont work. And then when an unexpected issue comes up, you - and only you - can make an educated guess what will be the root cause, and where to look to fix it.
Actually when we solve problems, we dont only create solutions. We compile knowledge about failures. This knowledge is unique to us and the solution. The problem, the solution & then the engineer. The holy trinity.
This means after we solved a problem, actually 80% of the results are situated not in the code, but in our minds. It is that innate knowledge about the solution, about what worked and what didnt. And what probably might in the future.
Reality shows that this is mostly unseen by companies and human resources departments, which happily let employees go, rather than giving them a raise. They expect the resignation after 2-3 years (atleast in tech), and they are happy with it. They are fine with it.
But to us engineers, the next time we’re battling with a problem, when we are behind on time, when we seemingly make no progress, we might know: There is no such thing as no progress.