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.
Recently I got a Google reminder about a trip I took nine years ago. It was a business trip to the East Coast, and I remember it well, because it was at that meeting where I successfully convinced a customer that we needed to launch a large new development effort.
Little did I know at the time how the decisions made at that meeting would steer the direction of my next several years. And not just me, but our company, and the raft of individuals who we hired to work on the project. A handful of whom are still involved after all this time. And several whom I number amongst my friends.
The more I think about it, 10,000 people influenced over a lifetime is starting to sound like a low estimate. Our actions have real consequences. That’s a sobering thought, but also an inspiring one.
Ohio in the early 90s had few educational options for a middle schooler interested in computers. But when there’s a will (and willing parents, thank you) there’s a way. Somehow I got signed up for a correspondence course in Pascal in 8th grade. Yes, an actual class where I never met in person (and only rarely spoke to the teacher on the phone). Where the majority of exchanges were via the good old fashion United States Postal Service. Where code had to be printed out, mailed, marked up, and mailed back (how’s that for slowing down rapid iteration!)
Despite it seeming painful to modern ideas of remote learning, the material was quite useful in my overall development. Up until then I was completely self-taught; reasonably good in BASIC and some rudimentary C. Learning Pascal, however, really opened up a new world. And luckily for you all, I still have a number of my Pascal programs, which I recently uploaded to Github for your browsing pleasure. Here’s the good stuff that awaits you:
MARKET.PAS – This one’s special for two reasons. First, it’s the oldest of all these files, with a last modified date of Dec 6, 1992, making it the earliest example of code I wrote that I still have in digital form (the absolute oldest being this handwritten BASIC program from 1987). And second, it was my attempt to implement the Stock Market Game, a board game from the 1970s that my mom and I played together when I was a kid. No one else in the family ever wanted to join; it was kinda “our thing” (as was Scrabble).
GRADE.PAS – A simple gradebook app for teachers. I believe this was the final project for my correspondence course.
CYBER.PAS & CYBORG.PAS – Today you couldn’t pay me enough to get into video game development, but as a youngling I had a thing for trying to build them. This code is a tiny step towards what looks like a side-scrolling shooter involving robots and lasers.
KARATE.PAS & KGRAPHIC.PAS – Another game effort, this one a fighter like Mortal Kombat, but with stick figures, because I am terrible at visual art. Pretty sure I got it to a reasonably playable state, though the mechanics were terrible and it required two people because there was no AI to speak of.
JDNCRYPT.PAS – Built this encryption tool to protect DIARY.TXT, which I still have (but no, I’m not gonna share it). Basically I reinvented a simple rotation cipher using an insecurely predictable pseudo-random number generator, with an easily bypassed magic parameter kill-switch on the executable. How cute. Rule one of cryptography: never ever write your own.
GAME133.PAS – In college a mathy friend of mine and I got really into the Number Jumbler. I wrote this solver to do research into combinations that had no solutions. Two years later when I started my first real job, I was tasked to learn Ada, and as part of that effort I ported this solver.
FYI, in upcoming posts I intend to expand on my personal tech history; including a visual history of my computer setups. Will it be of interest? Maybe! But I’m going to do it regardless.
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.
(Editor’s note: the past two posts, Mother Of Invention, Edge Case, and this one form a trilogy of sorts, all related to a particular project I’ve been digging into).
When I first needed a way to get access to AWS from a non-cloud-based computer, I implemented 3 options: hard-coded IAM user credentials (generally bad), user-based Cognito (okay but not super scalable), and X.509 via IoT (good technology, but cumbersome to set up).
This week I had a similar authentication need within an on-premises cluster, and was happy for the chance to learn the most up-to-date approach: IAM Roles Anywhere. I really appreciate the authors of these two blog posts who captured the step-by-step quite a bit better than the official documentation:
I used my own certificate authority because AWS Private CA is too dang expensive; $400 a month doesn’t grow on trees, ya know? Here’s the bash script to create the root CA:
mkdir -p root-ca/certs # New Certificates issued are stored here
mkdir -p root-ca/db # Openssl managed database
mkdir -p root-ca/private # Private key dir for the CA
chmod 700 root-ca/private
touch root-ca/db/index
# Give our root-ca a unique identifier
openssl rand -hex 16 > root-ca/db/serial
# Create the certificate signing request
openssl req -new -config root-ca.conf -out root-ca.csr -keyout root-ca/private/root-ca.key
# Sign our request
openssl ca -selfsign -config root-ca.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext
# Print out information about the created cert
openssl x509 -in root-ca.crt -text -noout
The output from the above is what’s used to create the Trust Anchor. Then here’s a script to create a certificate for the process that will be authenticating:
# Provide a name for the output files as a parameter
entity_name=$1
# Make your private key specific to your end entity
openssl genpkey -out $entity_name.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
# Using your newly generated private key make a certificate signing request
openssl req -new -key $entity_name.key -out $entity_name.csr
# Print out information about the created request
openssl req -text -noout -verify -in $entity_name.csr
# Sign the above cert
openssl ca -config root-ca.conf -in $entity_name.csr -out $entity_name.crt -extensions client_ext
# Print out information about the created cert
openssl x509 -in $entity_name.crt -text -noout
Special thanks also to the creator of iam-rolesanywhere-session, a Python package that makes it easy to create refreshable boto3 Session with IAM Roles Anywhere. Seriously, could it be easier?
This was a good reminder that technology marches ever onward, and what made sense yesterday might not be the best approach today. It was also a reminder that, like DNS, TLS and PKI are some of those things that every technologist ought to know (I’ve queued up this book in my Goodreads for a deeper dive). This isn’t the first time I’ve had to write code to create certificates, but it’s now the last, because I’ll have this reference post plus its associated code repository. And so will you.
Good technologists stress the importance of capturing information in written form. Examples are myriad and diverse: design decisions, code comments, commit messages, operational runbooks, and performance feedback, all of which benefit from being documented for future reference. In this post I want to suggest another data set worth capturing: your work history and professional accomplishments.
Sometimes referred to as a brag document, and much more than just a résumé, a complete log of your work can serve you in several ways. It’s useful to provide to your manager and other leaders during performance reviews season, or to make a case for a promotion. When it comes time to search for a new job, you’ll be prepared to recount your experiences in detail, and provide concrete examples to questions (a post for another day, but good interviewers love specifics). And when you’re discouraged about your future or feel like an imposter in your present, you can review your past successes and remember that you belong.
No amount of detail in your brag document is too much. Start with the what and where, and be specific about your role in the work. Add artifacts wherever possible, such as public links to code, articles, blogs, press releases, or anything else you can think of. Don’t have public artifacts? Make some if your situation allows. I even collect screenshots/photos if they’re not proprietary, or if they help me remember the people that contributed to successes.
Speaking of which, including information on who, when, and why are also critical (and easy to overlook). No one cares about technical minutia if the work didn’t make a difference. Write down the difference you made! Metrics are best (e.g. increased sales, more users, faster response times, people helped), but anecdotes work too. Capturing timeframe is useful to understand context when relating to other work. And documenting who you worked with is useful for multiple reasons: one, it ensures you remember a network of folks who can vouch for your work should you need it. And secondly, it provides context on the level that you were operating at within your organization. This was one of the tricks we Amazon Bar Raisers used to suss out a job seeker’s influence: were they talking regularly with customers and other stakeholders outside their immediate team? How far outside? And were they peers, managers, directors, executives? This context was directly applied to leveling decisions.
Capture your work log in situ. The longer you wait, the less likely you are to remember correctly (“the strongest memory is weaker than the weakest ink” as my childhood pastor used to say). Having a regular cadence can work well. Friday afternoons especially so, as that’s a great time to reflect on your weekly accomplishments.
It’s not just you that’s likely to forget if you wait too long, but so will others who can provide feedback on your work. Few things are more powerful in a brag document than actual quotes from project stakeholders. It can feel awkward to ask, but get over yourself and do it. Ask for both the good and the bad, accept it gratefully, and save it away alongside the rest of the details about a project.
“the strongest memory is weaker than the weakest ink”
If you’re just starting out, don’t overthink the arrangement of info in your brag document. Pick a tool and get started. Especially don’t wait for a manager to do this documentation work for you; career development is your responsibility first, and besides, they probably don’t see nearly as much as you do (doubly true in the age of remote work).
Eventually your document is going to need some organization. The objective is to tell a coherent story that captures the reader’s interest. Chronological order is probably the easiest, and can work if well if you have a mostly linear career progression. Clustering activities by industry or domain packs the most punch if you’re trying to make a case for your expertise in a specific area. Ordering accomplishments by impact, with most impactful first, is a great way to highlight the value you can bring. If you’re building a case for a promotion, you should consider aligning your document to the next-level role guidelines provided by your organization (and if you don’t have such guidelines, ask for demand them).
Finally, I suggest keeping two versions of your work accomplishments. One internal to your current employer that has maximal detail, and one you keep personally, edited down to comply with any non-disclosure or confidentiality requirements you might have. The latter is the perfect source for résumé material when needed.
Klaus Teuber died this week. His career began in dental hygiene, but by its end he’d designed one of the world’s most influential board games, The Settlers of Catan. I learned it about 20 years ago from a college buddy, and right away fell in love with its balance of strategy and luck. Enough of the former to make it interesting, enough of the latter to appeal to a broad audience. It also requires deft handling of social dynamics through alliances, trades, and the occasional threat.
It’s hard to overstate the influence this game has had on my life. Quick games of Catan formed early bonds between myself and my wife during the stress of having young kids. When we moved to San Diego it was a vehicle to make new friends in an unfamiliar area. And it’s been a staple of family game night since my children were in middle school (I still remember exactly where we were when we taught them to play for the first time). The above photo is from a game played just last night (I’m green, and I won with 4 cities and longest road).
I once read that a typical person will have a direct influence on 10,000 others over the course of a lifetime. No idea if that’s true (or what “typical person” could even mean), but the point remains that whatever influence we each have, it’s likely larger than we think. Certainly Klaus Teuber had no idea that his game would affect me and my family so positively. But I’m thankful nonetheless.
When I die, it won’t really matter what systems or organizations I’ve built, but it will matter how those systems and organizations have influenced the people involved, and promoted human flourishing more broadly. My tools are technology, but they’re not the goal.
Last month, my post on layoffs got 113 views in one day. I suppose that’s what passes as “going viral” around these parts. While I certainly wouldn’t mind more readers, I’m okay with my current reach.
How does that square with the principle of thinking big? The common way of considering scale is quantity; it’s certainly the easiest to measure. But one can have an outsized impact in quality without needing large numbers. Think of it like big in depth vs big in breadth. When it comes to technology I embrace breadth, but when it comes to impact, I value depth quite a bit more. And sometimes to get that result requires thinking small.
On my desk is the following photograph by Eric Peters. It captures my objective well.
Speaking of things on my desk, perhaps I’ll document my setup in a future post. That could be fun.
I’ve also successfully written on this blog at least once every month, another of my resolutions. This is my 31st post, so I’ll finish the year no worse than averaging 2.5 posts a month, a pace I’m happy with.
However, I haven’t ended up learning a new programming language this year, my other resolution. And that’s okay. Not because ChatGPT stands to replace coders soon (spoiler: it won’t), but because while goals should be SMART, they needn’t all be actually achieved. The goal of resolutions is not absolute completion, but inspiring yourself to accomplish something. To move the needle positively for your life. To take a step towards become a fully flourishing human person, as Christian Smith would say in the book I just read (echoing Aristotle 2300 years before him).
While each goal in and of itself should be achievable (the A in SMART), in aggregate they should be aspirational. When discussing goal setting with my team, I want them to define enough goals for themselves that it’s likely there’s one or two they won’t complete. Otherwise they’re not thinking big enough.
