Triple the number of blog posts you write: Follow-up

In yesterday’s post, I had some ideas for tripling the number of posts you write, but I forgot one source of posts: the follow-up.

I had mentioned that Art and Fear [affiliate link] had been the source of my advice to focus on ideas that have thousands of variations (not ideas for single posts). Another lesson from that book is that old (flawed) work is the inspiration for new work. I frequently read my posts hoping to find that it’s flawed in a way that inspires me to write more on the topic.

Now, this post might be a contrived example. I wish I could say that I planned it this way when I wrote the first post, but I’m not that clever. But I did read yesterday’s post and think: why did I not plan out three posts on how to triple my number of posts? And then I thought: what would I have planned? And this post is not what I would have planned, but it’s what came out of thinking about what more I had more to say on this topic.

The reason I am able to do this is that my posts are not meant to be my exhaustive view. I am following my advice to Lower the Bar to Practice, and that means I publish posts when they are good enough to publish, not the best they could be. I know that there’s always room to add more later.

Triple the number of blog posts you write

One of lessons I got from Art and Fear [affiliate link] was to not focus on ideas for a new piece of art, but instead to find ideas for Thousands of Variations and use that to produce A Life’s Work. I do that in the large with this blog, but you could also do it for each new post. If you have an idea for a post, try to think of two more that are closely related.

Sometimes, while writing, I realize that I need to explain something in an aside. Instead of doing that, I write that aside as a post first, which I can link to. The aside may not seem like enough, but I find that when I can give it its own space, I can expand on the idea. But I do it even if it seems short.

Another thing that happens in my first drafts, is that I discover in my first pass edit that a paragraph or two just doesn’t fit at all—it’s not an aside, I was just rambling. I don’t delete the text, I move it to my notes as the seed of a new idea. I discussed this in Write While True Episode 6: Editing First Drafts. If those paragraphs are developed enough, I’ll start a quick draft in my blog editor to look at later.

Finally, some posts are cohesive, but just too long. Those can usually be broken up into a few parts, which make it easier to digest. The individual posts are often easier to link to because they are focused. For example, I learned three lessons from Art and Fear, but by breaking out the “Thousands of Variations” into its own podcast, I got three podcasts out of those lessons, but also, this one is easier to refer to.

Write While True Episode 45: Gather Your Work

But even with all of that new writing, a lot of the ideas and content are drawn from my blog. That’s what I want to talk about today — How I started this project by reviewing and gathering my work.

My first step, at the end of 2023, when I decided that I wanted to write a book, was to immerse myself in my own writing, so I just read my blog. I just read all of the posts.

Transcript

The Lorraine Hotel

I’ve been to Memphis twice, which means I’ve been to the National Civil Rights Museum at The Lorraine Hotel twice. The first time was in the early 90’s and the second time was in 2022. My memory of the first time was that it was just the Lorraine Hotel and walking through it was a fairly short, but powerful experience. After seeing a retrospective of MLK’s life and the 60’s era civil rights movement, I watched a video of his “Mountaintop” speech where he seemed to predict his own death, and then walked to his room, and then to the exit. Everything was quiet. We were within a few feet from where he was shot. I just stood there and let all of it overwhelm me as it should.

A photo of the Lorraine Hotel. There is a flower wreath at the spot of MLK's death. The hotel has been preserved to what it looked like then with two cars from the time parked outside.

Why ChatGPT Works Better for Newbies than StackOverflow

On StackOverflow, it’s common for newbie questions to get downvoted, closed, and draw comments making fun of the questioner. To be fair, many of these questions are not good and show that the asker didn’t follow the guidelines. Even so, StackOverflow is often hostile to new programmers. To be honest, I’m surprised that ChatGPT didn’t somehow learn this bad behavior.

ChatGPT answers are sometimes totally wrong, and they will be even more wrong for the way newbies ask questions. If they weren’t, StackOverflow wouldn’t have had to ban answers generated from chatbots. But, I still think ChatGPT a better experience because it’s fast and synchronous. This allows it to be iterative. Of course, this doesn’t help if the suggested code can’t be used.

If I were StackOverflow, I might consider how LLMs could be used to help newbies ask a better question that gets answered by humans if the LLM can’t answer. Let the user iterate privately, and then have the LLM propose a question based on a system prompt that understands StackOverflow guidelines. Normally, I’d expect the LLM to be able to answer at this point, but I just ran into a problem yesterday where it kept hallucinating an API that was slightly wrong. This kind of thing happens often in ChatGPT for me. In a lot of cases, I could guess the real API or search for it in the docs, but a newer programmer might not be able to do that.

A Tale of Two Blogs

I have a blog here (the one you are reading) and another at App-o-Mat. This one is on WordPress, and App-o-Mat used to be a Django site, but is now a static site generated by that Django app, which I run locally. I had to do this because my hosting company sunset their support for Django, and I didn’t want to pay for better hosting.

So, for this blog, all I have to do to write a post is login, tap the “Add a Post” button and type type type until I am happy with the post. For App-o-Mat, I have to do a bunch of steps I forgot to write down. I think I could figure it out—it was something like:

  1. Run the Django app locally following the steps in the README (this will have a side-quest of getting Python environments figured out again)
  2. Go to the Admin and add a post entity to my DB
  3. Use curl (I think) or maybe wget to crawl the whole site and dump HTML
  4. I should probably diff this against the site to make sure it worked
  5. SCP the changed files over to my server

Now that I have written this down, I actually feel like I should write a new post soon because this is the most momentum I have had on this site since I had to migrate it last April. The change before that was to migrate from Bootstrap to Tailwind. I do more futzing with App-o-Mat than writing. But, whenever I change the site, I write about it here, so I am using my waste.

I’m not always prolific on my main blog, but that’s not the fault of the software. I was thinking about this earlier today, and now there’s a post. Whenever I have ideas for App-o-Mat, I forget them before they had a chance to exist.

Evaluating the Evaluators

I was a member of Toastmasters during most of 2023 and 2024. Most people know that Toastmasters is a place where you go to get more comfortable at public speaking. A lesser known aspect is their approach to evaluation.

If you give a speech at Toastmasters, it will be evaluated. This is something semi-formal, meaning that there is a format and a rubric. That makes sense and is probably what you would think it is. What was unexpected to me was that an evaluation is treated like another speech and is evaluated as well (but we stop there—it’s not an infinite game). The evaluation of the evaluation is less formal. It’s usually a few lines during the general evaluation, which needs to cover the entire meeting. When I had to do it, I would try to pick out a line from the evaluation that was worth emulating, to underscore it.

I thought of this while I’ve been going down a rabbit hole trying to learn about LLM evaluations, which also has the concept of evaluating the evaluators. I don’t have much more to say, but just want to leave a link to Hamel Husain’s excellent post: Creating a LLM-as-a-Judge That Drives Business Results, which was the best thing I found on how to improve LLM based features in a product.

Do Software Developers Need a Brand?

When someone hears that you are working on something, your brand is what they think will happen. So, the question isn’t whether or not you need a brand, because you already have one as long as people hold some opinion of your work. The questions to ask are (1) what is the brand, (2) how consistent is it, and (3) how widespread is it.

The most important thing is that the opinion people have about you is generally positive, but there are a lot of options for what that is. It could be that people generally believe you are highly skilled. Or they could believe that adding you to a team is good because you help teams jell. Or perhaps adding you to a startup is a good idea because you have a large network of peers to recruit from who like to work with you. Or maybe you know a domain on a deep level. Each of these are examples of a positive brand, and they all can work well (or even better in combination). Whatever your brand is, it is built from your visible accomplishments.

So, in addition to accomplishing things, if you want those things to be part of your brand, make them visible. If the work can’t be public, then you could still make sure your team understands your contribution, ensure your manager understands it enough to use in a promotion packet, or talk about it on an internal blog. If the work is public, then having some public explanation of the benefits of that work is worth adding to it. If you use LinkedIn, I would say that this should show up in your headline, summary, and job history section. There is no need to make posts for this, but I do think having a trickle of LinkedIn activity is helpful to help people remember you or get them to look at your profile.

A positive brand is always helpful, but a consistent one becomes more important as your career progresses. You can’t always control exactly what you work on, but you can improve how that work is understood by using emphasis. I have done this on my LinkedIn profile and when applying for a job by making custom resumés and cover letters.

For most of my career, I concentrated on doing good work and having positive interactions. But it’s easier to communicate this by fitting that work into a narrative. I emphasize the parts of my career that are more likely to result in relevant work, and I expand it in direct conversation if it makes sense.

I’d like to think that this was all intentional, but it wasn’t really. This narrative is something I found after the fact. There are alternative brands that I could use, but don’t, like “FinTech Engineer” or “Mobile Engineer”, which are positive but not consistent with what I am trying to do. I don’t want to be hired to do those things, so it’s only important to talk about them if a specific engagement needs that in addition to what I try to sell. But, to get the job at Trello ten years ago, I emphasized the “Mobile Engineer” and “Startup early engineer” narrative and downplayed my management experience.

But when developers ask whether or not they need a brand, I think they are mostly asking about the “widespread” part. In that case, the answer is easy. No. You do not need a widespread brand. My career has been successful without one, and I think I’m the norm.

I am not well-known outside of my network. This is true even though I have written a book, spoken at conferences, been on some podcasts, written for tech publications, and worked on a fairly well-known app. To the extent that these things touched people outside of my network, I don’t think it resulted in a widespread brand. But, I do think the people that know me have a positive association with me in a way that is consistent with my narrative.

The more important thing is that your positive and consistent brand be widespread within your communities: inside your current employer, among your ex-colleagues, and among your clients. If you participate in developer online communities, then in there too. To the extent you are on social media, then among your followers, no matter how small a list that is.

Rather than working to grow your brand to strangers, I would first recommend you grow it within your network. The best way to do this is by doing good work in the way you want to be known. Then, build a consistent and widespread brand by tying it into the narrative you want people to have about you when they hear your name.

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.