How I’m learning programming

This is an outline of how I’m personally going about learning to be a better programmer, and learning to build webapps in particular.

Starting

All of my programming learning is project-based: I just dive right into trying to build some tool or script that would be concretely useful for me personally. (Whether or not it would be useful to someone else is not a question that I consider at all.)

I keep a running list ideas for applications to build, processes to automate, and new features for software that I’ve already built, and I pick projects from that list. I’ll bias towards things that are fast to build, things that I think I might use every day, and things that are just beyond my current knowledge of how to start.

So far this tends to be…

  • scripts and processes to automate or streamline workflows that I already do manually, or
  • Tools that somehow make it easier or faster for me to learn or practice something.

Then I’ll find a tutor to help me. If I’m hacking on or extending an existing piece of software, I might find the community hubs for that software and make a post saying that I’m a medium-novice programmer, I’m interested in building some [whatever] extentions, and ask if anyone would be interested in tutoring me, a combination of teaching me how to do it and pair programming with me, in exchange for money. For instance, when there were some simple roam extensions that I wanted to build, I asked on the #roam-hacking channel of the roam slack, and found a person to work with that way.

For this, I’m usually not looking for someone who’s done a lot of tutoring, necessarily, just a moderately skilled software engineer who’s familiar with the software we’re working with.

For projects that are starting from scratch, I’ll start by writing a one page spec of what I’m wanting, and ask my software engineering friends what tech stack they think I should use. Then I’ll search for tutors on Wyzant.com who are familiar with those technologies.

With Wyzant tutors, I’ll typically try a few over the course of a week or two to filter for one that’s really good: one of the main features that I’m looking for is if they’re tracking what my level of understanding is (Are their answers to my questions meeting me where I’m currently at, or are they skipping over inferential differences?) and how easy is it to get them to give me the space to think through a problem myself, instead just telling me the answer.

Each session

I’ll typically book 4 hour sessions with a tutor, with a planned 20 minute break in the middle.

I always do programming sessions with a dual monitor setup: VS code and the application itself (in a browser usually), in the larger external monitor, and a notes page on my laptop monitor.

Depending on how familiar I am with the tech stack that we’re working with, the tutor might be almost entirely steering. But I do all of the typing, and I ask questions about what various things do and why as we go. Anything that feels “big” in my mind, I paraphrase back, to consolidate my understanding.

I’ll take notes on key concepts and on the syntax of the language that I’m using. I also air on the side of commenting too much, leaving pretty detailed notes about what each block of code does for future-Eli.

For any given bug, I’ll generate a sketch of how I would try and solve it if I were working myself, first, and then the tutor might share their solution. Usually my solution would work, but their solution has better design principles. And usually, hearing their solution I’m able to correctly guess / extrapolate what those design principles are. I’ll paraphrase, and then take notes on those as well.

Within a day or two (a few days at the most), I’ll review all my notes from the session, during batched notes review, and make anki cards for all of the new syntax, so that the fiddly procedural details are “at hand” for me the next time I need to use them.

After we’ve completed a large section of the code, I might spend a whole session or more walking through the program-flow: where does it start, and which functions trigger which functions. In the process I’ll streamline the code or rename variables to be easier to follow, and leave comments describing what the code is doing, but mainly I’m consolidating and compressing my understanding of the whole interlocking machine of that code section.

I might also spend whole sessions refactoring my code, if the way the project developed

I’ll hack away on a project like this, with the tutor’s help, until I get my feet under me.

Reading documentation

One specific sub-skill to develop to being able to program independently is reading documentation.

I don’t have much of a handle on how to do this yet, but I suppose that I should use the same basic pattern as above.

For any particular piece of functionality of a given library, I start trying to look it up myself. Maybe I should read for a time-boxed 5 minutes, narrating my thought process out loud as I go, and then at the end of 5 minutes have the tutor offer feedback about my search process: were there hints about whether a given bit of documentation had the info I wanted, or not, that I missed?

As I mature

Eventually, I’ll get familiar enough with a given tech stack, I know the key steps for how to get started with a project and the basic alphabet of basic functions and syntax to compose.

When I reach this stage, I’ll start starting projects on myself: sitting down and trying to build the tool that I want to use.

However, I’ll still have a low bar to booking a tutoring session, to ask for help if I get stuck.

If I don’t know how to build something, I’ll ask ChatGPT (or similar), including asking followup questions. But if I don’t feel like that’s giving me a conceptual model or it isn’t solving my problem, I’ll book a session with a tutor to go over it.

And when I’m debugging, I typically don’t spend more than an hour trying to root out the bug, before either asking a friends or hiring a tutor who has more familiarity with the specific tech stack that I’m using.

Leave a comment