I tell myself to not adhd it and instead take time and read through a whole manual, experiment in a local sandbox, grasp the limits of knowledge and features and also where it gets deep.
Then in a regular work I explicitly detect where it pays off and feel “see I told you”. This creates a motivational loop to continue not-adhd-ing through tech.
Sometimes I still fly over the knowledge, but then may note that what I’ve been doing in a complex way could be solved with one parameter, if only I knew about it. This creates negative feedback against flying over.
This is ofc only one facet of learning, but I find this “see I told you” method very effective, cause my main issue with learning is unwillingness to learn for no clear reason.
My issue with this method of learning is… deadlines. During work time, I often feel that I need to solve something “quick”, which then leads me to usually learn and really deep dive outside of regular work hours instead.
Now, I mostly actually enjoy doing this and thus it has not really limited me. But I wish I could just spend some actual work time on more ‘non adhd-ing’ what I learn.
Yeah, deadlines suck. Historically I managed to "manage the management" into a reasonable rush/cook balance most of the time, which allows for healthy exploration, but that is absolutely "ymmw" thing.
I love the manual method and occasionally used it. Basically assuming there is no Internet, just a book and a repo of source code and try to figure out how to do something.
Sadly I'm now so easily burnout that even setting a dev env up can burn me out.
The key is to figure out what your learning process looks like.
For example, I discovered early on that I learn in three phases:
1. I get exposed to something (a concept, a process, etc); basically discover that something exists.
2. I then see how that thing is used whether through mentorship or tutorials or, increasingly, through trial and error.
3. I apply that thing to some novel problem.
Through this cycle of Discovery-Tutelage-Application, I can assess my level of comfort with new material and understand when my struggles are due to trying to short circuit the process.
It's likely that you have some form of learning process that is equally cyclical, yet undefined -- once you identify and codify those steps, you can evaluate your progress when it comes to acquiring new skills.
This is a difficult question to prescribe an answer for that works for everyone, but the best I personally can think of is "practice".
To make that more actionable... My approach in life has generally been to find a project (even something seemingly incredibly dumb, as long as it is fun), then work through it, learning what I need to know as I go along. To learn "well", you must then also constantly question what you have done as you complete various stages of the project to see if you have done them as effectively as possible, and try to incorporate any lessons learned into future projects.
I have found that how individuals do the learning required for this differs significantly from person to person, so it is hard to recommend any particular approach.
You learn to learn with time and imo it's different slightly from field to field. In tech field you just learn by doing, asking questions, making mistakes and gaining experience. Take a sample code in a new language, make it do something slightly different. Then add one more thing on top. Then something slightly more complex, then finally try to make it do what you want. Once ready, deploy, test, and iterate.
At its simplest, rewrite and interface regularly with knowledge. There’s an entire hobby around personal knowledge management, and it‘s all up to you to find what works best, but taking meaningful notes and rewriting those notes, processing them further and further, will help form deeper mental connections regardless of method.
