4 ms·
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
by onetimeuse92304 3y ago
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.
- jbstack 3y agoI 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.
- specialist 3y agoExactly 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.)
- groby_b 3y agoThis. 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.
- hinkley 3y agoI’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.