My Gmail account turned 20 years old today:
I’m fairly certain it’s the only technology, hardware or software, that I’ve used continuously over that time period. That’s an impressive accomplishment; tip of the hat to the Gmail team. May we all be so fortunate in our endeavors to build something that lasts.
Spent my morning debugging a data extraction pipeline that’s been failing to properly update a dashboard, despite it completing without error (lovely). Digging through the output of the pipeline software got me thinking about logging. There’s a real art to getting it right: too much is impossible to parse (and potentially leaks sensitive information), but too little is useless. Sometimes the difference between finding the source of the problem and not is having logs in a Goldilocks Zone.
In today’s case, the log looked something like this:
- Calling the API
- The API call succeededBetter than nothing, at least it would have let me know if the API call was failing altogether. But this would have been so much more helpful:
- Calling the API with parameters X=a and Y=b
- The API call succeeded and returned N itemsI updated the data pipeline to provide the above output, and will see how it runs tonight.
Details matter, y’all! I wish I knew a way to teach the above to software engineers, but I fear there’s no real way to learn except through the experience of having to do this sort of debugging. It’s not fun work, but it’s oh so valuable.
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…
Of the various AI-powered chat tools out there, I’ve been leaning into Claude the most. I appreciate their stance on safety for one thing, and I also really like features like document uploads, shareable projects, and artifacts.
Yesterday I exported the entire contents of this blog, loaded it into Claude, and then asked it to summarize my career trajectory.
Based on your blog posts, your career trajectory can be summarized as follows:
1. Early Years (Ages 4-18):
- Started programming at age 4 on a TI-99/4A computer
- Self-taught BASIC, then learned C and Pascal
- Developed various small projects and games
2. College Years (Ages 19-24):
- Studied mathematics and computer science
- Worked on academic projects, including computational mathematics
3. Early Career at Defense Contractor (Ages 22-34):
- Started at TRW (later became Northrop Grumman) right after college
- Worked primarily with Ada and C
- Developed algorithms for terrain analysis and flight path optimization
- Gained experience in mapping software and API design
- Moved to San Diego and got first taste of technical leadership
4. Mid-Career Transition (Age 35):
- After nearly 13 years at Northrop Grumman, moved to Everyone Counts
- Transitioned to working with Java and Perl
- Became technical lead for the company's voting application
5. Technical Growth Period (Ages 36-37):
- Expanded skillset to include Angular, Node.js, and Docker
- Focused on continuous learning and adapting to new technologies
6. AWS and Cloud Focus (Age 38 onwards):
- Joined Amazon Web Services as a Senior Consultant in the public sector
- Obtained multiple AWS certifications
- Worked extensively with cloud technologies and services
7. Leadership Role (Recent):
- Became a technical manager, leading a team of software engineers
- Focused on both technical and people management aspects
8. Current Role (as of last blog post):
- Chief Technology Officer at Research Improving People's Lives (RIPL)
- Working at the intersection of technology and public policy
Throughout your career, you've consistently demonstrated a passion for learning new technologies, solving complex problems, and gradually taking on more leadership responsibilities. Your trajectory shows a progression from low-level programming to high-level system design and management, with a growing focus on cloud technologies and public sector applications in recent years.That’s surprisingly accurate! Well done, Claude.
While his material is worth reading for anyone in the software industry, Ryan Peterman’s work is especially valuable for mid-level developers looking to take that next step. The Tech Lead’s Playbook, for example, captured the responsibilities better than my own thoughts despite being half the length.
He jumped 3 levels in 3 years at Meta, which is an insanely-fast series of promotions. He knows what he’s talking about! That being said, I bet it took a decent amount of luck too, so don’t expect similar results even if you follow his advice perfectly.
A big oops happened this weekend, and it has me thinking about failure. It’s a topic I’ve talked about before, but there’s plenty more that can be said.
Common leadership advice is to avoid making failure out to be a bad thing. “Failure is good,” well meaning folks will say. They’re not completely wrong, but they’re not absolutely right either.
Failure can only be good in moderation. Of course repeated failure of the same kind is bad. Absolutely learn from mistakes so they’re not repeated. But continually making new kinds of failure isn’t great either. No endeavor, professional or personal, can sustain that.
Eventually there need to be successes to offset the setbacks. So I’m not keen on over-celebrating failures, or treating failure as something that ought not have consequences. Maybe in the case of this CrowdStrike fiasco no one deserves to take the blame? But I doubt it.
Last night ChatGPT had a bug. But not your run-of-the-mill problem like increased latency or complete unavailability. No, it went completely off-the-rails: spouting gibberish, repeating itself ad infinitum, and other nonsensical behavior.
Hilarious though some of the outputs were, it was a powerful reminder that AI technologies are still new and mysterious, and definitely require human oversight. While this incident ended up with random output, I can now imagine a whole class of bugs where language model outputs are wrong in all manner of specifically bad ways. Humorous now, but perhaps less so once we give them agency to act on our behalf.
I anticipate the day coming when I ask my personal Scarlett Johansson to book a family vacation to Fiji and it instead sends an email to my mom lambasting her for wearing white after Labor Day and then sells my living room furniture on eBay.
The future’s going to be something else, of that we can be sure.
I once had a customer call me an “idea hamster” because of how easily I went down rabbit trails of ideation when discussing the project we were working on. We had a good laugh about that turn of phrase, and I do see the value in idea generation to some degree, but ideas are easy. I’m not impressed by someone who can come up with many of them (least of all myself). What impresses me is people and organizations that can execute on their ideas.
There might be “second half of life” factors at play as well in my desire to get better at finishing. In the last week I’ve added 10 draft ideas to my blog backlog, and this will be only the first one I’ve published. At the rate I’m going I’ll never get done, which perhaps is a good thing, but still, I want to get a few of these ideas out in the wild, and that means I need to power through the writing part.
Speaking of persisting, there’s two books I’d recommend on the topic:
While targeted to traditional artists like writers and musicians, both have much to say about broader creative activity, within which technological work definitely falls.
P.S. If you’re short on time, you can find a selection of extracts from the latter book in this article: How to Fall in Love with Hard Work.
P.P.S. I almost didn’t write this post because both these books have considerably mixed reviews on Goodreads. But I decided to take their advice, post anyways, and let the reader decide. How meta!
Generally speaking, people want to know they’ve made a difference in the world that will outlast themselves. Few occupations have the intense immediacy of potentially giving one’s life for the future of human flourishing than that of the solider. It’s an admirable profession that is worthy of respect, especially for those for whom this potential became reality. However, not many are suited for such work, not to mention ideally the need for soldiers will shrink as societies mature.
Thankfully there are myriad other ways in which a person can approach a career with the future in mind. Last week I read through a number of articles from 80,000 hours, and I have the book of the same name queued up as well. The premise is that our jobs take up a considerable fraction of our lives, likely more than any other activity, and thus it behooves us to think deeply of how to spend that time. That’s hardly controversial, but applying logical principles and data-backed guidance to maximize the future impact can be (similar to discussions around Effective Altruism).
Personally, I find the arguments compelling. It’s why I’ll spend the rest of my time as a technologist dedicated to work in the public sector, and especially in the space of tech and politics. When it comes to maximizing human flourishing, good public policy is critical, and with a shrinking world, the risk of bad policy existential.
Many have died to give those who remain the chance to build this better world. Honored to be among the latter group; don’t intend to let it go to waste.