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.

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