Keep It Safe
Ever need to dump all your AWS Security Hub findings to a CSV file for easier analysis? I got you.
Kinda crazy that export isn’t built into the console, though. Can I submit a feature request?
Headquarters (Part 3)
Just when you thought there couldn’t be more (oh trust me, there’s more), here’s comes another round of my series on computer setups (earlier posts are here and here).
Years: 2005-2010
Machine: The box in the closet from my last post but with a snazzy new LCD monitor (my first flat panel), wireless peripherals, and my wife’s great-grandmother’s writing desk.
What I was doing: writing daily on Xanga; applying to family camp; traveling to Tennessee to watch Revenge of the Sith with a high school friend; hosting LAN parties for Age of Empires III; traveling a lot for work.
Years: 2006-2007
Machines: A plethora of cast-off parts coalesced into a couple functional boxes in the garage.
What I was doing: running a NAS for storing all my media; trying to get Gentoo Linux to compile; realizing that running a bare web server on the Internet is asking for trouble.
Years: 2008-2010
Machines: A beefed up HTPC rig in a rackmount case with a whole bunch of amps to power my Magnepan speaker system, plus the plethora of beige boxes from before, but better arranged.
What I was doing: shivering in the garage when using this desk in the winter, listening to Comfortably Numb at peak volume, hosting movie-watching parties.
Year: 2011
Machines: Same rack mounted setup, but relocated from our old garage in Ohio to a closet in our new garage in San Diego, plus a random beige box (those just won’t go away).
What I was doing: Playing with some audio recording gear; streaming Game of Thrones; stocking up on printer paper, apparently.
Years: 2012-2014
Machines: Moved inside, and rebuilt the guts from the rack mount case into a traditional one (albeit black and silenced), also got my first Mac laptop (from which I’ve never looked back).
What I was doing: writing election software; creating hand-made guitar effect pedals (that were terrible); developing back problems thanks to a crummy chair.
Figuratively Speaking
Speaking effectively to non-technical people can be a challenge for technical folks, but it’s an essential task for all but the most mundane (read: least-effective) of roles. One mechanism that I’ve found helpful is the use of metaphor. I’m a huge fan of trying to describe complex topics by mapping them to more broadly understood concepts. Being able to come up with such mappings fluently is a powerful skill. There may be many ways to develop it, but I suspect one is cultivating a wide set of interests.
While I was writing Tuesday’s post, it occurred to me that today’s Generative AI tools are to software what today’s 3D printers are to physical objects. On one hand, it’s incredible to be able to provide a specification and have it manifested in near real-time. Printers can make a variety of solids: toys, some kinds of replacement parts, that sort of thing. GenAI can create chunks of useful code, quick user interfaces, and basic apps, like my Pinochle scoresheet. But there are limits. Can either of these tools produce high tolerance, precision parts / highly secure, performant code? Can they build complex solutions like electronics / web browsers?
I could be wrong, but just like we’re a long ways from 3D printing an iPhone, we seem a ways away from vibe coding Microsoft Word or an entire government system of record.
Old Dog, New Tricks
Over two years ago I bought a few domains with the intent of building a tool for keeping track of card game scores. Like many of the best laid plans, I didn’t get around to doing so. Until now.
With the advent of GenAI and “vibe coding” I figured there was no longer any excuse. I spun up Lovable and started prompting. The results? Not bad. Not bad at all. With maybe a dozen prompts and half an hour, you can see the results at onlinescoresheet.net. What was most impressive for me is that I was able to simply ask the model to do Pinochle scoring, and it was able to understand what that meant and implement it without me explaining the rules.
What’s up next? I’d like to generalize the scoring system to be configurable, or at the least add explicit support for a few more game types. I’d also like to dig into the source code to evaluate quality. Should be fun!
Right On Cue
Another gist for your holiday season: this one makes it easy to run a specific terraform version in Docker. Why might you want to do that? Well, for one, if you need a specific version (though tfenv can get that job done too).
My reason, though, was that I needed a version so old that a handful of plugins aren’t supported on Apple silicon. Docker with Rosetta to the rescue.
Happy holidays y’all!
In Brief
I like Github gists. They’re perfect for long-term publishing of any code snippet you might want to refer to later, without the overhead of a formal repository. I’ve used them as backing storage for a number of blog posts as well, and will do so again today:
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.
Happy scripting!
Lightning vs Lightning Bug
For many organizations (mine included), November is performance review season. I know it’s not everyone’s cup of tea, but I quite enjoy both getting and giving of constructive feedback. So much so that apparently I like writing about how I like performance reviews every November as well.
Today’s post is about specific questions for collecting feedback from stakeholders about a person you’re reviewing. Giving such feedback is uncomfortable for many people; it can feel like tattling or speaking ill of someone behind their back. But as a manager, my perspective is inherently limited (and usually biased). I require input from those who are working with my team day-to-day in order to fairly evaluate them and give them the feedback they need (both growth opportunities and especially praise they may not otherwise hear).
I’ve used a variety of approaches in the past, with mixed success. But I recently formulated a pair of questions in conversation with a career coach that I think can coax out the desired information without making stakeholders have too icky a feeling about giving it. They’re delightfully simple, and can be answered quickly and discreetly via BCC-ed email or even DM:
- What do you appreciate about them?
- What advice would you give them?
Question phrasing matters. I’ll be giving these ones a spin this year, we’ll see how it goes!
Tunneling Through
From time-to-time I have need to connect to VPNs, usually when doing work directly for one of my government partners. For a reason that utterly escapes me, Cisco hides its AnyConnect client behind a login that requires a license. And it’s a heavyweight install to boot. Ugh. I’d rather use a CLI; enter openconnect.
It can be a bit tricky to get the parameters right, so I put together a little helper script that abstracts some details, not the least of which is storing the VPN password in the local keyring for quick retrieval.
Posting it here for posterity. Enjoy!
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.
Fightin’ Words
Well, this is fairly provocative: Story Points Are Pointless, Measure Queues.
I’ve advocated for story points plenty of times, but I do see the article’s point. Estimation is hard. And I like the notion that in absence of other data, just having a count of tasks yet to be completed is a decent approximation of remaining work.
And perhaps it rightly centers the definition of the tasks themselves as the important part of estimation, versus the assignment of a numeric value to said tasks? A question well-asked is half-answered, or something like that?
It also made me think of a tension I’ve seen for much of my career. Product folks tend to think in terms of features and user outcomes. As they should, for outcomes is what ultimately matters to a customer. But estimating “features” is a fool’s errand. Engineers need to think in terms of tasks: add X, build Y, modify Z, etc. The latter are (generally) easier to estimate. And, as the article argues, if sufficiently broken down, don’t really need to be estimated at all, just counted.
Making the above work, though, requires that engineers own that translation of user stories to tasks (and consequent planning thereof). That takes work, no doubt, but probably less work in the long-run than arguing about numbers.