Tag: Invent And Simplify

Lightning vs Lightning Bug

Lightning vs Lightning Bug

By | | Comments 0 Comment

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

Tunneling Through

By | | Comments 0 Comment

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

In A Nutshell

By | | Comments 0 Comment

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

Fightin’ Words

By | | Comments 0 Comment

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.

Jump The Line

Jump The Line

By | | Comments 0 Comment

While it’s not an absolute guarantee, there are a few ways to get my attention when applying for an open role for which I’m responsible.

First, read the job description and the minimum requirements. If you don’t meet them but want to take a chance anyways, don’t shy away from where you fall short. Address any gaps head-on in your cover letter and how you can mitigate.

Speaking of a cover letter, you should absolutely write one. Yes, actual you, not an LLM. I value engineers who can communicate effectively, especially in writing, given the realities of remote work. This isn’t about nitpicking spelling or grammar (though in 2024 there’s little excuse for stumbles here, given the tooling available), nor is it about quantity. It’s about concisely communicating what you value in a job and what excites you about the role enough to apply.

When describing what you value, show don’t tell. I love to see an example of work you’re proud of in a cover letter, because the way you discuss what’s important really matters: are you enamored with technology as an end in itself, or do you value impact on a customer? And what kind of impact do you value?

Finally, be sure to follow the instructions in the application process. Employers may have specific reasons for their requests; deviation does you no favors. For example, RIPL asks for an email to a specific address that goes to a shared inbox. If you send your info directly to an individual it might be missed. And if you DM me in LinkedIn instead, well, I get a lot of DMs, so don’t expect a response.

Played The Fool

Played The Fool

By | | Comments 0 Comment

I’m not into pranks, giving or receiving. Maybe it’s just because my years are limited, but I don’t generally appreciate being inconvenienced in ways that waste my time for no reason other than humor. It’s a bit like an individualized corollary of the broken window fallacy.

Because of the above I get somewhat hypersensitive around April 1. I feel I’m generally good at sniffing out the BS, but I got taken pretty hard this year, cleverly enough that I have to tip my hat.

So a website I visit regularly posts periodic brain teasers. The one on April 1 sounded innocuous enough. The gist:

Start with a number. If it’s even, divide by 2. If odd, multiply by 3 and add 1. Repeat enough times, and you’ll end up with 1. Prove why that’s the case for any starting number.

I’m a sucker for that sort of mathy puzzle, and I spent a decent amount of time throughout the day noodling on it. Well, here’s the deal. Known as the Collatz conjecture, this convergence to one is famously unsolved, described on the Wikipedia page as “an extraordinarily difficult problem, completely out of reach of present day mathematics.” Lovely, so you’re saying this Ph.D. dropout is unlikely to solve it?

To be fair, I should have known. Numeric conjectures that intermingle addition and multiplication are notoriously complex, despite their apparent simplicity. I used to joke that a life goal was to solve Goldbach’s conjecture, which states that every even natural number greater than 2 is the sum of two prime numbers. Apparently I said this enough at my first job that when I left, they gave me this fill-in-the-blank certificate as a gift:

It’s a good reminder that it’s the “easy” stuff you have to worry about most. It’s never five minutes.

Missing The Trees

Missing The Trees

By | | Comments 0 Comment

Are you the kind of person who, when you have a bunch of questions you need answered, dumps them all into either a single email or a series of Slack messages (optimizing for overall throughput)? Or do you dole them out serially, waiting on an answer for each time before moving on to the next one (optimizing for clarity and completeness)?

I’m not here to say either approach is right or wrong, but I tend to be the “spew all the questions at once” type. And I wonder how many times it’s bitten me.

I came across one obvious example over the weekend when writing my previous post. The discussion of recruiters got me nostalgic, and I went back and read the original email thread I had when going through the initial screening process at Amazon. This exchange jumped out:

You’ll notice I was addressing several things in one go: I was responding to a specific question, and asking a bunch more, somewhat unrelated questions. The recruiter did a decent job with a detailed response, but never answered the highlighted question in particular.

Now, that oversight may have been deliberate (or at least subconsciously skipped) because those roles likely weren’t in this recruiter’s purview. But looking back, I would have been considerably better suited for them vs the one I ended up initially taking.

I’m not complaining about how things played out, but I still have to wonder how differently my Amazon experience might have gone if I’d not made the blunder of burying a critical question, namely ensuring I was aligned to the best job for my skills. Yes, I was unemployed at the time and trying to move fast, but that’s no excuse.

Whether this anecdote means serial communication is better I’ll leave as an exercise for you, dear reader.

Run It Back

Run It Back

By | | Comments 0 Comment

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.

Edge Case

Edge Case

By | | Comments 0 Comment

I was today years old when I learned that an object key in S3 can end with a slash. Why might someone use such a strange key, you ask? Well, I was working today on a static website served by CloudFront that needs to serve a particular JSON document at /foo/bar/ (note the trailing slash). One option was to create the corresponding object at /foo/bar and then use a CloudFront function to remove the trailing slash. But that adds complexity, cost, and a tiny bit of latency. Could there be a better way?

Indeed there was! Create the object with a prefix of /foo/bar/ and Bob’s your uncle. Admittedly it’s a bit tricky to create an object with such a key. The console won’t do it, and neither will the aws CLI (at least not without getting fiddly with encoding, and no one’s got time for that). But boto3 to the rescue, it’ll happily do it.

Obligatory bit of additional knowledge: know your slashes.

Mother Of Invention

Mother Of Invention

By | | Comments 0 Comment

More often than not, the tool you need to solve a particular programming problem has already been created and is easily discoverable via PyPI, npm, etc. I rejoice in these times.

Sometimes, however, the tool you need does not exist. Yet I still rejoice in these times, because they present an opportunity to create a new thing and share it with the world.

I’m thus here to announce sql-to-odata, a Python package containing tools to facilitate adding an OData interface in front of a SQL database. It’s limited right now to my specific use case (creating static extracts from SQLite), but if there ends up being broader interest, who knows what it might become.