How Often Should We Sharpen Our Tools? | Hacker News Reader

How Often Should We Sharpen Our Tools?

tratt.net

67 pointsingve37 comments

I use Seasons of Feast and Seasons of Famine. For about 3 months I will gleefully add new tools to my kit, trying them out, seeing what sticks and what doesn't. Then for 3 months I'll pare down to only what I actually find value in using from that collection. Rinse and repeat.

Shell Bling Ubuntu was partly formed out of running through this a few times. Every tool that is included in the 3 scripts is a tool I found persisting beyond a full Season of Famine, and therefore it gets my recommendation. https://github.com/hiAndrewQuinn/shell-bling-ubuntu

I'm on the SysAdmin side, but do similar with the tools/apps I keep handy. It's a great way of paring down what you actually need commonly and what's damned handy, but only once in awhile.

Ventoy is a great tool for those that need multiple bootable images handy, but even then, I have to pare down the images on it, at times, because when I find a handy image, I tend to just throw it on the Ventoy drive.

Love this. Is there a reason you feel a season (3 months) is optimal? Does it change depending on the craft?

I do the same, but over 30 years instead of 3 months. I turn 36 this weekend. It's not going well.

Happy birthday!

I don't think the analogy to woodworking is sensible. The problem with dull tools is twofold: (1) the wood can be damaged and so the task has to be started anew and (2) the woodworker can get injured.

Neither applies to the problem at hand. The problem at hand, as others have pointed out, is about switching tools.

I switched from decades of using emacs because stretching for key chords started to hurt my hand. I went to vi. It was a pain for a few days because my hand-brain had memorized emacs. After about a week, I was able to do simple things without errors. A few weeks after that, it started to be fun and I got to the point where I could work as easily as I had in emacs. And then, owing to plugins, I started to get more productive.

Here's my advice for folks switching to vi: get a medium-sized postit note and write a couple of common key sequences on it. Add new sequences as you need them, but don't bother for things that you only do once in a while. After a few days you'll need to tape the note down, because you have been removing it repeatedly to add new things. Use tape to hold it down. After a few weeks you won't need the postit note. But spend an hour or so each week reading up (or viewing videos) about vim things -- not things you need, but things that interest you. This hour is your long-term investment.

As for configuration, I wasted a heck of a lot of time on that (in both vim and emacs). A few months ago I switched to lunarvim, which is a neovim that comes in a state that already has a ton of things I want. That's my advice for anyone switching to vim ... go past it to neovim, perhaps trying lunarvim as your variant. (There are other variants, and I've not explored them. I did some web searching and it seemed as though lunarvim was well regarded. All I can tell you is that I feel no need to switch.)

I 100% agree with this, even as much as I am someone who spends a lot of time on meta-improvement: the equivalent of sharpening one's blades is more like keeping all of my devices charged. I have to do this or the device fails me, and it is time and effort that is at times annoying, but can itself be optimized, and there are some tools that need this work done less often, leading to interesting trade-offs.

As a woodworker, ya, it didn't make much sense. You sharpen tools to keep the output high quality and yourself safe. The analogy here would be like me tossing a $800 planer in the trash and buying a new one because it was dull.

> the woodworker can get injured. Neither applies to the problem at hand.

> I switched from decades of using emacs because stretching for key chords started to hurt my hand

We not just switch to evil mode or boon. Lets of ways to make emacs more ergonomic, no reason for apostasy.

Before reading I had imagined this article was going to be about improving fundamental skills rather than configuring text editors and IDEs. At least for me, the former has had a far larger impact on productivity and I consider those my real tools. Daily practice and learning (see Mike Acton's discussion about this) has had a huge impact on my long term productivity. For editors/IDEs I've found the most effective thing is to find something where the defaults do most of what you want, learn the key bindings and then get on with work.

EDIT: also, if I were to concentrate on sharpening these kind of tools, i.e. software, editors are not close to the most important tools I use. More important are version control, debugger, profiler and data transfer tools.

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).

Yeah 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.

I 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.

I've stopped trying to make analogies between software development and other crafts. It takes more effort and care to talk about issues directly, but anything that comes out of the discussion feels a lot more actionable.

I've considered writing a post called "software analogies considered harmful" but it would basically be what I just wrote.

Rather than just tools, think about improving your work overall:

* working explicitly to be better at what you do, * including being better at using the tools you need for your work.

I will call the above "improving" as opposed to "business as usual". Business as usual would be doing your work (developing code, meeting with clients, etc.)

My answer is:

You should improve as much as you can get away with without hurting your experience from performing business as usual.

The rationale is that over time, people who improve more should, theoretically, outpace people who do not improve or are slower at it. With one important note, than experience of doing work is itself an important component of improving.

Personally, I spend about 2:1 improving vs doing work and have been for past couple decades. Thanks to so much improving I did in the past, I can do a lot of work in short time. Frequently, this is just about knowing what to do instantly with least effort. And a significant component of my value is being able to answer hard questions and solve difficult problems or even just being available to do those. I don't even need to do a lot of work to bring value -- just being available is a lot of help for people I work with.

Now, coming back to "sharpening our tools". There is quickly diminishing returns from being able to use an editor or IDE or email client better. I have observed some people being extremely productive with things like PowerPoint or Excel to make instant presentations or simulations. So some tools have different rate of the diminishing returns also depending on your job (probably more useful to be better at Excel in finances than in software development, duh!)

I think it is important to understand that being good at the low level tools becomes kinda less important as you get more experience. As you get more experience, your experience is going to be the most important tool to do your job well. Does my 80wpm typing speed help me? Probably lets me input more email or code or documentation in shorter time. Does it make my emails or code or documentation better? Probably not much or not at all -- most of the time is spent gathering thoughts anyway.

I think what this misses is the very important motivation factor. Thinking in terms of "Improving my editor will let me write code 20% faster" is missing the point in my opinion. If your improved editor is more pleasant to use, you will find it much easier to find the motivation to actually use it, stay focussed, and get work done. I think this is the main reason people adopt things like Vim/Emacs, tiling WMs, CLI over GUI, etc. It's not that using the keyboard to move your windows around vs your mouse saves you a significant amount of time. It's that it makes the whole experience of using your computer feel much easier and more pleasant and it helps you maintain flow when working. The real time saving is found every time you spend an extra hour working because you feel more motivated, not in the 2 seconds you save each time you don't have to move your hand to the mouse and back. Writing at 80wpm isn't about saving a few seconds when it comes time to convert your thoughts into code. It's about not finding the process of typing text frustrating and boring.

Exactly right.

Yes and:

> ...makes the whole experience of using your computer feel much easier and more pleasant...

IIRC, the (mostly insufferable) NNGroup determined the feeling of speeding up when using keyboard shortcuts (vs mousing) was mostly an illusion (at least for WIMP UIs).

And to your point, if keyboard (or whatever) helps gain and maintain flow state, I'd score that a win.

(Further, is a placebo that works, even when you know it's just a placebo, still a placebo? Hmmm.)

This. Right here.

I can write code just fine in ed. (Don't ask...) However, it saps away my will to live in about 15-30 minutes max.

I am probably faster in vim (or Sublime, or VS.Code, or...), but not by much. But it's a much more enjoyable experience, and I can devote some extra mental space to the problem at hand instead of the tool.

I’ve had or witnessed many talking-past-each-other arguments between management and devs and the realization I’ve had is that They - and sometimes We - are fixated on hours and not energy.

If you think in hours, then you should be able to schedule any two 20 hour tasks to a single engineer in the same week. But if those tasks require high vigilance, the developers will say no and refuse to budge. Fuck your math, I won’t agree to those.

That balking could be due to deep work, vigilance due to foot guns, or coordinating a task that takes 8 hours spread over three days with lots of hurry up and wait steps. I can’t and won’t work on three of those at a time, and every time I forget and volunteer myself for that shitshow I/we pay the price.

You want a trivial task to fill in the holes, and Gantt charts don’t know that.

I sometimes wonder how new users of some of this tech get going with it... Example: I have been a vim user for geez, decades. I just read this article and thought "wow, I know I have heard of neo-vim, never used it, maybe I should change". So I searched the fine web for neo-vim sysadmin plugins. I came across this [0].

OK, wow, now I have the same thoughts as the author. How long would it take just to look at say the ColorScheme section or Utility section of that document?? It really makes me pause and think "too many choices lead to larger levels of inertia against change". I know I can just go and grab a neo-vim and look up a specific plugin, but it does make me wonder if we are overwhelming the tech/programming community with choices.

[0] https://github.com/rockerBOO/awesome-neovim

Depends on the tool. Text editing gets improvements here and there but overall it doesn't change much. I do try out new things here and there, in the long term some tools and workflows survive an OS reinstall and some do not.

> Migrating from Vim to Neovim looked like it would take almost as much time as migrating from NEdit to Vim, but with many fewer benefits

This puzzles me a bit, for me the biggest obstacle was looking up how to make NeoVim use the .vimrc file and figuring out how to exit terminal mode.

The biggest annoyance I have faced so far is also causing issues in Vim: NeoVim adopted a configuration for .zig files that auto-formats the entire file every time it gets saved, without asking. On top of that it automatically invokes the zig compiler to show bright orange compiler error messages in the status bar, again without asking. Vim seems to have gotten the same treatment but the call to zig fmt fails, resulting in an error message each time I save a .zig file. Before that I'd only gotten issues like that from optional third-party plugins.

It's disappointing, so far I've been using (Neo)Vim exactly because it was one of the rare tools that don't do this kind of thing.

A timely topic, for me in particular, as I'm currently in the throes of a developing woodwork hobby. Specifically, I've spent a bit of time (and money) in recent days and weeks going down the extensive rabbit-hole of tool sharpening.

One could say there are many lessons analogous to life, and digital work, in the process (and probably even more that aren't).

I think one of the key principles is that sharpening symbolises the leveraging of past-developed wisdom - similar to the 'standing on the shoulders of giants' idea. It's not me who discovered that rubbing my blade over a succession of grits [no, not the eating kind, USA-ians!] gives me the means to get a lot more done with my time. But it'd be my peril, my loss, were I to ignore or trivialise that key wisdom provided by others.

The moment you spend more time tinkering tools instead of doing work, you obviously lost control. But even that’s too much. I believe you shouldn’t be spending 10% of your daily work time on tinkering tools. That’s an hour out of an 8h working day.

You shouldn't, but its still a pretty fun thing to do for procrastinating.

You and I have very different notions of what counts as "fun". :)

Sharp tools mean that for the 7 remaining hours I get 7 units of work done. Dull tools get me 3 units of work done.

7ps - Proper Planning and Preparation Prevents Piss Poor Performance

> Sharp tools mean that for the 7 remaining hours I get 7 units of work done. Dull tools get me 3 units of work done.

That's not how it works. You get the same amount of work done, but with less precision, a less good finish and more errors (and more accidents). Because you need more power to force the dull blade (or whatever) into/through the wood (or whatever).

> You get the same amount of work done

Not necessarily. I work with a lot of legacy spaghetti code with many layers of unnecessary abstractions which requires navigating through the code a _lot_. I have set up my IDE and toolset to make it easy and fast to navigate through the mess. Whereas some of my coworkers haven’t and getting to the same result takes much longer. This is just one way that tools can actually speed up your work to get more done.

I was talking about actual woodworking hand tools.

I’ve done a fair amount of car work. The analogy makes sense for me when I think about workspace habits. There was a time where I’d grab a wrench and then leave it wherever when I was done turning that one bolt. It might have been on the ground next to my right hand, on my belly, or on the bumper.

That changed after I spent far too many frustrating moments looking for a 12 mm wrench and losing my train of thought to backtrack my steps.

I hit a stride when I learned to organize my tools and keep them organized between tasks. It’s still obvious to me now because I have friends who don’t work this way, and I feel overwhelmed when I go into their garage or kitchen and all work surfaces are covered in tools, knives, unopened boxes, etc. I need to actively expand mental energy to ignore those things.

  I also think that there is a place for sharpening one’s tools just for its own sake

Everyone forgets this. I use Vim, GNOME, Arch and other less common toolchains because they are fun and hackable. I KNOW they make things harder for me, but I also program and design for a living and it is my primary vocation. I BETTER have fun using my tools.

That's probably a better way to think about it, rather than everyone having to spend so much time justifying their choice of tools, and feeling guilty if they don't spend hours constantly chasing slightly improved efficiency like a robot.

I would say as often as the tools somehow annoy you and stop you from effectively focusing on using them. There is always a threshold, but at point you are over it. You should at least take a look how to fix it.

What actually works is "as soon as you start thinking whether you should sharpen them or not".

Switching tools comes with a pretty hefty price tag. I only really consider it if my current tools are no longer effective enough in some way.

Software is written by teams. It’s not enough to introduce a new tool or strategy, you also need to find the will to eliminate an old tool or process. Otherwise you ramp up the knowledge required to run the system, and one day you realize that employees with 3, 6, 9 months on the job are still basically useless, because they only know a fraction of what is needed to operate independently. Once you go that far you have to slow down first before reversing course. And now you have employees that cannot get promoted for years, and they won’t stick around for that (and those in power won’t leave).

Reply on news.ycombinator.com