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.

Applying My Book Selling Content Strategy to Social Media

This is the final part of a series on how I am marketing my book via content generation.

In this final part, I will talk about Social Media, which I treat as a mix of Part 2 and Part 3. I have a feed that I control, but it’s mixed into a communities with norms. Posts are conversation starters, and the comments replying to them should be on-topic. I treat each social media site differently, but a common thread is that I try not to link to my work, and I make each post or comment self-sufficient and useful in the reader’s feed.

Mastodon: I used to post to Mastodon rarely, but I have recently begun to understand it better. I only follow software developers and people I know in real life (who, on Mastodon, seem to skew towards being software devs). If I post something personal, I don’t use hashtags. But, for anything that I think would be interesting to software developers, I use hashtags to cast a wider net. Doing this has made Mastodon much more interactive to me. I also follow all of those hashtags and engage as I would like to be engaged (mostly by replying when replying is asked for and “yes, anding” anything else I can in a positive way). Posting on Mastodon is mostly a way for me to get ideas and practice writing.

LinkedIn: I have written about how I use LinkedIn before. Basically, it’s to keep in touch with people I know and like. So, in a way, it’s more like what I do in communities, but since my posts are in my feed (and people can follow, unfollow, mute or block me), I feel more free to talk about my work unprompted. I still follow nearly a 0-link policy. Most posts are a trial draft of something I intend to write, so there’s nothing to link to yet anyway.

Reddit: And on Reddit, in the software developer subreddits that I participate in, I just try to answer the questions as asked. These questions are often great writing prompts. I try a draft in Reddit, and then expand on it in this blog later. I do this a little on Hacker News as well. It’s not often thought of as social media, but my StackOverflow contributions are similar.

In all of these places, I am not anonymous, and my bio links to this site. If someone were interested in what I had to say, they could easily find this place, add it to their RSS reader, podcast player, or subscribe to my email list.

I don’t know if this is the most effective way to market my book. I suspect it’s not if the goal is the number of subscribers or sales. But, it’s what I would appreciate in others.

Applying My Book Selling Content Strategy in My Communities

This is a follow-up to My Content Strategy for Selling a Book and Applying My Book Selling Content Strategy on Sites I Control. In this post, I will tell you how I market my book in communities that I am a part of on Discord, Slack, Meetup, and IRL with friends, clients, or mentees.

I don’t.

For sites that I control, there’s an expectation that I would talk about my projects. The posts on this site are meant to be useful, but they are based on my experience—they would make no sense if I didn’t explain what I was working on.

But, in communities, we’re having conversations. We’re building relationships. Having fun. It’s just not the place. This doesn’t mean I never talk about my work—sometimes that’s what we’re talking about (our work). And when the book is finally launched, I will ask my software developer friends to read it (because I think it would help them). But, even though I don’t have a strategy to market to them, the conversations we have drive my marketing strategy.

Fairly often, our conversations lead to me writing something. In fact the past three posts (including this one and the next one) are based on a conversation I had in my writing group about my plans for marketing my book. The post, Network with Alums Just Ahead of You, was based on a conversation I had with a mentee. PM-led vs. Engineering-led Time and If code reviews take too long, do this first are based on conversations I have had with clients. Those are just the recent ones.

A lot of my posts over the past 20 years started out as conversations. It’s more of a product development (content generation) strategy than a marketing one, but I believe that these conversations are evidence that the market has these problems too, so it’s marketing in the research sense.

Applying My Book Selling Content Strategy on Sites I Control

As I wrote yesterday, the core belief that drives my marketing strategy for Swimming in Tech Debt is that I truly think the book will help software developers get things done in codebases with tech debt. Given that conviction, and the fact that I care about software developers, I don’t feel shy in asking you to read my book.

On sites that I own, I just overtly write about the book and the processes that I used to develop it. This content goes out to my email list, this blog, and my podcast. Each place is slightly different.

The subscribers to my email list are expecting updates about the book. That’s the specific reason I give for signing up, so sending those updates is not only expected, but I would be not meeting my obligation if I didn’t send that update. That being said, I usually try to send something along with the update that would be interesting to people who signed up.

Similarly, readers of this blog are ostensibly expecting me to write about what I am working on because all of the advice I give on this site is based on my experience. If you are subscribed to this blog (and read it and like it), then I am sure that you’ll like the book—about 1/3 of the content is based on posts here. So, I don’t think you’ll mind me mentioning it.

The podcast is a little different because it’s only about writing and not software development. In season 4 of my podcast, I am going through the steps that I took to write the book. If you are a software developer with a blog, I think I have tips for you to turn your posts into a book. If you don’t have a blog (or even private writing) yet, then the first three seasons are about developing a writing habit that results in a corpus of work to draw from. I talk about my own book in order to explain the process of writing it, but content from the book isn’t appropriate for the podcast.

So, for places I own and that are tied to my identity, I feel free to just write and talk about the book. For all other places, I just want to be a good citizen. The way I do that is to try to use a 0-click strategy. I don’t know if this is the most effective, but it’s what I personally value.

I’ll write about that tomorrow.

My Content Strategy for Selling a Book

I am hoping to be done with Swimming in Tech Debt in a few months. Most of the work between now and then will be getting the book through three editing passes, which gives me a lot of down time. I’m using that time to market the book via content creation. This blog post is part of that.

I don’t mind just saying that overtly because I am following the advice of Zig Ziglar in Selling 101 [affiliate link]. If you don’t know him, Ziglar was one of the selling gurus and motivational speakers of a half-century ago. I would say that it’s the exact kind of person I wouldn’t read, but he’s often mentioned by Seth Godin, so I bought the book and read it years ago. He’s not at all what I imagined—a core part of his philosophy is integrity.

This line has always stuck with me:

If what you are selling is not good enough for your friends and family, then why are you selling it? If it is good, then why would you want to keep it from those you care about most? […] The key is your conviction that you really are offering something that will strengthen the friendship.

Here’s another:

Here is the most important step [to] take when it comes to helping others. If you truly have a desire to help other people; if you truly believe in your product or service; if you truly want the prospect to benefit […] always ask for the order.

It is with this conviction that I am writing these posts to tell you about my book. I think that most of the people that read this site got here because they are software developers, and if you have come back after reading, then my way of thinking at least resonates with your way of thinking. But, I don’t just want to post an advertisement (or even an addvertisement). I want each thing I write to be useful on its own, not a pitch for the book.

So, that’s my strategy—I am telling people something I think will benefit them. To do this, I am posting on Mastodon, LinkedIn, Reddit, here on this blog and in my podcast, to my email list, and other places. I have different criteria for what I post where, which I’ll go into soon.

Can non-programmers make applications with AI?

Of course! Non-programmers have been making applications for decades, well before there was anything like AI helping them. In my experience, the people who really want to make applications learn what they need to learn. AI closes that gap. No-code tools do that too. So does having things like npm, htmx, React, Pandas, SQLite, AWS, etc. But, the motivated can close bigger gaps if they have to.

My first job was in 1992, working for a company that made FX Options Pricing software. That company was founded by an FX Options trader who was a “non-programmer” until he wasn’t. He taught himself enough C to make simple programs to help him price options at work, and just kept making them better until he was able to sell copies to FX Options brokers and traders. And then he used the money to hire programmers, but he still worked on it for at least the first five years of the company.

A couple of jobs later, I got a job at a startup where the first versions were written by the founder, a mechanical engineer, who probably took programming courses, but was not a “professional programmer”. His first two hires were also self-taught. They went from hacking around with scanners and simple websites to building the web-based scanning and Ajax document viewers that were the basis of our acquisition.

At both places, programmers (like me) were brought in. We added some “professionalism” to the codebase and processes. We helped the teams scale, the products be more reliable, and the delivery be more predictable. But bringing us in was just another tool they used to close the gap.

Write While True Episode 44: Write In Public

Podcast: Play in new window | Download

My intention after episode 43 was to follow along the process of writing the book and share what I learned along the way. But, a few things happened that derailed me (in a good way).

transcript

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.