[Rastonbury]

I don't get that take, wouldn't most people use a tool if it made you even 5% or 10% more efficient at your job after a little bit of research? Sure digging for the tool and task use case takes time but it'll more than pay back itself

[swatcoder]

Deskwork efficiency has never been a challenge in my work or in my career. My productivity is usually paced to some client or collaborator already, so getting a little bit mode done in my time doesn't win me much but a longer wait at that gate. That's been consistently the case for nearly 25+ years.

So no, I don't invest a lot of attention in further optimizing how quickly I get my work done. If anything, I'd rather invest that attention in strengthening the routines and practices of my work so that it demands less conscious attention as I do it, at no loss of quality. Write a module 5% faster? Doesn't matter to anyone. Leave a workday refreshed and ripe because I've mastered my tools and workflows? Huge win for me.

[JTyQZSnP3cQGa8B]

If it was the case, most developers would take a few hours to learn how to use regular expressions to search faster in their code. But they don’t.

[zen928]

Not accounted for in the initial calculation is cost of adoption needing to learn how to apply them in your workflow in the most effecient / least disruptive way to realize the 5% improvement

I don't think anyone's against self improvement, but the cognitive overload of continually juggling multiple 5% improvements vs a possibly more-disruptive (but in reality usually more streamlined) 25% improvement down the line just doesn't make sense if you value your own time, especially if you have to essentially embed yourself as an expert into the domain to be able to follow improvements

[ggoo]

5/10% efficiency gains may not translate into 5/10% compensation gains.