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.

Write While True Episode 37: The Passive Voice Was Used

Podcast: Play in new window | Download

Today I want to talk about one of the rules that’s in Strunk and White. It’s actually in almost every book about writing, which is to use the active voice and to prefer it over the passive voice.

Transcript

September 2023 Blog Roundup

This month I published four episodes of my Podcast. We are in the middle of season three, which has been about the basic building blocks of writing: words, sentences and paragraphs.

I rediscovered PlantUML. I had dismissed it because I thought the setup was too complex. Then I realized that I mostly want diagrams in Confluence and that there was a plugin that let me do that easily. There are also lots of online editors, so there’s no reason to run it locally.

I made journals with prompts for guiding morning pages. To do that, I added a lot more features to Page-o-Mat (a tool for creating journals). Then, I used it to create the cover and inner-page PDFs that I used to make the book on Amazon KDP.

I wrote some more posts on software job hunting

Speaking of how little it takes to stand out, I celebrated Post #500 by sharing some of the ways this blog has impacted my career even though it’s not widely read. The more you put out there, the more chance you have of being found, but anything is better than nothing.

It takes very little to stand out

One thing I tell mentees, particularly those in college looking for internships or their first job, is that they have to think about what the job application process looks like from the other side. When an employer opens a job position for an entry-level position, they will be inundated with resumes. The vast majority of them are indistinguishable from each other. They have the same classes, GPAs in the same range, similar job histories. You have to be honest with yourself with whether you’d stand out in that pile.

What you should do depends on the situation, but the general idea is to do more than your peers. The good news is that your peers (when you are entry level) are pretty clueless. It takes some effort, but it’s doable.

Do research, follow up, network, find peers that were successful and get intel on interviewing. Just don’t assume that you are done once you send in your resume.

Prompt Engineering is a Dead End

LLM chatbots are bad at some things. Some of this in intentional. For example, we don’t want chatbots to generate hate speech. But, some things are definitely not intentional, like when they make stuff up. Chatbots also fail at writing non-generic text. It’s amazing that they can write coherent text at all, but they can’t compete with good writers.

To get around some of these limitations, we have invented a field called “prompt engineering”, which use convoluted requests to get the chatbot to do something it doesn’t do well (by design or not). For example, LLM hackers have created DAN prompts that jailbreak the AI out of its own safety net. We have also seen the leaked prompts that the AI companies use to set up the safety net in the first place. Outside of safety features, prompt engineers have also found clever ways of trying to get the LLM to question its own fact assertions to make it less likely that it will hallucinate.

Based on the success of these prompts, it looks like a new field is emerging. We’re starting to see job openings for prompt engineers. YouTube keeps recommending that I watch prompt hacking videos. Despite that, I don’t think that this will actually be a thing.

All of the incentives are there for chatbot makers to just make chatbots better with simple prompts. If we think chatbots are going to approach human-level intelligence, then we’ll need prompt engineers as much as we need them now for humans, which is “not at all.”

Prompt engineering is not only a dead end, it’s a security hole.

Triangle Estimates

I estimate using time, not points. I do this even though I have mostly worked on product development teams inside of companies and not as a contractor for clients.

But, estimation on product development is not as high-stakes an activity as it is if you are billing based on it. The judgement of a successful product development project is based on whether it moves some business needle, not whether it was under budget. The margin on successful product development dwarfs reasonable overruns. There is also a lot of appetite for risk, where we know that we’ll win some and lose some.

That’s not true if the work is for clients. If they pay by the hour, they expect the estimate to be accurate. But there are very few (if any) big software projects that can be accurately estimated. When you’re wrong, you either have to eat it or have a very difficult conversation.

I don’t have a good answer, but I would start with triangle (or three-point) estimates. To use them, you estimate a most-likely estimate and then a best and worst case on either side. The three numbers describe a distribution (see the wikipedia page for how to combine them). The result is an estimate with a error range and a confidence interval. I would recommend sharing that instead of a single number.

The only task management system that I have seen that offers this option is DevStride, which carries three-point estimates throughout its system.