Just heard this template from The Art of Charm ep. 782 for how to answer “What do you do?” when you are meeting someone in a business context.

The idea is that you want to tell them something they can remember and repeat to the right person. So, you lead off with the kind of people you help, and then you say how you help them.

For me that’s something like: “I help B2B software companies by advising them on their product engineering.” I would somewhat alter that based on who exactly I was talking to (maybe niching down to fintech or mobile). It’s intentionally not very detailed to either invite questions or to let the conversation move on.

Later, if that person meets someone who works at a B2B software company that says something like “I wish I could get a handle on our developer productivity”, they might think of me.

A few weeks ago, I wrote about what computing did to baseball, which was that it had doubled the number of stats they report every 18 months.

Right now, I am watching the Jets on Monday Night Football. It’s been a while since I tuned into a game live because I don’t live in NYC any more, so the Jets are hard to watch.

The thing that stands out to me is that there don’t seem to be any new stats. Maybe football really is just yards and points.

More likely is that there have advances in stats that help scouts, but the announcers have concluded that they are boring. They are right.

I work alone on my programming projects, but I still make pull requests. I also review my PRs. It feels silly hitting the Approve button in BitBucket, and BitBucket knows that. It keeps warning me that my PR doesn’t have any external reviewers.

In 2003, the first year of this blog, I wrote about using Source Control for One, where I agreed with Eric Sink that source control was useful when working alone. It’s hard to think that there was a time when that would be non-obvious advice, but it wasn’t.

Today, in 2023, I think making PRs when working alone is probably common. I think that reviewing them isn’t. I’m not sure if I can convince you, but the reason I do it is that I keep finding problems. Also, it keeps me honest and makes sure that I keep Constructing PRs to Make Reviewing Easy.

Yesterday, when I wrote about the semantics behind art and content and making and whatever it is I do, I said that I know that calling my code “art” was a stretch.

There is code that is accepted as art. Games or any code that creates visual art or music are examples. But what about the payment system for a B2B SaaS app? I think a lot of people would call that craft.

But, I recently read Art & Fear [amazon affiliate link] and I am convinced by their distinction between art and craft.

In essence, art lies embedded in the conceptual leap between pieces, not in the pieces themselves. And simply put, there’s a greater conceptual jump from one work of art to the next than from one work of craft to the next. The net result is that art is less polished — but more innovative — than craft. The differences between five Steinway grand pianos — demonstrably works of consummate craftsmanship — are small compared to the differences between the five Beethoven Piano concerti you might perform on those instruments.

[…] your job as an artist is to push craft to its limits — without being trapped by it. The trap is perfection: unless your work continually generates new and unresolved issues, there’s no reason for your next work to be any different from the last. The difference between art and craft lies not in the tools you hold in your hands, but in the mental set that guides them. For the artisan, craft is an end in itself. For you, the artist, craft is the vehicle for expressing your vision. Craft is the visible edge of art.

– Bayles, David; Orland, Ted. Art & Fear (CRAFT) / emphasis mine

To Bayles and Orland, the Artist is using craft to explore Thousands of Variations of an idea. They are not seeking perfection. If that’s the distinction, I personally resonate with the idea that my code is more art than craft. I could see others thinking the opposite about theirs.

If you look at the headers from GET’ing http://info.cern.ch/hypertext/WWW/TheProject.html, it has these lines:

HTTP/1.1 200 OK
Last-Modified: Thu, 03 Dec 1992 08:37:20 GMT

I believe that it really hasn’t been updated since 1992. Look at the top snippet of the HTML to see why I think this:

<HEADER>
<TITLE>The World Wide Web project</TITLE>
<NEXTID N="55">
</HEADER>
<BODY>
<H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area<A
NAME=0 HREF="WhatIs.html">
hypermedia</A> information retrieval
initiative aiming to give universal
access to a large universe of documents.<P>
Everything there is online about
W3 is linked directly or indirectly
to this document

There are a few obvious differences between this and modern HTML

1. No enclosing <HTML> tag
2. <HEADER> instead of <HEAD>
3. <P> is being used like <BR/>

But, Safari renders it as I think it was intended.

Is this because bad HTML has always been rendered? Or is HTML somehow backwards compatible to this? I suspect the former.

I’ve always been annoyed that browsers render bad HTML. I think it makes it harder to find problems. But, I also love long-lived systems that don’t require human intervention and substitutable versions, so I hope that it’s planned backwards compatibility instead.

I just finished migrating App-o-Mat from Bootstrap to Tailwind. Here are some things I recommend if you are trying something similar

1. Don’t try to keep the same markup. It’s likely you can make it a lot simpler.
2. If you need icons, use Heroicons.
3. If you use @apply, use it to style tags or to make more utilities.
4. Generally, Tailwind seems mature enough that what you think of as an edge-case is covered somehow.

The next thing I will try is using it in a React site (with TailwindUI components)

The best teams use “methodologies” for ideas and to figure out what works for them. Without buy-in, nothing works.

So, the most important part of a software process is the ability to change it.

I have dozens projects on my drive that are playgrounds for me to try out things I am learning. Each of them is a simple example of a “type” of project (e.g. a React Native app, a React App, a clojure program, a SwiftUI app, etc). I don’t actively maintain them until I need to use them again.

Two of these playground projects are public: Habits and App-o-Mat.

Habits is my first iOS App. I made it in 2008, and it’s the codebase I have continuously worked on the longest. It always builds in the latest Xcode, and it has both Objective-C and pre-CoreData sqlite code. It also has modern Swift.

App-o-Mat is a content site for iOS and watchOS tutorials, which is made in Django with a simple HTML-heavy front-end. I made it in 2014, and it’s my second longest continuously worked on codebase. I regularly migrate it to the lastest Python and Django (it was originally Python 2 and Django 1.0).

Whenever I want to try out new iOS features, I can usually find a place in Habits to do that. When I want to try out a new CSS framework, App-o-Mat is simple enough to try it out and see if I’d like it, but not too simple.

I started converting App-o-Mat to Tailwind a couple of days ago. I have run into enough edge-cases that I am sure that I am giving Tailwind a good look. I have tried out other CSS frameworks in the past (even just trying to update to the lastest Bootstrap) and it hasn’t gone as well as this is going. Tailwind is different enough that you need to try it on something real, and App-o-Mat

Making them public has been an incentive to keep working on them, which means they are playgrounds that are always ready for more play.