Categories: business

RSS - Atom - Subscribe via email

Emacs tweaks: Choosing what to hack on

Posted: - Modified: | emacs, life, productivity

[2024-01-22 Mon]: How do you combat being overwhelmed by choice? is somewhat relevant. I particularly like this comment which talks about delaying the decision to see if it still makes sense.

Is it the Emacs lifecycle that you tweak your config for few months and then you live off of fat of the land for >4 years? My Emacs config is a Org-tangle spaghetti that I touch only if I want to set some more sane config variable.

@xgqt@emacs.ch

This got me thinking about how tweaking my config fits in with other things I want to do–how I choose what to hack on and for how long.

Text from sketch

Choosing what to hack on - 2024-01-16-01

When it comes to computer work, I can usually choose what to do.

Idea -> Test

XKCD on automation: time to automate vs frequency x time saved

I focus more on what I'll enjoy (both the destination and the journey)

  1. How can I make this better?
  2. What's the smallest step I can take? What can I fit in 15-30 minutes?
  3. What's nearby?
    • Relevant functions or packages
    • Next steps, possibilities
  4. What kinds of notes can I leave for myself or others?
  5. like desire paths: where, what size
  6. or like a river wearing down rocks

Sometimes when I chat with other people about automation, this XKCD chart about Is It Worth the Time? comes up.

I realized that this isn't quite how I consider things. I'm lucky in that when it comes to computer things, I get to choose most of the things I spend my time on. My consulting clients have very long wishlists that I pick from based on interests and priority, and I play with Emacs for fun.

Drawing of a task sandwich with Emacs tweaking, the actual task, and blog posts and comments

Because I enjoy tinkering around with Emacs, I often build a little Emacs hacking into my tasks. 15 or 20 minutes of exploring an idea can make it even more fun to do the actual task it's supposed to help with because then I want to test it out. Then after the task is done, I get to write about it. It's like making a little task sandwich with really nice bread. This is also a little related to sharpening the saw, which is pretty fun in Emacs. (Vim people do it too!)

These little changes add up over time, making things even more enjoyable. It's a little like the way desire paths show where people actually walk between buildings and give a sense of how much they are used, or how rivers smooth down the edges of stones. The easier I make something, the more likely I am to do it, and the more I'll get to enjoy the results of my code. It's a little like the Igors described in this essay.

When I think about something I might tweak about my Emacs configuration, I usually consider the following:

1. How can I make this better?

I like looking for ways to reduce manual work or looking-up. I tend to have a hard time with tedious, repetitive tasks. I also keep an eye out for things I've been meaning to learn.

2. What's the smallest step I can take? What can I fit in 15-30 minutes?

Small steps make it easy to squeeze in things here and there. I know my brain's going to suggest half a dozen things along the way, so it helps to start as small as possible and capture most of the other things in my inbox for later. That way, I can get to experience the benefits right away without feeling lost.

Another advantage of picking really small tasks and using Org Mode to capture the rest of the ideas is that I can try to avoid the Ovsiankina effect.1 I spend most of my day taking care of our 7-year-old, so I squeeze in my focused-time tasks early in the morning before she wakes up. Sometimes I have little opportunities to work on things throughout the day, like when she wants to read a book or watch a video. She might do that for 15-30 minutes before wanting to connect again. If I pick the wrong-sized task or I don't dump enough rough notes into my inbox so that I can get the open loops out of my head and trust that I can pick things up again, the unfinished part pulls on my brain and makes it harder to enjoy time with her. Then I get tempted to let her binge-watch Minecraft or Rubik's cube videos2 so that I can finish a thought, which doesn't quite feel like good parenting.

Lastly, I don't usually understand enough about my needs to build something complex from the start. Trying things out helps me discover more about what's possible and what I want.

3. What's nearby?

Thanks to Emacs's amazing community, there are usually relevant functions or packages that I can borrow code from. I mostly have a sense of things from the blog posts and forum threads that cross my radar because of Emacs News, and I should probably get used to skimming the descriptions in the "New packages" list because that can help me find even more things.

When coming up with possible approaches, I also sometimes think about other related ideas I've had before. Filing those ideas into the appropriate subtrees in my Org files sometimes helps me come across them again. If I can take a small step that also gets me closer to one of those ideas, that's handy.

I also like to think about next steps and possibilities. For example, even if I spend an hour or two learning more about data visualization with Org Mode and plotting, that's something I can use for other things someday. This works pretty well with keeping things small, too, since small parts can be combined in surprisingly interesting ways.

Let me try to trace through a web of related features so I can give you a sense of how this all works in teeny tiny steps.

G defun defun my-include:...?from-regexp=...&to-regexp... my-include:...?from-regexp=...&to-regexp... defun->my-include:...?from-regexp=...&to-regexp... my details my details defun->my details defvar defvar defun->defvar emacsconf-el emacsconf-el defun->emacsconf-el context context defun->context my-include:...?name= my-include:...?name= my-include:...?from-regexp=...&to-regexp...->my-include:...?name= :summary :summary my details->:summary defun-open defun-open :summary->defun-open web links web links emacsconf-el->web links Embark Embark :comments both :comments both Embark->:comments both QR code QR code Embark->QR code :comments both->context web links->Embark

  • defun: I often wanted to write about a specific function, so I wrote some code to find the function definition and copy it into my export post hidden inside a details tag with the first line of the docstring as the summary. 2023-01-02
  • my-include:...?from-regexp=...&to-regexp...: Sometimes I wanted to write about longer pieces of code. I wanted to include code without repeating myself. The regular #+INCLUDE can handle line numbers or headings, but neither of them worked for the Elisp files I referred to since the line numbers kept changing as I edited the code above it and it wasn't an Org Mode file. I made my own custom link so I could specify a start and end regexp. 2023-01-08
  • my_details: I wanted to put the code in a details element so that it could be collapsible. I made an org-special-blocks template for it. special-blocks
  • :summary: For Org source blocks, I wanted to be able to do that kind of collapsible block by just adding a :summary attribute. 2023-01-27
  • defun-open: I wanted to sometimes be able to keep the function definition expanded. 2023-09-12
  • emacsconf-el: Since I was writing about a lot of EmacsConf functions in preparation for my presentation, I wanted a quick way to link to the files in the web-based repository. 2023-09-12
  • defvar: Made sense to include variable definitions too.
  • web links: The emacsconf-el links were so useful, I wanted to be able to use that type of link for other projects as well. 2024-01-07
  • Embark: I wanted to be able to copy the final URL from a custom link at point, so I used Embark. 2024-01
  • QR code: I started livestreaming again, so I wanted a quick way for viewers to get the URL of something without waiting for stream notes. 2024-01-10
  • :comments both: While scanning Reddit to find links for Emacs News, I learned about :comments both and how that includes references to the Babel file that tangled the code. 2024-01-07
  • context: Now that it was easy to link to the web version of an Emacs Lisp file, I thought it might be fun to be able to automatically include a context link by passing link=1. I also wanted to be able to navigate to the Org source code for a tangled function. 2024-01-11
  • my-include:...?name=...: I wanted to be able to refer to Org Babel source blocks by name.
I promise it's all connected. (Pepe Silva meme)

In the course of writing this blog post, I learned how to use URLs in Graphviz, learned how to include inline HTML for export with @@html:...@@, used position: sticky, figured out how to highlight the SVG using JS, used CSS to make a note that should only show up in RSS feeds, and submitted a pull request for meme.el that was merged. And now I want to figure out sidenotes or at least footnotes that don't assume they're the only footnotes on the page… This is just how my brain likes to do things. (Oooh, shiny!)

4. What kinds of notes can I leave for myself or others?

I might take years before revisiting the same topic, so good notes can pay off a lot. Also, when I share what I've been working on, sometimes people e-mail me or comment suggesting other things that are nearby, which is a lot of fun. The ideas I come up with are probably too weird to exactly line up with other people's interests, but who knows, maybe they're close enough to what other people work on that they can save people time or spark more ideas.

Inspired by Mats Lidell's EmacsConf 2023 talk on writing test cases, I've been working on writing occasional tests, too, especially when I'm writing a small, function to calculate or format something. That's a good way of sketching out how I want a function to behave so that I can see examples of it when I revisit the code. Tests also mean that if I change things, I don't have to worry too much about breaking important behaviours.

Ideas for next steps

How can I get even better at this?

  • Popping the stack (untangling interruptions and ideas): When I let myself get distracted by a cool sub-idea, I sometimes have a hard time backing up. I can get back into the habit of clocking time and practise using my org-capture template for interrupting task so that I can use C-u with C-c j (my binding for org-clock-goto) to jump to a recently-clocked task.
  • Braindumps can help me use non-computer time to flesh out notes for things I'm working on or ideas for next steps.
  • If I skim the descriptions of new packages in Emacs News (maybe even the READMEs instead of just the one-liners), I'll probably retain a brief sense of what's out there and what things are called.
  • Vector search across package descriptions and function docstrings could be an even more powerful way to discover things that are close to something I want to do.
  • Using elisp-demos to add more examples to functions can help me look up things I frequently use but don't remember.
  • Figuring out more modern IDE features like refactoring support, on-the-fly error checking, and code navigation could help me code faster.

So that's how I tinker with Emacs for fun: start with something that mostly works, keep an eye out for opportunities to make things better, use tinkering as a way to make doing things more fun, look for things that are nearby, and

Footnotes:

1

I used to think this was the Zeigarnik effect, but it turns out the Zeigarnik effect is about remembering incomplete tasks versus completed tasks, while the Ovsiankina effect is more about intrusive thoughts and wanting to get back to that incomplete task.

2

At the moment, she likes Eyecraftmc and J Perm.

View org source for this post

Quick thoughts on leadership, impact, and finding my own path

| business, leadership, learning, purpose, reflection

I was talking to a friend about leadership, succession, and impact. In particular, my friend was curious about how to grow more leaders. I realized some things about how my parents made big differences and about how I want to grow.

Succession is hard. Big companies spend millions on leadership programs, have huge, motivated talent pools to draw on, and even turn to external recruitment, and it's still uncommon to have a successful transition or a long-lived company. It's even tougher in the nonprofit and volunteer worlds.

I wonder if going sideways can help work around the succession challenge. Instead of hoping for the right intersection of same time, same place, same Bat channel (an interested, capable, available potential leader turning up when you want to start grooming one and sticking around until the right time), what about the franchising approach instead?

I realized that this is one of the things my parents did, and that's how they managed to do so much. They didn't count on any one initiative staying around for the long term. My dad probably would have gotten impatient and bored anyway. Instead, they got the hang of quickly starting things up, and they inspired people to start similar efforts. After the first few projects, happy sponsors and relationships made the next ones easier and easier. My dad could just share a crazy idea on Facebook and people would sign up to help make it happen. Professionally, my parents cared about teaching both the art and the business of photography, and having workshops open even to active competitors.

This approach is probably out of scope from most leadership programs that focus on succession planning because they assume you need a specific thing to continue, but franchising is the closest business analogy, I think. It might be a good way to increase impact through a wider reach. It could be like:

  • Getting more out of the stuff you're already doing: My dad was media-savvy. He could imagine the pictures and news articles that would come out of a project, and he was great at lining those up. Something similar (or partnering with someone who thinks about that sort of stuff) could increase the visibility and impact of things you're already doing some making people feel good about the projects too.
  • Getting better at sharing the cool stuff you're doing and the initiatives you're involved in: pictures and stories on social media could let people find out about stuff, explore things you're into, get updates, etc. Similar to the previous point, but more personal.
  • Accelerating your startup for ideas: people to talk to, channels for sharing ideas, ways to get people involved, templates, etc.
  • Getting better at sharing lessons learned, questions, and artifacts
  • Automating, simplifying and documenting processes so that people with less experience can do better work: Can be very useful for both your initiatives and other people's, and it's good for both direct succession and franchising. This is definitely my focus, and it's awesome for expanding reach over space and time (even without active attention). My mom focuses on this too, although she often struggles with adoption. The E-Myth book might be relevant here.

Figuring out swarms might be an interesting challenge: how to quickly gather people around a particular project, and how to help other people with their own. There's a lot that to practice even without a candidate successor, so that might be one way to keep growing.

At the moment, I'm focusing on:

  • automating/simplifying/documenting: Perfect timing! I need to make things simple enough so that a child can do it, and there happens to be one handy for testing. I also personally benefit from automating and simplifying things enough to fit into the snippets of discretionary time I have, and documenting things so that I can declutter my brain and make the most of scattered moments.
  • getting better at sharing lessons learned, questions, and artifacts: Hooray for blogging! I'm getting better at writing on my phone while A- sleeps on top of me (like right now), and I'll figure out how to mix drawing back in, too. I'm probably never going to feel comfortable using the “expert” voice. I like the “Here's what I'm figuring out, and here's what I'm thinking about next” sort of approach. There are so many ways forward, and it's fun to think of everything as a grand experiment.

We were talking about the 2×2 matrix of size of impact versus number of people affected. My friend said many people focus on the “big impact, lots of people” quadrant. I think I like the “small impact, few people” quadrant, which perfectly characterizes things like my Emacs stuff and my consulting. I like small fixes and improvements. I scale up by trying to help things stay fixed/improved and available even when I'm not actively thinking about them, which is why coding and writing fit me well. If I can get even better at making and sharing those little improvements, and making them findable when other people want them, that sounds like a good path for growing. I also like connecting the dots between ideas, which is another example of a small contribution that can have a larger effect.

The long-term impact could be mostly about the ripples from people I've helped (like the way I get to learn more about cool things to do with Emacs by people who tell me I helped them get curious about it a long time ago! :) ) and maybe maybe maybe someday, books worthy of being part of the Great Conversation / archive of human knowledge.

I probably won't do anything as awesome as my dad's advocacies, but I think this path of sharing little ideas, experiments, and lessons learned – this path could work for me. :) If it happens to resonate with you and you want to pass along lessons learned or share the things you're figuring out, that would be great!

Making my to-do list more detailed; process versus outcome

Posted: - Modified: | emacs, org, productivity

Some time ago, I wrote some code to make it easier for me to update my web-based Quantified Awesome time logs from Org Mode in Emacs, clocking into specific tasks or quickly selecting routine tasks with a few keyboard shortcuts. I've been refining my/org-clock-in-and-track, my/org-clock-in-and-track-by-name, and defhydra my/quantified-hydra, and I've been getting used to the new workflow. The more I smooth out the workflow, the more possibilities open up. Because I've set it up to prompt me for a time estimate before I start a task, I can see a running clock and timer in my modeline, and Emacs lets me know if I'm running over my estimate. Come to think of it, this makes it even easier to track at the detailed task level than to track at just the medium-level categories available through my web or mobile shortcuts. (If you're curious about the Emacs Lisp code, you can check out my Emacs configuration.)

I've also been sorting out my workflow for quickly adding tasks. C-c r t (org-capture, with the t template I defined in org-capture-templates) displays a buffer where I can type in the task information and set a time estimate. From there, I can file it under the appropriate project with C-c C-w (org-refile), or maybe schedule it with C-c C-s (org-schedule).

Since both creating and tracking tasks are now easier, I've been gradually adding small, routine tasks to my task list. This includes household tasks such as vacuuming and quick computer-based tasks such as checking for replies to @emacs. These tasks are in my routines.org file or tagged with the :routine: tag, so I can sort them in my Org agenda view or filter them out if I want.

It might be interesting to bring that data from Emacs to my mobile phone, but it's not particularly important at the moment. I'm usually home, so I can just check my org-agenda throughout the day. If I'm out for some errands, my errand list is short enough to remember (or quickly note somewhere), and I can use my phone to quickly jot short notes to add to my to-do list when I get back.

The next step for that workflow would probably be to improve my views of unscheduled tasks, choosing new things to work on based on their time estimates, contexts, or projects. I already have a few org-agenda-custom-commands for these, although I still need to tweak them so that they feel like they make sense. Project navigation works out pretty well, though, and it'll get better as I gradually clean up my Org files.

It feels a little odd to use my to-do list this much throughout the day, compared to the less-structured approach of deciding at each moment. The day feels less leisurely and expansive. Still, there's a certain satisfaction in crossing things off and knowing I'm taking care of the little things. I'll find a new balance between the number of items on my list and the time I want to use to follow the butterflies of my interest or energy. Maybe I'll use tags or priorities to highlight energizing tasks, the

. (Ooh, I wonder how I can get different colours in my org-agenda.) In the meantime, I think that fleshing out my to-do list even more – capturing the little routines that might get forgotten if I get more fuzzy-brained or distracted – may help me in the long run.

I think one of the things about working with a list of small, varied tasks is that there's less of that feeling of accomplishing a big, non-routine chunk. One way I can work around this is to pick a dessert-y project focus for the morning and finish several tasks related to it, before getting through the rest of the routine tasks. There's also a different approach: focusing on the process instead of the outcome, cultivating the satisfaction of steady progress instead of the exhilaration of a win. If I keep on improving my workflow for managing tasks, ideas, and reviews, I think it will pay off even as circumstances change.

2015-12-04e Process versus outcome -- index card #productivity #mindset #perspective #stoicism #philosophy

2015-12-04c Preparing for steady progress -- index card #productivity #fuzzy #preparation

View or add comments (Disqus), or e-mail me at sacha@sachachua.com

What it’s like to work with data

Posted: - Modified: | business

How did I learn to work with data?

I learned the basics of SQL in high school, I think. In university, I got most of my kicks from the extracurricular projects I worked on because doing so let me hang out with interesting people. As those people graduated, I moved to handling those systems on my own. Blogging have me another reason to explore data analysis, since I was curious about my stats. Eventually, with Quantified Self, I started collecting and scraping my own data.

I do a lot of data analysis and report creation as part of my social business consulting. It has deepened my appreciation of database indexes, subqueries, common table expressions, recursive queries, caching tables, arrays, partitioned queries, string manipulation with regular expressions, and visualization tools. I’d love to get together with other social business data geeks so that we could swap analysis questions and techniques, but we’d need to get approval for sharing data or set up a sanitization protocol that my clients would be comfortable with. We’re doing some pretty cool stuff.
What is it like when my clients ask me data questions, or when I think of a question I’d like to explore?
I start by thinking of whether we have the data to answer that question, or how I can collect the data we need. I think about whether there are similar questions that are easier to answer. Then I start thinking about how to bring everything together: which tables, which joins, which conditions. Sometimes I have to use subqueries to combine the data. I’m getting into the habit of using common table expressions to make those easier to read. I feel satisfied when I can connect everything in a way that makes sense to me. I also like seeing the common threads among different questions, and turning those insights into parameterized reports.
Sometimes the first report I make fits the situation perfectly. Other times, we go back and forth a little to figure out what the real question is. I really appreciate it when other people help me sanity-check the numbers, because I occasionally overlook things. I’d like to get better at catching those errors.
Once the report settles down, I can think about the performance. Sometimes it’s as simple as adding an index or creating a table that caches complex calculations. Other times, I might need to modify the presentation or the question a little.
In addition to making my reports more reliable, I’d like to get better at visualizing the data so that people can get an intuitive feel for what’s going on.
I also want to get better at making inferences based on the data, especially when it comes to teasing out time-delayed or multivariate factors. I think my data sets are usually too small for things like that, though.
Anyway, that’s what it’s like to enjoy crunching the numbers. I love being able to do it, and I like exploring the kinds of questions that people imagine. =)
View or add comments (Disqus), or e-mail me at sacha@sachachua.com

Embracing the fuzziness

Posted: - Modified: | productivity

I'm feeling a little more clear-headed at the moment – not as fuzzy-brained as before. Well, there's the slight matter of my ongoing cough and congestion, so I'm not quite all the way there, but I can think more easily than I did last week.

Cycling through different mental states (normal, squirrel, fuzzy, etc.) in quick succession has been helping me get better at differentiating among them, and I've been thinking about how I can make the most of them. In particular, I've been thinking about the consequences of considering one or the other as my "default" state, or of getting rid of the notion of a default state altogether.

2015-05-03e Default or majority state and fuzziness -- index card #fuzzy

If I think of clarity as my normal state and fuzziness as a short interruption, then when I'm sharp, it makes sense to make the most of it, and when I'm fuzzy, it makes sense to do the background work that will help me make the most of my next sharp period.

If I think of fuzziness as my normal state and clarity as a gift, then when I'm clear, it makes sense to invest a lot into building the systems, habits, and skills that would make fuzzy times even better. I'm not sure how probable this is, but I'm leaning towards it being likely, even though I tend to remember my past as clear. I'm basing this on the fact that many people around me have reported being relatively slower compared to their younger selves, possibly due to age and circumstances. On the other hand, I know a few people who are older than I am and who seem to be accelerating, so there's something to be said for that.

A mix of both strategies seems to make sense. I can spend some time putting the infrastructure in place to do well during fuzzy times, and I can also take advantage of quick sprints to make things happen when I have a clear idea.

So that might translate into the following:

2015-05-02e When I'm sharp, when I'm fuzzy -- index card #fuzzy

When I'm sharp, that's the time to lean in on health and systems and skills, the time to act on ideas and explore questions, the time to come up with lots of ideas and define tasks that I can do while fuzzy. It's important to write, too, so that I can remember what it's like to be sharp.

When I'm fuzzy and don't feel particularly like pushing, that's a good time to focus on self-care and close relationships. It's okay to relax, to observe, to explore.

One of the nice things about being fuzzy is that it's easier to explore alternatives and develop skills; it's all right to do something you're mediocre at when you feel mediocre at everything, or too fuzzy to do things you're normally excellent at. <laugh>

And there's always the philosophical practice at being patient and dealing with challenges… It's good.

Hmm. What's a good way for me to tell whether I'm under-preparing, over-preparing, or getting the balance right?

2015-05-05f Balancing preparation and action in different mental states -- index card #fuzzy #sharp

Hmm. It might be interesting to revisit my notes on the kinds of things I can do when I'm sharp and when I'm fuzzy (High energy and low energy activities). That might help me detect if I'm using my sharp time well.

Also, it's okay not to totally optimize this. =) I can be a little inefficient.

There's definitely more fuzziness in my future. It might be interesting to graph this to see when I'm majority-sharp and when I'm majority-fuzzy, but even without those patterns, it can help to start slowly thinking about how I can make this better. Hmm…

View or add comments (Disqus), or e-mail me at sacha@sachachua.com

Enjoy the prep work

| productivity

In sewing, the actual sewing–the stitching of layers of fabric together–seems to be such a small part of it.

There’s choosing a sewing pattern, or making one up.

There’s choosing the fabric, thinking of how it feels, drapes, stretches, handles, and washes.

There’s tracing, marking, and adjusting the pattern.

There’s cutting the fabric. Accuracy in this step makes everything else easier.

There’s marking and pinning. How you pin it together depends on how you want the finished piece to feel like.

Sometimes there’s lining, sometimes there’s interfacing. I haven’t learned how to really work with these yet.

And then – sewing! But just a little at a time, because…

There’s pressing, which is a little like ironing except with more time and pressure. This is what creates those creases and curves. It’s important to do this. If you skip it, your seams might pucker or puff. Things just don’t hang right without it.

Sometimes you trim things with scissors, or carefully rip threads and resew if needed.

And then more pinning, more sewing, more pressing, more cutting… So much of sewing is outside that narrow definition of “sewing.”

Cooking is like that too: choosing tastes, recipes, ingredients; preparing the ingredients; cooking!; adjusting the taste; serving.

What are the writing equivalents? Researching, outlining, writing, revising, packaging.

Coding? Planning, coding, testing… Maybe testing is like pressing – it helps make different pieces of code fit together neatly.

It’s like these activities have a part where you can say “This is it! I’m sewing/cooking/writing/coding!” But all the other parts might be even more important than that one bit. Hmm.

The trick, perhaps, is to enjoy those other parts as well, even if you don’t feel you’re making good progress, even if it’s not the part with the pay-off or the glamour. Doing the prep work well makes the main work more effective and enjoyable.

I wonder if life works the same way too…

View or add comments (Disqus), or e-mail me at sacha@sachachua.com

Tell the difference between diminishing returns and compounding growth when it comes to investing in skills

Posted: - Modified: | learning, productivity

When is it worth improving a skill you're already good at, and when should you focus on other things?

I started thinking about this after a conversation about what it means to master the Emacs text editor. Someone wondered if the additional effort was really worth it. As I explored the question, I noticed that skills respond differently to the investment of time, and I wondered what the difference was.

For example, going from hunt-and-peck typing to touch-typing is a big difference. Instead of having to think about typing, you can focus on what you want to communicate or do. But after a certain point, getting faster at typing doesn't give you as much of a boost in productivity. You get diminishing returns: investing into that skill yields less over time. If I type a little over 100 words per minute, retraining bad habits and figuring out other optimizations so that I can reach a rate of 150 words per minute isn't going to make a big difference if the bottleneck is my brain. (Just in case I'm wrong about this, I'd be happy to hear from people who type that fast about whether it was worth it!)

Some skills seem shallow. There's only so much you can gain from them before they taper off. Other skills are deeper. Let's take writing, for instance. You can get to the point of being able to competently handwrite or type. You can fluently express yourself. But when it comes to learning how to ask questions and organize thoughts I'm not sure there's a finish line at which you can say you've mastered writing. There's always more to learn. And the more you learn, the more you can do. You get compounding growth: investing into that skill yields more over time.

I think this is part of the appeal of Emacs for me. Even after more than a decade of exploring it and writing about it, I don't feel I'm at the point of diminishing returns. In fact, even the small habits that I've been focusing on building lately yield a lot of value.

No one can objectively say that a skill is shallow or deep. It depends on your goals. For example, I think of cooking as a deep skill. The more you develop your skills, the wider your possibilities are, and the more enjoyable it becomes. But if you look at it from the perspective of simply keeping yourself fueled so that you can concentrate on other things, then it makes sense to find a few simple recipes that satisfy you, or outsource it entirely by eating out.

It's good to take a step back and ask yourself: What kind of value will you get from investing an hour into this? What about the value you would get from investing an hour in other things?

Build on your strengths where building on those strengths can make a difference. It can make a lot of sense to reach a professional level in something or inch towards becoming world-class. It could be the advantage that gets you a job, compensates for your weakness, opens up opportunities, or connects you to people. On the other hand, you might be overlearning something and wasting your time, or developing skills to a level that you don't actually need.

When you hit that area of diminishing returns – or even that plateau of mediocrity – you can think about your strategies for moving forward. Consider:

These questions are helping me decide that for me, learning more about colours is worthwhile, but drawing more realistic figures might not be at the moment; learning more about basic Emacs habits is better than diving into esoteric packages; and exploring questions, doing research, and trying things out is likely to be more useful than expanding my vocabulary. I'll still flip through the dictionary every now and then, but I can focus on developing other skills.

How about you? What are you focusing on, and what helps you decide?

Related: Good enough, good, awesome: Thinking about what I want to get to – March 2014

View or add comments (Disqus), or e-mail me at sacha@sachachua.com