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.
Hard to believe it’s been 3 years since I started taking AWS Certification exams, eventually passing all 12 that were active at the time, thanks in part to virtual proctoring and a knack I’ve had since college for being good at multiple-choice tests.
In order to stay current one must retake the exams within a three year window, so I’ve been working my way back through them. Over the summer I passed Solutions Architect Professional and DevOps Engineer Professional, and yesterday I completed the Security Specialty. Thanks to lower-level exams auto-renewing when professional exams are passed, that brings me to 7 exams that will remain current through 2025.
Seven is a nice number; don’t think I’ll bother renewing the others unless a need arises.
For the first one, so far so good. For the second, not so much. I read a book on Clojure, but haven’t yet had a reason to use it beyond tutorial exercises, so can’t really say I’ve learned it. Maybe it’s just that these days I’m thinking more about systems than software, and thus language choices seem less important?
Speaking of book reading, though, I’m well on my way to achieving my meta resolution (to read the same number of books as my age, every year, for the rest of my life). According to Goodreads I’ve completed 39 books so far against a goal of 43 (seven books ahead of schedule). Should be no problem to get to the finish line and beyond.
Honorable mention goes to Range, which I can’t recommend enough for anyone who feels like they’ve missed out on their calling by meandering through a number of life experiences. Generalists make the best leaders and problem solvers, so embrace the variety of perspectives you can bring to the table. Real life is not like golf or chess or programming only in assembly.
Back in 2014, I read The End of Men; having just been hired by a startup run by a woman, it felt like a good time to explore ideas about why men have traditionally dominated positions of power, and how and when that might change. I don’t remember many details about the book itself (and apparently it’s somewhat controversial in conservative and progressive circles alike), but I do remember coming away challenged to do my part in centering women as I moved forward in my career.
Fast-forward to this past week, during which I happened to have many interactions with female colleagues:
Two women presented a dashboard on team performance metrics to our team
I got career advice from the female founder of a major cloud consulting company
Three times I met with various female peers to discuss leadership transition opportunities
I provided coaching to a woman just beginning her career in technology
I partnered with a woman to conduct four back-to-back interview sessions
While there’s still more work to do to undo historic inertia, realizing that I’m surrounded by so many capable women from whom I can learn is an opportunity I hope only gets less rare.
