In “Advice to beginners” I said, “Learn how you learn,” and many people stepped up to tell me that learning styles are a myth. I know the research about learning styles, but people are over-applying it to dictate how people should learn.

If you haven’t heard about the theory and its debunking, you can read about it in The Atlantic or Education Next. Briefly: the theory was that some people were inherently visual learners, while others were textual learners, among other kinds. This has been proven untrue.

When I said “learn how you learn,” I meant for learners to take an active role in choosing what their path should be. I’m not talking about the four modalities from the debunked “learning styles” myth. There are many effective ways to learn how to program, and you have to choose your way. There are lots of possible choices:

• Do you want to start with computer science theory, or jump into writing small programs?
• Do you want to know the inner workings of things, or just how to use them?
• Do you want to work on small exercises, or choose a project of your own?
• Once you’ve started a project, do you complete it, or are you willing to leave things unfinished because something else has drawn your attention?
• Do you work a fixed amount of time each day, or do you adapt as your energy waxes and wanes?
• Do you want to dive deep into one technology or language, or dabble in many?
• Are you proactive (learn what you might need it later) or reactive (learn what you need right now)?
• Does studying with others help you, or are you better off learning alone?
• Are you choosing an industry, and aiming your work directly at it, or trying out many different domains?
• Do you like videos, or reading text?

These aren’t always binary choices: you might be somewhere in the middle, or shift over time, or seesaw back and forth. Understand what works for you.

I saved videos vs text for last because it seems to be the most contentious. Many people will tell you that watching videos is a bad way to learn programming. I agree that passively watching videos can lull you into thinking you understand concepts. You must write code to truly cement your understanding. Videos can be a fine way to learn, as long as you are active in the learning. But some people will simply rail against videos entirely.

Some experts lean too hard on “learning styles are a myth” and “videos are bad.” This seems to be just another gate-keeping flavor of “the way I did it is the right way.”

The debunking of learning styles was important because teachers were being expected to develop curriculum in many styles to suit different students’ needs. This was extra work, and could also prevent the students from developing learning skills in other modalities.

But I’m not talking about teachers’ choice of modality. I’m talking about learners finding paths that work for them. Today we have an abundance of learning materials, and learners have to choose among them. Everyone has be empowered to use the ones that suit them. This is a much bigger range than visual/textual/auditory.

Learners have to learn how they learn, and choose the path and materials that work best for them.

I often see questions like, “I’m just starting to learn Python, any advice?” The expected answer is something like “watch this video,” or, “here’s an awesome tutorial,” but more important are some tips about how to learn technology in general. Here are mine:

Learn how you learn: Some people like videos, some like books. Some like bite-sized tips, some like hour-long tutorials. Figure out how you like to learn and do that. There’s no wrong answer, there are just different answers for different people. Update: I wrote more about this in “The myth of the myth of learning styles”

Do things: If you aren’t sure if something will work, try it. Choose a project and start writing it. Lots of learning tools can be too passive. Write code. Write more code. Get your hands in there, do things and find out what happens. You’ll learn best by doing.

It doesn’t have to be new: Writing a project is a great way to learn, but your project doesn’t have to be innovative, or profitable, or new, or even useful. Sure, it would be great to have an idea like that, but you will learn even if you are building something that has been done many times before. Keep in mind why you are building it. You’re a learner, not an entrepreneur.

Be introspective: Think about what you’ve done, and what you like or don’t like about it. When you’re done with a project (or in the middle of one!), think about what you might do differently. Being self-aware about your choices and their results will teach you more than any tutorial.

Do it more than once: If you have questions about which path to take, try a few and compare the results.

Don’t measure yourself against others: “How long did it take you to learn Python?” It doesn’t matter. Everyone is on a different path, with different needs, different starting points, and so on. Learn at your best pace. It’s not a competition. For more of my thoughts on this: How long did it take you to learn Python?.

More languages isn’t better: Beginners will say, “I’ve learned Python, what language should I learn next?” Don’t measure your progress in number of languages. More important is to learn new techniques (database, web, testing, concurrency, etc.) in the same-old language. Rushing from language to language will probably make you a beginner in all of them.

Be open to change: Once you’ve made a choice, you can change your mind. Requirements change, technologies change, interests change. Nothing is written in stone. Explore where your interests take you.

For a long time now I’ve displayed a small textual info box in the otherwise unused upper-left corner of my mac screen. It was originally based on GeekTool, but a new laptop got me to re-think it, and now it’s implemented with Hammerspoon.

Hammerspoon is a Mac automation tool driven by Lua programs. It has an extensive API for integration with Mac facilities, so it can automate many aspects of the OS, potentially replacing a number of Mac utilities.

GeekTool was always a little odd and configured much of its behavior in fiddly property panels. Hammerspoon is fully driven by .lua files, so it fits my programmers’ world view better. GeekTool also seems unmaintained these days.

On my Mac, I hide the menu bar and move the dock to the left side. This maximizes the vertical space available to my own windows. But it leaves a small corner unused in the upper left. I have a small Python program that collects information often displayed in the menu bar (date, time, battery level, sound volume, etc). With Hammerspoon I can create a small canvas and display the program’s output text.

It looks like this:

Here’s the Lua code that runs the Python from Hammerspoon and draws the canvas:

-- ~/.hammerspoon/init.lua

-- Text-mode "menu bar indicator" replacement
canvas = nil
function createCanvas()
    if canvas then
        canvas:hide()
    end
    local screen = hs.screen.primaryScreen()
    local frame = screen:frame()
    local fullFrame = screen:fullFrame()
    canvas = hs.canvas.new({
        x = fullFrame.x,
        y = frame.y,
        w = frame.x - fullFrame.x,
        h = 175,
    })
    canvas[1] = {
        type = "rectangle",
        action = "fill",
        fillColor = {hex="#D0D0D0"},
    }
    canvas[2] = {
        type = "text",
        frame = {x=2, y=0, h="100%", w="100%"},
        textFont = "SF Pro Text",
        textSize = 14,
        textColor = {hex="#000000"},
    }
    canvas:show()
    canvas:sendToBack()
    drawInfo()
end

function drawInfo()
    local openPop = io.popen("/usr/local/bin/python3.10 ~/bin/textstatuses.py")
    canvas[2].text = openPop:read("*a")
    openPop:close()
end

-- Start over when any screen geometry changes.
watcher = hs.screen.watcher.newWithActiveScreen(createCanvas):start()
-- Redraw every 10 seconds.
timer = hs.timer.doEvery(10, drawInfo)
-- Redraw when any audio setting changes.
for i, dev in ipairs(hs.audiodevice.allOutputDevices()) do
    dev:watcherCallback(drawInfo):watcherStart()
end

This has a few advantages over GeekTool: it’s entirely self-contained in a text file I can commit to git, it can listen for events to be more reactive, it can compute its location to take the menubar into account, and so on.

Theoretically, Hammerspoon can also replace other Mac widgets like Caffeine, Rectangle Pro, and so on. I haven’t tried replacing them all, but it’s probably in my future.

One interesting side-effect: learning Lua!

Update, September 2023: now the Python code has been replaced with all Lua code.

In 1993 (30 years ago!), Alan Kay wrote The early history of Smalltalk, explaining the origins of the language’s ideas, its development, and an assessment of its successes and failures. It’s a thought-provoking piece for a few reasons.

First, his description of the central idea of object-oriented programming:

Everything can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of process and state inside itself.

(All his quotes here are slightly edited.)

He is of course describing objects. But notice his emphasis on the composition of objects. Many people these days offer the advice to favor composition over inheritance, which seems counter-intuitive to people raised on C++ or Java. Yet here is Kay, who coined the term “object-oriented,” literally using the word composition to describe the key idea.

He goes on to disparage object orientation being taught as a way to encapsulate data structures. He sees methods not as actions, but as goals, something I haven’t wrapped my head around. His original insight for objects was that each should be thought of as a complete computer, and complex systems could be recursively subdivided into smaller and smaller machines exchanging messages. It’s interesting to hear this idea in today’s world of networked micro-services.

Second, the piece is a real mix, moving from historical details about long-forgotten machines to philosophical asides (he references Plato, Leibniz, and Hobbes), to other computer luminaries of the time (Minksy, Papert, Perlis, Lamport, and so on).

Along the way are details about the difficulty of being advanced researchers inside a company like Xerox, finagling budgets and adjusting projects to get things done despite the environment.

Lastly, what motivated Kay was the idea that computing could become a personal activity. When he started, computers had rooms devoted to them. He struggled to build machines that could be carried. He wanted computing to be something that everyone could do, not just consuming content, but creating programs for computers to pursue individual ideas. In the ‘70s when the main work on Smalltalk was happening, computers weren’t used for content at all. When he said “computing” he meant programming and running programs. He saw computing as a liberal art: a way to see the world and a way to develop deeper understandings.

Because of this, his thinking about computing was intertwined with thinking about learning and teaching:

Knowledge is least interesting when it is first being learned. The representations—whether markings, allusions, or physical controls—get in the way and must be laboriously and painfully interpreted. From here there are two useful paths which are important and intertwined.

The first is fluency, which is building mental structures that disappear the interpretations of the representations. The letters and words of a sentence are experiences as meaning rather than markings.

The second is taking the knowledge as metaphor that can illuminate other areas.

The “trick”, and I think this is what liberal arts education is supposed to be about, is to get fluent and deep while building relationships with other fluent deep knowledge.

He calls this fluency with deep ideas “literacy,” and goes on to give a prescient example, including his dream of the ways people might use computers:

Another kind of 20th century literacy is being able to hear about a new fatal contagious incurable disease and instantly know that a disastrous exponential relationship holds and early action is of the highest priority. Another kind of literacy would take citizens to their personal computers where they can fluently and without pain build a systems simulation of the disease to use as a comparison against further information.

At the liberal arts level we would expect that connections between each of the fluencies would form truly powerful metaphors for considering ideas in the light of others.

The reason, therefore, that many of us want children to understand computing deeply and fluently is that like literature, mathematics, science, music, and art, it carries special ways of thinking about situations that in contrast with other knowledge and other ways of thinking critically boost our ability to understand the world.

Now 30 years later, we have not achieved Kay’s ideal. Everyone has a powerful computer, not just on their desk but in their pocket, but they are used for consumption and socialization, not computing. I won’t wring my hands about this: Kay’s ideal of liberal arts as a way to build deep fluency isn’t happening to the extent he would like outside of computing either.

I am interested in how to help more people learn computing in Kay’s sense. Highlighting fluency and metaphor is insightful. They are good north stars for education of all sorts.

One thing I wish I had mentioned in my PyCon 2023 keynote: small talk. Engineers often find small talk difficult. I know I’ve had trouble with it. It can feel like “talking about nothing.” But small talk helps build connections between people.

If you haven’t seen the keynote (you should watch it!), a central idea there is that our words carry both information and sentiment, that sentiment is important for being heard, and that missing sentiment is defaulted from history and similarity.

That model gives us a way to see the value in small talk, even if it’s about nothing: simple chatting about simple things can be positive interactions that build a history. Talking about non-work topics can uncover surprising connections, adding to a feeling of similarity. These both create a reserve of good sentiment to draw on in future interactions.

Talking with another engineer recently, they said, “small talk feels unnatural to me.” I think what they meant was that they weren’t intrinsically interested in the discussion. A good definition I heard once is that a nerd is someone who is unfashionably focused. Small talk won’t fall into their narrow focus, so it feels useless or boring.

In the keynote I make the point that engineers are good at learning new skills, and people skills are no exception. You can bring engineering approaches to getting better at people skills. Small talk can be difficult even with this in mind though: you can’t see the reservoir of good will you are building with someone.

As my engineer friend put it in classically nerdy terms:

It’s not clear if  conversations[-1].outcome == Outcome.GOOD

I get it, I’m not sure I’m that good at small talk myself. I don’t have pets, I’m not a foodie, I don’t drink beer, I don’t play video games, I don’t know anything about Magic The Gathering or anime, and so on. It can be hard to find something insubstantial but shared to talk about. And “insubstantial” doesn’t sound good in the first place.

Connecting with people is worth it, small talk is a good way to connect with people, and everyone can learn to be better at it. Did I mention I gave a keynote about interacting with people?

Boston Python runs weekly office hours, and I noticed the discussions there often start from a familiar point: how do I get my Python environment to work?

This is a question that recurs in any Python support arena. Python has gotten a lot of heat for environment complexity, but that complexity is due to a number of factors, none of them bad on their own: Python has been around for a long time, it’s used in many different ways, it lends itself to experimentation with tooling, and so on.

I don’t want to gripe about the complexity, and I don’t have a proposal for how to reduce the complexity. What I would like is a resource that people can use to find their way through the complexity.

I’m imagining a self-guided tour that would ask questions about what the user needs, and would bring them to pages with solutions. It would be similar to a Choose Your Own Adventure, but for Python environments. I’ve even started toying with tooling that could produce pages like that.

But there are a number of possible questions that people could be starting with:

• How do I install Python?
• How do I install modules to use?
• How do I package my code for distribution?

Answering any of these well requires finding out details from the user:

• What domain are you working in?
• What kind of expertise do you already have?
• How deeply do you want to be involved in the decisions?

And then more technical details:

• What operating system?
• What shell do you use, if any?
• What editor/IDE do you use?
• What version of Python?

and most of these might be answered with, “I don’t know, can you tell me which to use?” which just leads to more attempts to educate and explain complexities that to the user feel like distracting confusing trivia.

Even harder is the question, “I tried to do it myself, but it’s not working, how do I fix it?” Untangling that requires forensics and details, then education about the inner workings of things and how they got mis-configured.

As tempting as it is to try to capture all of the possibilities and solutions in a flow chart or adventure game, it’s almost certainly impossible to solve most peoples’ problems.

Has anyone seen examples of instructional materials organized in a decision tree like this? Not even about Python, but about anything? I feel like this is impossible, but if it could make a dent in the difficulties people are having, it could be very valuable. I can’t quite get the idea out of my head, and I can’t make a serious start on it.

What can I look at to learn from? Not learn about Python environments, but learn how to construct self-guided decision tree materials?

Update: Dennis Dawson reminded me that I previously blogged about On undoing, fixing, or removing commits in git, which has been updated to be more dynamic at Git Fix Um. These are a good example of the kinds of thing I am looking for.

More update: I got some more suggestions of examples of this sort of thing. SmartBear Online Troubleshooter is a classic wizard flow. There are a few for installation instructions:

• Download and install Zabbix
• Install spaCy
• LineageOS

More: Veracode cheatsheet and PyTorch Get Started.