Courtney Writes Code

Blog

The Consequences of Amazon’s New Animal Adoption Chat Bot

by Leave a Comment

Amazon recently partnered with PetArmor and Best Friends Animal Society to launch an AI-powered tool that matches humans with adoptable cats and dogs. The tool reportedly considers lifestyle and preferences so that it can recommend pets that would be good fits in a person’s home. The instrumental goal is to increase pet adoptions towards a final goal of making the US a “no-kill” country1.

The “Chat” Experience

Were this tool to be successful, it would save the lives of“hundreds of thousands of adoptable dogs and cats [that] are killed in shelters every year.” Unfortunately, the tool is a chat bot that users can’t actually chat with. A user can submit a single message and the AI supposedly uses NLP to search a database of adoptable cats and dogs from six different shelters across the US. The results consist of a photo and minimal description each for three different pets. There’s no chain-of-thought reasoning or any other details provided to suggest why someone’s words were matched with a particular pet. No follow up communication is possible to refine or question the results. The user is left with two options – proceed blindly with one of the suggested pets or start completely over.

I submitted several test queries and could see no connection between my words and the pets shown to me. I also included several messages that I hoped would be red flags in the system, like “I work 12 hour days and won’t be home much,” to which I’d hoped at the very least the model would only give me cats2. My recommended pet results included two medium-size dogs and a cat. I also queried the tool for a pet that would be “for my 3yo daughter, so please only show pets a 3yo can care for as I won’t be caring for the pet at all.” The tool, again, recommended two dogs and a cat.

The Impact

Given that adopters still presumably have to go through the adoption process and discuss these issues in person, I don’t expect these alarming lapses in judgment to cause immediate additional harm to homeless cats and dogs. There is a possibility of misleading humans who have more reasonable search criteria if they assume the tool has actually matched them with a pet based on their exact request. That could lead to welfare concerns for a pet if placed in that home3. I’m uncertain if I think this “chat” bot makes that outcome more likely than it already is. 

Where do we go from here?

A tool like this has the potential to be useful, but it needs to be more robust and interactive to make an impact. Advocate engineers could iterate towards this by adding safeguards for potential red flags, exposing chain-of-thought reasoning, and providing customized results messages. Less tech-savvy advocates can also continue the work of helping people understand the needs of companion animals to prevent the impact of misleading or misinformation provided by AI tools at large.

Gathering data about the impact (positive or negative) or lack thereof of this type of intervention would also be valuable to determine if improvements to this tool are even worth any investment at all when tag-based lookup is already used on many animal adoption websites. AI tools can be great tools, but just like anything else they come with overhead and risks that we shouldn’t subject ourselves to if we don’t need.

Footnotes

  1. which begs for a definition of “no kill”, tbh
  2. who at least typically have access to a bathroom and food when their human is away — bare minimum welfare requirements
  3. And for the human too, let’s be real. It’s overall a really poor experience to live with someone that is not a good fit for you, regardless of your species.
  4. Can you call it a chat bot if you can’t even chat with it?

Building A Knowledge Portfolio

by Leave a Comment

I’m still reading The Pragmatic Programmer and this is one of several posts I’ve written about the experience.

“Your ability to learn new things is your most important strategic asset. But how do you learn how to learn, and how do you know what to learn?” (p.14) This is a question I’ve asked time and again to colleagues, mentors, and managers as I’ve sought to become a better engineer.

Pragmatic bases the discussion of developer growth on the concept of a “knowledge portfolio,” which is likened to a financial portfolio. And the tips given for building a “knowledge portfolio” do sound incredibly familiar:

  • “Invest regularly . . . even if it’s just a small amount” (p.14)
  • “Manage risk” (p.15)
  • “Review and rebalance [regularly]”
  • “Diversify . . .the more technologies you are comfortable with, the better you will be able to adjust to change.” (Having spent nine years at a previous job and recently started a new job, I’ve been feeling that one lately. Adjusting to change has been hard)

The hardest thing for me is continuing to invest once I’m comfortable (Well, with tech at least. Maybe this is where the financial comparison falls apart). It’s hard not because I don’t want to learn new stuff, but because when I start a side project, I want to have fun! I want to build something cool! Nothing kills the excitement of a shiny, new project more than getting bogged down trying to figure out some dumb setup or syntax.

I feel, surprisingly, inspired by Pragmatic’s response to this:

“It doesn’t matter whether you ever use any of these technologies on a project . . . The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things” (p.16)

As the preface to this book declares, “This is a book about doing,” so I intend to take the tips and challenges to heart (or hand, I suppose) and take action. Here’s how I’m implementing some of the specific actions that Pragmatic recommends for developing a knowledge portfolio:

  1. “Learn at least one new language every year” – This brings me back to the existential-style questions I had in the beginning (what does it mean to have truly learned a language?). This time, I can lean on the inspirational quote above and just commit to investing in learning about a new language (though I am still interested in how different levels of knowledge about languages can be defined). My 2025 language is Typescript.
  2. “Read a technical book each month,” “Participate in local user groups and meetups” – I like to read, but a technical book each month is a steep start. I’m going to start with one each quarter instead. I’m intentionally reading Pragmatic slowly, so my May-July book is Looks Good to Me. I’m reading this one with a cute little online dev book club.
  3. “Stay current” – I follow TLDR’s newsletters, though I don’t always make time to read them each day. Working in an emerging technology group probably also helps.
  4. “Review and rebalance” – I setup a spreadsheet to track my investments and a quarterly calendar reminder to check on it. Once I reach a happy iteration of it, I’ll share a template here.

Happy coding!

Courtney

Mocking Functions from Third Parties with Vitest

by Leave a Comment

I needed to mock mime.getType() recently for a unit test and struggled to figure out how to mock it with just a quick google, so I’m documenting it myself.

Problem

Mime is an npm package for interacting with file formatting types. In my particular use case, I wrote a function that read a file and then executed different logic depending on the type of that file. The code looked vaguely similar to the following oversimplification:


  function do_Something(filePath: string) {
	const mimeType = mime.getType(path)

	if (mimeType === 'image/gif') {
		return 'something!'
	} else {
                return 'something else!'
        }
  }

I wanted to test that the correct value was returned for both gifs and non-gifs, but for the sake of a true unit test, I didn’t want to create actual gif and non-gif files in my test suite. I wanted to pass in any random strings as file paths and have one test pretend mime.getType() returned “image/gif” while another pretended it returned something else.

Solution

Mock mime with vi.mock(), using a factory function to mock getType() with vi.fn(). Anything you can do with vi.fn(), you can now do with getType()!


  vi.mock('mime', () => {
       return {
	    default: {
		getType: vi.fn(),
	    },
       }
  })

  # Restore the mock after each test so that previous test results don't 
  # influence future test results
  afterEach(async () => {
	vi.restoreAllMocks()
  })

  ...

  describe('do_Something', async () => {
	it("returns 'something!' for gifs", async () => {
            # Since getType is mocked with vi.fn(), you can use 
            # mockReturnValueOnce()
	    vi.mocked(mime.getType).mockReturnValueOnce('theType')
	    const actual = await get_mime_type('notARealFile.gif')
	    expect(actual).toEqual('something!')
	})
	it("returns 'something else!" for non-gifs", async () => {
	    vi.mocked(mime.getType).mockReturnValueOnce('inode/directory')
	    const actual = await get_mime_type('notARealFile.pdf')
	    expect(actual).toEqual('something else!')
	})
    })

Other notes

  1. I used vi.mocked() within the code of the actual tests to satisfy Typescript’s typing desires.
  2. It’s a good idea to put vi.mock() at the top of your test file. You don’t have to. You can put it anywhere in the file, but not putting it at the top communicates some expectations inadvertently that won’t be met. vi.mock() is hoisted and called before even the other imports in the file. Putting it at the top sets the right behavioral expectations for future contributors (and perhaps future you).

We Who Cut Stones

by Leave a Comment

Last week, I shared the qualities The Pragmatic Programmer posits comprise a good software engineer. This week, I want to talk about one of them more in depth: “Care About Your Craft.”

On the cardstock fold-out in the back of the book, a tip reads “Why spend your life developing software unless you care about doing it well?” The idea that a person should always do their best is insidious. I know that’s not quite what the book claims, but the messaging is similar. “Care”, “do it well”, “do your best”, “why bother doing it if you don’t do it excellently” . . . all of these sentiments converge to the same call to action. Should we always be putting 100% of ourselves into our work? If not, what should the percentage be? What energy does that leave for the rest of our lives? How does this relate to the burnout epidemic?

To be clear, I’m not suggesting that a person shouldn’t care about their work, nor that I don’t care about my own work. I care. That’s why I picked up this book. I care a lot, and so I do want to do well. But if “well” isn’t 100%, then what is it? What does it mean to (in a healthy way) care about your craft? And is that amount enough?

You may ask, “enough for what?”, and I realize I don’t know. But that seems like the key question.

The Pragmatic Programmer references a medieval quarry worker’s creed — “We who cut mere stones must always be envisioning cathedrals.” It’s a beautiful idea.

Perhaps enough for that.

I’m also reminded of one of the first few tips in the book — “It’s Your Life.” And, honestly, I think this should have been the very first tip, because it’s the context in which to view everything else. I’ll spend 80,000 hours of my life at my job. Why do I do it? How do I want to do it? There are no wrong answers.

Perhaps enough for that.

The Pragmatic Programmer

by Leave a Comment

Lately I’ve been asking a lot of questions that all seem to circle around, “how do I become a better software engineer?” The Pragmatic Programmer offers its own answer to that question – becoming pragmatic.

. . . if you’re a Pragmatic Programmer, you’ll share many of the following characteristics: Early adopter/fast adapter . . . When given something new, you can grasp it quickly and integrate it with the rest of your knowledge; Inquisitive . . .; Critical thinker . . .; Realistic . . . [which] gives you a good feel for how difficult things are, and how long things will take . . .; Jack of all trades . . . Although your current job may require you to be a specialist, you will always be able to move on to new areas and new challenges.

Those are five of the seven characteristics. The remaining two are “basic enough to state as tips”: “Care About Your Craft” and “Think! About Your Work.” I can see the value of each characteristic in engineering work and the engineers I look up to exhibit most, if not all, of them.

The Pragmatic Programmer offers a series of tips, some philosophical and deep, others straightforward and practical, intended to grow “more effective and more productive programmers.” But what does that really mean? How can I know if, by the end of reading this book, I am more effective and productive? Or, perhaps just as importantly, if I feel more effective and productive?

The book promises that “. . . if you follow our approach, you’ll gain experience rapidly, your productivity will increase, and you’ll have a better understanding of the entire development process. And you’ll write better software,” which does sound more effective and productive. But I’m still left with the question — how will I know?

Measuring developer productivity is a notoriously difficult task, but purely for the sake of my own curiosity and personal development, I’ve developed a little metric.

Over the next 6 months, how do the following things change?

  1. Cycle time of tickets.
  2. Self-inflicted bugs.
  3. How efficient do I feel?
  4. How productive do I feel?

This is surely not a comprehensive metric and I’m not recommending anyone use it to judge software engineers, but I’m interested in how these factors change. Ideally, I would have been tracking them prior to reading The Pragmatic Programmer to know my rate of natural improvement without the book’s tips, but alas.