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.That’s surprisingly accurate! Well done, Claude.
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.
Can’t focus on an important bit of work? Stressed out? Need some time to think?
Take a walk outside.
An afternoon walk has become a regular part of my routine, as important as any other daily task. I can’t recommend the habit highly enough.
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?
Today I finally came up with a layperson’s descriptor of the CTO role that I’m happy with:
Responsible for making sure we build things right, but more importantly, that we build the right things.
Yup, that sums it up nicely.
Of all the sources of happy birthday messages (which are truly delightful, by the way), one I least expected was a text from the customer service agent at CoveredCA that I worked with to get health insurance after I was laid off nearly 5 years ago, and haven’t interacted with since.
I get that it’s trivially easy for any organization that knows your date of birth to send out such messages, but…
That’s gotta be some kind of automated message, right? Or a mistake? In any case, thanks for “thinking of me” on my special day!
Today’s cautionary reminder to know your audience is something of a sequel to Left Hand, Meet Right Hand. It involves a cold email from a recruiter I got two days ago. Which isn’t a rare occurrence by any means, but what was out of the ordinary was that 1) it was from my former employer, despite there being absolutely no indication the sender realized I was a recent ex-Amazonian, and 2) the jobs being offered were at or below the level I’d been hired at back in 2019, a full five years ago. Needless to say, I’m not interested (and I’m not just saying that because my current boss sometimes reads this blog).
Look, I recognize that this email was probably auto-generated from a LinkedIn search, but it’s a recruiter’s entire job to not only find, but adequately entice, qualified candidates. The poor person was hoist on their own petard with the boilerplate about “raising the bar” and “becoming an industry leader.” Failing to do even a modicum of homework is not frugal nor customer obsessed.
It’s not like it would be that hard. Even if the automation was solely LinkedIn based, my entire work history is right there and it’s pretty obvious I haven’t been a mid-level software engineer in ten years. But an Amazon employee could easily do even better, given that there’s robust internal tooling for querying data on current and past employees. I should know, because I wrote some of it. In fact, from memory I bet I could write a Python script that could cross check a list of potential job candidates against Amazon’s employee lists.
Thanks for the chuckle, my recruiter friend. But do better. Open up your browser, go to https://<redacted_wiki_domain>.com/view/Jud_Neer and you’ll find all the resources and documentation you need to avoid this error in the future.
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’m also not superstitious, so I don’t mind saying the above despite things turning out quite differently the last time I posted a similar sentiment.
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.