post: Focus by Automation

Last-minute rename, clean-up and publish.

site/posts/2024-03-19-the-cost-of-distractions.org → site/posts/2024-03-19-focus-by-automation.org

@@ -1,7 +1,7 @@
 ---
-title: The Cost of Distraction
-preview: true
-tags: Automation, Programming, Vim
+title: Focus by Automation
+preview: false
+tags: Automation, Programming, Emacs, Vim
 toc: 1
 ---
 
@@ -27,7 +27,7 @@ programming problems are undeniably "automation". However, automation in its
 purest sense isn't reserved for silicate or metallic machinery only. Biology
 automates through instinct and practice.
 
-In practice though what this means to me is that I relatively often invest a
+What this means to me in practice is that I relatively often invest a
 significant amount of time learning new things, practicing various skills, and
 iterating on my workflows. Not necessarily to save on some imaginary "net sum of
 time spent"[fn:1] – although Randall Munroe of ~XKCD~ has [[https://xkcd.com/1205/][shared]] some [[https://xkcd.com/1319/][thoughts]]
@@ -75,7 +75,7 @@ a post of its own. That became [[file:2023-09-19-programming-is-hard.org][Progra
 then I guess I forgot all about this one.
 #+end_notes
 
-* Distractions
+* Distractions ⚡
 
 Distractions; the arch enemy of every coder. Distractions break our focus by
 ripping us out of our flow states. It doesn't help that programming environments
@@ -96,12 +96,13 @@ or something in your surroundings. It may be somebody "just popping over to ask
 a question" or some meeting looming on the horizon about to evacuate you from
 your warm and cozy "flow zone".
 
-Some less obvious forms of distractions are phenomena I've been aware of, but
-not consciously considered distractions until recent years. Maybe they've
-previously felt like a natural part of "work" or I've never stopped to consider
-how they may negatively affect my productivity or cognitive ability. However,
-tiny inconveniences can add up to make solving issues more difficult than it
-needs to.
+In recent years I've also grown more conscious of less obvious forms of
+distractions. Things like small papercuts and annoyances which I previously
+might have accepted simply as a natural part of "work". By not acknowledging
+these minor nuisances as distractions I've never stopped to consider how they
+may negatively affect my productivity or cognitive ability. However, tiny
+inconveniences can add up to make solving issues more difficult than it needs
+to.
 
 Much can be done to reduce the distractions within an organization, but
 introducing transformational change can be hard for an individual alone.
@@ -137,8 +138,8 @@ I must admit I have a lot of issues with ~emacs~, but the way some of these
 to find anything matching what I'm after.
 
 There is A LOT of literature on personal organization, so I don't want to spend
-too much time on this topic. Let's move on to another critical tool in the
-battle against distractions: mastery.
+too much time on this topic in this post. Let's move on to another critical tool
+in the battle against distractions: mastery.
 
 * The value of mastery 🧙
 
@@ -148,12 +149,11 @@ also come to realize that another trait of practice and mastery is how
 automating our skill through practice helps us cancel out distractions in order
 to maintain focus.
 
-Mastery of our tools is important as it allows our brains to focus on the task
-at hand. If we are forced to spend a significant amount of our brain power
-learning programming language syntax, editor bindings or APIs then we have less
-mental energy to spend on solving /actual/ problems. Attacking complexity on
-multiple fronts also increases context switch overhead and leads to loss of
-focus.
+Mastering our tools is important as it allows our brains to focus on the task at
+hand. If we are forced to spend a significant amount of our brain power learning
+programming language syntax, editor bindings or APIs then we have less mental
+energy to spend on solving /actual/ problems. Battling complexity on multiple
+fronts increases cognitive load and often a loss of focus.
 
 A dancer who doesn't know the basic moves of a dance style will have great
 trouble connecting motions in the choreography while maintaining rhythm and
@@ -162,43 +162,44 @@ interpreting compiler errors will have a harder time constructing a mental model
 of the problem she's solving.
 
 But we do not necessary have to become specialists to become effective. In fact,
-trying to become a proper expert in more than a handful of fields is a fools
+becoming and staying a proper expert in more than a handful of fields is a fools
 errand in modern software development. Ecosystems evolve too quickly, new tools
 and practices come and go. Not to mention the looming paradigm shift of
 artificial intelligence and how it might render significant aspects of
 conventional programming obsolete[fn:2].
 
 What I find useful is to learn enough about a wide variety of topics to build a
-basic intuition to know when specific technologies or methodologies will help
-solve the problems we're faced with. Expertise will gradually come from this
-somewhat organically[fn:3].
-
-Practice and repetition is crucial to become a master in just about anything.
-Just as a musician spends time with her instrument to improve, programmers who
-spend time with their "tech stacks", editors and tools will most likely grow to
-become very skillful at some point. And just as a musician is likely to butcher
-an unfamiliar instrument, a programmer dropped into development environments new
-to them will most definitely cause some initial regression to their
-productivity.
-
-This is normal, and is also the way we learn. Experts weren't born experts. And
-even though talent or determination allow some to progress faster than others
-nobody who achieve mastery within any discipline will admit to not having worked
-hard, or for a long time to acquire the skill they possess. If we wish to follow
-in their footsteps then we must be patient and humble, and be prepared to step
-outside of our comfort zone.
-
-Whether you're a specialist or a generalist I believe software development is
-quite unique in the way many skills are transferable across environments. Some
-skills invested transcend their technologies almost entirely due to their
-pervasiveness or general applicability.
+basic intuition for when specific technologies or methodologies will help solve
+the problems we're faced with. You'll then eventually start picking out what
+matters to you and your expertise will grow somewhat organically[fn:3]. Also try
+to surround yourself with smart people complementing your own abilities.
+
+Practice and repetition is crucial to become a master in just about anything. A
+musician spends time with her instrument to improve, programmers spend time with
+their "tech stacks", editors and tools. It's a matter of starting somewhere.
+Experts weren't born experts. And even though talent or determination allow some
+to progress faster than others nobody who achieve mastery within any discipline
+will admit to not having worked hard, or for a long time to acquire the skill
+they possess.
+
+Just as a musician is likely to butcher an unfamiliar instrument, a programmer
+dropped into a new development environment will most definitely experience some
+initial regression in their productivity. This is normal, but it is also the way
+we learn. The difficulty is knowing (or choosing) what to learn, and when. In
+the middle of a high-stakes project is probably not the right time to pick up a
+new language or framework.
+
+Whether you consider yourself a specialist or a generalist I believe software
+development is quite unique in the way many skills are transferable across
+environments. Some skills invested transcend their technologies almost entirely
+due to their pervasiveness or general applicability.
 
 [fn:2] Nah, don't worry. You'll be fine!
 
-[fn:3] Don't get me wrong, I've also studied and geeked out on a bunch of
-things as well.
+[fn:3] Don't get me wrong. I find it very important to combine theoretical
+studying with practice and applying knowledge.
 
-* Vim bindings ⌨
+** Typing speed
 
 Muscle memory and habits are both important abilities of the body and mind to
 increase our efficiency and reduce our cognitive load. Making things more
@@ -223,22 +224,24 @@ interpreter and executing it.
 I would say it's worth putting effort into improving your typing. And while
 you're at it, why not also try to improve /how/ you type?
 
-Let's take [[https://www.vim.org/][vim]] and modal editing as an example.
+Let's take ~vi/vim~ and modal editing as an example.
 
-In ~vim~ there are keybindings bound to operations which operate on various
-textual structures. I call them structures because there's really not that much
-common in between them. The bindings may operate on "bodies" of text like
-letters, words, sentences or paragraphs. Or they operate on pairs of quotes,
-parentheses and brackets. They can work on locations like the beginning and end
-of a buffer. Or even metadata not represented in the buffer itself, like the
-location of compilation errors from an external tool or spelling errors from a
-spell checker.
+** Vim bindings
+
+In [[https://neovim.io/][(neo)]][[https://www.vim.org/][vim]] there are keybindings bound to operations which operate on various
+textual structures.
+
+Bindings may operate on "bodies" of text like letters, words, sentences or
+paragraphs. Or they operate on pairs of quotes, parentheses and brackets. They
+can work on locations like the beginning and end of a buffer. Or even metadata
+not represented in the buffer itself, like the location of compilation errors
+from an external tool or spelling errors from a spell checker.
 
 Once ~vim~ motions are internalized it's amazing how efficient it feels to
 "delete all word" (~daw~) or "change in paragraph" (~cip~) without breaking a
-sweat. The great strength and power of ~vim~ motion bindings come from how a
-handful of general-purpose operations translate across different types of text,
-from prose to any style of programming and markup languages.
+sweat. The great strength and power of ~vim~ motion bindings come from how a few
+handfuls of general-purpose operations translate across different types of
+textual motions, from prose to any style of programming and markup languages.
 
 #+begin_notes
 Editors like [[https://github.com/mawww/kakoune][Kakoune]] and [[https://github.com/helix-editor/helix][Helix]] attempt to improve further on this concept. I
@@ -253,26 +256,44 @@ exactly people benefit from it. Personally I'm certain the time I invested into
 learning motion bindings and compound operations many years ago has reaped
 dividends way past the initial investment.
 
+** Optimize the common paths
+
 But how? By letting me type faster? What has typing and ~vim~ motions to do with
 avoiding distractions?
 
 Everything!
 
+The keyboard is still my main interface to the computer. As long as it continues
+to be it matters to me to wield it well.
+
+Similarly to ~vim~ motions most mainstream ~$SHELL~ prompts default to
+~emacs~-style ~readline~ bindings[fn:4]. To me that was motivation enough to put
+some effort into internalize the most common ~readline~ keyboard bindings on the
+CLI (for ~emacs~ users this is trivial).
+
+Raise your hand if you know how to undo edit operations in ~readline~ ✋ (yes,
+~C-/~ and ~C-u C-/~ works in your prompt!)
+
 Programming is littered with micro-distractions, remember? Not only do you
 increase your efficiency at typing out actual programs by learning effective
 text navigation and manipulation (as well as text generation through snippets
 and generative A.I.). You also do so while sparing your brain from having to
 think about these trivial "problems" and road-blocks.
 
+This is just as true /in/ your editor as outside of it.
+
 It's not uncommon to find myself thinking about my /next/ steps while doing some
-other thing like text navigation or manipulation using ~vim~ keybindings.
-They're so ingrained in muscle memory that I more often that not think about
-/what/ I need to do, not /how/. It just happens.
+other thing like text navigation or manipulation using either ~vim~ or
+~readline~ keybindings. By now they're so ingrained in muscle memory that I more
+often that not think about /what/ I need to do, not /how/. It just happens.
 
 And let me say that the point of this section is not to boast or rave about
-~vim~ bindings. The point is that by learning your tools really well they
-eventually get out of your way and you're free to tackle the actual problems
-you're faced with.
+~vim~ and ~emacs~ bindings. The point is that by learning your tools really well
+they eventually get out of your way and you're free to tackle the actual
+problems you're faced with. It's even better if these skills are applicable in a
+wide variety of applications and environments – try to stick to defaults.
+
+[fn:4] Many shells also support ~vi~ mode bindings, but it's rarely the default.
 
 * Braaains 🧠
 
@@ -282,6 +303,12 @@ mental exercise, and like physical exercise learning can be very exhausting. The
 same goes for problem solving – it's our brains applying our existing knowledge
 in order to achieve something new.
 
+Knowing when to invest time into learning, automation or optimization is not
+trivial. Done prematurely there's the risk of sinking costs into efforts that
+won't pay off, yet stubbornly sticking to old ways could be impeding future
+efficiency. A big part of maturing as a software developer is knowing (or more
+likely, /sensing/) when the time is right for you.
+
 The biggest bottleneck of software development is still the (human) brain. It's
 a precious resource, but it can only do so much and distractions greatly reduce
 its capacity.
@@ -294,58 +321,4 @@ gracefully recover from distractions when they occur.
 
 Now, what was I doing again...?
 
-* Cuts ✂ :noexport:
-
-Programming is not hard because
-
-Programming is uninuitive in the sense that code written to solve specific
-issues might end up having no internal resemblance to the problems it's intended
-to solv
-
-This, of course, isn't news to a programmer.
-
-It's quite helpful to write code which closely resembles the problem domain.
-
-Software development sits in a unique blend of disciplines.
-
-As somebody who programs for a living (and sometimes for recreation) I tend to
-think that my primary responsibility is that of being a problem solver[fn:4].
-
-The code that I write is a means to an end.
-
-Our responsibility is to meet real-life requirements by applying our knowledge
-of technology and our ability to evolve technology to construct solutions for
-automating or offloading tasks to computers.
-
-Programming is hard. In fact, nothing in /my/ life comes close to rivaling the
-mental energy I expend on a daily basis thinking about programming-related
-tasks. Being a programmer by trade it's not surprising that I /would/ spend a
-significant part of my time working on computer programs, but what I'm trying to
-say is that this "work" consumes much of my mental ability.
-
-In this sense programming is very much brain-bound. Our brains are a very finite
-resource, and much of the perceived complexity of software development has to do
-directly with managing complexity within this constraint.
-
-Through the years I've invested quite a bit of time learning various kinds of
-tools and incorporating different types of workflows into my daily habits. Quite
-a few of these probably has a questionable ROI[fn:5]. I'm not very concerned
-about this imaginary "net positive" approach to why learning tools and processes
-can be useful.
-
-First of all it's important to determine what /is/ this "net positive" metric?
-Is it seconds, minutes or hours saved on a particular task? Is it improved
-quality of work? Is it ....?
-
-To me, I think one of the most important metrics of measuring whether or not
-time invested into a tool is how it helps me avoid disruptions to my flow – when
-I'm programming "in the zone".
-
-[fn:4] Disregarding the fact that creating software perhaps more often than not
-lead to a whole new set of problems, including fixing bugs, maintenance,
-operations, and everything else that goes with providing software services to
-the masses.
-
-[fn:5] Return on Investment
-
 * Footnotes