Huh, I guess I still have a blog!
How many of you folks out there are going to Kubecon EU 2020 in Amsterdam? Well, Team Tilt will be there with bells on! …But I myself, unfortunately, will not. Which is a particular shame, because I studied in Amsterdam for a semester in undergrad, and would love to go back! In lieu of that, I’ve written up a bunch of stuff I’d do if I went, and that I want my coworkers to do in my stead. Thought I’d post it here for the whole internet to see—if you want to have some fun in Amsterdam on my behalf, then please please do so! (And if anyone wants to bring me back some cheese or hagelslag, well, I wouldn’t complain 😋 ).
To all of y’all going to Kubecon (or just touristing around Amsterdam): veilige reizen, en veel plezier!
Canal houses in the sun (Maia McCormick, 2013)
(Cross-posted from Windmill’s blog.)
At the end of April, Windmill (all five of us) trekked down to GothamGo to learn things, meet people, and pitch our product. As Silver Level sponsors, we had our very own little table on the first floor; it was the perfect chance to pitch our fledgling product, make connections, and figure out what developers might want from us. The only question was: how?
We’re a brand-new team, and GothamGo was a great excuse to do some important work. In preparation for the conference, we talked, we brainstormed, we aligned on our values and objectives and product goals; and then took the results of those conversations and ran with them, building our booth and our pitch from the bottom up.
The first order of business was: what was our booth going to look like? We asked this question of the team, and immediately realized that we first had to tackle our zeroth order of business: what were our objectives for the conference? In other words, what did we as a company hope to get out of GothamGo? Our answers would shape how we interacted with attendees, and how we decked out our booth to encourage those interactions.
Life update time! After three great years at Spring, I’m moving on to my next adventure; in April, I’ll be joining Windmill as their fifth engineer, where I’ll be building cloud-based developer tools, as well as company culture.
The most frequent question I’ve got from people upon telling them this news (after “what the heck is Windmill?!”) is, “How did you prepare for your interviews?” (And all the related questions: “How long did you prep for?”, “What were your on-sites like?”, etc.)
This post aims to answer those questions. Here’s some detail on my own personal interview prep and interview process. Of course, everything here should be taken with a grain of salt, as all of this will vary widely based on you and your skills, the sorts of companies you’re interviewing for, etc.
If you’ve been in Python-land for long, you’ve probably seen some @-sign thingies hovering (often mysteriously) above functions and class definitions, saying things like @patch or @classmethod or perhaps something even more obscure. Maybe you already know that these are called “decorators”. Maybe you’ve even used them, or written your own!
Even if you’ve done all that and still don’t quiiiite get what’s going on under the hood with decorators… don’t worry, my friend, you are not alone. Heck, I’m still not quite sure what goes on under the hood with decorators, but after a very productive afternoon of fiddling, I have a much better idea, and I’m here to share the fruits of that fiddling with you. Ready? Here we go:
Decorators are callables called on callables that return a callable which then replaces the original callable.
Got it?
…No?
…Yeah, okay, that’s fair. Let me try that again.
This is a blog post about interfaces in Go. I wanted to write about a headscratcher that cost me several hours of work when I first started learning Go, and I figured I might as well start from the beginning and write the article on interfaces that I wish I had read back then. The story of my encounter with nil interfaces is coming soon, but for now, here’s a brief and hopefully accessible piece on interfaces in Go.1 So, without further ado, I give you…
Coming from the dynamically-typed wild west of Python, one of the bits of Go that took the most getting used to was the idea of interfaces. An interface is a way of typing things according to their methods. If I want a function that can take any number of different types, so long as they have a given method (or two, or five) in common, I’ll want to use an interface to accomplish this (since I can’t pass in any old thing because of Go’s type safety rules). To give a concrete example, say I’ve got these classes:
Raise your hand if you’ve ever git commit’d something you shouldn’t have. (It’s okay, this is a judgement-free space.)
And raise your hand if you’ve ever used git commit --amend --no-edit1 to try and hide your terrible, terrible shame. (We’re not even gonna talk about git push -f origin master. Don’t do it, kids.)
And raise your hand one last time if you’ve ever git commit --amend --no-edit’d and then paused and looked at your computer and were suddenly struck by the realization that you’d ruined everything.
That last one might be just me, but I’m going to pretend it happens to other people to make myself feel better. (Like all of those times I thought I was fixing a slightly incorrect commit, only to realize I had instead wiped out all of my latest work. Whoooops.)
I came out of school with a BA in music, tripped and fell, and landed in the tech world. The folks at Spring took a chance on me as an extremely junior developer and offered me a job. I’ve been here now for a little more than two months, and I couldn’t be happier. Going into my first day at Spring (which also happened to be my first day as a software engineer, full stop), I was understandably pretty nervous. But I was also excited for what lay ahead, and Spring has done a fabulous job of easing me into my new life here. Here are some reflections on that first month (posted, er, somewhat belatedly), to give you an idea of what it’s like to be a new junior engineer at Spring.
Truthiness in Python is occasionally confusing. Obviously, False is false and True is true, but beyond that, what then?
None is always false–though this doesn’t mean that False == None, which is a mistake I made early in my Python career. I was confused by how a nonexistant list and an empty list were both falsey, and somewhere in my mind I thought that they were both None as well. Not so much.
Three months later, I’m done with my OPW internship with GNOME Music.
I’ve learned that open-source contributing isn’t as scary and impossible as it once seemed, and that IRC is full of nice people who are happy to help! But I’ve also learned that diving into a new codebase is challenging, at best, and nearly impossible at worst. pdb, for x in dir(foo): print(x), traceback.print_stack(), and inspect.getargspec(myfunc) have become good friends of mine in the past three months. Good documentation, it turns out, is essential—the project I was working on had very little, and the libraries it utilized (at least, the Python wrappers for those libraries) were similarly sketchily documented, and all this made learning the code waaaaay tougher than it needed to be.
