I’ve been working on a little project here at this blog, one that’s required me to go back and re-read all my old posts. Truth be told tonight I was using it as a distraction from what I really should be doing (backlog grooming ahead of tomorrow’s new sprint).
Let’s just say this post hit a little close to home. I suppose I better press pause for now (but you’ll hear more soon, I promise, and if you’re observant, you might be able to guess what I’m doing).
During interviews, a common question directed at me is what my day-to-day looks like. While it feels like a cop-out, the answer is that I do whatever my customers need me to do. Some days that might mean writing Python, Node.js, or Java. Other days it might mean terraform, CDK, or (ugh) CloudFormation. Still other days it might not mean code at all, but leading daily stand-ups, drawing architecture diagrams, writing documentation, giving training, or planning long-term goals. And that’s not to mention all my managerial tasks like 1-on-1s, goal setting, performance reviews, an mentoring, since I view my team as customers of a sort.
We talk at AWS of being comfortable with ambiguity. It’s a posture that doesn’t suit everyone, but pretty much any technical job of worthwhile complexity requires the ability to deal with unknowns. There are no hard and fast rules. No absolutes. System design, software development, team leadership, they are all just as much art as science, requiring both good intuitions and good data to get right.
Don’t believe me? Then consider how Stack Overflow tells it.
Today I saw the following commit message in a code repository:
fix typi
It wasn’t me this time, but I’ve been there. We should all strive for better. There are dozens of guides on how to write good commit messages. And if you mess one up, as long as you haven’t pushed, git commit --amend is your friend.
Other than learning to type faster and more accurately, there are few activities I know of that can rapidly level up a developer’s effectiveness than becoming fluent with git. And I don’t mean just the basics, but really digging into the details and practicing until it becomes second nature. Start by reading Pro Git, cover to cover. You won’t regret it.
Anyone remember this commercial (and the lead-in to it)?
If the kid is me, the doll is Python. Anywhere I go, it goes too. If I have a problem to solve, it’s the tool I reach for nine times out of ten. We’re like peas in a pod, Python and me.
In all seriousness, though, the comparison is apt. I’m a generalist at heart, and I don’t know of a better general-purpose programming language than Guido van Rossem’s masterpiece. Only recently did I make this association, but it fits.
As a team leader, I aim to be adequate or better with any part of the tech stack, so I can plug myself in wherever I’m needed. But it’s unlikely I’m the best one on my team at any of the tech either (in fact, if I am, the team probably doesn’t have an ideal mix of talent). That’s an awful lot like Python, which is the second-best language at everything:
Besides us both being generalists, Python and I are both minimalists. It eschews superfluous bits like delimiters, and you needn’t bother declaring types if you’re in a hurry and the situation doesn’t demand it. I also don’t like clutter, e.g. consider my primary workspace:
Did I mention Python is really easy to learn? And the community is great? And it’s just plain fun? As far as I’m concerned, Python is the Holy Grail.
P.S. It also has a great name. And that’s not nothing.
We talk all the time about customer obsession, it’s the first amongst equals of our Leadership Principles. The general idea is that you always imagine the customer is in the room with you when making decisions, and consider their preferences when implementing a feature.
As email got more prevalent (and with it, junk emails), one feature that came along in the spirit of customer obsession was one-click unsubscribe. Me being a person who strives for inbox zero, stopping email subscriptions easily was a welcomed capability. But who knew it could be done even better. Behold, zero-click unsubscribe:
How cool is that? Recognizing that I haven’t interacted with any of their emails or visited their site, they automatically unsubscribed me from their lists. That’s customer obsession in a nutshell.
The really surprising thing about this capability is that it’s surely dirt simple to implement. I bet I could pseudo-code it off the top of my head in one minute. Ready, go!
all_emails = database.get_mailing_list()
for email_address in all_emails:
last_contact = database.get_last_contact(email_address)
if datetime.today() - last_contact > ONE_YEAR:
database.remove(email_address)
See how easy that was? Any marketing email system worth its salt already knows when you click on a link in any of their mailings, so the data is there. Just takes a company thinking more about their customers than the size of their distro.
If you only read one article about how to improve your experiences with virtual meetings, read Why are video calls so tiring?
It’s also a helpful reminder that diversity takes many forms, and making sure we are inclusive in our meeting behaviors takes effort.
The Morning Paper is wrapping things up, as explained in its final post. A treasure trove of computer science deep dives, it will be missed. But I can certainly relate to the desire to move on, especially when a global pandemic has brought life’s various priorities into sharper focus.
Luckily for all of us there is a rich back catalog of posts that could keep one busy for months. Do check them out. Need a place to start? Here’s my absolute favorite: Applying the Universal Scalability Law to organizations.
Several weeks ago I recorded a half-hour talk for our big annual kickoff meeting. It turned out to be quite the production, with ring lights and lav mics and a team of people helping me set up and run the recording. Not to mention the time that went into prepping the content and having it peer reviewed and copy edited.
There was a moment amidst the mayhem when I wondered if it was worth it, especially considering all my other responsibilities. I briefly thought about calling it off altogether. But it’s an honor to be selected in the first place, so perseverance was appropriate.
Turns out it has been a singularly rewarding experience hearing positive feedback on the session. Not just from my own team, but from people all around the world. Twelve countries at last count (in order by timezone):
I happily responded to every email and Slack message, even had a couple quick video chats about it. Pretty darn cool.
I’ve written a couple of posts in the past that provide an outline of my career progression. Today’s update is in that vein, as I’ve taken on a new role as a technical manager, getting back into people management after a few years off from it.
I was chatting yesterday with one of my new team members, and he asked me a pointed question. Paraphrased, “Given your technical background, why would you choose to be a manager?”
On my résumé, I describe myself as having
a keen interest in architecting systems that are secure, scaleable, and cost-effective, and then building the organizations best suited to implement them
And therein I think lies the reason. I’m a builder at heart, to which this blog’s domain name testifies. And building great solutions requires building great organizations, and it’s that latter team construction which is a manager’s primary responsibility. So I think it makes sense that the builder mentality can carry over to people, even if the technologies involved differ.
Here’s a great upcoming year!
In all my time thinking about how naming is hard, I’ve never come across a concise set of practical suggestions for choosing variable names in software. Until now. I’ve used the A/HC/LC Pattern my whole career, but never had a term for it. Honestly it could use a better name (naming is hard!) but the concept is solid.
There isn’t a single piece of advice in the above that I disagree with, and a few I absolutely love (my goodness do I hate context duplication in namespaced variables).