Courtney Sims

courtneysims

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.

Animals Playing Music

by 4 Comments

Earlier this summer, I participated in a hackathon. It was an un-themed, free-for-all hackathon (my favorite kind), so, naturally, I asked myself — what if we could use technology to help animals play music?

Credit to emperor_slime

Observation

I live with a herding breed dog. If you know anything about these kinds of dogs, you know they’re always staring at their people, waiting for something to do. They’re very smart and very active. If you too have lived with a herding breed dog, you know how easily they get bored and how much they rely on you to fix this for them. You also have probably developed some empathy for this situation and feel a little guilty when you do activities that don’t include them. Or maybe that’s just me, but that’s where this whole thing started.

I like to play music, but often when I sit down to play, my dog stares at me with her sweet puppy dog eyes and, instead of feeling happy about playing music, I feel sad that she can’t play too.

Question

What if it didn’t have to be like this? What if Penny (or Luna, the cat!) could join the band?

Hypothesis

  1. If I arrange a way for Penny and Luna to step on something that produces musical sound, they will choose to do this for a reward.
  2. The stepping can be done in a way that complements music being played by others.

Attempt #1

What happens when I try to convince them to play an instrument without technology? Maybe we don’t need tech after all. Let’s find out . . .

Materials

  • Piano
  • Tiny scoop of cat food
  • Cat toy

Methodology & Results

Luna

  1. Attempt to lure Luna onto the piano with a scoop of food. -> No response.
  2. Attempt to lure Luna onto the piano bench with a toy. -> No response. Absolutely no interest in approaching the piano for any reason.

Penny

  1. Leverage previous trick experience to get Penny to put her paws on the piano bench. -> Success!
  2. Leverage “shake” cue to get Penny to put her paw on the piano keys. -> Somewhat successful . . . but the sound was not very pleasant and she looked physically uncomfortable in that position . . . and tbh I was concerned she would hurt the piano.

Attempt #2

What if we use a little bit of physics instead of tech? How much better is that?

Materials

  • Small midi keyboard placed on the ground
  • Some random hook that the person who owned my house before me left in the garage
    • Could be anything you can turn into a lever though
  • Box from an Amazon delivery
  • Box cutter

Methodology

  1. Setup a midi keyboard to create a fun sound with the push of adjacent keys.
  2. Cut small pieces of cardboard for stacking.
  3. Create a simple machine (by placing the weird hook on pieces of cardboard) to concentrate the weight of the paw onto those specific keys (and simultaneously protect the keyboard from direct paw->key contact).

Results

Luna

Zero interest. Not good.

Penny

Not bad.

Attempt #3

Okay, let’s think more about the user experience here. What if there was something flat on the ground that could just be walked across to produce sound? Can we create a pressure sensor and somehow connect that to a music producing device?

Materials

Methodology

  1. Follow steps 1-5 of this guide to create a DIY pressure sensor. It is shockingly straightforward.

Optional: to confirm the pressure sensor is working, connect the wires to a battery and lightbulb.

2. Follow this guide to connect the raspberry pi to the pressure pad. Choose the basic setup option with the resistor and, of course, the DIY pressure pad instead of a store-bought sensor. Strip the ends from the wires to insert them into the breadboard, just like when taping them to the aluminum foil previously.

3. The code is super simple. Use the RPi.GPIO library for the breadboard connection and the pygame library for the music. After trying several sound types, I left it on piano, which can be heard in the videos.

Results

Look at them go!!

Conclusion

This was a good MVP. I created a device that produced musical sound and that my users seemed to like.

Looking back at my hypotheses, I validated 1/2 of them. When I arranged a way for Penny and Luna to step on something that produced musical sound, they did in fact choose to do this for a reward.

The next steps for this project would then be validating the second hypothesis, which I sadly did not have time for during this hackathon: Configure the device to complement music being played by others. There are so many options for this! Can the animals play a chord at the right time? Can they play a series of recorded notes on a consistent beat? Could we time the reward dispensation to a pattern that facilitates this? Or maybe the animals could have their own versions of a guitar solo at a particular point in a song?

Some things to work out for this next phase are how to work with more advanced sounds in the code (I couldn’t get my own mp3 files to play, only the samples), how to automatically dispense the rewards, and how to keep the animals nearby and engaged when rewards are not being dispensed.