Sometimes I’ll ask for feedback knowing it will make the work better but end up feeling insulted when people provide edits. Objectively I know my first draft is never perfect but somehow I get it in my head that a missing comma is tantamount to me being a failure. 

Once the moment passes, those edits almost always make the work better. My PhD thesis had a whopping 35 pages of recommended edits over its 200 odd pages. If I had tied each one of those to my ego it would have never been finished.

Why it matters: In many contexts, the things we create should have a high bar for quality. Work for publication, code we write for our job, ideas we present to others. Baked into that work are ideas and meaning, we’re responsible for ensuring those ideas reach the world in a refined form.

• In a professional context it is probably the simplest to understand. We’re being paid to produce our work, getting feedback on it helps it improve and helps our customers or colleagues receive better output.
• When we’re making things ourselves the situation is more difficult. We cannot hide behind the banner of our corporation, in many ways our work does reflect us. Even still, feedback and editing are a key part of that process. The world sees our final draft, not the count of missing commas along the way.

How to detach yourself from your work: Remember is that the beauty is often in some intangible core of your work, not the work itself. I am a terrible painter, I could try to capture a beautiful scene on a canvas and it would likely look terrible. This doesn’t mean the original scene was ugly, only that I didn’t manage to capture it well. Think of editing not as a reflection on the core, but a refinement in capturing it.

• I still get a little frustrated and defensive when I get feedback. That in the moment response is tough to change in a hurry. What’s important is what you do next. Take the time to consider feedback before acting (or responding).
• Like anything else, practice will help. Ask for feedback more often than you think you need it.
• Ask for the right type of feedback. People should be able to point out that a sentence doesn’t land or some code looks messy without giving you an alternative. In the end it is still your work to change and produce.

Choosing when to skip the edit: Sometimes editing can become a barrier to putting out work. There’s no doubt that editing adds time. Depending on the context sometimes the more important thing to do is just publish.

• These posts for example. They usually get a light edit with something like Hemingway Editor but don’t go out to other people before I post them.
• Keeping the number of editors low is also important. Ask enough people and you’ll eventually round off all the edges in your work and end up with something horribly generic.

Almost everyone will find something to mention if you ask for a review. They don’t want to seem silly. You also have full license to ignore any suggestions you receive. Including those in this post.

These metrics I’ll call Diagnostic Metrics. We choose Diagnostic Metrics to be flags, signalling that something is broken. They often have a threshold (or two for a range) that if surpassed, you act. If the metric is in its healthy zone, the best thing you can do is leave it alone.

Why it matters: There’s a temptation to believe that every metric can be optimised forever. Sales can keep going up, cost of acquisition we try to lower as much as possible. For performance metrics, that makes sense. Trying to optimise diagnostic metrics however, is a waste of effort. If we’re happy for the CPU load on our server to average below 60%, trying to drive it down to 0% doesn’t really mean anything.

• Diagnostic metrics exist at a personal level as well. Not to mistake the term diagnostic here but many blood markers have a similar healthy range. If you’re in the healthy band for iron levels then there’s no change needed.
• Diagnostic Metrics won’t give you an immediate fix. They are there to provide a diagnosis, an indication that something is wrong. They’re not there to give you the cure.
• Take the average CPU load as an example. If the server spends a day at 95% load there’s no load level we can pull to drop it back down (ignoring spending more on CPU). The alert sparks an investigation, once we find the cause, we make the change and the alarm disappears.

How to classify a metric: You may be thinking, is my metric a Diagnostic Metric or a Performance Metric? The answer, perhaps frustratingly, is that it depends. Any metric or measure can be Diagnostic or Performance depending on how we use it.

• Let’s say this quarter we’re focused on software performance. We use Response Time as a guide. We’ve not measured it before for this endpoint but have a feeling based on customer feedback that its too slow. For the next quarter, Response Time is a performance metric. We work on it to see how low it can go. We make some progress, complaints stop and we’re happy.
• Next quarter rolls around and we already have our Response Time metric on the dashboard. Given complaints are low enough we don’t want to dedicate more time to it but we certainly don’t want it to regress. Now, response time has become a Diagnostic Metric. We pick a threshold and as long as we don’t drift above that level, we’re happy focusing effort elsewhere.
• A good time to switch from Performance to Diagnostic is when we see diminishing returns on new work. We can drive up our click through rate for a quarter or two but eventually we’ll hit a ceiling. We then decide if a much smaller shift is worth as much effort, or if resources should be better spent elsewhere.

Why it matters: Chat offers breadth as an interface, but it has thus far proved to be somewhat unnatural. Guides on prompt engineering show these models need help to perform at their peak. To bring the value of these models to everyone, we need to wrap them in accessible and intuitive interfaces.

• Chat is unlikely to disappear but it'll likely be for power users, much like the command line is today.
• Graphical user interfaces have replaced the command line for day to day users. Teams of user experience designers work with end users to try and remove friction.

I had a moment recently that triggered this post. There's a new feature on YouTube that plays an effect on the like button when someone says “hit the like button”. This was a small moment but likely involved several ML models. One translating speech to text, another looking for phrases about the like button. As far as I can tell, this all happens behind the scenes with no user intervention. 

What’s holding it back: Designing user experience is hard. It is a specialty in itself. Chat is wide open and flexible which has made it an attractive default. Despite that, our job is to remove friction in giving users what they’re seeking. The current interface for many LLMs is setting system level prompts. This is a behaviour which doesn’t lend itself to moving away from ‘chat’ at the primary interface.

• Providers like OpenAI will likely start to introduce other ways to guide models. Other models for image generation have some options with things like temperature.
• The challenge building on top of off-the-shelf models is that adding other levers requires more training. Without that level of access to a model, chat becomes the only option.
• It’s also worth noting that even the best of today’s generative AI models have some serious shortcomings. Hallucination, regurgitation of copyrighted content and safety are still being worked on. Where they land and what that means for the future of these models is yet to be determined.

Ultimately, users buy products to solve problems for them. We need to make sure the products we build are solving problems with as little friction as possible. Explaining a problem, correcting mistakes, and chanting secret prompts won't work long term. We’re still early in the world of UX for AI so I wont call it a loss at this stage. Five years from now we'll likely look back on chat as the primary UX the same way we look at the command line today.

There are three general rules of thumb I use to judge a metric. They all come down to the lifetime of that metric. Some measures are just fine for a quarter but would steer us off track if followed for a year. Conversely some metrics make sense when thinking about a ten year plan but are meaningless on a day to day scale.

How to avoid feeling powerless: Sometimes there is a really obvious metric. Something like ‘Raise our EBITDA to $2M by the end of the calendar year’. At face value that is a pretty good metric. It’s precise, well defined and has a timeline. If that was an annual goal it’d be ideal. If you’re in a big company however, you may have a good portion of the company wondering how on earth they can do anything today to make that happen. Typically called lagging metrics, these are the outcome, they’re great for targets but not great for in the moment action. To correct for them, we need leading indicators.

• For this metric within a sales team, we might look at something like new cold calls or follow up meetings. That’s a number that an individual can optimise on a daily basis that should help move towards the long term goal.
• For other teams it might be completing a smaller project. Maybe there are customers waiting for a new paid feature, getting that feature shipped might be close enough to track. If that project is huge, the tickets or tasks within it might work too.
• OKRs try to get this done with lower objectives feeding into higher ones. That can help but only if there is also a shift from lagging to leading as you move downwards through objectives.

How to avoid optimising the wrong thing: Track leading metrics for too long and you’ll start to see them lose meaning. Anything you measure runs the risk of eventually losing its meaning and becoming a goal in itself. Take the sales cold calls objective above, if that becomes the primary incentive for a sales team you may start to see meaningless calls being made just to hit a quota. In order to avoid your metrics becoming pointless you can try one of two things. One, let your metrics expire. Two, pair quantity metrics with quality metrics.

• When you pick leading indicators it’s fine to pick metrics with only a loose correlation. They’re around to be day to day sign posts that things are moving in the right direction. As soon as they become more than that they lose their value.
• Given these metrics are often loosely correlated and somewhat arbitrary, one method to avoid them becoming meaningless is to let them expire. If there is a similar, but not identical measure of leading success each quarter it will be much harder for anyone to game the numbers.
• Be warned though that changing the metrics too often can make things feel chaotic. It’s a balance of ensuring metrics are around long enough to let people optimise but not too long to have people over-optimise.
• Pairing metrics means finding a counter balance. For cold calls that might be cold-call to meeting conversion rate. The goal here is to ensure that any increase in the volume of calls isn’t coming at the expense of the quality.
• If you take this route it’s important to make sure both metrics are equally valued. It’s easy to have a quality metric that becomes an afterthought if incentives are still aligned solely to quantity.

How to avoid measurement becoming a time sink: Sometimes it becomes tempting to try and find the perfect metric, or to find enough metrics to get perfect visibility over every aspect of what you’re trying to optimise. Collecting, collating and displaying metrics can be a full time job. It’s important to make sure that work doesn’t become a distraction. At the end of the day, the metrics, dashboards and goals you’re setting are signposts for the value, not the value itself.

• A dashboard with a thousand metrics will tell any story you like. You can find evidence for or against your gut feeling. That comfort is a trap sometimes. Depending on your personality that might paint a far too optimistic picture, or one filled with signs of failure at every turn.
• On the other end of the spectrum is the quest for the one perfect measure. The combined, weighted, maybe even AI generated signal that should drive all behaviour. Beyond being at major risk of being impossible to influence, it can create an endless workload of collecting and cleaning data just to keep the metric up to date.
• Sign posts, as most metrics should be, are there for a quick glance to confirm things are moving in the right direction. Or as an early signal to stop and check what’s taking things off course.

Going Deeper: Given the time of year, new metrics and new goals are a hot topic. There is far more written on this than I could consolidate here. Broadly I would suggest the following resources as decent further reading into how to pick metrics in a business context. There is likely a whole blog post (or more) I could also write about statistics and how to avoid making decisions on random noise, but that is for another time.

• Measure What Matters - https://www.whatmatters.com/the-book 
• How to Measure Anything - https://hubbardresearch.com/publications/how-to-measure-anything-book/ 
• High Output Management - https://www.goodreads.com/book/show/324750.High_Output_Management 

Set a schedule: Right now for me this is 45 minutes first thing in the morning. I get up early and try make a bit of progress. Often that progress feel frustratingly short on the day, but over weeks and months those efforts stack up. I've found that a little daily effort is easier to sustain than trying to lump that time into one block on a weekend. If you miss one day you're 45 minutes behind, if your one weekend block is impossible due to other plans, things feel much further behind.

Leave some breadcrumbs: Often, the hardest part is getting started. If you're following a schedule and only have a small window, getting right into things is even more critical. What's helped me here is leaving a jumping off point for the next time I start on a project.

• If its code it's a line in my git commit like: NEXT: Add a form for adding a new weekly time block.
• For blog posts and videos I'll leave something not quite done, a half finished sentence or edit.
• These breadcrumbs mean I don't have to eat into my session choosing between the many things I could do next.

Make it fun: If your side project feels like a total chore, it'll be hard to keep going. Every project has it's slow periods but it can help to inject one or two small things that keep it interesting. That might be a new library or tool to dive into. It helps ensure that even if the particular project is a flop, you can point to something you picked up on the way. That being said, I've found the chance of a failed project increases the more 'new' things I add. Boring and familiar has its place too.

Assuming your side project is in fact 'something on the side' I would encourage you to become OK with them taking as long as they take. When I was at university, time was plentiful. I could build, study, work and do everything else I needed to.

For a while I beat myself up because I wasn't pulling all nighters to build things, later I realised thinking that way was unhealthy. These days there are other things high on my list of priorities and that's okay. I can still build, just in a way that matches the time I have available.

Why its tempting: Some days you feel like things are stuck. You're not shipping as fast as you once did. There's a lot to juggle and it feels a bit like chaos. If you just get the setup right, things might all be simple.

• Assuming that you're working on something novel you're going to spend a lot of time in the unknown. Problems worth solving don't have known solutions.
• If you're a maker it's hard not to have your maker hat on even when you're in management mode. You want to build systems that are optimal, ones that feel smooth and remove all the complexity.
• A clean slate is extremely tempting. You built from zero to your current setup so it can feel like a second shot at that will be easier.

It's easy to get stuck in a loop here. Restarting the first little chunk of a prioritisation system. Each time feels great in the beginning but it's easy to end up back where you started, this time with a slightly different configuration or process.

If you really want to ship good stuff, I'd recommend smaller tweaks at a lower frequency until you hit a point where its clear you need a major revision. Advice that is just as true for a complete codebase rebuild as it is for a rebuild of process.

Why it matters: Building product, either along or in a team, is a process of shipping the most good stuff as quickly as possible. Regardless of size, teams I have been a part of always have more they want to build than they can get out the door. The teams I've seen do well are the ones that manage to pick the right things to build more often.

• Choosing those things is tough. Even getting them onto a list can be a challenge but lets assume we have a list of ideas that aren't totally crazy.
• Ultimately we want to build all the ideas, but whether its a personal project, startup or large organisation it's nice to get signal that we're not wasting time.
• Just about every company that's reached a certain size will eventually publish a blog post on how they build product. Inevitably this will be some combo of team make up, prioritisation methods and (hopefully) feedback loops to know what got built is working.

In my early days as a developer and even as I started to manage teams, it was tempting to see some new method and be tempted to shift process. Every blog post paints a glossy picture of smooth running product teams.

Changing systems has two costs. First is an adjustment period, new systems take time to set up. Second is a false reset of expectations, we buy ourselves false time to let the new system get up to speed. The harder yet admittedly more boring option is to keep things going.

Advice to my former self: I am not here to say never change systems. Going from gut feel to some sort of ranking system will probably help. What I am advocating for is patience. Small tweaks to a long run process can add up far more significantly than big swings. It also helps in not causing blog-post-methodology fatigue throughout the rest of the team.

• When I am building things, on the tools building things, there's no better feeling than being in a groove. Maintaining process or making small tweaks helps maximise that feeling.
• It is fairly unlikely that anyone is going to write blog posts about their crappy systems. We don't hear about teams warming up to new methods, failed systems or down sides.

When your current system starts to really fail, you're going to know. Post it notes won't last long when your team grows. Customers will eventually bring in more requests than your system can handle. When you hit these points, revision is possible.

Changing systems because you feel like things aren't 'perfect' is not the way to win. Building things is hard and requires hard work, no methodology out there is going to change that.

Why it matters: Every now and then you'll have a thought. One you think is novel enough to be worth sharing. If you are at all compelled to write online, you might be tempted to blog about it. Having an idea you can't quite articulate can be incredibly frustrating. Much like everything else we do, the answer is more practice.

• Writing can be tough. There's usually no better way to realise how poorly formed your ideas are than to try and write them down.
• Most of us likely write a lot in our day to day, email, texting, all sorts of communication is text. Despite this, getting a brand new idea into words can be tough.
• It's easy to put off publishing smaller, simpler ideas out of worry that they're not big enough to matter. I am personally guilty of this one.

How to start: In the end it comes down to the most annoying kind of advice. Just do the work. To get yourself into a spot that you're ready when big ideas come along you need to practice.

• Writing down and publishing little ideas is the most direct way to practice. The more you do it, as long as you're deliberate, the better you'll get.
• Writing but not hitting publish isn't enough. Most people put a higher bar of quality on something that's being made public. Even if nobody will ever read it.
• That doesn't mean hours of painstaking editing. It's a blog after all, not a novel.
• One thing I have found handy in this regard is keeping a list of "Things I could write about". I pop new ideas on there when they come up and then I sit down and write.

In fact, this very post came from one of those ideas. Somebody once said people blog about things they wish someone else had told them. This is probably true here.

The end goal: It's important to remember that these posts are not meant to be wonderful. The goal here is to do the reps. Be ready for when the big ideas arrive.

• You probably will get better at writing out little ideas. If you pay attention to what you're writing, you'll spot areas where you can improve.
• You'll also get faster at getting ideas out of your head and into words. Some of those words might get culled in an edit but it's a lot easier to do that when they're solid.

Plus in the end, who knows, some of those little ideas might be great big ideas for someone else.

Finding time to reduce tech debt is an important part of balancing development time. Making up for intentional previous trade offs in quality for time is tech debt. A mental model or abstraction can become unsuitable for users as the variety of use cases grows.

Replacing these abstractions should be a part of product process, not tech maintenance. Replacing abstractions without concrete use cases will lead likely to premature optimization and new abstractions which are unlikely to be correct.

Backstory

I'm now leading product at a logistics technology startup with a code base roughly four years old. Recently we needed to scope an upgrade to how we store prices for point to point transport of goods. The setup we designed would map prices against two locations. These locations could be concrete places, like a warehouse, or broad locations like a suburb.

In designing this setup, we found that a number of other places in the code base had similar concepts. We made the call that this unified location model brought a lot of quality of life additions and would work to migrate the code base to use this new model where we could. After input from the development team, it turned out this would be a big job. One we initially painted as cleaning up years of tech debt.

It's easy to come into an existing project, or look back on a long running one and assume everything from the past is out of date. Having done the work it is easy to look back and pick out issues. We need to remember that what we needed yesterday might have been different from what we need today.

Along those same lines, building next year's solution today isn't the right move most of the time. We assume we know better looking backwards but I'd bet a year from now, whatever we build today will have it's flaws too. Building products, especially software, is rarely a bounded process. We grow, requirements change and the world we're building in continues to shift.

Treating everything we've done in the past as tech debt or a mistake only serves to make us miserable. Yes, tech debt is real but it should be reserved for real instances of trading off speed for completeness, not a change in complexity or requirements.

A few more thoughts:

• Working with Rust is pretty nice. I've worked with it quite a lot to date but it was another reminder that the tooling and package ecosystem is pretty excellent.
• There was a lot of TDD + refactor loops in the book. That worked okay for me as I was chipping through it in chunks of about 30 mins first thing in the morning. I imagine if you sat down to run through the whole book, that could get annoying.
• It took me about 25 hours start to finish to work through the content. I wasn't aiming for speed by any means but that might be interesting for some people when considering the book.
• Some libraries had undergone a version change since the PDF I purchased was created. I took that as a bit of a personal challenge to migrate to the new library. SQLX in particular has a new offline mode which took a moment to work out. Overall though, the book and the code repo seem to be getting minor updates and if you stick to the noted packages you'll be fine.
• The tracing, logging and related tools mentioned were very cool. Sets a high bar for other ecosystems.
• The book is written really well, props to the author for creating some really approachable content.
• The final comment I will add is that following a course feels like its teaching you a lot but having the code there can be a crutch. I finished the book and started a similar project. It was interesting how quickly I needed to head back to Google to check on syntax etc.

Overall, good book. I feel more confident in Rust than before and keen to get stuck into some larger projects.

Similar cities exist all over the world but lets stick with Tokyo as an example for the moment given it's where I was most recently.

There are a lot of people in Tokyo. Over 13 million by last count with another 2-3 million commuting in and out during the day. Despite this, Tokyo didn't feel packed. You could walk in the street, cars weren't bumper to bumper. This is likely mostly due to the world class public transportation. The networks of trains and subways keep the city moving. Missing your subway is a handful of minuets delay at most. Better yet, the cost to get almost anywhere across the city is low, equivilent to a few Australian dollars at most.

This was the first marvel of population density. Systems like this cannot exist at a small scale. You need a certain volume of people to run through a station every day to be able to offer prices that low. You need the volume to justify the outlay for tunnels, new lines and new stations. All of this is far more difficult when density is low. Where I live in Australia a large portion of the "city" population lives in the suburbs. Getting a train network to every up and coming suburb would be a massive drain on government funds. Pack the same population into a much smaller area and the return on investment is much higher.

The second thing that struck me was the number of small businesses. Tokyo is full of office buildings, but more so its full of small resteraunts, cafes and peolpe delivering lunch from the back of a van. Global pandemics aside, the chance of running a successful resteraunt growth with local population.

Hell, even a bad one probably lasts longer just based on having more peolpe willing to try things once before never coming back.

I don't think anyone could ever eat or drink everywhere in Tokyo. By the time you'd made it through a new lunch spot every day, there would be new ones opened to add to the list.

Places to eat and drink were high on my list as a tourist but this is no doubt true for business of just about any kind. When you start a business in a city of 15 million, the need to fret over global expansion plans is not a day one concern. In Australia on the other hand, it's top of mind.

I have no doubt that brands start, grow and prosper without every leaving the city. That gives a lot of people the opportunity at a lot of success. Something I think we need more of. It also creates the need for a vast support network.

No matter where you look in a big city there will be peolpe working to keep it running. Cleaning, repairing, constructing and supporting. These jobs multiple with population. If every hosue needs lights and air conditioning, there's a lot of opportunity when you put 3000 people in every square kilometer.

The final thing that struck me is how abruptly the city flipped to greenery. Catch a train in any direction for half an hour and high rises are replaced with mountains and trees. There are plenty of people living outside the city as well but high population density needn't be at the expense of greenery.

I will say this all hinges on doing things well. I've been to other large cities where things aren't as smooth. The low crime rates in Tokyo don't just happen. The city planning and city management to make it run this way are huge factors alongside density and I give those credit.

What I felt though was the potential that comes from brining a lot of humans together. Maybe that can exist in other ways, it probably does a little online but it was powerful feeling it first hand.

I am not setting my sights on moving to Tokyo but this has made me viscerally reflect on how much good can come from building denser, taller cities and bringing people together.

This isn’t limited to lies on the internet. There are plenty of examples in which we assume we’re the exception. Most of us, when asked, will report to be above average at driving, better looking and most and smarter than most of our peers. All of this despite the fact that statistically, that’s impossible.

In much the same way, when we see something obviously wrong on the internet we’re enticed to act. If we don’t say something, how would anyone know this is wrong. If we leave it alone it might spread, it might become a “well known fact” that’s built on a lie.

We become tempted to be the hero but in the end, we’re taking the bait. The sign of a good troll is to be compelling enough to engage without being down right insane. Toe the line of truth just enough that we move to correct the narrative. We rise up swinging the sword of “um, actually” with the hope that we’ll correct our way to victory.

Ideas like these become self reinforcing. Adding our comments helps to show just how lucky it was that we were there. Instead we need faith in each other. An understanding that we’re not above the average, and that’s okay. If we’re nothing special and we can see behind the curtain, others can too. Trust that we’re not all fools. A trust that extends beyond bandwagons on the internet.

If we can shift to a default of “this is BS and everyone can see it” we start to set different defaults. Defaults are a strangely powerful thing. They set us up for a lot of our downstream behaviour. When the default is trust and a sense that its us against the same forces we build community. We look to others and give the subtle head nod of “look at these fools trying to pass this off as true”. We lose the temptation to engage. There’s no need to correct the lie, it’s an obvious lie. We can shift our focus from engaging in pointless town squares and start focusing on real problems. Working together to make things better.

I think it's important that we come up with some simple criteria that a model needs to meet to be considered 'foundational'. As a developer, these are going to be developer centric and have a strong bias towards open source. Here's what I'm thinking:

1. Foundation models are pre-trained
2. Foundation models are general in nature
3. Foundation models are open source

Foundation models are pre-trained

There are hundreds of new papers each week showing off new model architectures. Chances are that some of them are great but reproducibility in AI is still a big problem. If you want to call your model foundational it needs to be pre-trained and ship as a ready to run model.

That doesn't mean it needs to smash all benchmarks without fine-tuning but just proposing a model architecture is not providing a full foundation.

Foundation models are general in nature

Foundation models are, in most cases, there to be a useful starting point for a number of applications. In many cases that will require fine tuning, or in some simple cases prompt wrangling.

ChatGPT and Midjourney are great because of their breadth. The applications and models built on top of them will likely be more specific and tuned to a single use case. This, to me, is the ideal scenario.

Foundation models are open source

Probably the most contentious of the three here. If you have an API as the only interface to your model, it's not a foundation model. It might still be a wonderful model (ChatGPT as an example) but it's not a foundation.

Open source here means open code, available weights and ideally access to the original training data. I'd settle for the first two in a pinch but ideally it hits all three.

If we look at Stable Diffusion it hits at least the first two. Knowing if you can access all the training data is harder to verify but a good portion of that is open as well.

Once stable diffusion was released there was a flurry of activity on top of it. People built GUIs, tweaked the setup and fine tuned it to develop many new models. Similar activity happened when OpenAI released Whisper.

That kind of rapid creation and collaboration is what makes a model foundational.

ChatGPT and GPT4 on the other hand are API access only (at least at the time of writing). There will likely be many great products built on top of those APIs but they're not foundation models while they are locked away.

Similarly, Stable Diffusion is available as an API. That doesn't stop it being considered a foundation model. I am all for wrapping these models in managed services but the foundation of AI should be open.

I am currently looking to move house and in preparation I've been trying to read books that have been on my shelf too long. These are books I have been meaning to get to for years. Often gifts or books I thought were interesting last time I browsed a book store.

The Frontiers of Knowledge by A. C. Grayling was one of those books. I took advantage of a timely Audible credit and picked up the audiobook version, leaving the physical copy as something to pass on to someone else.

The Frontiers of Knowledge explores how humans have compounded our understanding of the world. From our early beginnings as early sapiens through to modern discoveries in quantum mechanics. Split into three sections, the book explores the history of progress in science, psychology and historical inquiry. In doing so, Grayling presents some commonalities and consistent stumbling blocks on our quest to further enlightenment.

Each section aims to begin as early in the development of that field as is useful. For science, this begins at the development of early tools. For historical inquiry, the earliest records of human kind. Through each topic we take an entertaining and broad path through discoveries and missteps on the path to our current understanding.

This high level review keeps the book moving at a comfortable pace. An expert in any of the topics covered will find their field described only at a high level. While this may be frustrating for the expert, the intended general audience for the book will likely appreciate the accessibility of the topics covered.

I listened to this book primarily whilst out walking the dog. It made for an entertaining walk and I picked up a few interesting historical tidbits along the way (did you know they used to flood the Colosseum for nautical combat displays).

When thinking about where the physical copy of this book will end up (assuming it doesn't end up in a general donation box) I'll be looking to pass it onto someone with a broad interest in science and humanities. Overall this was a good read and I'd recommend it to anyone looking for a quick and broad description of human progress and how far we have come.

It all started when a Google employee made a call that LaMDA was sentient. LaMDA is an AI that creates chatbots. After several conversations, the employee felt the model had the same intelligence as a seven or eight-year-old child.

Look, honestly, it's a dubious claim. But there are some fascinating aspects to this. Before I get into them, here's the (curated) transcript between the AI and two Google employees.

https://cajundiscordian.medium.com/is-lamda-sentient-an-interview-ea64d916d917

First, the chat log is curated, edited and very selective. A red flag on its own. Secondly, we need to remember this is an AI trained to answer questions. Trained on millions of questions across the internet, this AI knows how to replicate answers.

The bigger question here, is what does it even mean for an AI to be sentient, conscious, or anything other than a pattern matcher and regurgitator? If we really want to get answers on this, we need better definitions. Most people I know that know more than a tutorial's worth of AI think that while clever, this AI is far from conscious.

On the back of this claim, there have been a series of rebuttals. They range from technical deep dives into more broad-brush claims that this is nothing more than human folly.

Nonsense on Stilts

No, LaMDA is not sentient. Not even slightly.

The Road to AI We Can TrustGary Marcus

Ironically, on the same day I came across a post on just how limited another AI from Google is:

Google’s AI Doesn’t Understand Restaurant Menus

In the glorious future, every website will be chock-full of semantic metadata. Restaurants won’t have a 50MB PDF explaining the chef’s vision for organic cuisine – instead, they&#…

Terence Eden’s Blogedent

One thing that fascinated me throughout all this was how quickly people switched to thinking LaMDA was in fact sentient. Comments on the transcript are full of people worried about the well-being of the AI and the risks of turning it off.

What this signals is the need for rules and tests on these topics. Convincing humans of sentience and true sentience are shaping up to be two very different things. Without a set of criteria (knowing full well they may change) we can't do anything other than arguing over semantics. It seems we might be closer than I predicted to mourning for AI.

Will we mourn for Siri?

I remember the first time I said “thank you” to Siri. I wasn’t paying attentionand had asked for a timer to be set. Nothing particularly difficult, but withoutmuch thought, out slipped “thank you”. To be clear, I don’t think Siri is doingwhat I ask out of politeness

Elliot C SmithElliot Smith

Much like DALLE-2 and its secret language, what's going on here is likely just good pattern matching. These AI are trained to mimic real-world behaviour, we should expect them to eventually get good enough to fool us.

There is, however, an alternative. As hard to believe as it may be. It could be that these AI are in fact sentient. Not as young children, but as squirrels.

From Me

Tom and I have been putting out our podcast. Our most recent episode was our first foray into a live show. Check it out here: