Apples and Oranges are (Relatively) Easy to Compare

I don’t like stack ranking because it’s hard to compare people into a rank ordering.

One of the most surprising things I learned in math was that complex numbers had no natural ordering. Meaning, less-than and greater-than are not defined for complex numbers. It makes sense when you think of it for a minute. The same applies to other multi-dimensional things like matrices and vectors.

So, why do we think we can rank order people? I’m specifically talking about companies that do this for their employees, but it comes up in other contexts (e.g. class rank).

People are hard to compare, but when we say that it’s like comparing apples and oranges, I disagree. Apples and oranges are both fruit, they both have around the same number of calories, they are about the same size, shape, and cost. They are easy to turn into snackable pieces (slices or segments). Even for me personally, I like them both about the same. On a lot of dimensions, they are about the same. When that’s true, the comparison might turn into just a single dimension where they vary more—maybe only in specific situations.

For me, the main way they are different is in how they travel. Eating an orange is more of a mess and harder to deal with outside of my kitchen. I’m much more likely to grab an apple to throw in my hiking bag or take to the beach. Another way is in recipes. I know a lot more apple desserts than orange ones. It stands up to baking better.

But, how about apples and raisins, or apples and candy, or apples and tempeh, or apples and bicycles. Those are harder to compare because they vary on more dimensions. In the bicycle case, they don’t even share dimensions except generic ones—they are both objects that have size and weight.

Getting back to stack ranking (which I still don’t like). Inside of a team it makes no sense to me. You would have a mix of levels and experience. That mix makes the team valuable, and arbitrarily favoring a dimension hurts the mix.

Like comparing apples and oranges (which is easy), it would work better if you could remove dimensions and only compare one or two. So, for example: compare just your backend senior developers with each other on just system design skill. You could reduce the set to just those with two years at this level. This might be useful when considering a promotion. In this situation, you might value mentoring and consensus building skills more than in-depth knowledge of TypeScript. So, it’s situational (like which fruit to use for a pie) and has reduced dimensions. Another advantage is that you don’t need a full ordering to complete the task.

Video Ideas for a Podcast

I started a podcast in 2021, which has 43 episodes with writing exercises in it. I’m thinking of turning it into a YouTube channel, but I don’t want to just post the audio.

Here are some of the ideas I’ve had for adding video

Rerecord the podcasts with a camera pointing at me: Each of my episodes is about 5-10 minutes long, so this isn’t as bad as it seems. I also have a transcript for each one, and with my janky teleprompter setup, I might be able to pull this off.
Record myself sketchnoting the episode: I am not currently good at sketchnoting, but this might be a way to get better. I tried it out and it’s very hard to do this live. But, I can do it slow and fix it in my video editor.
Make a presentation and record it: This is probably the easiest thing I could do. I’m guessing it would also be the least successful
Show drawings in a presentation: This would use the drawings from the sketchnote, but instead of you watching me draw them, you see them in a deck.
Stylized Transcript: Normally you see this as an overlay on TikToks or shorts. It can look nice—maybe someone has made a generator.
AI: Just putting this here as placeholder. I’ve seen some videos that feel like they have been made by auto-generating (or matching) stock video to the audio. I hate them, but they aren’t horrible.
Fiverr: There are people that can make nice looking videos from audio. There are also some that look like they use AI (see above)

Of all of these, the stylized transcript appeals to me the most because I think I can write a script to do it and then I can make it look like however I want.

Leet Code at Work

I prefer work simulation questions to leet code questions for tech interviews. I like to ask interviewees to write code that is similar to what we actually did was better than, for example, finding a successor node in a BST. At Trello, our tech interview would have you refactoring code in a way that is very common in iOS or implementing a UI from a spec. At Atalasoft, we had a lot of image processing algorithms in our code base, so I wanted to see you do something simple with pixels.

The other day I was thinking about my career and trying to remember if I ever did have to code a custom algorithm given a specification, and I did come up with a few examples. I’ve written before that my career happened to have a lot of math in it, and those same jobs sometimes also needed me to implement algorithms.

But more often, I chose algorithms (or knew that I needed to). I think that’s a more universally useful skill. It’s often the case that something just isn’t fast enough. A lot of published and common implementations of algorithms work well for the general case, but you may be able to make some assumptions in your specific application that allow you to do something better. Or your particular workloads might make a different set of trade-offs more appropriate.

To do this, it’s good to have broad knowledge of a bunch of choices, just so you know what techniques might be possible. These days, I think AI can help you a lot with this, but it helps to know what to ask for and when to ask for it.

Announcing View Source

I finally wrote a post for View Source on Substack. I started it back in 2021, but never posted to it, because I didn’t know how it would be different from this blog. When my guest post for The Pragmatic Engineer went out, a lot of people subscribed to it because that’s where the guest post was hosted, and it was linked to my name automatically. This happened even though it had no posts.

So, now I see that the advantage of Substack is discoverability. I’ll use it as a place to publish more thought out, longer pieces probably based on the best posts on this blog, but rewritten to be better (since Old, Flawed Work is the Jumping Off Point). I decided that View Source will be about the causes of developer productivity.

My book, Pay Tech Debt to Go Faster Now, is my argument that some tech debt payments result in immediate developer productivity that pays for itself, so you should do that. The chapters offer practices for individuals, teams, and leaders on how to do that.

But, View Source, will be broader and look at other sources of productivity.

Write Pitches to Test a Book

I started writing a book a year ago, and I just realized something I could have done back then that would have helped me develop it.

I am thinking about 2025 and what I can do to market my book. So, I got the idea to pitch myself to speak at tech conferences. I had done it before, I like it, and I’m always up for some travel.

I found a few, read their application guides, and crafted pitches based on the content of my book. I applied to an automated testing conference and a few software development conferences.

And then I realized something.

I could have done this a year ago. I had an outline for the book—I could have read these guides to see the kind of content they were willing to “buy” and then crafted pitches based on what I planned to write. If I had been accepted, that would have been great signal that I was on the right track. If I had been rejected, I could have used that to try something else.

Anyway, hope this helps someone who is thinking of writing a book—write some pitches instead. Even if you don’t want to speak, you could just turn it down—you would know whether your idea had some resonance with the organizers.

Applying my first two programming lessons to teaching kids to program

I have been meeting with my 10 year old nephew about once a week to make video games together. It’s mostly just to have fun and for me to also chat with his dad, who helps on his side—we’re across the country from each other. His dad and I went to middle school together and got kicked out of wood shop and into a computer “shop” where we learned to program on the Commodore PET. We were 13 at the time and learned enough BASIC to make simple games. So, in a way, we’re carrying on that tradition.

My first program back then was to draw on the screen given a list of coordinates. It was about 5 lines of real code (and a dozen lines of DATA). It was easy to understand and it put stuff on the screen right away, which was my first lesson in programming.

It’s hard to do that in modern programming, especially if you want to be able to keep going on to build something more real. There’s just so much boilerplate and ceremony to just get something on the screen.

After some trial and error, I have settled on using Phaser as our game engine and Glitch as our editor.

Glitch lets you edit code like a google doc. We can both be in the editor and change code simultaneously. Ironically, it took me time to remember Glitch even though I got to witness its genesis inside of Fogcreek when I was working at Trello.

Glitch is easiest to use with JavaScript, so I had to pick a JS game engine. Since someone already had made a remixable Phaser game, I started with that. My second lesson in programming is that it’s easier to learn how to modify a working thing than to make something from scratch. This is really an extension of the first lesson—when you are making something bigger, it takes too long to get something working, so to learn how to make big things, start with the big thing already done. First you modify parts to get a sense of all the pieces, and then later, you will be able to make one from scratch.

I’ll post some of our games next week. They are mostly simple ports of classic 2D games from the 80’s and 90’s.

Write While True is Returning Soon

In 2021, when I went independent, I decided to get serious about becoming a better writer, and so I started reading books about writing and using their exercises. Soon after that, I started a podcast to share what I learned. As of today, there have been four seasons and forty-three episodes. The last one was in April.

Write While True is a podcast about writing for software engineers who want to write better by a software engineer who wants to become a better writer. The title implies that writing is an infinite loop, which is how I think of it. You become a better writer by writing. Each episode is short and ends with an exercise.

I announced Season Four at the beginning of the year and published the first episode in March. The idea was to podcast while I was writing a book about tech debt so I could share tips along the way. The first four episodes were how I was applying The Four Disciplines of Execution to design a process that would help me finish a book by the end of the year.

It’s November, and I have 40,000 words of unedited text. I will definitely finish, but not by the end of the year. My original goal of 10,000 words in a pamphlet size book grew as I learned more about my topic by sharing my work with others. I was able to do this, in part, because I gave up things like the podcast.

Now that most of the book is written, I’m ready to podcast again. I am going to pick up Season Four where I left off. But, instead of sharing tips as I learned them, I can share them with the benefit of some hindsight. The script for episode forty-four is written, so I hope to get it done this weekend.

If you want to listen, subscribe to Write While True in your podcast player.

Mutation Testing

A couple of years ago, I wrote about a testing technique that I had learned, but didn’t remember the name of, so I called it code perturbance. I mentioned this technique in my book, and a helpful beta reader let me know the real name: mutation testing.

The idea is to intentionally change the code in a way that introduces a bug, but is still syntactically correct (so you can run it). Then, you run your test suite to see if it can find the problem. This augments code coverage, which will only let you know that code was run in a test, not if an assertion was made against it.

Now that I know the name, I can find out more about it in google. For example, there are tools that can do it for you automatically. The one that I’m most interested in is Stryker-mutator, because it supports TypeScript. I’ll report back when I try it.

How I Wrote (most of) a Useful Book This Year

A couple of years ago, I read Write Useful Books by Rob Fitzpatrick. This year I applied it to writing a book about tech debt. These five things had the biggest impact.

1. Imagine the conversation where someone recommends your book

This helped me narrow down my topic from many other ideas I had. I know first-hand that software developers talk about tech debt all of the time. Many of my ideas for chapters were from things I said or thought in those conversations. The ideal conversation is one where engineers are complaining that they can’t get support to pay more tech debt — nearly every chapter addresses that.

2. Make a clear promise

My title is Pay Tech Debt to Go Faster Now because I think the long-term benefits are unsure and over estimated, and there’s a way to get benefits immediately if you direct debt payments at developer productivity to deliver the current roadmap faster (which everyone wants). In that conversation above, my title is the short form of the answer I would give (the book is the long answer)

3. Write in public

I started the book in January and posted it in February. Did a rewrite in March. Posted it in April. That version was discovered by Gergely Orosz of The Pragmatic Engineer newsletter who published an excerpt in September (He also graciously gave honest feedback on what did and did not work)

The article led to hundreds of software engineers signing up to get updates. I just sent them six chapters to read and am getting more useful feedback. I was approached to give a private webinar and shared a different four chapters with them. All of this is honing and shaping the book — the book that I would have written in private would have been very different (and not as good).

4. Market the book by sharing behind the scenes information

For example, this post :)

5. (not in the book): Join an Accountability Group

Rob runs the Useful Books community — https://www.usefulbooks.com/ — I meet with community members three hours per week where we spend 45 minutes of it just writing. A lot of my book got written in those sessions (~70%)

Why LinkedIn Works For Me

With all the talk of migrating to either Bluesky, Mastodon, or Threads, I’m happy that I “migrated” to LinkedIn two years ago.

I joined LinkedIn in 2003, but it was mostly a place to keep my resume for job searching and to message former co-workers.

But, now I use it more like a combination of a social network where I want to stay connected to real-life colleagues and a place to try to get business by networking with potential clients.

My goals with LinkedIn are:

I want to be ambiently aware of which of my ex-colleagues might be looking for jobs and which might be hiring, so I can introduce them to each other. LinkedIn (for whatever flaws it might have) is the best way I have found to do that.
For my business, I want to reach software developers when they are thinking about work and career growth. I want to reach software company tech leaders when they are having problems that I might be able to solve. That happens on LinkedIn and not many other places.

To do those things, LinkedIn has several advantages over other social networks for me:

I see no political content or ads. I checked the box in Settings to turn off political content, and that’s been effective.
LinkedIn shows a normal, time-based (non-algorithmic) feed if you request it in Settings, and it stays that way.
People here seem to be real, not bots. If someone auto-posts their work’s content or is posting a lot that I don’t want to see, I unfollow them, unless I know them well.
Comments on my posts, even by strangers, are civil. Generally, people are positive and casually professional.
My ex-colleagues are here in large numbers, and mostly they talk about work/career things.
There aren’t a lot of posts, and almost every one of them is an update from someone I care about talking about what’s going on in their career. When I read them, I don’t think of myself as doom scrolling — it’s the opposite: it sparks joy to see my friends succeeding.

Twitter was never any of those for me, and so it was easy to give up. It didn’t help me accomplish my goals for using a social network, but worse, it was addictive and a waste of time, so I had to block it. I’m sure Bluesky and Threads are a better Twitter, but I doubt they are a better LinkedIn for how I use it, and as bad as Twitter in all the ways that matter to me.