Retro - Learning nvim in public

Aug 09, 2026

What I learned about my way of learning while learning nvim.

Intro

2 months ago now I talked about

an experiment to focus on learning one thing at a time and making it real by publishing something, again this is an idea I got from Fernando Borretti
Applying that idea to learning Neovim

I got wildly distracted, created convoluted plans, and overengineered notes. But despite that managed to end up with nvimexample, as a finished product.

Through the mess of that process I discovered what works for me when picking random topics to learn.

This post is the summation of that discovery.

What doesn't work?

Learning logs. Just stop doing learning logs.

The good thing about learning logs is that they encourage you to check in on a daily basis. This is good for keeping momentum on self directed learning missions.

However, it eventually becomes an anti-pattern where all I'm doing is checking in, watching or reading, and compiling notes on a daily basis.

That's not a good way for me to learn.

What ends up happening is I get mountains of notes that seem valuable at the time, but are rarely referenced later. In the case of Neovim, there were a lot of interesting keymaps, quirks, and other things I would write down so that I "don't forget them".

This was largely a wasted effort, compulsive note collecting, because any keymaps worth learning I memorized more or less automatically through continual usage.

Compulsive note collecting in general ends up being an anti-pattern (for me). Time spent copying and organizing notes, is valuable time lost to something more profitable (for my way of learning), experimenting.

What does work?

Using lightweight and disposable note taking strategies. These facilitate capturing ideas in the moment, getting them out of your brain, and allowing you to keep working on the project at hand.

I found 2 note taking strategies that were helpful to me, Scratchpads, and Atomic Notes.

Scratchpads

A Scratchpad is a blank piece of paper that you use while working on a project to capture distracting thoughts, or perform short term organization strategies.

Using Scratchpads to brain dump, getting thoughts out of my head by writing them down, helps me move forward with a task.

Often I need to break tasks down into steps before I can get started on them. I find writing simple sequential instructions VERY helpful. Scratchpads are the perfect place for that.

They can be physical or digital. They are not precious, they are disposable. Microsoft Notepad notes, and printer paper are great candidates. The brighter and more obnoxious the better for me, it's a blaring bright white reminder that I'm not meant to spend time there. Get in, get out, and back to what's important. The project, your thing!

Often I don't even save them, just throw them out when done. Like I said, disposable.

Atomic Notes

Atomic Notes are Obsidian notes created with the following format note MM-DD - topic. The leading word, note, could be swapped for things like: idea, retro, project-plan.

These serve as a place to collect LOOSELY structured information from the learning project that you might need when reflecting:

links, or references
instructions you wrote yourself
insights you had
ideas

A simple MM-DD (or %m-%d if you like datetime formats) timestamp along with a high level description, topic, provide just the right amount of structure for me to be useful.

Simplicity is hard.

I found this style of note taking much more efficient for learning on the fly. It encouraged me to write things down so that I could maybe reference them later, and then move on.

Recap

There is a theme with these notes ... Prevent distraction, and minimize structuring notes and making them pretty. Focus that time on creating, and figuring out for yourself!

What should we do next time?

Creating public evidence of something new you are learning should probably not be the goal from the start. At least you should not try to determine the output of your learning prematurely. This caused me to focus on polish, and details far too soon.

Instead I should have prioritized hands-on experimentations, and unstructured mini projects.

Instead of doing a learning log, I should have just written small games in Lua. Instead of trying to do a writeup for the config, I should have created a config that got me started sooner, used it to write more code, and continued learning along the way.

It is really easy to get distracted when learning on your own, and coming up with your own structures. I started out wanting to learn Neovim, but then thought Lua was really cool and wanted to learn more about that.

You never know what detour you may want to take, and oftentimes those detours end up being where all the fun is, and where we stand to learn the most.

A better way - Absorb, Create, Cement

A better format for learning something (programming related) might be:

Pick a resource (video series, tutorial, book)
Absorb info from the resource (take lightweight notes)
As soon as you are inspired to create something, or get an idea, DO IT
Just keep working, and if you hit a wall, refer back to your notes or continue with the resource
Resist the urge to learn EVERYTHING about the topic, that is impossible
1. Pick your battles and learn, just enough

I suspect I could also apply this to drawing, or playing guitar. Will need to test that.

What still puzzles me?

Where exactly does the publish step come in? How can I prevent myself from doing it too soon?

It's funny I was working on a drawing recently that started purely for fun. It was a maze that I made by combining basic shapes (squares, and rectangles mostly) to make complicated ones.

Eventually it just felt ... done.

Maybe I need to take a similar approach to writing? Programming and drawing are different because you can just have a project you work, and work on, and the end result is proof in itself.

It's also tricky because I think having a time budget for my projects, or at least something resembling a deadline, is the only way I will get them done.

When should I apply the time budget and deadline method?

I didn't need that with my drawing maze, because then it would have felt like ... work.

Perhaps deadlines are good with learning new things in a targeted manner, since growing a skill requires dedicated effort and intent. You likely won't learn a new or difficult skill by just picking up your medium (programming, or drawing) and messing around with it for 30 minutes.

That is to say, apply deadlines when you have a specific goal in mind.

Cementing knowledge via writing (especially if you create a guide or instructions) is tricky, because you have to wrestle with what you do and don't know as you create it. You can't really just find your way through it like with art and hands-on creative projects.

Final thoughts

I've always known it, but this project made something painfully clear to me. I'm a perfectionist.

It took me about 15 hours or so to write that guide. I use devlogs on my projects to track time spent:

I spent an unnecessary amount of time 'polishing' my guide out of fear and worry that "it didn't look good or right".

I want to move away from my perfectionist mentality. One step I'm already taking is setting a time budget up front, telling myself how much time I am willing to allocate toward a project and sticking to it. Telling myself that an "imperfect" outcome is much better than a non outcome.

In fact I'm doing it for this very writing, and so far we are on track 😊.

I probably would not have had these insights if I did not make the decision to share things publicly. Sharing prevents compounding ignorance with inaudibility (or in my case invisibility).

I'm really proud of myself for following through. Great work!

Also be sure to leave more time than you think for your FINAL edit.