Learning
When I conceptualize “learning”, I think of “true learning” as opening up a textbook and just reading it end to end. Or repeating your craft over and over in the workshop. I don’t know, there are some very poignant notions of “learning” that I get, that are probably from a mix of popular culture and ancient culture, when the knowledge volume itself was small.
Yada yada, we live an information age, we live in an AI age. I need to adopt my workflow for this better.
There is a virtue in suffering in almost all theories of (human) learning. I disagree in the specific mechanism - suffering applies once you have a stable craft that you know you want to do. You cannot and should not ever optimize for “suffering” without knowing that that is what you want to do.
Checklist
Checklists are one of the GOATs that I dismissed for a long time. I might end up writing a vision post justifying them - but I digress.
Literature Search
Searching the academic literature and textbooks for the thing you want is always a good option. This is the place I usually start - immerse yourself immidiately in the jargon, and use AI to help bootstrap up.
Code Source Search
Since I am a software engineer, there’s bound to be a open source projects and a lot of existing code out there for the thing I’m searching for. Code is not in an academic vacuum, after all.
Limiting Scope
Everything is connected to everything - you need to be able to sit down and define something. Not formally, not “actionable”, just something that you will go back to and verify that you’re still on the same page.
If you’re struggling, just remember - your goal is probably not “Findng out if Unicorns exist”. If it’s not that, it’s probably not a bunch of other things as well, which implies that you have some goal, no matter how fuzzy or loose it is. Make all the philosophically (valid!) complaints you want, sit down and try something.
Changing “Requirements”
And yet, contradictorily to the last point, you have to know when to pivot. These two moves are probably the biggest source of churn. It’s also entirely not clear how you preserve older work - commensurability? artifacts / snapshots? Short writeups and starting from first principles? The process of learning is really, really weird.
Reverse engineering source
OK, back to something more practical. I’m not advocating for stealing IP - this can be as mundane as pointing an LLM to the raw source of an open source project, reverse engineering dead games (I am a fan of older flash games, for example). If you want ideas, this should not be off the table. LLM’s are really good at this kind of stuff - tell it to build a map for you and extract insights. When there is something concrete for an AI to chew at, it’s pretty good. This is only possible because it’s 2026 :)
Joining communities
I’m a bit more hesitant on this one, mainly because it’s not really worked out for me that much. I suppose the ideal for this is, you join a public forum and you stalk the channels for super interesting technical discussion from the passionate core maintainers or something like that. In reality, the community is a medium to get stuff done, so if you don’t have an inkling of wanting to contribute to the project, it may not be worth it.
Artifacts
Artifact bloat and in general keeping learning truly persistent is a tough problem. Even in normal software engineering ,docs go out of date and knowledge is institutional. I also find myself not really reading through the tons of AI generated docs that AI generates.
AI Research loops
I’m hesitant on this, because it seems like you need a lot of the ontology fixed for this to actually be useful. This implies that you’re probably already at a big corporation with a lot of these pipelines and metrics in place, and you’re trying to basically at some point solve an optimization problem, not a design problem.
It does point to a potential end goal, but in my experience, letting the AI run amok too early in the design process doesn’t lead to good results. And as we mentioned, there are extremely hard “discontinuous” moves such as changing requirements. IME, AI will continue to charge towards the direction you set it out to even after it, itself, has discovered a potential flaw, but it discards it. Of course, I can imagine why - imagine the bad cases where AI “discovers” a fatal flaw, and decides to halt; people don’t like that, hence, AI is trained to do everything autonomosuly.
It also isn’t generally fun - this ends up turning into a universal problem that runs into universal philosophical problems, because you’re dealing with abstract things such as “conceptual change” and “how do we make sure we find the right root causes”. You’re saying that, if you can coerce AI to solve this super general problem, you win. I agree, but it’s not really feasible for me, and it’s also not fun, so I will find other methods in the meantime. OpenAI can go figure their autoresearch out.
Fun is more important
If a process is feeling awful, sure, you could always chalk it up to, “You’re weak and lazy, you just need to suck it up and do it again, try harder”. There are a lot of these “always” knobs. Actually, when I was younger, I was constantly “gaslighting” myself almost because of these generic sayings that can be applied to pretty much “any side” (and no, “unfalsifiability” and other heuristics don’t help - see the philosophy of science).
And I’m not going to pretend like this is “objective”, either. even if you can ‘objectively’ say something is not fun, what can you do about it? There are a million ways to describe the problem and focus on which issues, which will inform your further decisions, which may or may not fix it, which may or may not conclude you to focusing on the wrong “root causes”. It’s all fallible all the way down.