Fractal Teaching and Learning

I’m sitting here in the cigar lounge, texting back and forth with a buddy of mine who’s being introduced to actual computer science finally, in the last stages of his coding boot camp. Exactly backwards.

I tell ya those things should be scorched from the face of the earth. They’re just awful. I’ve never even heard rumors of one that wasn’t just a god damned mess of details thrown at inexperienced people under the guise of being “an intensive study.” They get these kids to go in to hock thinking they’re going to break in to the world of software development after eight weeks of taking a firehose of undifferentiated information to the face.

The problem is they can’t tell the difference between “a shit ton of new material to absorb” and “a disorganized mess of untethered incomprehensible bullshit.” Now that’s no fault of the students, to be sure. How the hell would they know. But when people tell me what the hell they’re being “taught” (read: having thrown in their laps and left to figure it out) it makes my blood boil.

I swear they end up sounding like domestic abuse victims with Stockholm Syndrome. “Well I guess it’s good for me because it’s just way over my head.” NO man. It’s ridiculous what they’re making you go through and what they expect. It’s not “intense” it’s bad.

There are ways to teach this material that don’t involve a bunch of kids wanting to blow their heads off. It’s a matter of organization of the material, the methods of presentation, and sequence of exposure from the top down.

[If you’d told me 12 minutes ago that THIS was where I was going to end up going with this I’d have cackled like a maniac. Then I’d have been haunted that you were that insightful.]

One of the things that I loved doing when I was a developer was to (hold on to your seats now) talk about what I was working on. It’s one of the things that made me a pretty good coach on a 1:1 basis.

When presenting technical information (or perhaps any information, but I’ll stick with what I actually know something about) people seem to make the mistake that you can talk like a book. Actually people seem to be under the misapprehension that you can write a technical book like a narrative book, which is really what I mean.

People seem to be used to this wholly incorrect idea that information is best presented in a linear fashion, like listening to an album front to back. But that’s not how ANYthing actually works. It’s not how music is made. It’s not how books are written, even narratives.

As I see it writing is (or should be) done in a more or less fractal manner, zooming in and out between overarching themes and individual details.

It should be presented and consumed in the same way. Tangentially: This is why the Evelyn Wood speed-reading stuff is so interesting. It accounts for that deficiency about perfectly. As such I VERY highly recommend this: You can usually get it pretty cheap. Among the things it teaches is how to consume the information in a book in exactly the right way, with increasing levels of contextual familiarity from the highest most vague level down to word-by-word.

At a previous job I had a piece of software that I inherited and beat into shape, turning it from a godawful error-prone mess that required daily baby sitting into a multi-stage process that looked pretty complicated, but was “safe”, easy to manage, and fast as fuck (at least in relative terms.)

At one point I realized that while it was pretty central to our business processes, I was the only person who knew anything about it really. I mean, people had some vague idea, but if I got hit by a truck they’d be pretty fucked while they figured it out.

In software development there’s something called the Truck Number. The Truck Number is: How many people would have to get hit by a truck and die for your business to be well and truly fucked? The more critical information is in the hands of only a couple people, the lower your Truck Number. Having a low Truck Number is bad and is always a reflection of really shitty management.

So I have a half-day lecture on what this thing was, what it did, how it worked, the normal kinds of problems that would occur, and the heuristics to troubleshoot, diagnose, and solve them.

The job it did was pretty much as follows: Take files of data sent to us by customers and get them in to our database. Now, a LOT of things needed to happen to that data to get it ingested properly. Sometimes customers would send the same file twice. Sometimes there was shitty data. Sometimes there was duplicated data WITHIN a file. Sometimes there was SOME data duplicated across multiple ostensibly different files (i.e. overlap.)

All of these problems needed to be dealt with on the way in.

So the process was split up into four separate processes:

Initial load, cleanse, decorate, publish.

  • Load: Take “whatever the hell we got” into a clean separate environment, a staging location where it could be operated on further. This includes adding in things like “where exactly did this come from and when did we load it?” So we could track every single line-item to its source.
  • Cleanse that data: Format the dates correctly. Take dollar-signs off the dollar amount fields. There were about three dozen separate little operations like that.
  • Decorate: We had our own keys and information to represent each customer. They had no idea what that was, nor should they. But the data needed to be tagged with OUR information.
  • Publish: Take the cleaned up data and push it in to our system, making sure to leave out duplicates.

I designed and coded all of these steps so that any one of them could be re-run out of sequence at any time with no fear of stepping on our toes. So if someone found a bug in the cleanse or decorate processes, they could look at the data and the code and just rerun it, knowing it wouldn’t fuck up the production data.

Whatever, I’m getting off track.

Point is it’s a pretty complex series of moving parts to solve a relatively simple problem for the sake of safety and speed.

So I gave this little seminar in how it worked and was able to get everybody on board with what was going on by shelling down from the outside the way I did here.

1: “This is a thing that does this. It consists of 4 separate applications, run in sequence with these jobs. Each one does this and when it’s run we know what state everything is in.”
2: Let’s dive in to the mechanics of where the data comes from and roughly what operations are handled by each process, without drowning in detail.
3 & 4: I got down into the the weeds, with concrete examples from the code and the data, and increasingly detailed descriptions about my design decisions for performance considerations and data safety.

Now, because I’d given the 50k foot overview, then the 10k before diving into the muck, everyone in the room had the context required to picture what was going on.

Without having some grasp of the context in which information fits we really have very little ability to put it in its proper place to integrate and understand it. Again, it’s damn near redundant to say so.

EVEN if some of the people in the room didn’t understand some of the details (and there were a couple IT managers in there) at LEAST they had a broad brush understanding of how it was all supposed to flow. So they could see what was going on, were able to understand “yeah this failed in stage 3 because of soandso” and were able to ask useful questions.

If I’d started with “the parser auto-detects the format of the incoming data based on the following four factors” their eyes would have glazed over almost immediately.

You can’t DO that to people. It’s rude at best and contemptuous at worst.

But if you go to a udemy course on…oh, whatever the fuck, it’ll almost always be “in this course we’re going to .” then they just dive straight down to the bottom, opening an editor (usually Visual Studio Code because that’s en vogue) and starting to code.

Even if the course is good, when they present the information that way you have NO choice but to hang on to every word and type along with them to see what’s going on. If you miss something you don’t really know what it is you’ve missed or what the repercussions might be. You end up coding along with them, not sure why you’re doing what you’re doing. I have to assume there are exceptions. But I haven’t seen them.

It’s inFURIATING. I’ve followed along so many of those courses and some of them end up having been really good. But even the best suffer from this horrible structural deficiency.

It’s time for a change in the way we teach these things. I’m sure this is relevant to topics aside from software development.

But maybe this just means it’s time for me to start developing my own courses.

It’s something I’ve been batting around in my head for a while. I just need to come up with a project to start with to build my first and see how it goes.

I’ve got a couple ideas. I’ll let you know.

Leave a Reply

Your email address will not be published. Required fields are marked *