On-demand learning comes at the cost of conceptual understanding
jernesto.com
jernesto.com
You had to because you were studying for a specific exam, which you would fail if you only understood the deeper concepts but not specifics of the questions on that exam.
It's also true that you probably don't understand the concepts as well as you'd like. If you're like most of us, you passed the exams by means of an academic Fosbury Flop. Sort of throwing yourself over the bar in pieces while your center of gravity passes under it.
On the other hand, most of the things I do understand well are things that I've been on-demand learning about. You end up coming back to central concepts because they're central. Knit together enough programs and you will end up thinking about code organization at some point in your career. You will run into a Big-O problem at some point. You will run into distributed systems.
Yeah so I'm not sure what my point is, perhaps I agree in a way that it's a bit of a continuum, but also I think with enough exploration you actually end up finding gold.
I was the conceptologist. I learned by fitting things into chunks.
Then I got to the world of tables of apis and frameworks and shitty microservices and all of it ad-hoc, and found that my mind, tuned to do what I found valuable and beautiful in the world, was worthless.
- Databases: Postgres, ClickHouse - Back-end frameworks: Ruby on Rails - Front-end frameworks: Elm
I lost count of the times I was reading the documentation of these projects and had my mind blow thinking "The person that came up with this concept was a genius! I'm glad I get to learn it."
This works for me pretty well in software. I still have problems with things requiring memorization, though - like some bits of chemistry, or the grammar of German language.
I feel like the move would have been to go very deep on something. Too late for that now.
I started out in a 300 kloc c++ codebase.
I've never had a better environment since =/
I have no real ability to do that, and even when I try to cram it feels like cheating (take that up with my therapist.)
What I did in college is figure out the classes I was likely to take next semester, then furiously study before the semester started until I had a learning buffer of a few weeks. Then during the class I tried to study deeply, always ahead of the class and exams, and ideally the buffer would be zero by the final.
The textbook was usually better than the teacher anyway.
I mostly operated that way on a class-by-class basis in grad school, but at some point it became a conceptual understanding. The "aha" moment came in grad school when I was a TA for a class I didn't do particularly well in as an undergrad. During a help session, I couldn't recall a couple specific formulae, but I was able to infer and derive them based on my conceptual understanding of the topic.
I think the real difference was that I was now teaching the material, and in doing so, had to approach things from a totally different angle than studying for the test.
However the class of one's degree (first, second, etc.) depended only on the finals and the oral examination of the final year experimental work. The intermediate examinations counted for nothing except to justify your continued study.
On demand learning doesn't work in such an environment you have to have simultaneously a broad and a deep understanding of the system of physics not just isolated bits of it.
learning without purpose sucks, I mean it's still very valuable, but it sucks in that sense that it is "unpredicatbly effective".
It means that you may learn some stuff and be asked about it on a interview month later, or use it in your task a two months later. It's unpredictable.
It has one strong advantage - namely you're prepared when facing problem.
In both work and academia I've been doing things ahead - sometimes due to work, sometimes due to curiosity and when facing those problem during lectures or work then I've been prepared.
It's advantage, but the process sucks, is boring and unpredictable.
I think on-demand approach doesn't work well when the problems are getting harder and require more knowledge / exp and you gotta have solid foundations and proficiency to some point in your hands.
I think it'd be hard to do cryptography, reverse engineering, writing database, compiler, os, etc. when learning on-demand. It'd feel miserable, I think.
Your presumption is that people are only interested in learning things that make them more effective. This is certainly true of many people at least some of the time, of course. This can be established by direct observation: How many times have you ever heard someone in a classroom ask, "Will this be on the test?"
Bt as a universal proposition, it can also be contradicted by direct observation: People learn things for "the pleasure of finding things out," the title of a Feynman book.
Why else would anyone read a book like Raymond Smullyan's "To Mock a Mockingbird?" There are precious few occupations where you will become more effective if you know how starlings and kestrels can combine in various permutations to compute anything computable.
The first half of your sentence is correct: Learning without purpose sucks. But there are many purposes for learning, including fun (like learning combinatory logic via songbirds in forests) or a desire to understand the way things work or the desire to be viewed by our peers as a learned person.
One of the ways you make more time available for the things you learn for fun (esoteric programming, rock climbing, ultimate, playing music, flying gliders) is by being very intentional about what you choose to learn for "your job."
Another comment made a good point: Perhaps we should call such learning "training." We expect automobile mechanics to know the basic physics behind ICE, but nobody expects the person changing their oil to learn about the computational fluid dynamics involved in designing fuel injection systems.
If you ask, "How can I learn about programming," I would expect the answer to involve a mix of both CompSci basics and practical direction for writing actual programs in a reasonably accessible programming language.
But if you ask, "How can I train to get a job working as a programmer in BigCo," I totally get that the answer should lean in, hard, on the practical and the currently marketable.
I feel like deep diving into conceptual things makes more effective. There's no longer dark corners in my mind when I think about certain problems. It helps me move forward with confidence knowing I've done the research and I know I'm on the right path, rather than following a heuristic.
Learning can be it's own reward. Learning can give you new eyes to appreciate the world.
I think that in the context of this thread we are talking about learning to get purely better at job/craft
There certainly are important points to be made there, and the article makes some of them.
I didn't understand all the terminology choices and definitions. For example, where does Papert's theory of Constructionism fit into this dichotomy of "preliminary learning" vs. "on-demand learning"?
I'm kind of hoping that IoT or open source firmware for SOCs and BMCs will give people some more fodder for learning systems thinking concepts that are currently being buried behind giant frameworks and stackoverflow.
Here is an example. I was interested in real-time 3D graphics programming. How did I go about it? I followed the bare minimum tutorials to get OpenGL set up with C++ and then I just wrote code for several months, trying different things. This allowed me to develop my own intuition around linear algebra, geometry, 3D rendering, GPU pipelines, etc. I knew I wasn't doing anything groundbreaking, but what I found was after this experimentation I was able to readily digest and understand the formal approach to the topic. And it was out of my own interest too. I was watching university lectures, reading about mathematical proofs, etc. Something I thought I'd never be able to do. And I found it much more rewarding as I was able to see where my intuitions were correct and lined up with the formal approach, and also where I was very wrong.
Don't get me wrong, it's a valid pursuit, but I'm not convinced by the arguments presented.
Instead you can say it opens the door to more serious work such as say language design, operating system teams, things like that. It rarefies your skillset especially if you don't suck at it. You aren't likely to get an important position at say, nvidia, by going through bootcamps. The crack of that door is open much wider for those with a Stanford PhD in hand. I'm sure there's exceptions, but I'd imagine they're quite rare.
I think it's unlikely, however, to make you necessarily more proficient in the latest churn of frameworks to implement the latest churn of websites.
If you're early in your career, focusing on marketable skills and getting experience is a smart move. Once you start thinking about progressing to intermediate and beyond, theory starts to be a secret weapon of sorts that lets you tackle bigger and harder problems.
A plumber doesn't need to master the mathematics of fluid dynamics or have an advanced degree in chemical engineering to do their job well. A hair stylist doesn't need to pursue a dermatology medical degree focused on hair growth.
Plumbers and cosmetologists have plenty of work and it's a good profession. They need to go to school, pass exams, get a certification, it's a real thing.
Similarly, getting an e-commerce site up or building a mobile app doesn't require an ability to say, demonstrate the correspondence principle of procedural abstraction in lambda calculus. There's jobs that do but that ain't one of them.
I've found that this makes instant proficiency with a lot of things easy ("oh, it's one of these") and mastery fairly quick too ("it's one of these, but with these key differences/details").
The biggest downside is I learn (truly) new things slowly. Where most people note things down, remember them and move on, I can't learn until I've understood what the new thing is, in the sense of having some sort of complete idea of what it is (not necessarily with all the details, just enough for it to be coherent). But once that is absorbed I can move on fairly quickly.
So when I'm being taught "preliminary" I just can't get whole picture I need, and it all goes by too quickly for me to figure it out in classes and lectures. The other problem with this sort of teaching is that it tends to be bottom up whereas my mind tends to work top-down, not wanting to know most details until later. I'm more interested in why you would want to have this thing as it is or why you need it at all, because that reveals much more to me, rather than describing how it works or how it fits in with the next step up.
I think learning through experience and hands on activities is totally valid, and in most cases I don't know if I would say that kind of learning is 'on-demand'. Preliminary learning doesn't have to be reading out of a book or having to do 10 years or school, but it should be a cohesive, prolonged effort to understand fundamentals.
"On-demand learning" is apps like iNaturalist and eBird. Folks are asking "What is this?" basically in a knowledge vacuum. It's good that people are curious. But learning the overall taxonomy over time, from combined classroom and fieldwork, makes it a much much richer experience.
Not sure this translates 100% to CS concepts. But I do understand the point being made in the article. Thanks for sharing.
The core body of knowledge (in programming anyway) really hasn't changed all that much since the 90s, at least.
Sure, the languages and frameworks have changed, and maybe I'm not typing as many semicolons as I once did, but a function is still a function and a class is still a class.
I've seen plenty of the example that you give involving things like iNaturalist. These are people who just plain suck at learning on their own. Sorry, I know it's harsh, but I think that's usually the case. These are people who wouldn't be particularly successful in a classroom either, though they may do somewhat better in a classroom setting merely because it does away with the need for the student to exercise the skill of seeking the right information.
I am more adept at the on-demand side of things. It's not that I can't learn in a classroom setting, but a classroom can also be smothering to me because it doesn't permit much deviating from the formula. What I'm good at is getting the basic idea of something, ditching what I don't think to be relevant, identifying what I believe may be incorrect, and using that to go on my own learning journey and developing the necessary skills. Only after I have exhausted every other feasible option will I ask someone "What is this?" One reason I hated being in a classroom is that a certain amount of question-asking is expected of you, and you'll get singled out if you're not asking enough questions; I don't ask questions because, quite honestly, most lectures are redundant to reading material and taking notes.
For the preliminary learner, they need the classroom (learning on rails) because they don't have what it takes to be self-directed. They're probably not going to rigorously question the information being given to them. If they self-guide their learning, the process they'll go through will be one of frequent astonishment.
What I'm trying to say is that I think this really comes down to the individual and not so much the process. Certain personality types are better suited for preliminary learning, and others are better (and happier) with on-demand learning.
Yes this, thank you, this expresses much more accurately, what I was getting at. When I said "classroom" I think what I meant was really "research."
It also digs out the core of my concern, which is I guess the laziness fostered by these apps. They don't encourage the "learning journey" much. And that is so much richer and more interesting, than a jumble of disconnected names.
This looks a false dichotomy to me. Concepts can be learned on demand as well. Talk to any professors in a theoretical STEM field (I assume their learning is as conceptual as one can get), be it maths, physics, stats, CS, or something, they would advise their grad students not to spend too much time reading through the tombs before starting research. Instead, they would ask their students to learn the concepts along the way when doing research. Of course, one needs to have solid foundation to learn concepts quickly along the way, but it does not conflict with the effectiveness of learning on demand.
What matters is what to learn on-demand and how.
You don't need to know the concepts of material engineering or thermodynamics to be able to repair it. You just learn the functioning of an engine and the tools you need.
Trying to learn in advance is a waste of time. Most people learning for tech roles agree, and the industry agrees. It might be helpful to step back and look at the big picture when you learn or to backfill knowledge gaps to understand a topic better. But if one avoids learning on the spot or on the job, they just put themselves at a tremendous disadvantage.
> preliminary learning is quite bad for learning tools but is the only way of learning concepts.
This claim is not justified. Why must concepts be learned just-in-case (preliminary) rather than just-in-time (on demand)?
I can imagine you might struggle to get a good map of some territory, or a deep explanation of why something is true, without a teacher and/or setting aside some time. But what does this have to do with just-in-case versus just-in-time?
The specific quote you include isn't totally wrong, but it overstates the connection and ignores the contextual differences that maken it more or less true.
One of those contexts in the amount of time pressure vs. slack time you have. When you are under lots of time pressure, it's harder to take the time to learn concepts and easy to skip straight to tools.
To me, this indicates that the author has misunderstood the cause of the problem. The problem isn't that tool learning replaces concept learning, but that workplace/management cultures commonly don't value concept learning and as a result don't schedule time for it or reward it.
Because you don't know which concepts you need unless you already know what they are.
[1] http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...
1. You don't invest in learning something you won't use, and;
2. Learning something you will eventually use, but not in the near future, has an opportunity cost: What could you be doing with that time and attention that will produce value now?
I will make a separate comment describing what I think the drawbacks are, but I wanted to focus on my support for your preferred nomenclature.
It seems like the article is lamenting the fact that many of these become "not in time" learning in practice.
:-)
First, two definitions, from the author:
1. On-Demand Learning: Learning done to solve a specific problem as it is encountered
2. Preliminary Learning: Learning done for the sake of a broad understanding of a subject
I disagree with the naming, but we'll roll with them for brevity's sake.
The author worries about on-demand learning being applied to the exclusion of preliminary learning.
Put another way, too many people read tutorials without reading general information.
So, the solution is pretty simple, on the face of it - make sure you're regularly learning broad areas, not just specific solutions.
Read a variety of books. Acquire a broad base of knowledge.
I think it's mostly driven by agile development. Agile has killed technical apprenticeship in the workplace. What has replaced it is the project manager/product owner with a cadre of junior engineers, all of whom are trying to 'figure it out' by reading Stack Overflow posts.
Many tech interviewers prioritize 'fundamentals' during hiring (and by doing so bias the hiring process to college grads but i digress). Your team has a lot of well versed, knowledgeable engineers that can write heap sorts, bubble sorts and compute the bigO notation and write a left-handed parser, but they don't know how to build a piece of software yet. The internet becomes your mentor and you get that gadget shipped.
The result of course is the Cambrian explosion of garbage systems left behind by junior engineers that have since moved on to other jobs. Looks like it's time to rewrite that code with a new team!
I think fundamentals are important but unlike other academic disciplines there's a huge gap between academic CS and actual software work. In CS you need senior ICs to bridge that gap.
In the first case to learn a thing you learn all its dependencies and you understand everything about X once you learn it (but you take a long time before you can connect the dots, it's frustrating cause you wait long for the feedback, an it's harder to learn dependencies without understanding what they will come useful for later).
In the other case you skip the details and learn the general idea, then (if you have time) - you make another pass going into more details, and so on. The good thing is that you have general idea about everything quickly and you know more or less where to look for more details if you need them. The bad thing is that you don't really understand most things, you just think in leaky black boxes until you're forced by the debugging to learn the details.
This is the difference between my wife's (a math teacher) and my (a programmer) learning styles, and we had it very hard to overcome these differences when learning together at university :)
The curious will often descend into conceptual rabbit holes and acquire conceptual knowledge as well. It's sort of anticipatory yak shaving for future projects.
Older generations are used to studying the field, and learning about the capabilities of the language, environment, etc.
It comes down to this. A language is a tool. Learn your tools well. Become a master craftsman in the tool, and then you will be able to craft amazing things.
If you just learn "enough" to get by for now, i.e. "On Demand Learning", then you won't even be aware if some particular capability of your toolset exists, because, you can't "learn it" if you don't know about it.
Eventually, you will "see some code" that does something, and suddenly you will be prompted to "go learn it", but your understanding will always be limited.
I still take time to read through books (Oreilly, packt, etc) or do some langauge reviews to understand what my tools can do, and do my best to get a good feel for the capabilities. As I approach a particular problem, I usually need to do some more review, more "on demand" learning to deal with the specifics of the problem.
I guess, my approach is a bit of both. General coverage so I "know" my tools capabilities, and then on-demand for the details when I'm trying to use a particular capability for the first or 2nd time.
In a more broad sense: a specialist, too specialist and of low general culture to know/grasp "the big picture", so someone unable to evolve, who tend to have just a hammer and so see only nails etc.
I do not understand the "on demand" part. Beside the title the issue is very old and far older than the industrial era or modern time: the issue is that broad and skilled people know the big picture so are hard to master like famous Greek's "useful idiots", while "useful idiots" are... Useful, but not much a threat for a leader, anthropomorphic bipeds easy to chain and forge ad human-robot.
In some moment in history some leaders have tried a "more culture" path, like Peter the Great, and it does end not very well for him and just partially well, and at a very big price for the people. In some moment the opposite path was took and again it does not end well as well.
Probably the ancient Roman's "in medio stat virtus" (in the mean lie the virtue" is still valid, and find the mean is not so straightforward, NOR easy to keep since we are a living being not a static iron bar...
How effective is preliminary learning vs on-demand learning? If I can have 80% of the conceptual understanding in 1/10 of the time is that a good trade-off?
For preliminary learning, how do you know which knowledge will be useful in the future and which will be abstracted over?
How fast is the field moving and what do you want to focus on?
For example, someone asked on the ML subreddit about theoretical ML research and many comments said theoretical research was unnecessary:
"But, regarding the value of pure ML theory research e.g. convergence bounds, versus practical ML research e.g. quantization methods, my personal feeling for quite some time has been that purely theoretical ML research has been predominantly bunk. Machine Learning is so high dimensional that things that can't be proven universal can be nearly guaranteed probabilistically, and things that can be shown to be possible can be staggeringly unlikely; for example, just because the No Free Lunch theorem exists, doesn't mean that Adam won't work in the vast, vast majority of cases."
https://www.reddit.com/r/MachineLearning/comments/101qbfl/d_...
This topic is extremely grey, and blunt arguments like "on-demand learning is ruining the tech industry" are not interesting.
I recommend you watch this talk by Laurie Voss where he (They?) explains that fundamentals are always shifting. What you consider "conceptual understanding" now was a tool many years ago. Tools solidify into the new generation of concepts over time. One controversial point he makes is that at some point, new developers will not know HTML and that's ok!
I've learned that it is a waste of time (and brainpower) to blindly tweak code without understanding the algorithm, hoping it will magically work. Yet, I've observed many newcomers to machine learning essentially doing this. It might be somewhat useful at this moment, but if it is easy to do then it will likely become automated.
I think having both skills is ideal; be able to quickly get things done, but also be able to acquire deep knowledge when necessary. T-shaped skills.
In reality I think there is no clear divide. If you do the on demand thing, you'll encounter situations that require a deep dive or if you recognize the same patterns in different things. If you do new things learning is inevitable.
I don't share the concerns, I think there is no shortage of people with super deep knowledge on many topics and I think we are actually getting better in using that knowledge to everyones benefit. I'm thinking tools like Streamlit, Supabase and Framer. You don't need to be a FE pro to build a simple dashboard, you only need basic SQL skills to create a backend, and you with just design skills you can make great websites.
It's a bit too far to say one is ruining the industry. I think you could however argue that it is robbing people of an education. Most people take the extreme of only doing JIT learning and that makes us lazy. Some people take the extreme of only doing AOT learning and they get nothing done. A balance is definitely needed.
I remember early in my career when I got a request to make a graphic slowly start to circle around a user’s mouse as they hovered over an area of the page.
I couldn’t use a tool to solve this problem. I used on demand learning to go back to high school trig and figure out how to animate something in a circular motion.
My point here is that often on demand learning and conceptual preparation merge into the same thing and aren’t mutually exclusive.
The problem is that it’s hard to build the concept from the ground up. For example, everyone knows that it would be best to learn linear algebra before learning machine learning, but no one, in practice, has the time to learn linear algebra from the ground up.
Programmers quickly learn that the presence of good documentation cannot be relied on, and bad/outdated documentation is worse than no documentation.
This is a very different paradigm from traditional schooling where almost everything is built on mostly reliable documentation (i.e. carefully curated textbooks).
But this brings me to where I really disagree with the article:
> Putting it bluntly, on-demand learning is excellent for learning tools, but it sucks at learning concepts.
I could not disagree more about this, in fact I think it's borderline gibberish. First of all, you can absolutely learn concepts on-demand, and in fact a concrete use case can often make the concept much clearer than if you learned it from first principles. Secondly, of course tools are easy to learn this way, since a tool is a thing which was already thoughtfully designed for a purpose—if your goal is to quickly get something done, and a tool is available, of course that is likely going to be your first choice.
Overall preliminary vs on-demand is just about time horizons and they are not mutually exclusive. For example, I don't see any shortage of programmers continuing to learn over the long-haul and develop new concepts and practices inductively based on years of short-term focused work.
Thank you all for the thoughtful and eloquent comments.
The authors should really look at many interdisciplinary domains, where doing preliminary learning each and every one of the underlying subjects is not only unnecessary, but unfeasible. This applies for domains such as data science, computational physics, and many others.
For most people, the reality is as simple and cold as: if you are not learning while doing, and doing it fast, you simply don’t get paid/funded and will go broke.
You can learn by doing, or by theory and then doing. The point of the theory is to take a compressible space of learnings and compress+cache them. A principle or law or whatever is just a cached compression of a model of reality.
It has all the benefits of compression: you acquire the knowledge faster.
It has all the disadvantages of caching: your knowledge may be out of date.
There is nothing inherently valuable about a "conceptual" understanding or understanding the "fundamental principles" of something. All the value comes from the fact that the alternative is you can slowly build your model by experiencing reality bit by bit, constantly trading off use of your knowledge for building more knowledge. Or you can accelerate that process by downloading precomputed indexes from other people: what we call "concepts" or "principles".
With this model of knowledge, you can see that so long as you can extract commonalities from experiences (using your inductive reasoning faculty to generalize from small samples) you will capture "conceptual" models. This model also permits you to choose when you should choose to learn "concepts" and when you should choose to acquire the raw uncompressed experience: prioritize the compressed cache when it is likely to not be stale and it is likely to cover a wide knowledge space.
A heuristic for this is for fields that haven't changed very much in a long time. e.g. basic Physics has not changed in a long time. Reading the compressed model is superior. On the other hand, cross-platform UI development is a new field. You will be better served by trying something.
Another heuristic is the search cost. Using your inductive reasoning requires some examples. Areas where these are hard to acquire should move you to acquire through reading the compressed model. e.g. studying epidemiology is better served by reading through the state of the art in the field. On the other hand, you don't need to study principle to determine if one way to play a level in a videogame is superior.
A third heuristic is how large the search space is. e.g. Your musical tastes are constantly changing, and it's trivial to play the piano. However, the space of notes that sound pleasing to you are likely a small fraction of the space of notes that you can play on the piano. Here you will be better served learning some principles to cut the search space down.
P.S. By the way, to the author, you may benefit from running your posts by some English-fluent friends to proof-read. It is unlikely you meant to use "gives more inside".
That's true, but I felt like he was getting at something else, though. I've met (and worked with) programmers who tried to stumble through everything by looking for a solution to the problem immediately in front of them, solving that immediate problem as basically as possible, and then working on to the next problem. They don't really understand how things like, say TCP or SSL or even HTTP work. They don't understand how their IDE relates to their compiler. They don't understand machine learning well enough to recognize when or how to normalize data. They usually expect somebody else to come along and "help" them with all of this stuff in a "just-in-time" way.
I remember attending a Java user group one time when Hadoop was relatively new and the speaker was presenting it. He was talking about some of the challenges they faced getting it up and running and a woman interrupted with "but whenever you had a problem, couldn't you just google the error message?" He said, "there usually weren't any error messages and even when there were, google didn't find anything". She seemed shocked and actually argued with him a bit in disbelief. I was dumbstruck that here was a woman who was actually working as a professional programmer deep enough that she was attending Java user groups who couldn't conceive that there even could be problems that required enough fundamental understanding that "googling an error message" wasn't going to help.
I did a lot of self-directed teaching about programming, starting with boyhood explorations almost exactly fifty years ago (1972!). Yes, I also have had formal education, but most of what I have actually ended up using has been based on self-directed learning.
The result for my N=1 sample is a broken comb profile. I know much more about some things than others, and there are areas of our industry where I am completely ignorant! The reasons for this in my case are that I tend to focus on areas where I already have some exposure/interest, and ignore those that I may not understand or even know exist.
"On-demand" learning tends to reinforce this. You are trying to solve a problem, so you ask yourself questions, and then do research to answer the questions you posed to yourself. But this can create a serious XY Problem[1]. As a self-directed learner solving problems when I encounter them, I search for solutions using the knowledge I already have, and I'm completely ignorant of the possibility that I'm solving the wrong problem and ignoring a deeper understanding of what I'm trying to accomplish.
This can be fixed in various ways, the most obvious of which is: Ask questions of people with experience that differs from yours. If you are a self-made programmer, you will learn the most by asking questions of people with a formal education. If you are in a three-person YC startup, you will learn the most from people in Enterprise companies. That is true no matter how little you value formal education ("credentialism") or Enterprise businesses ("bloatware crystallized as an organization").
And the other thing I'll mention is to embrace the "XY Problem." I personally am just like so many people you see on the interwebs. If I ask how to solve problem Y, and someone says "Wrong! You actually have problem X, and you solve that in the following way," I often emotionally push back. "Just let me solve Y today," I think, "I'll ready up about X later."
But that is the glaring weakness of being a self-directed, on-demand, just-in-time learner. We chase solving problem Y, sometimes aggressively ignorant of X. To be successful as our own teachers, we must be open to learning about X even when our "priority" is solving problem Y. And this is why being respectful of people with different contexts (those with PhDs or those who attend 57 meetings a week) is especially valuable for us. JM2C, YMMV, and especially, if I'm blathering about Y while the real issue with on-demand learning is X, I'm open to your feedback!
fire that asshole.
"I love making fun small projects and learning new things in the process. I’m interested in computer science, physics, math, and pretty much everything else."
Sounds like the sort of on-demand learning he's criticizing.