Don’t Make a Phone-a-Taxi App

In 2007, seeing the iPhone and owning a taxi company, you might think it was a good idea to make an app. After all, people need taxis when they are out and about. Maybe, you think, that people will stop using pay phones, so they won’t see the stickers you plastered there with your phone number.

So, you get Phone-a-Taxi made so that people can use an app to call you up. They tell you where they are and you send a cab. There are hardly any apps in the store, so you get a bunch of downloads and calls, and things look great. You are riding the smart phone hype wave.

And then Uber comes along.

That’s what a lot of LLM features feel like to me. Technically, they are using LLM technology, but mostly just trying to shoehorn chats and autocomplete into apps that were not designed around LLMs. Even GitHub Copilot is guilty of this. I love it, but in the end I still have the same amount of code I had before. I don’t even want code—I just want the program.

Like the Phone-a-Taxi app, they are still doing things the old way.

Not Rejected, Just Not Picked

When I was interviewing software developers in the 1990’s, it was very common that people would apply that could not code at all. I don’t think they were nervous or that the question was unreasonable. We were a C shop and the question I opened with was in K&R and just a simple question about arrays. Many candidates could not give any answer. I wasn’t the only one seeing this, which is why FizzBuzz was created.

These days, I hardly ever see that. Nearly everyone I interview can code and can answer the simple questions. Many can answer any reasonable question. This means that we often had more than one good candidate.

But we still had only one job.

The problem is similar to what I wrote yesterday about layoffs. You might need to layoff a person you would hire if you had the budget. In both cases, that person is not really rejected, they just didn’t get picked from (what was probably) multiple good options.

Comparing People is Not Transitive (Another Reason Why Stack Ranking Doesn’t Work)

Layoffs are hard, but we shouldn’t try to make it easier with stack ranking because ranking is inherently one-dimensional and forces you to compare pairs of people. For layoffs, you should want to compare different multi-dimensional teams.

In programming, we know that whatever algorithm you use to sort a list, you need a function to compare two items. But sorting this way only works if comparing is transitive. This means that if a<b AND b<c then a<c. This works for numbers, but you need to be careful when you make your own comparators.

There’s no natural way to order people, so when you make one up, it’s often not transitive. The second problem is that the comparator only has the two people to compare, not any other context. That means that when you are considering the “value” difference in a pair of people you are not using the context of the team that they will be on.

Instead of sorting, consider this visual aid:

A spike graph that shows multiple dimensions

I explained this graph in Raising The Bar is a One Dimensional Concept. Each spike represents an attribute of a team member that you value. For example: coding skill, team gelling skill, writing ability, domain knowledge, code-base knowledge, mentoring—you can have as many as you want. Your team members may each excel in some, but lack skill in others. For each member, put a dot somewhere on each spike of the graph and connect it to make a polygon. By overlaying the individual graphs, you can see if you have a balanced team with diverse abilities and interests.

Here’s how I suggest you use this. Let’s say you have 10 developers and you need to lay off 20% of total salary. To decide, try evaluating each member on all the dimensions you value and create a team using your budget to pick the ones that result in the team you want.

Let’s say you start with some obvious top-performer. They have the most seniority, have mentored well, write great documentation. They are all-around a person that you want to keep. The next person to add is probably not someone similar to that. You want to end up with a good mix of junior and senior people, so the next person might be someone relatively unskilled, but perhaps with other desirable attributes.

The key is that you are thinking of that junior person in combination with the senior one, not comparing them against each other. To the extent you are comparing team members to add, you are considering which one is a better multi-dimensional addition to a multi-dimensional team, not looking at them in isolation. As you build up the team, you may notice things the team needs, and pick the next person based on that. You should try this a few different ways, with different starting points, and see if they converge.

Instead of thinking of people that you need to cut, you focus on building the best team you can afford. You should already know how to do this because this is a good way to recruit as well.

Write While True Episode 38: Content-free Sentences

I’m reading a book by Stanley Fish called How to Write a Sentence. I found this book by Googling that exact question because I wanted to find anything that might be a fit for what I’m podcasting about this season.

Transcript

You Can’t Rank Order Multi-Dimensional Things

One of the most surprising things I learned in math was that complex numbers had no natural ordering. Meaning, less-than and greater-than are not defined for complex numbers. It makes sense when you think of it for a minute. The same applies to other multi-dimensional things like matrices and vectors.

So, why do we think we can rank order people? I’m specifically talking about companies that do this for their employees, but it comes up in other contexts (e.g. class rank).

Even if you were to think of people as a number, it wouldn’t be expressed as a 1-dimensional one. When I wrote about the concept of lowering/raising the bar, I said that that a bar is a 1-dimensional concept. So is rank ordering.

Just like with complex numbers, you can make up an order if you want. But then you lose information. For example, if you choose to order based on magnitude, then direction would no longer matter. Similarly, when you rank team members by, say, seniority, you lose orthogonal characteristics, like the ability to catalyze others.

The reason companies do this anyway is when they are looking to downsize. If they do need to lay someone off, it might well be the lowest ranked person, but it’s a terrible way to do this. I do have a suggestion, but I’ll get to that Monday. [EDIT: Here it is – Comparing People is Not Transitive]

Hype and Career Bets

My professional career started in 1992. Since then, there have been a lot of hyped technologies, but I only really have acted on very few of them. Most of them, I let go by without taking much action.

I only took big career bets on the web and smart phones. Before I learned how to program for them, I used them every day. Then, I taught myself how to develop for them and changed jobs to do it full-time. In both cases, going from a place where I was very comfortable to a startup.

I passed on nearly everything else: social media, web3, blockchain, big data, ML, functional programming, NoSQL, cloud infrastructure, VR/AR—I know them “enough”, but they were not big factors in my career. Partly it was because I was still benefitting from being an expert, but mostly because I wasn’t personally excited by them as a user or as a software product maker.

I’m thinking about this, because we’re in an LLM hype cycle now. I use products based on it nearly every day. I feel like I did when I used the web and smart phones. I’m getting a lot of value and I want to know how to make things for it.

Self-Hosting a Podcast: 2.5 Years Later

It’s been 2.5 years since I started working on a podcast and decided to self-host using the Blubrry WordPress Plugin and S3. Here are my original reasons and current thinking:

  • I want the episodes to be available indefinitely, even if I stop making new ones“: This worked out great since I took a break for 2 years between episode 15 and 16. It would have felt bad paying a bill for something I wasn’t actively doing.
  • I don’t want to pay for just hosting“: The key is “just hosting”. I think there are potentially a lot of things I (as an amateur podcaster) might like to pay for, but I didn’t see anyone offering something I cared about.
  • I don’t care about analytics“: This is the main downside to self-hosting. I rolled my own analytics, but I’m not 100% sure they are correct. The problem is that to get anyone else to do your analytics, you have to send listeners to their URLs, which I am unwilling to do—partly because of the privacy leakage, but mostly because I value my URLs too much. I haven’t found this, but I’d like service I could upload weblogs to and get useful podcast-oriented analytics from.
  • “I have the skills and desire to learn how to self-host“: I don’t think you should self-host unless this is true for you.

Two years later, I can say that my system is easy to use and never requires any intervention to keep running. I never think about the reliability of S3 or Blubrry. My analytics scripts have needed tweaking, but that has mostly settled down.

Your First LinkedIn Message Should Not Be a Lie

Every week I get a few messages that start “I was looking at your profile and I noticed …” or something to that extent, and then they just have some generic, irrelevant pitch. They absolutely did not look at my profile. If they had, they would not have bothered contacting me. So, their very first words were a lie.

I’m open to being contacted by strangers on LinkedIn. To some extent, I am interested in how people contact others to see if I can learn. So, I should be thankful that I learned how much I hate this kind of opening, so I will never use it.

Knowing What You Don’t Want

When I wrote that I think job seekers should write a job statement to help narrow your search, I listed twelve ideas for what to put in it. Many of the ideas are either/or type questions about company size, industry and so on. What I didn’t consider in that post is how useful it might be to just rule things out.

After working in IT for a non-profit for two years, I realized that I only want to drive revenue, not cost reduction. I also decided many years ago not to work in AdTech or Social Media. I now think of my job statement as being a positive statement about only working in B2B SaaS, but it took me a while to narrow down to that.

Ruling things out helped me get there eventually.

QA is Valuable When Releasing is Expensive

In 1992, at my first job, to release the software, someone took a few days to make 100’s of floppies, and then we all stuffed envelopes so we could mail them all over the world. Our customers were banks who only adopted new versions carefully. Releasing was expensive, so releasing with a critical bug was unthinkable. It’s not surprising that the person who did the most QA work was one of the leaders of the company who was a former customer and had deep domain expertise. To help him, we built custom test automation tools.

These days, releasing is so cheap, that it feels like software companies are fine with releasing a bug. Between the time that Apple sent out iPhone 15’s and the time most arrived, they released iOS 17.0.2, which fixed a critical bug transferring data. Apple has a support doc showing how to recover, so we know it happened to customers, but most people were guided by the installer to update their OS, and it was fine, I guess.

That’s an OS release, which used to be hard. Meanwhile, the cost of releasing a web app has been near zero for a while, and it’s a joke in the industry that the customers are the QA team.

If I were looking to do QA in this environment, I’d seek out software that is expensive to release.