I’m not into pranks, giving or receiving. Maybe it’s just because my years are limited, but I don’t generally appreciate being inconvenienced in ways that waste my time for no reason other than humor. It’s a bit like an individualized corollary of the broken window fallacy.
Because of the above I get somewhat hypersensitive around April 1. I feel I’m generally good at sniffing out the BS, but I got taken pretty hard this year, cleverly enough that I have to tip my hat.
So a website I visit regularly posts periodic brain teasers. The one on April 1 sounded innocuous enough. The gist:
Start with a number. If it’s even, divide by 2. If odd, multiply by 3 and add 1. Repeat enough times, and you’ll end up with 1. Prove why that’s the case for any starting number.
I’m a sucker for that sort of mathy puzzle, and I spent a decent amount of time throughout the day noodling on it. Well, here’s the deal. Known as the Collatz conjecture, this convergence to one is famously unsolved, described on the Wikipedia page as “an extraordinarily difficult problem, completely out of reach of present day mathematics.” Lovely, so you’re saying this Ph.D. dropout is unlikely to solve it?
To be fair, I should have known. Numeric conjectures that intermingle addition and multiplication are notoriously complex, despite their apparent simplicity. I used to joke that a life goal was to solve Goldbach’s conjecture, which states that every even natural number greater than 2 is the sum of two prime numbers. Apparently I said this enough at my first job that when I left, they gave me this fill-in-the-blank certificate as a gift:
It’s a good reminder that it’s the “easy” stuff you have to worry about most. It’s never five minutes.
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.
I’m a creature of habit with a particular love of regular daily routines. Thus starting back to work after holiday is one of my favorite times of year. 2024 is shaping up to be a season of change, though not until summertime, so for a few months at least I’m looking forward to normalcy.
I was today years old when I learned that an object key in S3 can end with a slash. Why might someone use such a strange key, you ask? Well, I was working today on a static website served by CloudFront that needs to serve a particular JSON document at /foo/bar/ (note the trailing slash). One option was to create the corresponding object at /foo/bar and then use a CloudFront function to remove the trailing slash. But that adds complexity, cost, and a tiny bit of latency. Could there be a better way?
Indeed there was! Create the object with a prefix of /foo/bar/ and Bob’s your uncle. Admittedly it’s a bit tricky to create an object with such a key. The console won’t do it, and neither will the aws CLI (at least not without getting fiddly with encoding, and no one’s got time for that). But boto3 to the rescue, it’ll happily do it.
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.
So you want to become (or have been told you now are) a technical team lead? Awesome, congratulations! You’re in for an excellent adventure. But if you’re wondering where to begin, and what’s going to change, lucky for you I’ve been there myself, helped several others through this transition, and have captured some lessons you can apply:
First, make sure everyone on the project knows you’re the technical lead. This isn’t about ego or power, it’s about clarity of function and accepting responsibility. With that comes the need to be responsive; availability for conversation is now part of your job.
Next, get to know the team personally and earn their trust though human connection. You cannot be everywhere all the time, so you need people who are comfortable coming to you with challenges both technical and otherwise. If there are folks involved external to your organization this is doubly-important. Identify a go-to person on that external team and engage with them regularly one-on-one.
Get to know the team professionally as well. What are each individual’s strengths and weaknesses? What technical skills do they have, and what parts of the system need those skills applied? What are their communication styles and ways of being motivated? Personalize your approach with everyone; it’s your role to put them where they can thrive, which in turn maximizes collective success.
Have a generalist mindset. Get to debugging level competency across the entire tech stack, no excuses. You don’t need to be the best at everything, in fact you shouldn’t be, but you should know what good looks like so you can ensure it’s happening.
There’s one area, though, where your knowledge should be unrivaled, and that is understanding your customer and the business case you are there to solve. Get familiar with their requirements and deadlines. Stay connected to your stakeholders, listen, ask questions, and then push their objectives down to the people in your charge. Once again, this is especially important if there are subcontractors who have a limited view of the big picture.
Make yourself present in meetings, erring on the side of being overly-present (especially at first). Requirements gathering session? You gotta be there. Sprint planning and backlog grooming? Not optional. But that deep dive on a bug or tricky technical problem? Maybe let your tech experts handle it, or at least have them gather the data and come to you if they run stuck or need a decision.
Speaking of decisions, apply wisdom to the ones you can delegate and ones you cannot. Specifics will vary project to project, but in general the more reversible a decision is, the less important it is you make it. Another rule of thumb: as soon as you know how to do something well, it’s time to teach someone else to do it, while you take up the next challenge no one else is equipped to solve. Fail at security and you fail full stop, so keep your eyes on anything that could jeopardize it.
High level architecture and technology choices will matter more in the long run than anything decided in a code review, so keep your nitpicks to yourself. Speaking of code reviews, their value mostly comes in peer to peer cross-checks. If you think you have to approve every line of code yourself, you’re doing it wrong. Treat your attention like the precious commodity it is.
Your good intentions of ensuring quality code and other deliverables won’t be enough. Establish quality mechanisms: automated linting and security scans. Automated testing. Continuous deployment. These are your eyes and ears, and more important for you to establish and monitor than you building features.
Take failure personally. Things will go wrong; the minute you blame those under your charge, you’ve lost. Instead, turn your gaze inward to what you could have done better. When you hold yourself to the highest standard, it calls others to do the same.
Finally, don’t stop listening and learning. Get feedback, even when it’s hard to hear, and act on it. Also, there’s tons more out there on being a tech lead, go do some searches and read up. Perhaps you’ll even (gasp) find counterpoints to my above arguments. That’s great! Ultimately you’re a technical lead to serve and empower, and that requires judgment on when to follow the rules and when to toss them and do what’s gotta be done, because no job is below you. Be the person who brings the coffee and donuts, orders the pizza, serves the drinks, and cleans the conference room afterwards.
Sound hard? It is. It’s gonna take a different set of skills and a significant amount of time. You’re going to have to let go of some things you’re used to doing and some things you’re good at (and probably enjoy doing) to find that time. But when a team you’ve led accomplishes more than you could ever do on your own it’s a unique kind of reward.
My first real job was at Burger King, which I got at my dad’s behest the summer of 1994. I was only 15 years old, and what I could do was pretty limited (no food prep, nothing to do with the deep fryer, couldn’t even do dishes because of knives). But what I could do was operate the register and take orders. On balance it was a positive experience, not least because it taught me how to talk to strangers.
I’ll never forget one particular aspect of my training. There was a question we were expressly forbidden to ask when interacting with customers, and if we ever did, even accidentally, our manager would yell at us from across the kitchen. The question?
Is that it?
Why was it verboten? Because it shuts down conversation. In social situations humans are wired to want to answer questions in the affirmative, and a “yes” response to that question means no more items to add to the order, and my corporate overlords definitely didn’t want us to encourage customers to stop adding fries, drinks, desserts, and more. What question were we instead instructed to ask?
Is there anything else?
The difference is significant, as an affirmative answer here encourages the customer to go ahead and keep ordering, subtly suggesting that perhaps there’s more they would enjoy. I realize now, though, that there’s an even better way to nudge a person to continue speaking what’s on their mind.
What else?
I first picked up this simple but effective question from one of my managers at AWS, as he would use it throughout our 1-on-1 meetings to get me to be honest about what I was thinking and feeling about my job. This question works because unlike the prior one, it assumes that a person already has more to say, nudging them to say it. I know it worked on me (I had no shortage of opinions to share, no doubt).
It reminds me of another short but powerful prompt that can take a conversation to the next level:
Tell me more.
When trying to listen actively, it can be a challenge to think of relevant follow-up questions in real-time, especially with a person who’s taciturn, or if you don’t have a prepared agenda. “What else” and “tell me more” are great because they can be used at any lull in the conversation; keep them at the ready, and they won’t let you down.
“For millions of years, mankind lived just like the animals. Then something happened which unleashed the power of our imagination. We learned to talk and we learned to listen. Speech has allowed the communication of ideas, enabling human beings to work together to build the impossible. Mankind’s greatest achievements have come about by talking, and its greatest failures by not talking. It doesn’t have to be like this. Our greatest hopes could become reality in the future. With the technology at our disposal, the possibilities are unbounded. All we need to do is make sure we keep talking.”
Just in case the post on crossword solve times didn’t make it obvious enough, I like to track things. I suspect it’s a corollary of liking gamification. Here’s a rundown of info I’m keeping and the tools I’m using:
Today the United States celebrates its independence. Amongst the barbecues and fireworks, it’s worth taking a few minutes to reflect on the significance of this day in history. For me, I’m most thankful for the contributions of this country’s founders to the ideals of good government.
We’ve had no shortage of trouble in living up to those ideals, and I’m convinced that some considerable reforms are still needed given how the nation has evolved (see Breaking the Two-Party Doom Loop for my favorite take on that subject), but on the whole, the system of government we enjoy with its equal representation, checks and balances, and problem solving using negotiation and compromise vs violence, has promoted human flourishing both here and around the world (well, sometimes at least).
It’s been a privilege of mine to work in the public sector for most of my career, and I don’t expect that to change anytime soon, as I’ve doubled-down on situating myself at the intersection of tech and politics. I figure it’s how I can best honor those who got us this far; to continue the quest for developing better governmental systems and policy.
