The other day I scanned and posted a gift I’d gotten from some co-workers. When leafing through the folder it was in, I found a few other fun artifacts I thought I’d share:
First, a certificate I got from my fourth grade teacher. It’s an objective I still aim for:
And second, an invite I got for helping support the underlying voting platform:
I’ve tried to do a better job recently of documenting my career experiences, not just the work-related items, but the fun stuff too. This week wasn’t so bad, even if the town isn’t my favorite:
On the same day I wrote about radical responsiveness, I came upon this post that seems to contradict it. I really respect Ethan Evans and enjoy his writing (especially this bit about why you fail to get promoted). And I understand the point he’s making about fragmented attention. The temptation to conflate interruptions with importance is real, and amplified by modern communication technologies. But I’m not prepared to say he’s right and I’m wrong.
For one, I believe it’s possible to be both radically responsive while remaining reasonably non-fragmented. Some degree of interruption is inevitable, but using techniques such as pomodoro can help protect focus while still ensuring important messages don’t get missed for long. Good old-fashioned discipline is required to stick to a plan, but it can be done.
The discipline gets easier with a well-configured set of tools, which is where many folks fail. Learn your tools! And not just the basic features, but the myriad of options for managing notifications, filtering messages, scheduling reminders, etc. It’s not a badge of honor to be “bad at email” or “not understand Slack” if you’re a professional in 2024.
(If any of my coworkers are reading this, they may quickly point out that as recently as last month I didn’t know how to join cell phone calls into a conference. Which… is true. But I learned! And now I know for next time).
Finally, Evans makes an assumption about communication that I don’t believe holds true. It comes through most obviously in this statement:
“Allow chaos to build up within the trivial (the inbox) to accomplish the meaningful.”
Did you see it? The assumption that messages in an inbox are trivial? Tell that to your customer who is informing you of a serious issue with your latest release, or your team member whose employment status is in jeopardy if you don’t respond to their immigration lawyer. Yes, we all get spam, but sometimes interruptions truly are critical and need attention. To lump all of that into the category of “trivial” for the sake of personal flow is a leadership fail. Communication is part of the job; sometimes it’s all of the job.
Of course, I could be wrong. Read the posts and decide for yourself.
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.
There’s nothing like an effort to make sure all my years of accumulated data is backed up to kick up some nostalgia (not to mention an impending birthday). I doubt anyone else much cares, but this is my website and I’ll fill it up with digital relics from my past if I want to. Consider this fair warning.
We’ll get things started with this beauty, which I wrote September 24, 1992, if the file’s timestamp can be believed. Over 31 years old, it’s the oldest digital document I can find that I wrote myself.
I do not like to go to school. All the teachers do is teach you things you already were taught in 5th grade. That is, except for math and computer class. In math, we learn all about neat things, like 3y2+4(2x3+4). Mr. Farley is a great teacher, and the other teachers should teach like he does.
In computer class we learn about computers, such as this one, and about different computer programs. That is really neat for me because I enjoy working with computers, although some kids are really dumb when it comes to computers. But it is not like English, which is the same every single year. BORING!!!!!
I suppose that Science is O.K. Mr. Freese is pretty cool, and we learn some new stuff, and some old stuff. Like the scientific method. We learned it in 7th grade, and we learn it again now. It doesn’t make any sense.
This is my story about school. I hope that someday teachers will be able to read this and learn from it. Although they won’t listen to the small ideas from a thirteen year old boy, maybe they might get ideas anyway.
For the tech nerds, the file was in WordPerfect format (which definitely squares with the technology I was using in 8th grade), and opened perfectly on my Mac using LibreOffice.
So you want to become (or have been told you now are) a technical team lead? Awesome, congratulations! You’re in for an excellent adventure. But if you’re wondering where to begin, and what’s going to change, lucky for you I’ve been there myself, helped several others through this transition, and have captured some lessons you can apply:
First, make sure everyone on the project knows you’re the technical lead. This isn’t about ego or power, it’s about clarity of function and accepting responsibility. With that comes the need to be responsive; availability for conversation is now part of your job.
Next, get to know the team personally and earn their trust though human connection. You cannot be everywhere all the time, so you need people who are comfortable coming to you with challenges both technical and otherwise. If there are folks involved external to your organization this is doubly-important. Identify a go-to person on that external team and engage with them regularly one-on-one.
Get to know the team professionally as well. What are each individual’s strengths and weaknesses? What technical skills do they have, and what parts of the system need those skills applied? What are their communication styles and ways of being motivated? Personalize your approach with everyone; it’s your role to put them where they can thrive, which in turn maximizes collective success.
Have a generalist mindset. Get to debugging level competency across the entire tech stack, no excuses. You don’t need to be the best at everything, in fact you shouldn’t be, but you should know what good looks like so you can ensure it’s happening.
There’s one area, though, where your knowledge should be unrivaled, and that is understanding your customer and the business case you are there to solve. Get familiar with their requirements and deadlines. Stay connected to your stakeholders, listen, ask questions, and then push their objectives down to the people in your charge. Once again, this is especially important if there are subcontractors who have a limited view of the big picture.
Make yourself present in meetings, erring on the side of being overly-present (especially at first). Requirements gathering session? You gotta be there. Sprint planning and backlog grooming? Not optional. But that deep dive on a bug or tricky technical problem? Maybe let your tech experts handle it, or at least have them gather the data and come to you if they run stuck or need a decision.
Speaking of decisions, apply wisdom to the ones you can delegate and ones you cannot. Specifics will vary project to project, but in general the more reversible a decision is, the less important it is you make it. Another rule of thumb: as soon as you know how to do something well, it’s time to teach someone else to do it, while you take up the next challenge no one else is equipped to solve. Fail at security and you fail full stop, so keep your eyes on anything that could jeopardize it.
High level architecture and technology choices will matter more in the long run than anything decided in a code review, so keep your nitpicks to yourself. Speaking of code reviews, their value mostly comes in peer to peer cross-checks. If you think you have to approve every line of code yourself, you’re doing it wrong. Treat your attention like the precious commodity it is.
Your good intentions of ensuring quality code and other deliverables won’t be enough. Establish quality mechanisms: automated linting and security scans. Automated testing. Continuous deployment. These are your eyes and ears, and more important for you to establish and monitor than you building features.
Take failure personally. Things will go wrong; the minute you blame those under your charge, you’ve lost. Instead, turn your gaze inward to what you could have done better. When you hold yourself to the highest standard, it calls others to do the same.
Finally, don’t stop listening and learning. Get feedback, even when it’s hard to hear, and act on it. Also, there’s tons more out there on being a tech lead, go do some searches and read up. Perhaps you’ll even (gasp) find counterpoints to my above arguments. That’s great! Ultimately you’re a technical lead to serve and empower, and that requires judgment on when to follow the rules and when to toss them and do what’s gotta be done, because no job is below you. Be the person who brings the coffee and donuts, orders the pizza, serves the drinks, and cleans the conference room afterwards.
Sound hard? It is. It’s gonna take a different set of skills and a significant amount of time. You’re going to have to let go of some things you’re used to doing and some things you’re good at (and probably enjoy doing) to find that time. But when a team you’ve led accomplishes more than you could ever do on your own it’s a unique kind of reward.
It was six months ago now, but I clearly remember the feeling of sitting with my AWS laptop on a Friday morning, knowing it was the last time I’d use it. There’s a surprisingly emotional bond that develops between a technologist and their equipment; I was genuinely sad about turning it in. But handing over the hardware wasn’t the worst part, it was knowing that every digital file I’d created on that laptop would be erased, thus anything I hadn’t transferred to someone else or otherwise handed off for preservation would be gone forever: every half-completed business idea one-pager, all my customer presentations, any little code utilities I’d built. Everything. Four years worth of accumulated artifacts is no small thing, and I didn’t want to see it disappear.
I was in this same situation back in 2014 when I left my first job, and at the time, for confidentiality and security reasons, I’d done nothing I could publish publicly or otherwise take with me. That was unfortunate, and I didn’t want to repeat that disorienting experience. Thankfully during my AWS tenure I’d taken steps to release whatever I could via open source mechanisms. And what I couldn’t directly publish, I’ve tried to capture after the fact on this blog, including this post on how to approach certifications (reconstructed from a talk I gave at an internal conference), my advice on brag documents (also from a talk), and a process for doing project estimation (rewritten by memory from a team wiki page).
Don’t make the mistake I did and wait until the 15 year point of my career to take these sort of steps. And don’t wait until you’re at the end of your time at a company either; like documenting your accomplishments, archival work is best done in real-time. Embracing open source development can help, even more so if your employer is onboard. Push them if you need to (you can find some talking points in this excellent article).
A final argument: continuous improvement is predicated on retention. “Those who cannot remember the past are condemned to repeat it” applies not just to history, and the DRY principle applies across both spatial and temporal dimensions. Or even more simply: save your work!
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.
Pro Tip: When creating a piece of code or infrastructure that you only need for a short period of time, mark it as temporary, and ideally include a date after which it’s safe to delete. That way in the future, if you forget to delete it yourself, when some person comes across it, they know it can be cleaned up without risk.
This is doubly important if the temporary thing you’ve made opens up a potential attack vector. The canonical example is adding remote IP addresses to a security group, which I had to do just today:
I view the above as a corollary to the Shopping Cart Theory. The world thanks you for your service.
For the first five years of my career, I worked for a defense contractor located on-site at an Air Force research facility. My job was to write software, but the lab had quite a bit of hardware as well. Over time, things could get pretty messy as we were regularly reconfiguring the setup, leaving random cables and parts strewn all over the place.
We must not have been unique in this, because about half-way through my tenure there the powers-that-be started a “tidying up” initiative that everyone was required to participate in, up and down the ranks, including uniformed military, civilian, and contractors. Being already something of a neat freak, I bought some split loom tubing (from Parts Express, my absolute favorite source for A/V parts) and used it to bundle all the cords at my desk. Apparently I’d done such a good job that word got around about my setup, and one afternoon the person at the top who’d launched the cleanup initiative stopped by and thanked me for my efforts, and said my desk was the example that others in the building should emulate.
Ever since I learned proper cable coiling technique I’ve enjoyed keeping areas with many of them as neat as possible, ideally with none of them visible. Today I was happy to do so in my wife’s classroom, including installing a light strip since the cubby where her desk lives is in a poorly-lit corner.
I didn’t need much nudging to do this; now the drive to tidy cables is a bit of a compulsion. If I ever see random ones laying about (such as on a conference room table), I’ll coil them out of habit. And if I ever see someone doing it wrong you can be sure I’ll have something to say about it. Yes, there is a right way, and it’s easy to learn with a bit of practice, so no excuses.
