Principle

Provide the right environment for highly demanding tasks.

Result

Noticing then solving inefficiencies

Write down inefficiencies e.g. repetitive chores, mistakes, ... per CognitiveEnvironments and Tools as they happen, then delegate some time in CognitiveEnvironments#TasksByEfficiency dedicate an amount of time to review then fix the most impacting ones e.g. 15min per day at the end of the morning to review, eventually using LazyImplementation but not necessarily as automation is not cheap.

It should be easy to update an existing inefficiency in order to see how frequently is it encountered.

Pay attention not to escape into local optimization but not maintain the big picture view. The goal is not to do constant yak shaving and procrastinate the hard problems. Consider also the running goals (or traveling goals) from a versionning or branching perspective, is it equivalent to a lack of proper merging discipline?

Dedicated sections (e.g. from [[#InefficienciesStart]] to [[#InefficienciesEnd]] can be considered in order to facilitate management. Ideally each would have a date and an estimated impact (from 0 to 1 excluded, 1 being completely stopping work to 0 being not actually inefficient). The date would allow to see which one have been there for the longest time and thus how they compound.

Consider PersonalUX#ToolSelectionProposal and in particular that one could require any new tool to be controllable (e.g. via an API or scripting feature or hooks) by the currently used tools and vice versa, to be able to control the other tools via the new tool.

Inspired by

‪7 Habits For Effective Text Editing 2.0 as seen in Vi and much later a brief remark on IRC regarding "extreme tweaking".

Tasks By Efficiency

  • use each task with its associated CognitiveEnvironments page as a building block of larger event, e.g. a day or a full project
    • those should match ones own patterns of efficiency
      • e.g. creative activity (programming, writing, synthesis, ...) in the morning, acquisition of information in the early afternoon (e.g. memory recalls, reading, watching, ...), social interaction in the late afternoon (e.g. social networking, ...)
        • acquisition of information should include feeds e.g. tagged with BrainSelfManagement and reflect justified Needs
      • overall it seems to be "output" then "input" then social, could be interesting to tag tasks using those categories
    • currently done via Irssi with cron.pl using .irssi/cron.save
      • available at Contact#Timetable and with (:timetable:)
      • improvements
        • produce logs from commands via encapsulation to provide data for analysis
        • allow to cancel for the rest of the day (cf /jobdisable and /jobenable)
          • done manually by dropping all jobs
        • bump the next task for X min
          • while maintaining proportion, overall this should be define as such so that if there is just 2 hours available during the day it would be allocated in the same way (except during temporary rush period)
            • e.g. morning-cron.save and afternoon-cron.save now available as /morning-only-cron, /afternoon-only-cron and /fullday-cron
        • allow access to generalist website like Wikipedia but for a certain amount of time, e.g. 30min during the creative/production section in order to delay tasks that would require longer learning period to the consummation/learning section

(:timetable:)

Inspired by

Applying Cognition#OptimalLearningClosure by removing Irssi notifications, switching Screen to a window opened on Cognition#BrainHijackers but desiring to expand it to Programming.

See also

General techniques and methods

To do

  • more tasks requiring specific cognitive environment
  • Template
    • with (:include CognitiveEnvironments/CognitiveEnvironments#GeneralStart#GeneralEnd:)
  • dedicated skin rather than print
  • electronic equivalent, open hardware helmet with FLOSS software
  • leverage Path:/pub/currenttask
  • in most situations let others know (directly or passively) what task you are conducting
    • so that they can act accordingly rather than having to change your process in the middle of it
  • facilitate recurrent tasks
    1. iteration 0 : do the task manually
    2. iterations 1-10 : do it manually but explicit the process as a serie of steps
    3. iterations 10-100 : find tools to delegate the most important steps to
    4. iterations 100+ : implement an algorithm to supports the maximum amount of steps automatically
      1. eventually optimize it, refactor it, ... while keeping in mind diminishing returns
    • lazy implementation, instead of evaluating the value on an as-needed basis, ones codes only when required but yet without wasting the already done thought process
      • start the script with the naive version, write under it your cool idea and if the need is there, take the time to implement it
      • coherent with "the wiki way" of improving one edit at a time
    • see also Programming#Refactoring and the more general Programming
    • consider adding to OwnConcepts
    • since early 2012 used as a 80% time dedicated to task progress and 20% maximum for automation
      • usually starting the 20% only after several manual iterations
  • multiple display vs unified workflow
    • multiple display in general is to be avoided except in comparison situations, the workflow should remain linear with a single point of focus
      • everything that facilitates fast feedback should run in the background
      • comparisons of multiple aspects should be displayed together
        • e.g. tests+specs, stats+code, debug+run, doc+code, diffs, ...
    • this applies in particular to multiple monitors but even window management should support such principle