4 ms·
The answer (for woodworking and just about anything else): as soon as it isn't sharp enough. Which is after between 5 minutes to 2 days of usage. Most important
by ReleaseCandidat 3y ago
The answer (for woodworking and just about anything else): as soon as it isn't sharp enough. Which is after between 5 minutes to 2 days of usage. Most important is to not wait too long, because the sharpening takes way longer and your work suffers - but it is _really_ annoying having to stop working to sharpen your blades (or even saw blades). That's why it's good to have another chisel or plane (or whatever) handy, which is sharpened - although my wife somehow disagrees with that argument. And yes, sharpening tools is the single most important skill when working wood (with hand tools, as in "non-powered-hand-tools").
But what he is talking about is _changing_ tools. I actually do not have a good analogy to tool sharpening while programming, the only one I could think of is fixing errors or warnings as soon as your LSP (or whatever) displays them. Or refactoring code as soon as possible (although too early does cause problems).
- giraffe_lady 3y agoYeah my career was as a cook before programming. I would hone a knife before applying it to a task and then sharpen all my knives every week on my day off. Programming has nothing remotely equivalent to either task. It's just not a useful analogy I don't think.
- XenophileJKO 3y agoI feel like the analogy has always been about spending time now so that I save time and reduce errors in the future. Often to me it isn't replacing tools so much as spending time figuring out how to use them more efficiently. I don't feel like "switching" tools is the right way to think about this. It MIGHT be the right choice, but usually it is about learning how to use your tools well and leverage the capabilities that require preperation or familurization. Examples are: 1. Creating templates inside your tools. Like any jetbrains ide. This has literally saved me years of time in laguages that have more boilerplate like java. 2. Configuring your tools to your usage patterns, using plug-ins or extensions. Once done, I could do something like generate my style of code in keystrokes. If I found myself making something more than once that isn't reasonably abstractable, I often made templates, plug-ins or infra. This can also be extended to something like if I know I am going to be configuring some type of system a bunch and I anticipate the technical/business needs changing a bunch, I'll spend the time to create a fluent configuration interface for it and it saves me TONS of time in the future.