When the topic recently came up about scheduling a weekly team sync call, to the chagrin of a few colleagues, I suggested 7am PT on Mondays. Given how most of my work is tied to Eastern and Central time, I’ve become accustomed to waking up early. Even on weekends (I’m writing this on a Saturday and I was up about 6:30, for example).
I get that it doesn’t work for everyone, but for me, early mornings are ideal. They also make an excellent subject for a song (this one’s been a favorite of mine since 2006):
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.
Yesterday I re-passed the AWS Certified Solutions Architect – Professional exam. It’s my third time taking it (2019, 2022, and now 2025). I went into it cold turkey, absolutely zero preparation, and while my score wasn’t as good as before, a pass is a pass.
I guess at this point, I’ve done enough work in AWS that the knowledge is pretty much permanently ingrained. It reminded me of this article on Buying Moves:
There’s an amazing quirk of the human body that makes fitness adaptations work a bit like powerups in a video game. You can spend some resource to add capabilities to your “character,” and if you do it right they’re always available to you (for the most part). I’m talking about muscle memory and our ability to “lock in” physical skills.
Perhaps there’s a mental version of the same phenomena?
Continuing from earlier, this post covers early adulthood, pre-kids.
Year: 2000 Machine: Custom built beige box with NewEgg parts What I was doing: Enjoying early married life; playing Deus Ex; renting movies from Blockbuster and watching them on my computer’s DVD-ROM drive; organizing documents in that green file box (which I still have).
Year: 2001 Machine: Same beige box but with new guts What I was doing: starting to explore high-end audio and home theater, applying to Ph.D. programs, anticipating The Fellowship of the Ring.
Years: 2002 Machine: Still the same beige box but a new “flat” monitor What I was doing: trying to understand Topology, skipping graduate school classes to play Diablo II; anticipating The Two Towers (I still remember waiting for this trailer to download… it was was mind-blowing, despite the low quality of the day).
Year: 2003 Machine: You guessed it, a beige box, though I believe I’d upgraded it yet again What I was doing: starting a blog on Xanga, anticipating The Return of the King (it was on this setup that I created a postcard inviting 40 of my closest friends to a private midnight screening at the Arena Grand).
Year: 2004 Machine: A second beige box filled with scraped together cast-offs from my main computer, complete with double optical drives What I was doing: embracing my minimalist tendencies by trying to hide boxy components inside closets and running cables through the walls; ripping my entire CD collection to FLAC; preparing for our first kid.
I’ve been an Android user since the original Motorola Droid was released back in 2009. However, last month I finally broke down and made the switch to iOS.
I didn’t buy new, though. Because I don’t like big phones, I found myself a refurbished iPhone 13 Mini. It’s perfect. Sure do wish Apple would acknowledge the ongoing market for small devices, but it seems they’re well and truly dead. Maybe I should get a second Mini as a backup, especially since I’m case-free?
Last week I finished The Principles of Product Development Flow, based on a recommendation from the article I wrote about in Fightin’ Words. To say it was relevant to my current line of work is an understatement; I immediately mailed a copy to our de facto development process person.
Luckily for us all, though, there’s an official TL;DR version online. It’s a plethora of pithy principles packed onto one page. Go check it out!
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.
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.
I aggressively unsubscribe from email lists in order to get to Inbox Zero. Which isn’t an end in itself, but part of a broader strategy of radical responsiveness. I’ve been pretty good about doing so with my personal email, but my work email has gotten a bit out of hand.
So the past week I’ve been working on that, for my own email address and several shared addresses and aliases that come my way. It’s tedious, but progress is being made. However, I’m regularly baffled by the number of sites that report that unsubscribe isn’t instantaneous. Today I was quoted “5-7 days”, and I’ve seen as much as “2 weeks”. Why? What could possibly take that long?
Anyone out there in the spam email marketing business that can explain it to me?
