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

• Building My Blogging Habit, With Toys

  Dec 30, 2024 •

  I would like to be writing more, and most self-help books about productivity say the same thing: If you’d like to encourage a good habit, you need to remove friction. To that end I’m trying out a few portable Bluetooth keyboards, under the idea that if it is easier to type on my phone on the go, I will type more on my phone on the go.

  The Arteck that I borrowed from my husband is just okay. I am typing on it right now, and it wobbles a little on my lap, and makes quite a ruckus as I bang away on the keys. It is also a little on the large side for stowing in a purse, although it’s light as a feather and so would be easy to toss in a larger bag. I have high hopes for the Plugable folding keyboard, which Redditors recommend, and which I grabbed on eBay (but has not yet arrived).

  Either way, one of these should make it easier to at least draft thoughts. I’m sure I’ll publish them from a laptop.

  Now to find out if I have anything to say…

• The Wrong Reason (and the Right One) to Blog

  Dec 21, 2024 •

  I wish I looked this relaxed when I worked on this blog. Photo by Vardan Papikyan on Unsplash

  You should keep a blog.

  Yes, you. You introverted developer.

  A blog helps you learn in public.

  The concept of learning in public is often discussed in tech circles (and rarely, in my experience, outside of tech circles). Popularized by Shawn Wang in 2018, the term basically boils down to: document your learnings.

  Doesn’t matter if you document through a blog, podcast, Twitch stream, newsletter, Github gist, whatever – the recommendation is just to do it where people can see. (So for the rest of this post, when I say ‘blog’, feel free to substitute your content type of choice – although I personally find blogging the easiest type of content to create, especially compared to a podcast or video, I realize that is not true for everyone.)

  Why should you do this? I’ll tell you why you shouldn’t blog, first, then tell you why you should.

  Why you should not blog

  You shouldn’t blog because you think you might become a thought leader. Some folks read Learn in Public and decided that they would build a multi-million dollar brand.

  Start blogging, the logic goes, and people will notice you and start helping you, because it’s rewarding to watch someone grow in public. You build your brand, because you’re ‘out there’, and eventually people will pay you for your thoughts/opinions/expertise, because you now have a public brand and have established yourself as an expert. Then you will suddenly make a million bucks a year. It’s easy. 🙄🙄🙄

  “But I don’t want to become a content creator!” Me neither, buddy.

  “But I don’t care about fame and fortune!” I don’t 100% believe you, but it doesn’t matter, because you’re not keeping a blog to become famous.

  The reality is, 99% of people who start learning in public are not going to grow a brand that does anything. They are not going to quit their day jobs to become full time content creators.

  If you start a blog and this happens to you, please come back and tell me. But for most of us, this is not going to happen. And that’s okay, because that isn’t why you should have a blog. There is a much more important, realistic reason to keep blogging.

  Read on →

• Advent of Code Day 14: That Won't Work

  Dec 14, 2024 •

  

  I guess finding the answer to part 2 manually is not going to work.

  Imagine this GIF goes up to iteration 4999….

• Composing Functions in Python

  Dec 8, 2024 •

  Beethoven did not compose any functions, that I know of.

  I have not done a lot of functional programming, although someone I used to volunteer with was very into it. This weekend, while attempting to solve Advent of Code, I came back across some functional techniques.

  I probably should have solved the day’s puzzle (a variation on the missing operators puzzle) with these tools. (Did I? Reader, I did not - I concatenated a giant string and then eval()ed it. I am a massive hack.) But let’s talk about composing functions, because I think it’ll be useful someday.

  What does it mean to compose a function?

  Composing functions does not have anything to do with writing music. It simply means to create a function that returns another function as its result. (I have also heard this described as a higher-order function.)

  So if you have:

  def square(x):
      return x*x
  
  def add_one(x):
      return x+1
  

  The normal way of invoking both of these functions might be:

  x=2
  x=square(x) #x is now 4
  x=add_one(x) #x is now 5
  

  But using composability, we could:

  def compose(*fns):
      return functools.reduce(lambda func1, func2: lambda x: (func2(func1(x))), fns)
  
  square_and_add_one=compose(square,add_one)
  square_and_add_one(2) #result is 5
  

  If this looks like witchcraft to you, it also did to me at first. Let’s break down what’s going on in compose.

  compose takes one parameter, fns, which is prefixed by the splat operator, which means we unpack each item passed to it into a list. (Similar-ish to ...spread syntax in Javascript). Then we use the reduce function on the list.

  I’m much more familiar with a reducer from math operations. For example, if you have [1,2,3,4,5] and want to know the product of 1*2*3*4*5, you can write:

  nums=[1,2,3,4,5]
  result = functools.reduce(lambda acc, num: num*acc, nums)
  

  Or in other words, for every item in nums, multiply it by the accumulated (reduced) result.

  1*2=2
  2*3=6
  6*4=24
  24*5=120
  

  Our compose reducer does the same thing, but instead of performing a multiply operation, it returns a new function whose function is to call the previous function.

  So if we do square_and_add_one=compose(square,add_one) the result is a function that first squares its input, then adds one to it. It would be the equivalent of: add_one(square(x))

  Cool. Why do we care?

  I initially thought I could solve the Advent of Code puzzle by composing functions. As I said, the puzzle was essentially the following:

  Given the numbers (for example) 81, 40, and 27, what combination of multiplication and addition will create the desired total, in this case 3267?

  With three numbers and only two possible operators, this is easy enough to brute force by hand, but of course the real challenge has 10+ digits in each line. I was hoping that I could get every combination of length n of the two operators (e.g. "+,+,+,+,+,+,+,+,+,+","+,*,+,+,+,+,+,+,+,+", and so on) and toss those into a compose, and see what popped out.

  This did not work for a number of reasons. One, because if you want your composed functions to take more than one parameter, you have to do some fancy work.

  Two, and this is more important, I don’t actually want to do add(multiply(81,40,27)). What I want is add(multiply(add(81,40),27)) and that subtle distinction is actually quite a big difference. I won’t say there isn’t a way to get that result with composing functions, because there is almost certainly a way to do everything, every way, in code. But by that point I’d been hacking away at the problem for a bit and I decided to just make a silly naive solution.

  I also think that unless you’re very careful, composing functions can lead to abstractions that are hard to read and debug, as cool as they look.

  I am not sure I will be making heavy use of this technique in my own work but I’m glad to have messed around with it, if only to recognize this pattern when I see it in the wild.

• Why I'm Not Doing Advent of Code (in Go)

  Dec 1, 2024 •

  

  I want to learn Go.

  • another statically typed language would be good to have under my belt
  • everyone seems to LOVE go
  • I want to see what all the fuss is about and stretch my brain

  Ergo¹, I should do a bunch of coding puzzles this month in go, right?

  That’s what I thought, until I actually started working with go. Perhaps embarrassingly, I didn’t know much about go before that other than the facts listed above: it’s strongly typed, and developers who use it love it, like Crossfit cult levels of love. Obviously I want to know what all that is about.

  After I went through a few tutorials, I decided that I like:

  • My god it’s fast. Go says “you won’t feel like you’re running a compiled language” and that is absolutely true.
  • Go’s error handling feels a lot like the Either control structure in Java that we use a lot at work, so while I don’t have strong opinions on whether that’s the “best” way to do error handling, at least it’s familiar
  • Pointers (jk, I do not like these, but I should probably learn how to use them eventually)

  However, besides those strengths, Go is not the best language for me for Advent of Code, which (in my experience) requires being fast, flexible, and a little bit hacky. This is the canonical way to reverse a string in go:

  func reverse(s string) string {
      chars := []rune(s)
      for i, j := 0, len(chars)-1; i < j; i, j = i+1, j-1 {
          chars[i], chars[j] = chars[j], chars[i]
      }
      return string(chars)
  }
  

  In hindsight, Go’s strengths are not those that serve one person doing silly coding puzzles for a month². As I have now read, Go is fabulous for concurrency, memory management, for working on big codebases with multiple people, and for deploying across multiple computers, none of which I will be doing in December.

  The other factor that worried me is that Advent of Code prioritizes speed. Not that I’m going to be hitting any leaderboards, but I still want to keep up with the daily exercises. I got to worrying that learning a new language while trying to be that fast might start me off learning bad patterns, and I want to learn Go correctly.

  So for Advent of Code this year, it’s back to Python for me, which is great because I can always improve there too. The first day wasn’t so bad so far. And I’ve picked out a Coursera course on Go that I’ll be working through instead.

  1. hee hee :) ↩

  2. or in my case, the first two weeks. ↩