Marbleized Code Fat?

I go back and forth on whether the name “Tech Debt” is the most useful term. In my book, I decided I can’t fight the term, so I use it, but in my opening paragraphs I make an argument that the problem we call tech debt isn’t like other debt.

The most common way I’ve seen tech debt is that it’s just everywhere. It’s not limited to a specific old module, it pervades the codebase like marbleized fat in a good steak, but not as delicious.

Follow-up on my Tech Debt Article in The Pragmatic Engineer Newsletter

About two weeks ago, The Pragmatic Engineer published an early excerpt from a book I’m writing on Tech Debt. This week, he published a follow-up that’s available for free. Read it here:

https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt-further-learnings

If you missed the original article, it’s here: 

https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt

After that article came out, there were a few LinkedIn posts with good conversations about tech debt. This one by Ellery Jose has an interesting table that breaks down how to treat technical debt as a financing decision:

​https://www.linkedin.com/posts/ejose_tpm-pmo-engineering-activity-7237750795348164610-5mKq/​

Also, Guillaume Renoult sent me this post he wrote:

​https://medium.com/elmo-software/how-to-sort-out-tech-debt-and-speed-up-development-9a1d27fdd39e​

There is a section of my book that has similar ideas to these two posts, particularly team management of debt using evidence and data. I’m hoping to have a draft done of that part in a few weeks. If you want to see an early version, sign up to receive updates.

My Guest Article on Tech Debt for the Pragmatic Engineer

I started writing a book on Tech Debt in January and I posted a few chapters in the Spring. A few months later, Gergely Orosz from the Pragmatic Engineer reached out to ask me to write a guest post for The Pragmatic Engineer newsletter—it just went up today.

https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt

If you want updates about the book, sign up here: Pay down tech debt to go faster right now

There are a lot of posts on this site about tech debt. Here are a few

LLMs Talk Too Much

The biggest tell that you are chatting with an AI and not a human is that they talk too much.

Yesterday, to start off a session with ChatGPT, I asked a yes/no question and it responded with a “Yes” and another 325 more words. No person would do this.

Another version of this same behavior is when you ask an LLM a vague question—it answers it! No questions. Just an answer. Again, people don’t usually behave this way.

It’s odd because in the online forums that were used to train these models, vague questions are often called out. It’s nice that the LLM isn’t a jerk, but asking a clarifying question is basic “intelligent” behavior and they haven’t mastered it yet.

LLMs Can’t Turn You Into a Writer

In Art & Fear, the authors write:

To all viewers but yourself, what matters is the product, the finished artwork. To you and you alone, what matters is the process, the experience of shaping that artwork. The viewers’ concerns are not your concerns. Their job is whatever it is, to be moved by art, to be entertained by it, whatever.

Your job is to learn to work on your work.

If you use LLMs to write for you, you will end up with writing. You’ll pass your class, get by at work, or get some likes on a post. But you will not become a better writer.

It might even be hard to become a better judge of writing. If you do, it won’t be by reading what LLMs bleat out. It won’t be by reading their summaries of great work. “Your job is to learn to work on your work” and to do that you need to do your own writing and limit your reading to those that do the same.

Policies that reduce dependencies

Over time I have become skeptical of most dependencies. I wrote in Third-party Dependencies are Inherently Technical Debt:

[…] any third-party dependency is technical debt. Third-party? Here’s how I am defining it for the purposes of this article. You are the first party, the platform you are writing on (e.g. iOS, Android, React, NodeJS) is the second party. Everyone else is third party.

[Third-party dependencies are debt because] you need to constantly update them, […] they introduce breaking changes, […] they become unsupported, […] your platform adds their own incompatible implementation, [… and] they don’t update on the same schedule as the [platform].

To that end, I like policies that tend to reduce the number of dependencies you have. Here are a couple that I have seen work.

  1. Become a committer on any third-party dependency you take on. To be fair, you kind of owe that to the project.
  2. Donate to any third-party dependency you take on where you won’t become a committer.
  3. Fork the dependency and bring in updates carefully.

Seems like extra work, right? The extra work is why they work.

Identity is a Powerful Habit Totem

In my post, Environment Hacking, I wrote about a problem I ran into with BJ Fogg’s Behavior Model:

One of BJ Fogg’s insights is that you already have habits that are completely automatic, so he suggests using those as prompts for a new habit you are trying to build. You repeat to yourself, “After I do [some automatic habit], I will do [some tiny version of a new habit]”. For example, “after I brush my teeth, I will floss one tooth”. In this case, the environment is your existing habit.

This works great, but I have some habits that I can’t easily tie to existing one (or at least I haven’t been successful at it yet). For these kinds of habits, I have been thinking of “habit totems” I can put into the environment to prompt me.

In that article, the idea was to place objects in the world that remind you to do things when you see them. I called those objects “Habit Totems”. A Habit Totem works because it’s always present at the place where you want to do the habit, and it prompts you to do it.

Your identity can be a powerful Habit Totem because it is always present, and it changes how you perceive the environment such that it turns everything into a prompt.

I have an identity as a programmer. I program all of the time without prompts, because everything reminds me about programming. I also have an identity as someone that eats plant-based food—no prompt needed at the grocery store or restaurant because it’s just a part of who I am.

But I struggle with my aspirational identities. I want to be a writer, but I still haven’t assumed that identity enough for it to be a driver on its own. I want to make my plant-based identity more specific by becoming “whole-food plant-based”, but I haven’t made a lot of progress.

What I am trying now is to try to internalize that I have already become the identity I aspire to be. I walked through the grocery store last weekend just repeating “I only eat whole plant-based food” and managed to leave with a cart more aligned to that identity. I am writing this blog because “I am a writer” and a writer writes. When I thought about my experience at the grocery store, I was more compelled to write about it.

It’s only been a few days, but it feels very powerful so far.

Humans Have Been Upgraded by LLMs

If, twenty years ago, you took the most sophisticated AI thinkers in the world and set up a Turing test with a modern AI chatbot, they would all think they were chatting with a human. Today, that same chatbot would have a hard time fooling most people that have played around with them.

In a sense, humans have been upgraded by the existence of LLMs. If we had no idea that they existed, we would be fooled by them. But, now that we’ve seen them, we’ve collectively learned how they come up short.

Write While True Episode 43: Accountability Groups

There’s a hole in this process, and we need to fill that right now. This only works if you’re doing the lead activities consistently, and if they really do build up to the end goal. It’s true that working on the book is intrinsically fun and interesting. And if that’s all that happened, I’d probably be okay with it, but I really do want a book in the end.

Transcript

Static Site Generation from Django

I created App-o-Mat in 2014 using Django (pre-1.0) and Python 2, and for all that time it was deployed on relatively cheap hosting that supported Python backends. Unfortunately, my host recently decided to stop supporting Passenger and Django had long ago abandoned fastcgi. My options were to upgrade my hosting or look for an alternative host.

I had been wanting to look at AWS’s App Runner service, so I started reading through the docs and doing a trial port of my site. Since I also use MySQL, I had to also learn RDS. At some point I knew enough to try to figure out what this was going to cost to host and it turned out to be more expensive than just upgrading my hosting platform, so I abandoned AWS.

App-o-Mat is a content-driven Django app. It doesn’t have any interactivity in the public pages—most of the advantage of Django to me is in its CMS admin interface where I can author new articles. The public site is essentially static.

So, rather than upgrade my host, I decided that I now just run the site locally on my laptop and use wget to crawl it to get a static site that I scp to my host. I had to manually cause issues to get my 404 and other error pages to be part of the crawl. I see that there’s a project, https://django-distill.com, that purports to turn any Django project into a static site generator, but it also doesn’t automatically handle your error pages.

I might use django-distill in the future, but I write new content very infrequently, so we’ll see.