Category Archives: Software Development

What Would Drumeo Style Coding Tutorials Look Like

I’ve watched dozens of Drum videos even though I don’t play drums and have no interest in learning how. But, I am interested in their teaching style. If you haven’t seen it, Drumeo is a website with drum lessons, charts, drumless tracks (for you to practice with), and suggestions for how to drum songs based on your level. It’s this last kind of lesson, shown in “The Five Levels” series, that should be emulated in other disciplines.

In a “The Five Levels” video, someone from Drumeo plays a song with an iconic drum track. Then they show you how to play a beginner version—sometimes with just one stick, or maybe a stick and a pedal. You are mostly keeping the beat. Each level progresses by incorporating a new skill and a new part of the drum set. By the fifth level, you are playing what the original drummer played. This idea works for coding lessons as well—in fact, it’s how I learned.

My first two programming lessons (in middle-school) were essentially like this. In the first one, we were given the code to draw ASCII art on the screen, but we added the data for exactly what we wanted to draw. Then we had to figure out how to add animation to it. In the second lesson, we were given a working slot machine game, and we were asked to alter it so that we always won. In both lessons, we started with a working system.

For both drummers and programmers, this is what the work really is—adding something, not building from scratch. In my career, I started something significant from scratch a few times a year at most, but I altered something that otherwise worked nearly every day. It’s baffling that the vast majority of tutorials start from an empty directory and teach you how to do something programmers barely ever do.

How to be avoid being replaced by AI

Right now, I am an independent software developer, and so I own all of the code I create. So, of course, I want it to be as efficient as possible to write that code, and I use AI to do that. I get all of the benefit. I am not replaced—I am freed up to do other things.

All of my consulting income comes from work that originated from my network, cultivated from over 30 years of delivering on my commitments. Some of it is because I am one of only of few people that understand a codebase (that I helped create and partially own). There are very few people that could replace me in this work, even with AI. Even if AI were able to 100% reproduce everything I say and write, the client wouldn’t know how to judge it because their judgement of me is almost entirely based on past experience.

It’s not just AI—there are many people who are smarter than me, with more experience, who work harder, and have better judgement. But if they are completely unknown to my clients, they couldn’t replace me.

Of course, I realize that this isn’t something that one could just replicate immediately, but if you are building a software engineering career for the next few decades, I recommend cultivating a network that trusts you based on your past performance and owning as much of your own work as possible. When you do that, all of the benefits of efficiency flow to you.

Thoughts on Tool Making

In my career, about two-thirds of that time I was making something more like a tool than a solution. For Droplets and Atalasoft, it was developer SDKs and for Trello/Atlassian, it was a productivity tool. Our customers used our software to build things. I feel like I did my best work during those times and enjoyed it the most. So, one of the things I am trying to do in 2025 is get back into tool making.

My inspiration is what I’ve called the Great Works of Software and the Great Works of Software Poetry. All of the works I cited in those articles were tools that the authors were using to make something else. I also noticed (after the fact) that 5 of the 7 works I cited were made to help publish writing: TeX, HTML, VisiCalc (for business cases), Markdown, and WikiWikiWeb. Other “great works” like Postscript, PDF, and Alan Kay’s Dynabook concept are also along these lines.

So, perhaps I should be looking at my own publishing aspirations. I did that a couple of years ago when I made Page-o-Mat to make a custom journal. All of the updates to it have been driven by what I wanted in my journals. I had to make it because I felt true friction with existing tools. I could have made my journal in a word processor, but the repetitive nature of the journal pages calls for a programming language.

The pattern of creating a programming language for creating documents seems to come up often. Aside from coming up with words, all of the rest is a pain and ripe for automation, from layout to distribution. Coming up with words is also a pain, but that’s a part I want to do.

Write Test Plans for Every PR (and do them)

On the ticket/issue/item attached to your PR, write out the steps to see the change in the application your PR introduces. Even better, record yourself doing them. Not just the happy path, but also show the types of errors that can happen and how the application shows them.

I wish I did this more when I worked on a team, but when I did, everything went smoother through code review and QA. Not because it helped the reviewer or QA engineer—I’m sure it did.

Mostly it helped because I made sure I did all of the steps in the test plan before I posted the PR. Also, writing down a test plan put me more in a tester’s mindset where I was trying to think of things to check and finding problems before I submitted my work.

With all of those things out of the way, the reviewer and QA engineer could concentrate on bigger picture things to check.

How to Find Bugs in a Code Review

I have written that the primary reason to review code is knowledge sharing, not finding bugs, and that the way to use code reviews to prevent bugs is to reject PRs that aren’t obviously correct. But what should you do if you really want to try to find bugs during review?

Run the code—preferably in a debugger from a test.

The best tip I got from Steve Maguire’s Writing Solid Code [affiliate link] was to step through my code in a debugger as I was writing it. The original version of this book (1993) came out before xUnit based unit-testing took off, so I don’t remember him mentioning them. But, I think a unit-test is a better way to do this.

If you don’t have a test that puts you at the line of code you want to inspect, then driving the code manually while stepping through the code in a debugger is a good-enough option. Of course, not having appropriate tests is probably a good enough reason to send the PR back, but if that’s not your team’s culture, and you want to find the problems manually during review, at least use a debugger.

It’s more likely you’ll see problems if you are actively engaging with running code. You will be anticipating what is going to happen as you step through, and if the code behaves differently, you’ll notice. You’ll either find a problem or learn something.

How to use Code Reviews to Prevent Bugs from Getting Into Production

When code has a bug in it, that is way more of an author problem than a reviewer problem. I don’t think it’s right to expect reviewers to find bugs (or to rely on it). It’s way harder to do that unless you actually run the code.

So, I would suggest that to fix the problem of buggy code making it into production, you do more things at the author level, since the author should be running the code a lot through tests and in the debugger. If you have a code reviews checklist, give it to the author, who should be reviewing their own code before PR’ing it.

Then, the reviewer should be verifying that there is evidence that the author actually did thorough work. The review checklist should be verifying the author provided evidence that the author did the pre-PR checklist. Check the tests, check their coverage, check UI screenshots, check that code is doing “something” with edgecases and that those are tested. Instead of looking for bugs, the reviewer should be learning the code and looking for higher level issues.

The author should be providing code that is correct and easy to see that it’s correct. If the reviewer doesn’t think it’s obviously correct, they should reject the PR. The presence of such a review will make the author do more thorough work.

My Year in Weeks

I released my 2025 Journal PDF (for Supernote) yesterday, and in the middle of describing it, I realized that I have never explained how I plan my year around weeks and 13-week blocks. There are mentions of it in a few posts, but nothing canonical.

I use a week as my main planning timespan, not months or quarters. Additionally, I use Monday as the first day of the week, which is normal for a lot of the world, but not Americans. When I think of how a week flows, the Saturday and Sunday are a unit. I think of them as the start of the week, but almost no software will let you do that, so I got used to them being at the end.

So, all of my projects are estimated in terms of weeks, and I program in sprints that are a multiple of weeks. Then, I split the year into four 13-weeks “quarters”, which is close to a year (364 days). This year, 2024, started on a Monday, and because it was a leap year, April 1 and July 1 were exactly on 13-week boundaries (Oct 1 was only a day off), so my system correlated to normal quarters about as well as it ever could. This doesn’t happen again until 2052. I hope I am there to see it and that I still care.

My journal is set up to follow the flow of a week. Days of the week tend to be similar to each other—so, there is a feel to a Monday, a Tuesday, a Sunday, etc. But March 3rd will not be like April 3rd or October 3rd. A lot of recurring meetings are weekly or bi-weekly, or on the “Third Thursday of the Month” or some other pattern that works well with my system.

When a year doesn’t start on a Monday, I have to incorporate some of the previous year into it. For me, 2025 starts on December 30, 2024. I usually start my yearly goals in the previous year just to get a running start, so it doesn’t really matter if a few extra days get into my journal.

If I have to deal with something that is on a month or quarter boundary, they are just a regular day in the journal. External deadlines can be on any day.

If this sounds good to you, you can use my 2025 Journal (PDF).

My 2025 Journal PDF for Supernote A5

I finished adding features to Page-o-Mat to support the journal I wanted to make for 2025 to use on a Supernote Manta. I fixed some bugs and added the following features:

  • Internal Links to pages: This is supported in titles, section titles, and rectangles
  • Start/End Dates on Pages: This is so I can show a date range in a title
  • More support for using expressions as values: This is so I could calculate a page link inside a loop or do more date math.

My Journals do not use heavily templated pages—Most pages are nearly blank, but they have a 5mm dot grid on them. You could do bullet-style journaling, sketches, or whatever you like.

The main opinionated thing I do is that my year is based around four 13-week “Quarters”, not the months or the typical quarters, and my weeks start on a Monday.

So, 2025 starts on Monday, December 30, 2024 and goes to Sunday, December 28, 2025. I did add on the week after, though so that Dec 29-31 are in the Journal (and the rest of that week). The full 2025 journal is 53 weeks with a little of 2024 at the beginning and a little of 2026 at the end.

Download my 2025 Journal

Since this was created with Page-o-Mat, you could customize it and make your own. See the config file in /config/2025-journal.yaml in the repo. The script uses Python—I added installation instructions to the README.

EDIT: More explanation of my system in My Year in Weeks

Page-o-Mat Updates for Electronic Journals

I wrote Page-o-Mat because I had an idea for a paper journal that I wanted to make. I could have just made a PDF, but making each page was a repetitive task that was easier to do with code. I could have just made a python script to make just that journal, but I was still designing the journal, so I put some configuration in a YAML file. Once I did that, the config grew to the point that it became a language for making journals. I made my 2023 journal with it and got it printed by LuLu.

In mid 2023, I wanted to make a different kind of journal (one for writing Morning Pages), and so I added some features to draw shapes on pages, which I also used to make covers. Later that year, I made my 2024 journal with it without needing more features. I hadn’t touched it since then.

I like my custom paper journals, but they are thick and heavy, so I am trying something different for 2025. I finally found an E-Ink tablet that I can use to replace my Kindle and get a more portable writing/journaling solution too.

I’ve been looking at E-Ink writable tablets. After considering the Kindle Scribe, Daylight, and Remarkable, I decided that I cared about a few things:

  1. It had to be hard to use the machine for anything but reading and writing because I want it to be more like factory equipment.
  2. It had to have a long battery life (like the Kindle).
  3. It had to be easy to get files to and from the device (unlike the Kindle).
  4. It had to be able to read Kindle books.
  5. It had to be readable in sunlight (I live in Florida and read at the beach).
  6. It had to be A5-sized.

The only device I found that met all of these criteria was something that Supernote used to make and said they would make again. I signed up for updates and waited. Then, I forgot it existed. I almost got a Daylight in the meantime, which is a nice device, but it’s too nice—it can easily run any Android software, so it’s too general purpose. I want a “worse is better” machine.

But a few weeks ago, I got an email from Supernote that the A5 is available, so I bought one—it arrives later today. In the meantime, I’ve been reading more about its capabilities, and I see that I can make my own planner for it by just bringing over a PDF, which is what Page-o-Mat produces.

I could make one just like my 2023/2024 planners right now with Page-o-Mat, but one of the advantages of an electronic journal is internal linking. So, I could be looking at a page of all months, tap and jump to a month overview, then tap and jump to a day overview (and back). All you need to do is add tappable zones to the PDF that link to a page.

So, yesterday, I added simple support for that to Page-o-Mat and pushed up the change along with a simple example.

This won’t be enough for my 2025 journal, but helped me get back into the codebase again. I have a week to get the features in so I can make a journal and use it on January 1st.

The only two things you need to know about software project management

  1. If someone asks when something will be done, they are asking for the date when they can use it.
  2. Every day, ask yourself what could happen to make it so the software won’t be ready to use by that date and do something about that.

The result of project management is that the software is ready to be used on the publicized date.

The details about how to figure out the date should be, what it will be, negotiating that difference, how to communicate it, how to change it, who “they” are, what “they can use it” means, changing that definition, what kinds of problems could happen, what to do about a problem, how to track all of this, etc is what project management work is, but in the end it just boils down to those two things.