Author Archives: Lou Franco

November 2024 Blog Roundup

Whenever I am near the end of a year, I start planning for the next one. This has made me blog more than I had been in the early fall.

I wrote about planning for 2025

I’m also going to start podcasting soon, and I’m trying to find a way to bring them to YouTube

One of my major activities this year was working on my book on tech debt. I am wrapping that up and starting to think about marketing.

My next draft of the book is due on December 4, and so I will be spending most of December finding things to do while waiting for it. I hope to have some new podcasts with my major lessons learned writing it.

Practicing Doodling

I want to add videos to each my podcast episodes, so that I can post them on YouTube. One option I’m exploring is trying to sketchnote them while listening to them. This is a lot harder than I thought.

I have two problems. The first one is that I can’t do it fast enough. That’s easy to solve: I can just do it at any pace and fix it in my editor. The second is that I don’t draw well. Slowing down helps, but I just need to get better at doodling and coming up with objects to draw that represent the concept I am talking about in the podcast.

To practice, I saw Quick, Draw! on the Verbal to Visual YouTube channel. Google is training a neural net to interpret doodles, and it’s already good enough for this simple game. It gives you an object to draw, and you have 20 seconds to draw something the net recognizes as that object. When you are done, if it didn’t get your drawing, you can explore other drawings that the neural net did recognize as that object. They even let you explore the dataset of simple doodles. If you see one you like, you can tap it to see it being drawn, stroke by stroke.

I try to do it without thinking first because I want to get better at doing it live. I’m especially bad at animals. One drawback is that every prompt is an object, but I want to get better at translating verbs and concepts to visuals. I’d also love to see what people would draw for words like confusion, hunger, defiant, or tired.

Even playing for a half hour, I got much better. Not at animals, though.

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.