The Need to Grind Concrete Examples Before Jumping Up a Level of Abstraction

> What a lot of math learners fail to understand is that grinding through concrete examples imbues you with intuition that you will not get if you jump directly to studying the most abstract ideas.

I feel that's more a lesson for a lot of math teachers to understand. I remember some frustrating linear algebra, calculus and computational complexity courses where the lector basically threw some formulas onto the blackboard, went line-by-line through a formal proof of their correctness and then called it a day. Giving actual examples of the application of the formula was an afterthought left to the student aides. Giving examples that could explain the derivation of the formula was not even considered as an idea.

It always reminded me of someone teaching an "introduction to vi" course but then just scrolling through vi's source code without any further explanation - and in the end expecting the students to be able to fluently use vi.

That's the same principle which makes it wise to first do some copy pasting before you abstract stuff into a common library. Gathering some (more than two) concrete use cases before you factor out the common functionality makes much better library functions.

A common sign of prematurely deduplicated code is a common function with lots of boolean flags and other knobs to tweak its behaviour for every use case added after it was written.

This is presumably about math problems, but I always approach programming problems this way.

One issue I have with math problems is that sometimes I wish I could immediately go down one level of abstraction and see something like a physics or programming problem that applies that specific or related problem I'm working on. I haven't found a resource like this yet.

Ironically, this post would benefit from showing some examples.

This was something that really lacked in my statistics degree. We were always learning different distributions, proofs and estimation methods but very rarely applied them to actual problems. I feel like you can kinda get away with this type of thing in math more, but in statistics, it makes things super hard to learn.

I’m adopting an Example Driven Development approach in my latest project. The project is a library/framework with a public interface. EDD is great in this case. To explore and experiment new features, I turn the use cases into runnable examples and use those to drive the internal implementation. This combines feature implementation, documentation, examples, and testing in one shot.

Yes, exactly. See [0] for a concrete example of an abstraction that can't be grokked without grinding concrete examples, and how people who have already grokked it forget this fact.

[0]: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

A concept I learned about in Knowledge Based AI (gatech ONSCS) is called “version spaces” where instead of starting at specific examples and moving to be more general or the other way around you do both as a kind of knowledge bidirectional search. I feel humans work that way too. We need both specific examples and generic models to help us converge to a deeper understanding of topics.

Relatedly: struggling is learning [0].

[0] https://news.stanford.edu/stories/2019/09/embrace-struggle-e...

This applies to code as well. I worked on an internal PostgreSQL protocol driver for work and I've been focusing on understanding the binary message format inside and out, then the server state machine and query behaviour, and only then building a driver.

Don't underestimate the value of time spent grinding the low levels for code that is fundamentally important to what you are doing. You come away with a much stronger understanding than if you just hack a solution, cargo culting some existing code and just shipping it.

The author is generalizing their preference here to say it's "right". Some brains need this, others need the abstraction before the examples provide the most benefit.

As noted by others this preference influences how one learns code effectively too. It's a pretty basic trait.

The author's stated preference is most common but it is not the only one.

Yes. I think I did well in math/physics classes in college and grad school just because I found the most effective way to study, for me, was to grind out as many problems as possible. Go through the old homework, old exams, books, anywhere you can find relevant problems with solutions to check against.

Makes sense. I always intuitively understood that going from for example electronic engineering to computer science is probably easier than the other way around, but this article makes a great point. Without some low-level knowledge, you do not fully understand the higher level. Then you can only parrot the higher level (I’m also looking at you here LLM).

It depends. Some people most certainly grasp things better if they are concrete, grounded in their perception of reality. For others, they see each 'example' as a mere partial projection at best that completely fails to capture the true essence of the abstraction.

That said, in sloppy engineering we often see the reverse. 'Here's a meta-model I cooked up overnight. Now if you spend the next 3 years gathering all the domain knowledge and expressing it in my nifty notation, you can have the outline of a potential candidate for your question. I'll write up a journal paper tomorrow about how I solved your problem'. There was a lot of that around when I was in academia.

With history classes in high school I wish they bumped up the abstraction level a little sooner. All those dates and names of important figures, almost completely useless information imho.

I need to grind concrete examples before jumping to theory.

Don't know how I finished my CS degree, because most of the theory I just understood years after leaving university and doing some hands on work...

That's how I make my grind easier, in Leetcode. Go direct to solutions first, to get intuitions.

And then the author gives zero examples

Similar to grinding scales on a music instrument.