Tag: Deliver Results

Concerning Hobbits

Concerning Hobbits

We’re all pretty big Lord of the Rings fans in our house, both books and movies. A few months ago we rewatched Return of the King, and I was struck by a couple moments in the dénouement that are worth talking about.

The first is one I’ve loved for a while. The hobbits have returned to the Shire and are together enjoying some well-deserved ales. Their reflective mood is in stark contrast to the conviviality around them, in particular one fellow who is showing off a massive pumpkin he’s grown. Our heroes don’t seem to mind the attention he’s getting; they’re content to sit in silence, apart from the crowd, with nothing more than a toast and some knowing glances.

No one else in that pub understands the grave danger they, and the whole of Middle-earth, were in. No expressions of thanks will come to Frodo, Sam, Merry, and Pippin. But that’s okay. It’s how it’s supposed to be. Leaders make the sacrifices so that those in their care can enjoy their pumpkins, and they seek not the credit. Fellowship amongst a small circle of friends who know the story is enough.

But even within that circle, there’s layers to the levels of awareness. It wasn’t until this most recent viewing that I realized that only Sam knows the full story: that Frodo had fallen at the last to the power of the ring, and its destruction was only completed through earlier mercy shown to Gollum, and some luck.

What Sam chooses to do with this knowledge is worthy of especial praise. When the fellowship is reunited in Rivendell, joy and celebration surround Frodo. Even the wizard Gandalf smiles in approval. Sam is late to the party, but catches Frodo’s eye from across the room.

In that moment, I wonder if Frodo is briefly afraid that Sam will interrupt with a tale of how he had to carry Frodo the final stretch, and that Frodo essentially failed, claiming the ring as his own. It would be the truth. But Sam doesn’t do that, and his expression says he never will. It’s as if he said, “I know that you aren’t a perfect hero. That at the end you did things you’re not proud of, even to me. But you gave everything you had, and the job got done. That’s worth celebrating. Fear not, my friend. Some things are just between us.”

I’m not sure if this is canon, but I imagine no one else, not even Gandalf, ever learned what really went down on the slopes of Mount Doom. That too is okay, because Middle-earth survives regardless. And that’s what ultimately matters.

Up Up And Away

Up Up And Away

Nothing thrills quite like launch day, and this time, it was nearly literal. It’s been a privilege to have been involved in this work, and fun that I can (finally) talk about it in public. I mean, when it’s on the news that’s gotta mean something right? You can check it out right here if you’re so inclined.

Hopefully the above partly explains why I’ve been pretty quiet here. As I said last month: crunch time. It’s certainly not for lack of ideas; sitting on 95 draft posts as I type. Someday I’ll get through the backlog. Or not. But it’ll be okay regardless.

Game Changer

Game Changer

I don’t use that title lightly. Not sure how I’ve never heard of git worktrees before, but I’ll definitely be giving them a spin.

Speaking of git, I don’t normally do a lot of coding in my day job, but crunch time is crunch time:

If nothing else, it’s cathartic to stretch those muscles.

Be A Lumberjack

Be A Lumberjack

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 succeeded

Better 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 items

I 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.

Life Imitating Art

Life Imitating Art

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…

In A Nutshell

In A Nutshell

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.

Showing The Way

Showing The Way

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.

Not An Option

Not An Option

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.

Buy Me A Coffee
If you found this blog helpful and want to say thanks, I like coffee.