I’m continually surprised at how much resistance I can put up to learning a new technology when there’s a comfortable equivalent to fall back on, because once I’m finally forced to engage, and get over the initial inertia, I’m typically able to quickly pick up the new skill.
Today’s example: FastAPI. I went from zero to fully-functional serverless stack in an hour. That wasn’t so bad! I probably shouldn’t have wasted any time with my go-to HTTP framework when I was prototyping, though to be fair, their conceptual similarities made porting painless.
Learning to learn fast is a driver of exponential personal growth.
Need to bulk update the contact information across a set of domain names you own in Route 53? I got you. Need to do it across a whole slew of AWS accounts (or anything across a number of accounts)? No problem.
While it’s not all been fun and games, my career has still given me a number of cool opportunities: spending a summer flying around in the back of a C-130, cobbling together election equipment from off-the-shelf printers and scanners, and traveling over most of the US and a handful of other countries (Australia and Mexico).
But one of the most unique experiences was getting to twice attend the Emmys, first in 2015 and again in 2018 (roughly around this time of year, as my phone has recently reminded me). It was at the latter event that I was able to capture a particularly funny moment.
Just a month before, I’d been shopping for new furniture and, in a moment of levity, snapped a photo of myself between cardboard cutouts of the Property Brothers:
Now, I’m not really a fan of the Property Brothers (or HGTV type shows in general); I couldn’t tell you their names even now. But when they were hanging out just a few tables down at the 2018 after-party, I couldn’t resist asking them to help me recreate the above IRL:
Not exactly the kind of thing you tell a budding computer scientist to expect from their career, but fun nonetheless. I wonder what craziness the future has in store…
For reasons not worth getting into here, I’ve been waxing nostalgic (a phenomenon to which I’m apparentlyrathervulnerable; I mean, seriously). In particular, I took a brief mental stroll down memory lane to think of key leaders who influenced my career trajectory in a positive way. People who took a chance on giving me more responsibility than I’d had previously.
This is far from an exhaustive list, but thank you to the following folks:
Greg, who hired me to my first full-time coding gig despite me not even having yet graduated from my undergraduate computer science program.
Rick, who got me internal funding to implement an idea I had, giving me my first taste of leading a project completely my own.
Cathy, who brought me to San Diego without having seen me in action, only my reputation with a particular set of skills, which her project desperately needed.
Lori, who first promoted me to a management position when my prior boss left the company, and trusted me to scale an engineering organization to meet the company’s big goals.
James, who gave me my first singleton leadership position, and helped me think beyond my team and begin operating at a broad organizational level.
Taj, who twice helped me step up into broader responsibilities, and who first challenged me to consider business implications of technical decisions.
Abby, who recruited me into my current role, and has taught me much about how to be a true partner at the executive level.
In all these cases, the individuals didn’t just give me advice. They made opportunities happen and put me in places that caused growth. That’s what makes a mentor a mentor.
If you’re on the other side of a mentoring relationship now, don’t just pontificate. Open doors. Delegate. Trust. Support. Praise. Endeavor to be on someone else’s list.
Nine years ago today I started this blog with a post that laid out my intentions in creating it. It’s cliché, but true, that a lot has changed in the intervening (near) decade, but for the most part, I think I’ve hewn pretty closely to the original idea, even if my underlying motivations have shifted.
Like many things worth doing, it took some time to find a good rhythm. After two initial posts I went almost 2 years without writing anything. Had a great streak going in 2017, but sputtered out in 2018 and didn’t get going again until early 2020. Since then, though, I’ve been on a roll. Maybe it was turning 40? Maybe it was COVID? Can’t say for sure, but I’ve been happy with my consistency since then (and a growing readership is nice too).
In other wistful, “how time flies!” type subject matter, my youngest kid left for college this past weekend and my oldest starts her junior year with a new location and major. They’re both gonna crush it, I have no doubt.
A common rhythm of my career is to catch-up on emails over the weekend. I’ve been appreciative of scheduled send, so that folks don’t get an email from me during non-working hours and assume they need to respond immediately.
However, this might be a new record: 14 emails queued up to go out first thing Monday.
That total may go up depending on how much progress I make on one additional task, which subsequently depends on what Olympic events are on TV this afternoon.
I get that weekend work isn’t for everyone, but I don’t mind it. It’s quiet. Usually no new tasks come up, so I can meaningfully shorten the queue. And finally, it helps alleviate pressure during the week. I’m much more comfortable signing off for the day come Friday afternoon knowing I can knock out a few lingering tasks before Monday ramps up.
Are you the kind of person who, when you have a bunch of questions you need answered, dumps them all into either a single email or a series of Slack messages (optimizing for overall throughput)? Or do you dole them out serially, waiting on an answer for each time before moving on to the next one (optimizing for clarity and completeness)?
I’m not here to say either approach is right or wrong, but I tend to be the “spew all the questions at once” type. And I wonder how many times it’s bitten me.
I came across one obvious example over the weekend when writing my previous post. The discussion of recruiters got me nostalgic, and I went back and read the original email thread I had when going through the initial screening process at Amazon. This exchange jumped out:
You’ll notice I was addressing several things in one go: I was responding to a specific question, and asking a bunch more, somewhat unrelated questions. The recruiter did a decent job with a detailed response, but never answered the highlighted question in particular.
Now, that oversight may have been deliberate (or at least subconsciously skipped) because those roles likely weren’t in this recruiter’s purview. But looking back, I would have been considerably better suited for them vs the one I ended up initially taking.
I’m not complaining about how things played out, but I still have to wonder how differently my Amazon experience might have gone if I’d not made the blunder of burying a critical question, namely ensuring I was aligned to the best job for my skills. Yes, I was unemployed at the time and trying to move fast, but that’s no excuse.
Whether this anecdote means serial communication is better I’ll leave as an exercise for you, dear reader.
More often than not, the tool you need to solve a particular programming problem has already been created and is easily discoverable via PyPI, npm, etc. I rejoice in these times.
Sometimes, however, the tool you need does not exist. Yet I still rejoice in these times, because they present an opportunity to create a new thing and share it with the world.
I’m thus here to announce sql-to-odata, a Python package containing tools to facilitate adding an OData interface in front of a SQL database. It’s limited right now to my specific use case (creating static extracts from SQLite), but if there ends up being broader interest, who knows what it might become.
One of my favorite tools is ngrok (pronounced en-grok, presumably referencing Stranger in a Strange Land, a book I read as a freshman in high school when I was far too young to appreciate it). If you need to get a locally-running service on the Internet, ngrok can do it in seconds with a single command. I use it all the time when experimenting with and debugging APIs, such as this weekend’s foray into LangChain.
Supposedly it can do a bang-up job of fronting production services also, but I’ve never tried it for that use case. Perhaps someday? In any case, I’m truly grateful it exists.
If you found this blog helpful and want to say thanks, I like coffee.
