| A form of 'doing nothing' I've embraced is just watching my coworkers who I support do their work and listening to them. Listening is very active, so it's not doing nothing, but it's keeping my hands off of the keyboard and preventing me from rabbit-holing on optimizing something or otherwise spiraling like we all tend to. The result is that I often know what I should do better than I would have. Make a point of talking to the people you solve problems for, get your hands dirty, and create that domain understanding that you need. You'll likely produce less code, but it'll be more useful. Or, in some cases, you'll write more. But it'll be for something you never would have realized you needed had you not 'done nothing'. The key for me was allowing myself to get out of the engineer mindset and into the mindsets my coworkers need to do their jobs, being less interesting in fixing and solving, and more interested in getting a holistic understanding of the required work and how it fits into our team and org and with our partners and so on. I'm fortunate enough to work somewhere where this isn't only permitted, but it's encouraged. The problem spaces are often highly niche and complex too, so the need for developers knowing what their users are doing is especially important. I do think it applies anywhere, though. Even in my own personal projects. Do less, observe and experiment, use the software, let things incubate. Then do the work once the mental model has settled in a way you know is better than it was. |