As a tech discussion grows longer, the probability of a mention of Generative AI approaches one. It definitely happened at today’s 4S Tech meetup; we didn’t even make it all the way through the introductions.
Additional common topics: biometrics, productivity hacking, ways to get funding, something someone heard on a podcast.
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!
If I had one minute to evaluate a job interviewee, I’d put a piece of writing in front of them (either code for a developer or prose for a less technical person) and watch them type it into an editor in real-time. If they are able to do so quickly and with few errors (for some values of quick and few), they pass.
This is completely unfair, and heavily biased towards certain privileges; many otherwise excellent candidates would be missed. But as a first-order approximation, I’d be willing to wager it works more often than not.
Speaking of persisting, there’s two books I’d recommend on the topic:
While targeted to traditional artists like writers and musicians, both have much to say about broader creative activity, within which technological work definitely falls.
P.S. If you’re short on time, you can find a selection of extracts from the latter book in this article: How to Fall in Love with Hard Work.
P.P.S. I almost didn’t write this post because both these books have considerably mixed reviews on Goodreads. But I decided to take their advice, post anyways, and let the reader decide. How meta!
Yesterday we held the inaugural 4S Tech meetup. In my book it was a success, with 8 attendees (including myself), and a nice mix of founders, CTOs from both small and large companies, engineers, and even a person from a venture capital firm. The conversation ranged across a number of topics: how to start a company, dealing with founder fallout, mid-sized opportunities that often go unnoticed, dealing with tech FOMO, and of course, generative AI. I know I had a good time and learned a few things, and given that everyone stayed the entire 2 hour allotted time and beyond, I’m guessing the others did too.
I’m already looking forward to doing it again next week. Can we keep the momentum going? I certainly hope so; if you’re in the area, consider joining us: Thursdays 2-4pm at Mostra Coffee in 4S Ranch.
Back in June, I reflected on the importance of professional friendships, and teased that I’d have more to say “soon” about it. Well, the day has come (and yes, I realize to some, a six week delay might not feel like soon, but in programmer terms, I think I delivered pretty quickly).
I’m excited to announce the launch of 4S Tech. It’s mission is to cultivate a community of technical leaders who live in 4S Ranch though encouraging them to get to know one another, discover each other’s work, and share ideas for collaboration.
Our meetings will begin on August 24 and every Thursday after that from 2-4pm. If you’re anywhere near the area, I’d love to have you stop by for casual conversation, networking, and co-working at the terrace outside Mostra Coffee. They also sell beer if that’s your thing, and there’s a number of other food and drink options nearby if you want to hang longer.
If you’ve got any questions or ideas, please let me know. Here’s to establishing connections!
When I was laid off back in early 2019, my emotions ran the gamut from sadness to fear to anger. That isn’t terribly surprising. But one feeling caught me off guard, and it took me a couple weeks of unemployment to name it: loneliness.
It’s not as if I was truly alone; I still had my family, who are awesome, and friends I saw regularly. But so much time is spent with coworkers, time that requires no planning or effort in the way that maintaining other friendships requires, that inevitably colleagues become a significant slice of a person’s social circle, and when that’s suddenly taken away it can be a shock.
While not as acute, there’s a similar feeling when a job is left voluntarily. As soon as word got out about my departure from my previous job, even though I was sticking around for a couple weeks to ease transitions, my interactions with coworkers changed, an unspoken realization that further investment in these relationships had limited value. “Let’s stay in touch” is a common refrain, but to do so takes effort that usually doesn’t get made. No matter how strong the connections may seem (and given the nature of things like mutual goal pursuit and shared trauma, they can feel quite strong), once the bond of shared employment and daily interaction is broken, that’s usually the end of it.
Nevertheless, I truly value the “work friendships” I’ve had during my career, even if they only last for a season. I was enjoying an afternoon coffee a while back reflecting on this topic, and a wave of nostalgia hit me hard enough that I decided to do something about it, sending out a bunch of LinkedIn “hey how’s it going?” notes and planning a happy hour get-together for former employees of the startup I worked at from 2014 to 2019. The latter happened this past week and it was delightful catching up with folks, most of whom I hadn’t seen in years.
Besides the upheaval that comes with job changes (voluntary or otherwise), the nature of work friendships are changing thanks to remote employment. I’m a big fan of ditching the commute and having a flexible schedule, but it does comes at the cost of the communal benefits of an in-person office. For many folks social circles are shrinking (see Bowling Alone for a deep dive on this phenomenon in America); not going to an office isn’t helping.
The above has me thinking about alternatives ways to help people fill this gap, tech people in particular, and tech leaders especially, since their potential for loneliness is compounded by being in positions where they can’t be completely transparent with the majority of their colleagues. More to come on this soon.
When I joined Amazon Web Services in the fall of 2019, I wanted to validate the experience I had through AWS Certification. It become something of an obsession, and I ended up passing all 12 exams within a year. I got frequent questions about this experience, enough that I developed a talk that I gave at a couple internal conferences, and once at re:Invent. This post is my best attempt to capture what I said there, plus some additional information that might be of interest to anyone seeking to up their cloud game.
Why?
The first question I typically get is a variant of “Why did you pursue AWS certifications?” And that’s usually followed-up with “And why so many of them? Did you actually absorb any of that information?”
There are plenty of places to get boilerplate answers to these questions, such as Benefits of Being AWS Certified and Four reasons you should pursue AWS certifications. For me it boiled down to wanting the broadest possible exposure to AWS services. Certifications were not the end of my cloud learning journey, they were the beginning of it. I’m a breadth person; my goal was not to get hands-on experience with everything, but rather to get high-level understanding so that I could apply the technology to customer problems. I also wanted to be able to have public verification of the skills I already had.
Is there also a depth benefit to certs? Yes, but the study approach is different than the one I present later in this article. You’ll want to focus more on hands-on workshops and less on purely information intake. Neither approach is better or worse, they simply have different end objectives.
Who?
Another common question is “Who should get AWS certified?” I’m admittedly biased, but given they’re relatively inexpensive and can only benefit one’s career, I tend to say yes to just about everyone who works in or around the cloud:
How?
Hopefully by now you’re convinced, so the next question is obvious: “How can I decide which certification(s) to pursue?” There’s decent guidance in the AWS Certification Paths brochure (which I like to take some credit for, as I both recommended its development to the Training & Certification team back at re:Invent in 2021, and consulted with them on its content), but I’ll add my two cents here as well.
Cloud Practitioner is the foundational exam, appropriate for anyone who wants to beef up their AWS knowledge no matter their role. Even for folks that already have cloud experience, I recommend they take this first just to learn the logistics of the exams. Lean into your bias for action here and just do it; at the time of this writing it’s only $100 and there’s no consequence for failing (which is true for all the exams).
After that one, I think Solutions Architect Associate is the best next step, as it’s a great introduction to solving problems on AWS. For technical folks especially it’s my first recommendation, and for non-techies who still need to hold their own in a cloud conversation it’s a perfect stretch goal.
From there, it starts to depend on role, but for those who have to wear a lot of hats the aim should be either Solutions Architect Professional or DevOps Engineer Professional (ideally both), and to prep for them there’s value in picking up SysOps Administrator Associate and Developer Associate as study guides. The material builds on itself, but be aware there’s a considerable jump in difficulty between the associate and professional exams.
Because passing an exam earns you a coupon for 50% off your next one, completing all the foundational, associate, and professional exams can be done for as little as $625. That’s not a large investment to pick up highly marketable certifications.
The specialty exams are different in several ways. For one, they contain much more completely new material compared to the way the professional exams build on associate exams (with one exception: if you have all the general certs, you’re 80% of the way to getting the Security Speciality). So if you’re a novice, expect to invest quite a bit more study time. I can’t really recommend any of these over any others unless you either 1) have a specific interest area, or 2) have completionist compunctions like me.
Fun fact: Advanced Networking Specialty is the only certification exam I’ve failed. It took a month of pretty hardcore cramming to get it passed the second time around, and I came away with a new respect for networking engineers. There be dragons.
When?
Once you have a certification identified, the next logical question is “When should I schedule the exam?” My hot take is to take a best guess on prep time, pick a date that works for you, and get registered.
(Quick aside: I strongly recommend creating your certification account using a personal email address, so that your certifications easily follow you if you change jobs. There are ways to fix this later, but it’s a hassle).
Actually forking over the money and scheduling a date and time will force you to get started. I’ve seen too many “good intentions” fail here due to over-cautiousness or indifference. Just do it! For one thing, you can always reschedule later. Second, as I said earlier, there’s no consequence for failure (other than a 2 week cooldown period before you can try again). Treat it as an investment to see where you’re at. If you don’t pass, at least now you know where you’re weak. And if you do pass, then you’ve passed, no more studying required! All considered, it’s the frugal choice.
If you want a rule of thumb for prep time, here’s my suggestion:
If you literally have no idea how ready you are, taking a practice exam is an excellent evaluative tool that you can do right now. AWS made these free last year, just go register on Skill Builder and you’ll find them. They’ll provide you much helpful context on areas you’re strong in, and areas where you need to do more studying. Since there’s now no cost to taking them, there’s no excuse not to just go try them out. Don’t think you have to prepare to take a practice exam; that’s backwards. Let the practice exam results guide your preparation instead.
Where?
Once you’ve got your timeline to an exam, it’s time to answer “Where can I find the best possible preparation materials?” Naturally Google and ChatGPT have a variety of suggestions here. Too many. The metric that matters most here is “density of relevant knowledge per unit of study time”, and while I acknowledge people learn differently and everyone’s needs are different, my opinions here are based on my own considerable experience. Take them with a grain of salt, but only one…
When it comes to high value tools, my number one suggestion is to read AWS service FAQ pages. Most services have one, and they are written at just the right level of detail to be applicable to certification exams. They’re the nutrient-rich superfoods of certification study materials; nothing will get you up-to-speed faster. When I was in the midst of my test-taking prep, I would keep a dozen or so FAQ pages open in my phone’s browser, and instead of mindlessly doom-scrolling on social media, if I had a few minutes I’d read (or re-read) one or two of them.
To give you an idea of their effectiveness, when I re-certified my professional exams earlier this year, the only prep I did was to re-read FAQs across a couple dozen services, and I passed them both with equivalent or higher scores than I did three years ago.
Each certification has a guide that lists the AWS services covered on the exam. Take a look, find the FAQs, and dig in:
Another excellent resource are the courses on AWS Skill Builder. Many of these are also free, and $29 a month unlocks a bunch more. Each exam has a corresponding “readiness training” that is well-worth the few hours investment it takes to complete. And check out the ramp-up guides if you need a plan structured around job role, solution, or industry.
If more in-depth course material is needed, I’m a fan of the A Cloud Guru video courses: they’re comprehensive, well-produced, easy to navigate, and a subscription is reasonably priced. A number of them also include hands-on exercises.
While I’m not here to criticize quality, or tell people what ought to work for them, there are certain resources I found less helpful when “value per time unit” is considered.
The first is books on the certification exams. Besides taking focused time to read versus a video which can be put on in the background (something I did often when doing other activities like laundry or dishes), books age quickly. I also found their content of middling quality compared to more official sources. They’re not cheap either when compared to the broad value you get from a subscription to Skill Builder or A Cloud Guru.
AWS whitepapers, while interesting and educational, are also not a terribly rich source of certification-related knowledge. I contributed to a few whitepapers in my time at Amazon, so it’s not that I see them as valueless, nor am I biased against them. There are simply better ways to spend your time.
Finally, I discourage endless grinding on practice exams. I mentioned earlier that these exams are great evaluative tools, but their value drops significantly with repeated attempts. There’s little sense in taking a ton of them in the hopes of encountering (and memorizing) every possible question. The official ones are not comprehensive enough, and the other practice exams you can find online are of questionable quality (if not blatant rip-offs of superior material). Ultimately such an approach won’t give you the synthesis skills necessary to answer questions not previously seen, and that’s not a winning formula.
What?
The final question now becomes “What can I expect the day of the exam?” Back in 2020 I wrote about the online experience, so if you chose that option I’d encourage you to read through it; everything there still applies. The in-person option is a pretty standard thing; you sit in a room with a bunch of other people taking tests at standalone workstations, with a person monitoring the group.
I’ve done both, and mildly prefer the online choice, but I have some privileges that make it easier (e.g. a quiet space I can have to myself, a personal laptop, reliable Internet). There’s no cost difference, so do what’s right for you.
In either case, standard testing best practices apply. Get a good night’s sleep, get enough to eat beforehand (food and drink are prohibited), and plan some downtime both before and after the exam, because your brain will be tired (some of these exams can last up to 3 hours). Speaking of, absolutely don’t forget to go to the bathroom right before the test. Your mileage may vary about whether an in-person proctor will let you step out to use the restroom, but it’s forbidden when taking the test online.
It used to be that you got your results immediately after finishing the exam, but nowadays there’s some anti-fraud analysis that’s done, and you’ll get an email the next day. If you passed, congratulations! On to the next exam. And if not, no harm no foul; take a couple weeks to redouble your study efforts, and register again.
No matter what happens, I hope you take joy in learning about some of the world’s most powerful technology. If you do, thank the good folks on the AWS Training & Certification team for all the work they’ve put into developing many of the resources I’ve shared here. I certainly am grateful.
(I seem to open a lot of blog posts with variations on “I’ve written before about X.” Here’s another one).
Back in 2017 I wrote three posts in a row about the tension between giving users what they want and guiding them to what is best. They came to mind this week when I ran up against on of terraform‘s more annoying (lack of) features: the inability to apply changes on a per file basis. I absolutely understand why it’s not supported, but sometimes it’s a quick and dirty way to keep moving forward, and dang it, I needed it!
After a day of annoyingly overspecifying --target flags in my commands, I rolled up my sleeves and built a wrapping script that would do the work for me, essentially adding a --file flag to the CLI. I share it here as a service to the Infrastructure-as-Code community. Usage is easy:
terraform-files apply --file my-infra.tfIt’s hacky as heck, so use at your own risk, your mileage may vary, etc etc. And if you want to make it better, revisions welcomed!
In the past several months I’ve been making efforts to do more networking with technologists. One avenue to do that has been joining a couple Slack workspaces (Rands Leadership and All Tech Is Human, specifically). A few days back a conversation topic was the difference between unit tests and integration tests; a topic on which I definitely have opinions.
As part of the discussion I came up with the following distinction, which I liked enough to codify here for posterity:
Inherent to this definition is some ambiguity, because a single “thing” at one level is multiple “things” at another level. What matters definitionally is the spirit of a test: is it trying to test one thing or multiple things. If the former, it’s a unit test. Otherwise it’s an integration test.
For what it’s worth, I’m a much bigger fan of the test diamond than the test pyramid. The ratio of “amount of stuff tested” to “effort required to write tests” is so much higher when writing integration tests. And they (typically) test at the “actual business functionality” level, vs at the “does this code do the thing” level. And value is all that matters.
On a tangential note, I developed another type of test diamond a couple years back. It was initially designed when evaluating taco shops along Poway Road in San Diego, but it’s applicable to just about anything you want to rate. I leave the interpretation of the diagram as an exercise for the reader (the ambiguity is a feature, not a bug).
