November 10, 2023

Pragmatic Thinking and Learning

Source: Pragmatic Thinking and Learning


What made me read this book was when I stumbled upon a talk by Dan North about effective teams, and this is also one of the key ideas that stuck with me by the end of the book: Dreyfus Model of Skill Acquisition.

Gist of it: There are 5 stages: novice, advanced beginner, competent, proficient, and expert. At each stage, your approach to learning and problem-solving changes. For example, novices learn by following rules and recipes, while experts rely on intuition and pattern matching.

The book looked into ways to unlock the full potential of our brains, and although there were parts that were like “snake oil” to me, the overall contents of the book were superb. It explained why I always found washing the dishes an effective way to unclog my mind, which in turn, allows me to figure out a solution to a problem by looking at the problem from a different angle.

The types of learning were also spot-on, as they described the different types of learning. Anyway, off to our notes on Kindle.


Journey from Novice to Expert

Also, given the phenomenon that experts are often unable to articulate why they reached a particular decision, you may find that someone at a competent level might be in a better position to teach a novice than an expert would be. When pairing or mentoring within the team, you might try using mentors who are closer in skill level to the trainee.

This is something that resonates well with almost everyone. Experts often have a hard time, or the patience, to teach a novice. They also have a hard time identifying which topic is just right to discuss, and which one is a little too advanced.

So, you want to be an expert? You need to budget about ten years of effort, regardless of the subject area.

This is what makes my “want” to be a generalist a little doubtful if I can achieve it or not. I’m just 13 years in, so do I need another 10 years to be an expert on another thing? Another point of concern is that if I focus on something else, I would most definitely be rusty about my previous expertise.

  • You need a well-defined task.
  • The task needs to be appropriately difficult—challenging but doable.
  • The environment needs to supply informative feedback that you can act on.
  • It should also provide opportunities for repetition and correction of errors.

This is one of the downsides of learning technologies that I’m sure of that I won’t be able to use. Step 3 and 4 is a little blurry when you don’t get to use it on an actual project.

This is Your Brain

If you don’t keep track of great ideas, you will stop noticing you have them.

This is a great point on why I should always have a note-taking app ready.

Get in Your Right Mind

Have you ever noticed that great ideas or insights may come to you at the oddest times? Perhaps while taking a shower, mowing the yard, doing the dishes, or doing some other menial task.

This resonates a lot with me. I always do the dishes, and when I do, those are the times I get to think of a solution to a particular problem I’m having trouble with or recite a full article that I could write in the company confluence about an idea that I want to sell to the team.

Apparently, it’s the L brain in motion.

Learn Deliberately

SMART stands for Specific, Measurable, Achievable, Relevant, and Time-boxed.

I heard this a lot at my work. Relevant is what would help one to keep on track. Oftentimes, I get demotivated to push through on what I’m learning when I’m learning some language that I know I won’t end up using day to day. Haskell is interesting, but the chances of being able to use that at work are almost nil.

Adult learners are a different breed from either children or college students.

This is so true. Oftentimes, some materials that are supposed to be for children are not effective materials because they were designed from the perspective of an adult.

The same goes the other way around, too.

The adult learner is motivated to learn if learning will satisfy their own interests and needs.

This resonates with me as well. There was a time when I enjoyed learning things for the sake of it, but nowadays, I easily get demotivated to learn a particular subject when I’m pretty sure I won’t be able to use it in my day job.

Even if I did manage to convince myself that there might be a position elsewhere where I can use the technology, another roadblock would be the thought of me taking 1 or 2 steps backward in my career because I cannot possibly say that I have actual experience on a technology outside of “self-study”.

Units studied should be real-life situations, not just isolated subjects.

Does this mean that the most effective way of learning a new technology or approach is by implementing something using the concepts that are being discussed? I guess this is why Dr. Angela Yu and Stephen Grider are pretty effective instructors.

Analysis of the learner’s experience is the core method employed.

As the instructor would not be able to get all the details of the learner’s experience, I think the learner has to put some effort into relating how similar or how different one topic is from their own experiences.

Adults need self-direction; the instructor should help them engage in mutual inquiry.

I believe this method is effective even for minors. I would like to think that decent colleges are done this way.

The instructor must allow for differences in style, time, place, and pace.

This would be one of the hardest ones to do, but I fully agree that adults do have a particular time when they are most ready to absorb knowledge, as adults usually have a lot going on in their minds (you know, adulting, responsibilities, problems)

  • Survey: Scan the table of contents and chapter summaries for an overview.
  • Question: Note any questions you have.
  • Read: Read in its entirety.
  • Recite: Summarize, take notes, and put in your own words.
  • Review: Reread, expand notes, and discuss with colleagues.

SQ3R - Survey, Question, Read, Recite, Review.

The next book I read, I’ll do exactly this one, probably jot my questions down in some notes after surveying.

As you go along, recite, recall, and rephrase the most important bits from the book in your own words.

This is what I exactly do on my highlights. Although, at times, I structure it in a way like I’m responding to a highlighted text, more often than not, I do input my understanding down.

Take some initial notes on these ideas. Invent acronyms to help you remember lists and such. Really play with the information; use your R-mode, synesthetic constructs and more. What would this topic look like as a movie? A cartoon?

I’ll probably try to do this the next time around. But it does feel like a challenge, trying to “imagine” how the topic would look like.

Deliberate, repeated attempts at retrieval consolidate learning and strengthen the connections in your brain. Repeated input, by itself, doesn’t do you nearly as much good. Try to write a program in that new language you’re studying—you’ll need to retrieve the key information to do so. Try to explain key parts of that new methodology to a colleague. Keep at the retrieval—the testing of your knowledge. You might think of it as test-driven learning. And when testing yourself, you can take advantage of the spacing effect.

Test-driven learning. This is a nice term for something that I always found effective.

It’s hard when just learning the concepts, but once you go practical and hands-on, it’s way easier to grasp whatever is being discussed. Especially when you see “properly understandable" compiler errors.

I assume the same goes outside programming, where feedback is readily available would make it way easier for the student to understand whatever they are learning.

it is common to waste a lot of time preparing low-level, detailed design documents that become obsolete almost immediately.

This is a struggle to do, but I completely agree. Writing down actual code is usually a waste unless we’re just writing down a sample code that isn’t really related to the project’s code.

Why is it important not to be derived from the project’s code? It’s to remove all the complexities and nuances that exist in a project’s code due to probably unrelated business requirements. We just want to see a sample snippet that would describe whatever was being proposed in the design document.

Agile developers do create documentation, but they use a pragmatic filter to make sure the investment in creating any documentation is really worth the effort. It has to have value.

This is so true. Only large complicated subjects need documents. This is usually accompanied by “spikes”.

Turning your attention inward, as you would do when working with a mind map, sets up some condition in the brain that allows for happy flashes of insight later in the project. So, it might be that documenting is more important than documentation.

It seems understandable though, as we try to explore the topic, chances are it would be retained in our head, especially if we have access to the document we created. We would be able to get some sort of reference point in our brain where we would remember the context when we jotted it down.

Hand-drawing the cards emphasizes R-mode processes. The active creation of the notes/ cards helps prepare the mind for the later activity. Visualizing the sequences and maneuvers can help “groove” the mind (we’ll talk more about this shortly in Imagination Overrides Senses ).

This is interesting to experiment with. Although I admit that at times I do doodle when I’m stuck on a problem that I’m writing down on my notes, I have yet to observe a positive output that was directly influenced by some creative activity.

another powerful learning technique lies in teaching others.

When we teach, we reinforce the information that we know.

SMART objectives and a Pragmatic Investment Plan

(S)pecific narrow down to something concrete “I want to be able to write a webserver in Erlang that dynamically generates content” (M)easurable how do you know when you done? take small bites and measure steady, incremental progress you have to see only 2/3 feet ahead (A)chievable need to be realistic attainable from where you are now (R)elevant are you passionate about it? it needs to matter (T)ime-boxed needs a deadline

Gain Experience

Mark Twain’s overly generalizing cat (in this chapter’s opening epigraph).

This is the extreme end of “learning from mistakes”, where just because we encountered issues after a particular decision, we avoid any similar scenarios in the future.

When the cat experienced the pain of sitting on a hot stove, it caused the cat to never sit on a stove again, even on a cold one.

Why is this important in the context of learning from mistakes? Well, it’s because if really want to learn, we have to acknowledge that we could commit mistakes down the road. If we stop after committing a mistake or avoiding the subject, then one can argue that we didn’t really learn and explore the subject thoroughly.

It would be better if we picked up that mistake, analyzed where it went wrong and tried to look at another angle that we haven’t tried out and maybe has a better potential of succeeding.

We seem to have a cultural tendency to put the cart before the horse: you struggle to shovel in information first and then hope to maybe use it later. That’s the basis of most formal education and corporate training. But the real world doesn’t work that way.

I am guilty of this one too. Oftentimes, I want to learn something new in the hopes that I would one day be able to use it.

And I totally agree that this is not an effective way of retaining knowledge.

Papert worked with world-renowned Swiss psychologist Jean Piaget and also believed that real learning—the learning that sticks with you—comes from experience and cognition, not from explicit teaching or rote practice. Their approach is called constructivism: we build to learn, not learn to build.

This is the most effective way of teaching. Practical education.

point: structuring learning so that you can build on top of existing experience.

For experienced engineers, this is really important. Even defining the differences between what they are learning against what they know and are an expert in is very helpful.

We need to be able to poke at a problem, to explore it, or to “get used to it” (as we talked about back in Engage an R-mode to L-mode Flow ). Playing with a problem doesn’t make the problem any easier, but it gets us closer to how we’re wired to learn.

This is where the importance of creating an environment where failing is acceptable is truly needed.

When we find that a particular query did not output the intended output, we look at where it went wrong. I think this happens all the time in programming, and we learn from it a lot.

Working with new material or solving a problem in a playful manner makes it more enjoyable, but it also makes it easier to learn. Don’t be afraid of fun.

This is where Duolingo app shined. It made learning fun. But the price is a little not too fun though XD

To solve a problem, ask yourself these questions:

  • what are the unknown aspects?
  • what do you know? what data do you have?
  • what constraints and what rules apply?

it’s not important to get it right the first time; it’s important to get it right the last time.

Getting it right at the earliest time is really great, but not as “important” as getting it right the last time.

An efficient, supportive learning environment should allow you to do three things, safely: explore, invent, and apply.

As engineers, we have to be pragmatic in this regard. There are projects that are critical, and those are the environments where we should stick to what we know. And then there are projects that have a little leeway where we can explore a little more.

When you plant lettuce, if it does not grow well, you don’t blame the lettuce. You look for reasons it is not doing well. It may need fertilizer or more water or less sun. You never blame the lettuce.

This is the perfect illustration of when some skill, or even a project requirement, is misunderstood by the team. Let’s understand what’s the cause of the misunderstanding, and not blame the people for misunderstanding it.

instead of issuing a stream of instructions to the student, the idea is to teach the student awareness and to use that awareness to correct their performance. Awareness is an important tool in becoming more than a novice.

Treating humans as… humans is the best way to teach. This can also be adapted to promote ownership.

This is a key aspect to playing the inner game: don’t focus on correcting individual details, but just be aware. Accept what is as a first step, and just be aware of it. Don’t judge, don’t rush in with a solution, don’t criticize.

This highlight was in the context of effective teaching, which can be applied to problem-solving.

don’t try to get it right, but notice when it is wrong. Then act to correct it.

Don’t hyperfocus on making things perfect the first time, but notice when something goes wrong. Then act to correct it.

Pressure Kills Cognition

This is an eye-opener as I always considered pressure as a driving force for me to deliver what I need to deliver. However, I realized that I delivered what I needed to deliver using the knowledge that I already had, which at times might not be the right or optimal solution for the particular problem.

The mere presence of a looming deadline can panic the mind into failure.

I’m not convinced that it would panic the mind into failure as more often than not, the mind just defaults to what we know and solves the issue using the concepts that we’re most familiar with

these devout students, under the pressure of an important meeting, practically walked on the beggar’s head in their mad rush to get to the appointment. But a second group was told they had that same crucial meeting, only they were given some spare time between events—they weren’t in a rush. The students in this second group stopped to help the beggar; they took him to the infirmary, cleaned him up, and so on.

This example does not seem to be the best example. The reason why those students ignored the beggar is primarily a failure of how things were taught at their school.

I do not think it’s equal to the pressure one gets to deliver on time:

  • in the context of problem-solving, if it’s part of the requirements of the deliverables, then it will be done regardless if the deadline is tight or not.
  • as for the example, because “helping the beggar” is not a requirement to get to the meeting on time, and the meeting is clearly what is important. It could decide if they pass or not.

You might disagree with this notion of pressure. You might think you are at your most effective when faced with an imminent deadline. While that might have some validity for L-mode activities (and I’m highly suspicious of that), it’s a certain disaster for creativity and R-mode activities, according to Dr. Teresa Amabile.[

It’s not a good idea to brainstorm when the deadlines are near. The clear action here is that the team has to negotiate to extend the deadline as brainstorming in itself has a variable output, and sometimes would not yield anything.

But as for creating a POC? Pressure could force one to actually deliver something.

Not only are you less creative when battling the clock, but there’s a sort of after effect: a time pressure “hangover.” Your creativity suffers on the day you’re under the gun and remains depressed for the next two days as well.

Regardless if the specific activity required the L part or the R part of the brain, the after-effects of a high-pressure situation are the same. We usually need a cooldown period.

That’s why it’s a good idea to end a project iteration on a Friday. That’s why you really do need some down time after an unscheduled, panicked crunch.

One issue with ending a project iteration on a Friday is the possibility of issues that would prop up after deployment that would cause the team to go online over the weekend. Compare that with wrapping things up in the middle of the sprint, it’s a lot safer.

Allow recovery time for your time-pressure hangover.

Hello managers 😆

In addition to gaining experience in the real world, you can gain experience inside your head as well.

It’s pretty hard to do this in the context of software engineering. Or at least personally, I’d learn a lot more if I could do it in a practical way.

by surrounding yourself with highly skilled people, you will increase your own skill level. Some of that is from observation and application of their practices and approaches. Some of that comes from the fact that you’re conditioning your mind to perform at a higher level.

This is very true. It’s one of the first few things I learned from XSplit’s CEO, Henri Lerving. He said “I like to surround myself with smart people”, and from that moment onward, I preferred working in a group of smart individuals rather than being the smartest one in the room.

every read of your memory is really a write. Memory is far from inviolate; your increasing expertise will steadily add to the filters and pattern matching you employ. That’s how intuition grows: you have more patterns to draw on and apply, as well as a growing body of tacit knowledge to know what to look for and when. In other words, you’ll start to see the beginnings of expert behavior.

This is very true. We usually identify what scenarios a particular concept we learned is the best solution whenever we get to use it in practice, so the next time we encounter similar problems, we immediately know which solution has the highest chance of succeeding. This is what we usually retrieve during crunch times.

Manage Focus

You need to be able to focus on the information that you want, filter the information you are bombarded with, and have the right information available to you at the right time, without being distracted by irrelevant details and without missing subtle clues that make all the difference.

This is a skill that is hard to do. I struggle with this during refinements whenever I did not read the tickets before the meetings. What we need are:

  • Increasing focus and attention
  • Managing your knowledge
  • Optimizing your current context

What counts as “work” or as “effort”? Are you “cooking” when you’re letting something marinate for twelve hours? Are you “working” when you’re sitting around thinking about a problem? Yes, is the short answer.

This is an eye-opener on how we see things. This is a perfect example of why “Spikes” (investigations), although they do not produce tangible code, are very important, and are part of the effort done for a particular set of problems.

In general, if you can’t think of three ways a plan can go wrong or think of three different solutions to a problem, then you haven’t thought it through enough.

I recently talked about this with Richard, it is something that resonates really well with us, but more often than not, we even struggle to come up with 2 options.

a controversial study done in the United Kingdom noted that if you constantly interrupt your task to check email or respond to an IM text message, your effective IQ drops ten points. By comparison, smoking a marijuana joint drops your IQ a mere four points

wow, just wow. I usually ignore emails nowadays though, but slack messages are another thing. However, when I’m really in the zone, adding a slack status that I’m busy really really helps.

Beyond Expertise

Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now ➤ Faust, Johann Wolfgang von Goethe


No fancy copyright. Just creative commons | There's some vanity tracking going on, sorry | RSS.