This is a natural follow-up to last week’s “I don’t want a large audience”.

I’ve long been contemplating moving further away from using Disqus. I switched to Disqus back in 2014 when I abandoned my WordPress blog for Jekyll-based Octopress. Disqus seemed like a great choice- lean, customizable, ad-free, and most importantly, allowed dynamic comments for a statically generated site (since this site is just a bunch of generated HTML pages).

The reason for the switch is two-part.

I don’t really have the emotional bandwidth to follow along with Disqus as a company as they revisit their values, change policies, or even just grow as a business. I think I may have been grandfathered into an ad-free plan (although that’s unclear - I have network-wide ad-blocking, and I didn’t bother enough to check if there are ads in the comments). And in principle, I can’t really fault Disqus for introducing ads for unpaid comment tiers, especially without seeing their balance sheet. Maybe the free comments took up much-needed server capacity, and it could be that paid subscriptions weren’t offsetting the costs enough. Or it could be that the company just got greedy, which wouldn’t be too surprising to me either.

But more importantly, I want to see what my blog would look like with less public interaction features.

Outside of tutorials (which I rarely write these days), I’m not entirely sure how valuable the comments are to my readers. In fact, I think sometimes comments can be detrimental to the reader’s enjoyment. Humans are a pack animal, and subconsciously we tend to favor things favored by others. So seeing a “100 comments” heading might make you think the post is popular for a reason, while seeing “Be the first to leave a comment” would make you consider if the piece is worth reading.

This is the same reason I don’t really like “likes” and other low effort ways of engaging with content. Mostly because I’d rather have said content stand on its own. Just because something is popular, doesn’t really mean it’s good and needs to become more popular. And in part because it’s hard for me to resist wanting to chase likes, and I don’t want to spend my time doing that.

Anywho, I exported Disqus comments (which in turn already contained comments I exported from WordPress back in 2014), and I embedded those read-only comments into the existing pages. I wanted to preserve the discourse - especially on the tutorials and more widely discussed posts, and the read-only comments work great for that. Here’s a live example: Prius Adventures, a year later. If you want to do something like this yourself, here’s the commit in question, but I think this might be too niche of a topic to warrant a step-by-step guide.

I replaced the comment functionality with a ✍️ Reply by email button which you can find at the bottom of this post. Yeah, that button simply opens your email client and pre-fills my address and the email title. That’s a private email, that only I will read, that I won’t post publicly, and others won’t see. But we might have a great conversation, which is better. Why don’t you give it a shot, and tell me if this message resonates with you?

I’m not severing my site from the rest of the Internet here, no. Ever since I learned about Webmentions, I eventually want to add Webmention support to my site at some point. But I might only filter it down to Webmentions from long-form posts on other sites, rather than comments or likes. It’s definitely a no on likes for me. Follow along and see what I’ll do.

P.S: Late addition right before hitting the publish button. I’ve just stumbled upon “Why Comment Sections suck - re:I want to comment on your blog post” from Kami’s Corner (thank you, winther blog postroll for aiding my blog discovery efforts). There’s a nugget inside that summarizes my core desire more eloquently:

When you want to make a response you have to either email the person or write a response post. That small barrier to entry cuts out most idiots. Because you have to actually care about what you have to say to sit down and write an email or to make an entire response post. You have to put in some effort.

I’m excited to see what the future of my blog will look like with the new functionality.

I’ve had this blog for 13 years now. I started it as a way to publish my programming journey, as I was learning C, Python, and tools like the command line or Vim. Since then, I’ve matured, both as a software engineer and as a person. Different things interest me these days. I’ve been managing engineers for some time and have things to say that I haven’t yet shared. I’ve also gotten into personal finance, traveled and lived out of my car for a year, and I’m even starting to enjoy engaging in the AI discourse. In the past couple of months, I’ve moved further towards subjective opinion pieces, which I enjoy greatly.

While my blog was never huge, I enjoyed my few thousand monthly users, most through organic search. This was primarily driven by the tutorial-like nature of my writing. Even when I would talk about my experience traveling the US in a Prius, I’d turn the article into a tutorial with step-by-step guides and tips.

After taking a little over a year of a break from writing, I’m back at it again. It was really the time afforded to me by my paternity leave that reminded me how much I like writing, and how much I enjoy others connecting with my writing. And now I don’t particularly care about wide viewership; I am more interested in the discourse, in the community.

A friend of mine, Patrick, started a newsletter after retiring. He sent a thought piece on AI to a humble private mailing list of 20 people. I think I was the only person who responded, but we’ve had some fantastic conversations. In fact, Patrick inspired me to write about AI, and even to pivot a small part of my role at Google to be defined by driving responsible AI adoption.

Since then, I’ve learned of new blog discovery mechanisms through communities like IndieWeb. I discovered my personal favorites like the winther blog or the uncountable thoughts. I even found some local San Diego bloggers on the chain, like Anthony Ciccarello, gRegor Morrill, or Joe Crawford. It’s been exciting to explore this new world of interconnected blogs.

It’s super engaging being able to connect with fellow bloggers. I can respond to their writing over email, get a thoughtful message, or even see a response to something I wrote on their own blog. I’m enjoying the quality local discourse and happy to be following local organic free-range fair trade blogs.

Chris Shaw asked me if I had category-specific RSS feeds on my site, and it felt like a perfectly reasonable request in the spirit of IndieWeb. This is a statically generated Jekyll site, and I couldn’t really find out-of-the box examples that worked exactly for my site.

Although, if you’re trying to kill two birds with one stone - that is to add categories and category feeds, you should use the jekyll-archives plugin, which seems to be capable of both generating the category pages, and category-specific RSS feeds.

I already have working and heavily customized categories through the unofficial jekyll-category-pages, and I needed a custom solution. This solution doesn’t rely on jekyll-category-pages though.

My Ruby skills are rusty, so I used Gemini Pro 2.5 to give me a hand with code generation. It took a couple of iterations, but the result is working fine.

First I added _layouts/category_feed.xml to create a layout:

---
layout: null
---
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>{{ site.title | xml_escape }} - {{ page.category | xml_escape }}</title>
    <description>Recent posts in {{ page.category | xml_escape }} category on {{ site.title | xml_escape }}.</description>
    <link>{{ "/" | absolute_url }}</link>
    <atom:link href="{{ site.url }}{{ site.baseurl }}{{ page.url }}" rel="self" type="application/rss+xml" />
    <pubDate>{{ site.time | date_to_rfc822 }}</pubDate>
    <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
    <generator>Jekyll v{{ jekyll.version }}</generator>
    {% for post in site.categories[page.category] %}
      <item>
        <title>{{ post.title | xml_escape }}</title>
        <description>{{ post.content | xml_escape }}</description>
        <pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
        <link>{{ post.url | absolute_url }}</link>
        <guid isPermaLink="true">{{ post.url | absolute_url }}</guid>
        {% for tag in post.tags %}
        <category>{{ tag | xml_escape }}</category>
        {% endfor %}
        {% for cat in post.categories %}
        <category>{{ cat | xml_escape }}</category>
        {% endfor %}
      </item>
    {% endfor %}
  </channel>
</rss>

Then, I added _plugins/category_feed_generator.rb (be sure to customize the blog/categories path to your liking):

module Jekyll
  class CategoryFeedPage < Page
    def initialize(site, base, dir, category)
      @site = site
      @base = base
      @dir = dir
      @name = "#{Jekyll::Utils.slugify(category)}.xml"

      self.process(@name)
      self.read_yaml(File.join(base, '_layouts'), 'category_feed.xml')
      self.data['category'] = category
    end
  end

  class CategoryFeedGenerator < Generator
    safe true

    def generate(site)
      if site.layouts.key? 'category_feed'
        dir = 'blog/categories'
        site.categories.each_key do |category|
          site.pages << CategoryFeedPage.new(site, site.source, dir, category)
        end
      end
    end
  end
end

This creates feeds like /blog/categories/programming.xml (or whatever URL you used).

Finally, I added category specific links to the category listing pages and the category index (that part will be specific to how you choose to display your categories): RSS feed for Programming.

<a href="/blog/categories/programming.xml">RSS feed for Programming</a>

You can see the full commit with the changes here. Happy Jekyll-ing!

I love bad coffee.

One of the least sophisticated ways of making coffee is to just brew some in a pot and pour it into a cup. America’s famous for its bad coffee. When asking for a cup of coffee in, say, Amsterdam or Paris, you often get a nice, skillfully brewed cup of espresso – concentrated caffeinated artistry. The bouquet of flavour in such creations is something to admire, really.

And yet, every time I travel outside of the United States, I miss my average cup-of-Joe. When I first came to the United States, I would occasionally stop by at a diner that would serve terribly burnt coffee that was probably sitting in a coffee machine all day. That brew wasn’t delicate or even particularly potent: it was a straightforward, unapologetic part of the landscape. And that sense of Americana stuck with me. It brings me warmth, and slowly sipping my terrible cup of coffee is a highlight of my day. There’s an unpretentious honesty to it that I find increasingly rare.

It’s in this appreciation for the simple and unadorned that I find a contrast to a broader trend. In an increasingly interconnected world, it’s easy to focus on wanting the best, or appreciating what we’re told is the best. We learn about the “top” dining places, the “must-have” brand for a pair of pants, the “best” everything. This pressure isn’t new, but the mechanisms delivering these suggestions have become incredibly sophisticated. Now, we’re constantly nudged, particularly through our digital interfaces and by algorithmic suggestions, towards a curated, supposedly superior experience, often designed more for broad appeal or engagement metrics than personal resonance.

Choosing “bad” coffee, then, can feel like a small act of rebellion.

It’s a quiet refusal to have my preferences dictated, whether by a food critic offline or the mighty algorithm online. It’s easy to lose sight of what you genuinely like when you’re bombarded with content – perfectly filtered, endlessly optimized – telling you that something else is “better.” It might be objectively better by certain metrics, it probably is, but it isn’t necessarily better for me.

Yes, the cat video YouTube’s algorithm surfaces might be, by its engagement data, the “best” piece of cat-related content currently available. But often, it has no real relation to me, to the quirky humor of people I actually know, or the niche digital spaces I would consider mine. There’s no personal history there, no shared context, just an echo of mass appeal. It’s the digital equivalent of a focus-tested AAA movie – technically proficient, but lacking a soul.

That diner coffee isn’t aspiring to be anything other than what it is; it hasn’t been A/B tested or optimized for viral sharing. It’s a personal anchor in a sea of imposed “bests,” a tangible connection in an often-intangible world.

This isn’t a wholesale rejection of quality or a Luddite call to abandon our digital tools. It’s about recognizing that personal resonance often trumps algorithmic perfection. It’s about the freedom to find joy in the imperfect, the idiosyncratic, the things that speak to us for reasons that don’t require external validation or a high engagement score.

Sometimes, that wonderfully “bad” cup of coffee isn’t just a beverage; it’s a small declaration of independence from the tyranny of the curated feed. And that, in its own quiet, un-optimized way, is deeply satisfying.

Being somewhat of an AI sceptic, but having to deal with the advent of AI tooling and its impact on engineering productivity is weird. As is often the case, the other day I was engaging in some AI fear mongering when chatting with my colleague Kate. We got into it, especially the concerns about the future of junior software engineer roles. She made a valid point that many other industries have already navigated significant shifts due to automation (Kate - you legend).

I thought about this before, but I’ve always dismissed the comparison due to the state AI tooling was in. Google practically forced all its engineers to use AI tooling far before it was ready, and many of us have burned out, and many of us have very strong opinions of how garbage this technology is. But over the past year alone we’re now at the point where AI models - with some guidance - can perform many junior development tasks - like putting together a simple website or writing a hyper specific tool. Oh, and shout-out to my then-manager-now-retired-friend Patrick - whose (exclusive, I am very fancy) newsletter encouraged me to dig into how AI tooling has changed. Thanks Patrick, I’ll probably send this to you.

In fact, Gemini Pro even helped me with an outline of this article. These are still my own thoughts, typed out with my own two hands (I find angrily typing out my thoughts to be therapeutic and the best part of writing). But there’s no writer’s block - I’m not staring at a blank document anymore. In front of me is a stub of an article that I hate with a passion, and this burning hatred for the AI-authored stub is what’s pushing me to write down my thoughts in one go.

You see, for a while I used to group AI with other tech trends like big data or blockchain - impactful technologies, but not something that fundamentally rewrote the playbook on software development. Yes, our databases are now order of magnitude larger, but we’re still using the same interfaces to engage with them - and it’s now just “data”. And blockchain, outside of niche problems, turned out to be a grift. No, AI is really closer to industrial revolution. And yeah, the news sources and many folks I know have been using these words have been saying this for years - but that just sounded too grandiose to be true. I couldn’t see the forest of changing job landscape for the trees of not-quite-yet mature models. But I think it’s true: the means of production will evolve.

Anyhow, Kate’s comments prompted me to look into how others adapted when their familiar landscapes changed.

The idea that “junior engineers won’t exist, so senior engineers won’t exist” has a simplistic appeal. However, it often overlooks how industries, and the people within them, actually progress. The software engineering career pipeline isn’t necessarily breaking - it’s just getting rerouted through unfamiliar territory.

Let’s be clear: the old model, where experience was often gained through highly repetitive tasks, was never perfect. It was simply the established way, the way of our ancestors: software engineers learn some math and not-particularly-useful concepts in college (or take a coding bootcamp, which is much faster, and in my experience, produces similar results), join a company, shadow more senior engineers, write some terrible code, make a few expensive mistakes for the company to absorb, and eventually graduate into productive developers of software. But like any system with inherent inefficiencies, this progression system was always susceptible to disruption.

This kind of transformation isn’t unique to software, and isn’t unique to AI. And in my brief research I found many examples - here are the three representative example - one where the career pathways evolved, one where that path was closed, and one where it became easier.

The factories

Let’s get the factory floor comparison out of the way - it’s not great, but it sort of works.. Getting to start in manufacturing meant working on an assembly line, performing a repetitive task hundreds of times a day, being noticed by the supervisor, and eventually being promoted up the chain. Throughout the later part of the twentieth century, industrial robots became a thing - these were big, dumb robots, but they could do what a worker did more consistently, sometimes faster, but most importantly - for a constant lower cost, and without sick days or unions.

The junior roles on the factory floor have changed - it’s now all about monitoring, maintaining, and troubleshooting the machines. Many jobs shifted from the factory floor to the office - you needed your CAD operators and technicians. The pathway to becoming a manufacturing professional is no longer about enduring years of menial back breaking labor: it’s all about understanding and interacting with automated systems.

The career ladder, while different, is still there for those who were willing to make the switch.

Opportunities aren’t better or worse - they’re just different.

Banking

Bank tellers. For a long time bank teller was a potential entry point into the world of finance. Learn the procedures, handle cash, advance through the branch, and move onto corporate. Then the ATMs were introduced in mid-twentieth century (in a moment of vulnerability I’d like to admit that I didn’t realize that ATM stands for Automated Teller Machine). The need for accepting and dispensing cash has diminished.

The teller jobs changed. It wasn’t about counting bills (and in fact, if you’ve been to a bank recently and interacted with a teller - they don’t really count the cash for you). The job didn’t die out, but is mostly about customer service and selling products for the bank.

With a change to teller’s role - now mostly of a customer service representative and a salesperson - a direct path from teller to a finance analyst is mostly no more. A finance degree and proficiency with financial software are what’s advantageous here, with the teller counter experience becoming irrelevant.

The door closes. Actually, the door’s been bricked up altogether.

Photography

Now for something that might have actually gotten better for folks trying to break in: photography. Ask your parents (or grandparents if you’re Gen Alpha) – about becoming a pro photographer pre-digital. It was a mission: you needed a darkroom, which meant space and a boatload of chemicals that probably weren’t doing your health any favors. Equipment cost an arm and a leg, film was pricey, and developing film was a whole other cost and skill. You’d need to wait hours or days to see if those expensive shots were any good. Apprenticeships were common because the barrier to entry, both in cost and arcane knowledge, was sky-high.

Then digital cameras, especially affordable DSLRs in the 2000s and eventually decent smartphone cameras changed the industry. Suddenly there’s no more darkroom alchemy - with Photoshop your house no longer smelled like a chemistry set. The learning loop shortened from hours or days to seconds: take a picture - look at the screen - delete - take another picture, and abundant online tutorials make learning free and accessible for all. S

Even distributing your work is easier - no longer do you need to contact a publisher or beg a gallery to look at your prints. Instagram, Flickr (is that still a thing?), and other photo sharing sites allow you to reach global audience in a few clicks. Yes, the market’s flooded, and everyone and their mother are a photographer now. Experts still do stand out in the sea of amateurs, although it’s definitely much harder to do so. But the pathway to learning the craft and getting the audience has been democratized.

Knowledge is widely accessible, and entry costs are significantly lowered.

A common pattern emerges: the mundane, the highly repetitive, the work that served as “experience building” largely through sheer volume – that’s what tends to get automated. And as a software engineering manager, that’s what I usually leverage junior engineers for. And that’s not setting them up for success - oh no it’s not.

So, what does this mean for software engineering, and what can we practically do?

Think about the evolution of programming itself. We moved from wrestling with machine code and assembly to C, where we gained more expressive power but still had to meticulously manage memory. Then came languages like Python or Java, which abstracted away much of that lower-level complexity, allowing us to build applications faster and focus on different, often higher-level, business problems. Each step didn’t eliminate the need for smart engineers; it changed the nature of the problems they focused on and the tools they used.

This AI transition feels like another such leap - albeit somewhat more dramatic - and there are more tech bros, and some of the NFT drifters have joined too. Which, combined with the costs and rough edges, makes it harder for some of us to see the value behind the technology. Yet, we’re getting a new set of incredibly powerful, high-level tools. The challenge isn’t that the work disappears, but that the valuable work shifts to orchestrating these tools, designing systems that incorporate them, and solving the new classes of problems that emerge at this higher level of abstraction.

If the common understanding of a junior software engineer is someone who primarily handles boilerplate code, fixes very basic bugs, or writes simple unit tests that could be script-generated, then yes, that specific type of role is likely to disappear. That work was more about human scripting than deep engineering.

The career path isn’t vanishing; it’s demanding different skills, often earlier.

For junior developers

Frankly, the advice for junior developers hasn’t really changed. Unlike Steve Yegge, I still think you should learn Vim though.

1. Learn the tools: Your early-career work will increasingly involve interacting with AI-generated code, understanding its structure, integrating it, and debugging the subtle issues that arise. Developing effective prompts, validating AI outputs thoroughly, and fine-tuning models for specific tasks will be valuable skills. This is still foundational work, but it requires a different kind of critical engagement.
2. Get good at learning: Tools and AI models will evolve quickly. The ability to teach yourself new paradigms efficiently is crucial. Focus on the underlying principles of software development; they tend to have a longer shelf life than specific tools.
3. Develop scepticism: Don’t implicitly trust AI outputs. Your value will increasingly stem from your ability to critically evaluate, test, and verify what machines generate. Seek to understand why a tool produced a particular result.
4. Practice: Theory is essential, but practical application is where deep learning occurs. Use these new AI tools to build something non-trivial. The challenges you encounter will be your best teachers.
5. Tread with caution: Your senior peers might be sceptical of AI tooling. There’s a lot of hype, and senior developers have been through many hype cycles - I know I have. Show, don’t just tell, and be prepared to defend your (AI-assisted) work rigorously.

For senior engineers and managers

These are the steps my peers and I should be taking to set up those in our zone of influence for success.

1. Adapt: Your role isn’t to shield junior colleagues from AI but to guide them in using these powerful tools effectively and ethically. This requires you to understand these tools well. Mentorship will likely focus more on system-level thinking in an AI-augmented environment.
2. Re-evaluate skills: Consider how AI changes the value of certain traditional skills. Is deep expertise in a task that AI can now perform rapidly still the primary measure, or is the critical skill now defining problems effectively for AI and integrating its solutions? Your metrics for talent should adapt.
3. Engage with tools: To lead this transition, you need firsthand experience with these tools. Understand their capabilities, limitations, and common failure modes. This practical knowledge is essential for making informed decisions and guiding your teams.
4. Redesign tasks: Phase out giving juniors only the highly repetitive tasks that AI can now handle. Instead, structure initial assignments around using AI tools for leverage, then critically evaluating, testing, and integrating the results. Their first “wins” might be in successfully wrangling an AI to produce a useful component, then hardening it.
5. Teach AI skepticism: Don’t assume junior developers will know how to question AI. Make it a core part of their training. Ask them to find the flaws in AI suggestions, to explain why an AI output is good or bad, not just that it “works.”

True engineering skill has always been about problem decomposition, understanding trade-offs, systems thinking, debugging complex interactions, and delivering value (to shareholders). AI doesn’t negate these fundamentals; it changes the context in which we apply them and the leverage available.

New engineers often lack deep context and the experience of seeing systems fail. AI won’t provide that - in fact it’ll make it harder to spot a lack of fundamental understanding.

The path to seniority won’t be about avoiding AI; it will be about learning to master it, question its outputs, and work strategically with it. It will require fostering critical thinking and deep systems knowledge to use these powerful tools wisely.

The old ways of gaining experience will not disappear - they will evolve. The challenge is to define what skill looks like in this new landscape and ensure our learning pathways effectively build it.

The future will need senior engineers; they will be the junior engineers of today who navigated evolving technological terrain and learned to harness its potential. It’s time to start mapping that new path.