I'm a full-stack web developer, and this is my blog. Please connect with me on LinkedIn or visit my Github for more! Also, you may be interested in learning more about me.

---

Projects

• Don't Sync State, Derive It! (With Apologies to Kent C. Dodds)

  Jun 9, 2025 • things-i-learned

  Syncing is for swimming, not for state.

  This is a pretty standard lesson (Kent C. Dodds talks about it a lot in his React courses and on his blog) but it’s still something that has taken me a while to internalize.

  With BookGuessr, I have a bunch of state!

  I have the list of all books that could possibly be part of the game, the list of books that is part of the current game, the score, the high score, the game’s status (started or ended), and probably some other stuff. This is a lot to keep track of, and despite knowing what I know, my first draft of the app looked like this:

  const [allBooks,setAllBooks]= useState(initialListOfBooks);
  const [chosenBooks,setChosenBooks] = useState([]);
  const [score, setScore] = useState(0);
  const [gameIsActive,setGameIsActive] = useState(false);
  ...
  

  and so on. Easy to write, not so easy to track.

  Now, if a player chooses a book, we need to:

  • remove that book from the list of available books
  • add that book to the list of chosen books
  • check if the score needs to increase, and increase it if so
  • check if the game needs to end, and end it if so

  That’s four separate state variables we need to manage! But we really only need to manage one state, if we turn our allBooks variable into something like this:

  [{'title': 'The Grapes of Wrath','author':'John Steinbeck','year':1939,'correct':true},{'title': 'Middlemarch','author':'George Eliot','year':1871},{'title': 'Snow Crash','author':'Neal Stephenson','year':1992,'correct':false}...]
  

  There are probably lots of ways to slice this, but this is the structure I have decided on (for now). Now, score is calculated by performing allBooks.filter(book=>book.correct).length, chosenBooks are calculated by filtering on the same condition and sorting by year, gameIsActive can be calculated by finding if any item in the array has the incorrect key, and so on.

  This turns the above code into something more like:

  const [allBooksForGame, setAllBooksForGame] = useState(allBooksWithDates());
  
  const currentBook = chooseNextBook(allBooksForGame);
  
  const score = calculateScore(allBooksForGame);
  
  const highScore = calculateHighScore(score);
  

  This is pretty clean (the implementations of the helper functions I’ll leave up to the reader), but more importantly, when allBooksForGame changes, everything else updates without the programmer having to do anything.

• The Making of (and Redesigning of) BookGuessr

  Jun 7, 2025 • things-i-learned

  A couple of years ago, I got into my head the idea that I wanted to make a Wikitrivia style game with novels. I love to read, there’s a lot of publicly available data about books out there, why not? I made the first prototype in a weekend, using a list of 1000 Novels You Must Read from The Guardian, and data from The Open Library, and it worked, but.

  I didn’t really want to show it to anyone because I really didn’t like how it looked, or behaved, and don’t even get me started on how it worked (read: didn’t work) on mobile.

  Recently, I got a bee in my bonnet about redesigning it. I’d take another weekend and just spiff up the CSS and be done.

  Lies, all lies.

  First I spiffed up the CSS. I’m not at all a designer, so this was harder than it sounds. But I used a few tips from Erik Kennedy and I think I made it better.

  Before

  After

  Then, because the mechanic of hovering over where you want to place a book is not just mobile-unfriendly but mobile-impossible, I remade the entire site using a drag-and-drop library. I chose React-DND-kit pretty much at random, and once I figured out its quirks, I can say I’m pretty happy with it, but there may be a future blog post forthcoming about all said quirks.

  Then, because I was running into some annoying React off-by-one bugs related to state being set when I didn’t expect it, I ripped out all the game logic and redid that. (Future blog post coming: Don’t store state, derive it!)

  This wasn’t a ton of coding work, but you know how side projects can drag on. So I’m happy to say, six months after thinking I’d just “take a weekend” to do a little cleanup, Bookguessr is finally ready for the world.

  Until I get the itch to redesign it again. Which might be tomorrow.

• I'm on a Podcast

  May 1, 2025 • presentations

  Last month I had the honor to appear on the “Her Corporate Compass” to talk about my approach to asking questions. (previously, and previously).

  You can listen to it here:

  If Spotify isn’t your thing, it’s also on Apple Podcasts here.

  I will be completely transparent: I’m still a little scared of the sound of my own voice, so I have not listened to this entire episode yet. However, I have listened to Elhannah’s previous episodes and so I know that she did a great job, and any problems or issues are on me, not her. :)

  Thank you so much Elhannah for having me!

• Secrets of the Git Commit Hash

  Apr 28, 2025 • things-i-learned

  

  I attended an online presentation recently about very specific ways git can get messed up. To be clear, git can get messed up in many ways, but this fascinating presentation, by Mike Street, was about just some of the ways we run into problems with git.

  Have you ever gotten this message:

  Updates were rejected because the tip of your current branch is behind its remote counterpart.
  If you want to integrate the remote changes, use 'git pull' before pushing again.
  

  This USUALLY means exactly what it sounds like (assuming that this message sounds like anything to you): The branch you were working on has changed on the remote, and before you push your changes to the remote, you should pull the new changes to your computer and integrate them, otherwise you might break something.

  But how does git know that something has changed at the remote? Git does this by comparing commit hashes, the 40-character strings that uniquely identify a specific commit.

  As I think I understand it, your git talks to the remote git and says, essentially, hey, I’ve got develop here, and before I made my changes, it had the hash abc123.

  

  And remote git (on github or elsewhere) says, “Cool, yeah, develop was at abc123 last time you pushed, so let’s go ahead and add your changes def456.”

  

  But let’s say your coworker updated develop while you were working.

  

  Now develop points to a different commit hash (now called new-work), and you get the above error.

  However!

  This comparison can only occur because git is comparing commit hashes. The hash is made up of a bunch of information, and here I quote Mike Street’s presentation directly:

  • the parent commit hash (or hashes, in the case of a merge)
  • the commit message
  • the commiter name and date of commit
  • the author name and date of authorship (these can be different than the above)
  • the file changes
  • magic

  (On a side note, if I understand this Stack Overflow answer correctly, creating this hash involves using the SHA-1 algorithm (at least) three times: the parent hash(es), the hash of each file that has changed, and the result of hashing the return of git cat-file, which is what contains the ‘metadata’ about the commit. And then it’s all mushed together, I presume.)

  The upshot of all of this means that two commits that are functionally the same: same files changed, same changes within those files, etc., can still look different to git, because the hashes change whenever the metadata does. So the ‘updates were rejected’ error can occur even when there are no true updates.

  And this is why if you do:

  git commit -m "do something"
  git push
  git commit --amend
  #change the commit message
  git push
  

  you will get the original error message:

  Updates were rejected because the tip of your current branch is behind its remote counterpart.
  If you want to integrate the remote changes, use 'git pull' before pushing again.
  

  The two commits are the same but git doesn’t know that!

  At this point, if you are sure you are the only person working on this branch, you could do a git push --force to resolve the issue. But it’s better to avoid this problem in the first place, by not amending commits that have already been pushed to the remote.

  We will see similar issues when rebasing (because the parent commit hash, as well as the commit date, could change).

  The short version of this insight is: the commit hash updates every time the commit, including the metadata, changes.

  Now you know!

  This presentation did not fundamentally change the way I use git: the way to avoid this problem was, and remains, “do not amend commits that have already been pushed to the remote.” But it did help me understand why this is the case. Thanks, Mike!

  Resources

  The presentation was part of Code and Coffee: A Virtual Coffee Conference. I believe that the individual talk will be posted shortly, but for now it is available as part of the livestream recording here, starting at about the 9 minute mark.

• The Joy of Leetcode

  Apr 13, 2025 • musings

  “This is what happens if you do very well on coding puzzles,” an acquaintance texted me last year during Advent of Code. I honestly assumed the link included in the text was gonna go to some meme of a skeleton dead in front of their computer.

  

  But nah, he wanted to link me to a Youtube video touting some Leetcode genius who had solved more than 3,000 problems on the site and landed a job at Google. And of course, getting a new job is why most people do Leetcode. As long as technical screens exist (which might not be that much longer, thanks ChatGPT), there will be people trying to prep for them on leetcode and leetcode-like sites.

  That said, I have been doing a little leetcode here and there, despite not being on the job market. That sounds a little crazy to say out loud. Why would anyone want to put themselves through this torture?

  Women and Gender eXpansive Coders DC has a monthly “Craft n’ Crush Your Coding Interview” event where a few folks get together and solve these toy problems in a supportive environment.

  The organizer, Melissa, structures the events so that everyone has 15 minutes to solve the same problem, then we spend 15 minutes discussing our approaches and solutions, and then take a 15-minute crafting/chat break. It’s a really supportive environment. And there’s yarn.

  Honestly, for some people the promise of crafts might be enough to get them to come. I’ve really been looking forward to the coding parts, though.

  • The fundamental problems and data structures in a Leetcode easy (the organizer mostly chooses easies) are often things I know about but don’t necessarily work with on a day-to-day basis. Can’t remember the last time I worked with a linked list outside of a Leetcode problem, but it’s probably a good thing to remember that such a structure exists.

  • Since everyone coming to this meetup has different skills and backgrounds, there are as many different solutions as there are people. I’ve often felt pretty proud of a solution of mine until another person comes along with an even better optimization. These are fantastic learning opportunities! Also, everyone uses their language of choice so I often get to go “Oh, Ruby can do that?”

  • I’m also not ashamed to admit I’m a tad bit competitive, so this meetup scratches that itch for me.

  • Plus, I’m making progress on a very cool cowl.

  If you’re a woman in tech in the DMV, I hope you’ll check out WGXC DC’s Craft-n-Crush series. And if you’re not in the area, perhaps you would be inspired to start your own Craft n Crush in your region?