No, it's not. It's about solving problems. And yes, we mostly do this by writing code. But there's an emphasis on solving problems, not on writing code. We're not there to blindly rewrite tickets to code. We're there to think about how to solve issues, and then solve them with code or not.
This is a small, silly example; one hour of time is not that bad. But it applies to bigger things as well, and this one hour could have been a day or a week.
Let's be honest. Writing code is not the most challenging part of being a developer. Maybe, in the beginning, it is. But at some point you're used to it, you know the language, you know the tools. You can write code all day long, without actually using your brain that much. Sometimes it's okay. After all, there are tons of boilerplate we need to write. However, you don't always precisely know what code you need to write. And this is where the challenge begins — coming up with a spec, new architecture, comparing different solutions.
Some tasks may sound like bullshit. And you probably have it in the back of your head when implementing them. Why waste your time, reviewer time, company time on it then? Why not stop and think — so what problem they want me to solve? What am I trying to fix or improve? Does it even make sense? Will the suggested solution work? If you can't answer these questions, then you probably need more context. Once you do answer these questions, you're going to have a better understanding of the task, and more insights on how to approach it. And also, if you answer these questions and conclude out that there's something wrong, bring this up. Do you see a problem that might have been missed? Do you know a solution that seems better?
Maybe the problem is too much focus on the code itself. You think about all the smart ways to implement the feature that you won't stop for a moment to realize that "hey, I'm removing this page in my other PR, should we actually do this?" or "hey, that will make some other feature unusable". That's the simple way to make your work counterproductive. It won't always mean a complete waste of time. But it won't be the best use of your time, either.
Most of the time, you won't be provided with all the answers and step-by-step solutions. Majority of the tasks will lack description. Or even if they don't, it's super easy to misunderstand the content. There's also a limit in hand-holding you can get. Don't demand it. Make sure to have enough context and at least try to think about a solution yourself.
I guess the heading speaks for itself, and also kind of summarizes the whole problem. Don't write code blindly. Think about the task first. And think about what the problem is.
Don't go to the extremes either. You don't always need all the context in the world. You don't need to know everything. And you won't avoid situations when you feel you wasted your time or when your solution wasn't the best choice. It's okay that you didn't know that there are plans to redesign whole sections that you're updating right now. Or that your colleague was working on the same thing and you misunderstood each other.
We are pretty lazy creatures. And writing code is more straightforward than thinking about solving problems, staring conversations with management, or putting yourself in your users' shoes.
What we can do is try. Change the perspective. Look outside of your editor.