Snippets 2/28/19: Work From Woods
What is this?
At the company that I worked for prior to the one that I currently work for (which is Squarespace, for those that don't follow me on Twitter) we had a weekly check-in called Blurbs. The idea was really cool: you would write down what you did that week, successes, things you were thinking about, etc. Some people even added music they were listening to, movies they saw recently, and other social sorts of things. At the end of the week, you'd get an email with the Blurbs of everyone that you followed (there was a Twitter-like "follow" component to it). It was a really cool way of keeping up to date with what people were doing, and more importantly for me it gave me a ritual for getting thoughts out of my head and reflecting on some of the bigger ideas of the week. I've been missing that a bit lately, so I've decided to revive it in blog form, which is to say I'm going to be writing content that would be a newsletter if I ever gained enough readers to justify writing a newsletter. I'm also planning on writing other stuff in this space, but journaling snippets is a much-missed form of writing therapy, so this blog might be mostly that. Or not, I'm not really sure yet. In any case, here's some of what's been in my head this week.
Also, at some point said previous company was talking about open sourcing Blurbs, and if anyone from there is reading this, you really should! (They've open sourced a lot of other cool things though).
The actual post
What does easy-to-delete Go code look like? I read tef's Write Code That's Easy To Delete article recently, and the question of how some of those patterns, or even the easy-to-delete heuristic, can apply to Go. I'm a sucker for "what is good code" heuristic talks, and I've not been able to find one on this topic so I'll probably flesh it out into a Gophercon submission.
I've been enjoying John Ousterhout's book A Philosophy of Software Design. The focus on "deep" modules (that is, modules that have a simple interface but encapsulate a lot of subtle details of lower level abstractions) has lead me to do some thinking about why I've historically tended to favor multiplicities of small functions. I think this is because I learned a lot of my programming ideas from Ruby. In Ruby, small functions are really beneficial because they're easier to test, and in Ruby test coverage does some of the heavy lifting that type systems do in languages like Go. But to paraphrase something I read on Twitter recently, sometimes small functions are like taking a paragraph, writing each sentence on a different index card, and trying to get a coherent picture from it. I've already learned to love type systems, but I still react to them with some of amount of surprise somewhere in the back of my head ("oh, the compiler will just tell me when I've messed up! Cool"). I think this reflection is really me learning to lean into them. I still love Ruby though. Mmm, syntactic sugar.
I'm at the "visualizing before I go to sleep" stage of talk prep for my upcoming talk at SRECon. This is a fairly common occurrence for me any time I have to speak to more than five people with prepared remarks, and has thus far happened for both professional (giving presentations, running trainings) and social (giving remarks at my wedding) occasions. It's not stress, at least it doesn't feel that way; it's more of a constant refinement of what I want to do before I commit to practicing it out loud. I do get the "butterflies in the stomach" feeling sometimes, but I learned from an excellent video by Bill Prichard (an amazing tuba player, bass player, and human) that what I'm feeling in that instant can be re-framed as excitement. I would link the video if I could ever find it.
I'm working from a rural-ish part of Georgia this week, visiting my family. Changes of scenery are great for writing code sometimes. Being in the woods with decent internet even more so. Screaming, adorable nieces not so much, but they make the trip worth it.
For the past couple of weeks I've been working on a rewrite of a Squarespace internal tool. The original version has served us really well, but it's was written in Python (a language that few people on my team have much experience with, which is a problem considering that we own the tool), and makes assumptions about how our Kubernetes clusters are grouped and configured that don't really hold anymore, so new feature development on it has been a bit slow going. The solution the team came up with was to rewrite the tool in Go (the lingua franca of the team), and focus on extensibility and better error messaging. As part of the extensibility part, the tool is supposed to have a plugin ecosystem. I formulated some abstract designs for what I thought the plugin ecosystem should look like, and then my Team Lead, Brad, made an observation: if we write the plugin API such that the system itself could be implemented in these plugins, it'll simplify a lot of the pains involved in plugin development. Brad often says really insightful things like this, and that's one reason I really enjoy where I work. I've started implementing parts of the tool as plugins, and thus far the simplifications of the mental model have been great. I might end up writing a blog post or talk about this.
It's interesting how much debugging Bluetooth issues on my Pixelbook has been like debugging Real (TM) systems. I was doing roughly the same amount of Googling and terminal hackery to get things to work. In the end it turns out that the issue is probably with the headphones I was trying to pair. The whole ordeal ended with a weird feeling that was simultaneously "yes, this is an awesome thing I wouldn't have been able to do five years ago" and "I just want to listen to Meshuggah without waking up the house, why can this not just work?". I think those are the software engineer and consumer halves of my brain arguing.
A discussion came up about Go monorepos in a meeting I was in. I hold that Go is probably a better language for monorepos than most. I don't have the inclination to elaborate on that, but I'd love to hear some success or failure stories.