Routinely Solicited Inquiries

Routinely Solicited Inquiries

By | | Comments 0 Comment

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:

  • Technology professionals specifically tasked to build in AWS? Obviously.
  • Software engineers who might be called upon to do cloud things, and should know what’s out there so they don’t inadvertently re-create the wheel? Definitely.
  • Tech adjacent folks like product / project / program managers and salespeople who want to be able to hold their own in cloud-related conversations? Can’t hurt.
  • Executives whose companies heavily utilize the cloud? Why not?

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’re reasonably confident, schedule it ASAP. Seriously, right now. I’ll wait.
  • If you just need to do some brushing up, 1-2 weeks of prep should be fine.
  • If you’re starting from zero, budget 4-6 weeks for foundational tests, 6-8 for associate-level, and 10-12 for professional exams.

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.

It Figures

It Figures

By | | Comments 0 Comment

Since becoming a CTO, I’ve had a major uptick in spam, everything from thinly veiled LinkedIn connection requests to blatant direct emails. This one was particularly funny:

Oh Brian, you have a delightful sense of irony. Your products probably won’t solve my unwanted solicitation problem, but your marketing attempt did bring a smile to my face, and for that I thank you. Now go away.

For All The World To See

For All The World To See

By | | Comments 0 Comment

Want an amazing example of learning in public, far more comprehensive than anything I’ve described here? Look no further than the blog of Juraj Majerik, where he chronicles in a 34-part series building an Uber clone from the ground up. No detail is spared in his journey, including setting up automated deployments and detailed monitoring dashboards. I’ve never seen a learning project this thoroughly developed or documented. It puts a number of real products I’ve worked on to shame. And his claim of it requiring about 300 hours is impressive as well, I would have guessed higher.

I tip my hat to you, Juraj. May your example inspire many more to embark on such educational adventures.

Eye Of The Beholder

Eye Of The Beholder

By | | Comments 0 Comment

In My 20 Year Career Is Technical Debt, the author outlines how most everything he’s worked on is eventually deprecated and replaced. It’s a hazard of technical work, where new approaches, frameworks, and solutions are being invented regularly. We’re not building cathedrals that will still be standing five-hundred years from now. At least not in the sense that the stuff of our creation, the ones and zeros, are still going be on a storage medium and flowing through a CPU long into the future (with some rare exceptions).

But that’s not the point. What you build doesn’t matter, it’s all going to end up technical debt (if you’re lucky) or deleted (if you’re not). What matters is the outcomes enabled by what you’ve created, and the relationships you’ve developed along the way. If your code plays a part in improving people’s lives for some period of time, then it’s done its job. And if those around you are better for having collaborated on it, you’ve done yours.

That’s all we can ask for. And it’s enough.

Not Forgotten

Not Forgotten

By | | Comments 0 Comment

Generally speaking, people want to know they’ve made a difference in the world that will outlast themselves. Few occupations have the intense immediacy of potentially giving one’s life for the future of human flourishing than that of the solider. It’s an admirable profession that is worthy of respect, especially for those for whom this potential became reality. However, not many are suited for such work, not to mention ideally the need for soldiers will shrink as societies mature.

Thankfully there are myriad other ways in which a person can approach a career with the future in mind. Last week I read through a number of articles from 80,000 hours, and I have the book of the same name queued up as well. The premise is that our jobs take up a considerable fraction of our lives, likely more than any other activity, and thus it behooves us to think deeply of how to spend that time. That’s hardly controversial, but applying logical principles and data-backed guidance to maximize the future impact can be (similar to discussions around Effective Altruism).

Personally, I find the arguments compelling. It’s why I’ll spend the rest of my time as a technologist dedicated to work in the public sector, and especially in the space of tech and politics. When it comes to maximizing human flourishing, good public policy is critical, and with a shrinking world, the risk of bad policy existential.

Many have died to give those who remain the chance to build this better world. Honored to be among the latter group; don’t intend to let it go to waste.

Wants What It Wants

Wants What It Wants

By | | Comments 0 Comment

(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.tf

It’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!

A Matter of Perspective

A Matter of Perspective

By | | Comments 0 Comment

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:

  • Unit Test: Tests one “thing” (function, module, service, system) in isolation
  • Integration Test: Tests multiple “things” (functions, modules, services, systems) in combination

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).

Slow And Steady

Slow And Steady

By | | Comments 0 Comment

As of today I have a backlog of 49 draft posts going back to 2017. A good chunk of this backlog, especially recently, centers around themes of maintenance, longevity, sustainability, and generally making sure that work outlasts oneself in some form or another. It’s obviously something on my mind.

So when I sit down to write, why do I most often start with something new instead of picking up an old draft? I suspect it has to do with a fresh take being more motivating. For today, that motivation was my completion of the La Jolla Half Marathon. It’s a race I’ve run before, though it’s been six years.

What’s the relevance to the theme that I mentioned earlier? It’s not only that I am still able to run it despite being in my mid-40s, but that I beat my prior time by over 10 minutes (today’s result was 1:56:05). Which means my years of running have created the kind of habits that enable successful long runs with little to no additional preparation (I only signed up for this race three weeks ago, and thus didn’t have much margin to do a ramp-up beyond my normal weekly miles).

Similarly, while I don’t code every single day (nor should I, it’s not the focus of my current role), I aim to do enough programming regularly so that I’m ready to do more if a situation calls for it.

There’s probably also something to learn here about the long-term benefits of keeping systems running that are doing their jobs as designed and continue to provide value, versus continually looking to replatform and rebuild.

In short: maintenance matters.

It’s Never Five Minutes

It’s Never Five Minutes

By | | Comments 0 Comment

There’s no magic method to software estimation that produces perfect results. Nor is it a skill that’s easily taught. For the most part, you just have to start doing it, make a lot of mistakes, and gradually you’ll get better over time.

That being said, here are a couple articles on the topic worth reading:

My own two (or more) cents is that individual task estimates will always have considerable uncertainty, but that can be mitigated by quantity. As long as there’s no systemic bias, the sum of estimates across a set of tasks will become more accurate as the set of tasks itself grows. And any bias that might exist (a tendency to underestimate is most common) can be compensated for by a final multiplicative factor (1.25 is a useful starting point, but can be refined over time).

Further, a diversity of estimates per task also increases accuracy, and directly proportional to the diversity of perspectives brought to it. Have front-end folks contribute to back-end estimates and vice versa; get estimates from both senior and junior level engineers; include people that cut across multiple projects. If nothing else it will promote collaborative conversations.

Here’s a process I use to achieve the above diversifications. It’s most applicable when estimating a project, but could also be used for estimating large features, though it’d be overkill for a single task. It can be done either synchronously or (mostly) asynchronously, and doesn’t take more than a couple hours.

  1. Put together a team of three estimators, ideally with a variety of skills and experience relative to the project being scoped.
  2. Each person reads through whatever project materials have been assembled so far (descriptions of the work, details on the customer and industry, overall objectives, etc).
  3. On their own, each person independently writes down in a few sentences their understanding of the objective of the project. This description should be non-technical and describe business outcomes, not implementation details.
  4. The group comes together and synthesizes their separate descriptions into a unified paragraph they all agree accurately captures the project objectives.
  5. Each person independently puts together a list of tasks to be completed based on that description. These should include everything needed to get to done, including not only implementation but design time, testing, bug fixing, deployments, documentation, and so on.
  6. The group reassembles and synthesizes each list into a unified task list, removing duplicates as needed, and discussing any items that aren’t broadly understood, until everyone feels good that the list is as complete and detailed as possible.
  7. The scopers separate once again, and on their own each person comes up with an estimate for each task on the unified list. Scopers should not get hung up too long on each task; give it a few minutes thought, make a best effort (err on the high side), and capture any assumptions or unknowns.
  8. Once everyone has independently estimated, come together again, and compare estimates task by task (as well as any assumptions anyone captured for that task). If there’s little variance across the estimates on a task, use the average as a final value. If there is disagreement on the estimate, discuss until a common understanding is reached. Reword the task, or split it into multiple tasks if needed, and then estimate those subtasks. If a consensus final estimate cannot be reached after a reasonable amount of time, the largest original estimate for the task should be used.
  9. Sum the final estimates for each task to come up with a total estimate for the project. Each person gets a chance to share their feelings on this total: does it seem right in aggregate compared to the original description of work determined earlier? If so, excellent. If not, re-review the task list and iterate on estimates again, either as a group, or even going back separately.
  10. Collate the list of assumptions and unknowns and discuss. Based on what is identified, decide on a final uncertainty multiplier. As a general guidance, add 10% if the list is short and/or simple, 25% for “standard” assumptions, and up to 50% if there are large unknowns or significant anticipated complexities. There’s no hard rule here; apply professional judgment.
  11. Apply this multiplier to the task estimate sum to get a final estimate for the project. Share it with stakeholders along with the project description and list of assumptions. Be prepared to defend the value, but also be open to questions and challenges.

I haven’t met anyone who truly loves software estimation, but it’s critically important if you want to be successful beyond hobbyist level. Put in the effort as a team and reap the benefits.

Remix

Remix

By | | Comments 0 Comment

I’m three weeks into the new job now, and while in many ways it’s exactly what I expected, there have been a few surprise challenges. However, what we’re facing isn’t new to me. Though the details are always different (history doesn’t repeat itself, despite the adage), and I’ll never feel totally up to the task, my nearly 25 years of professional technical work were excellent preparation.

It isn’t just the years of experience, though. I’ve intentionally pursued a variety of situations, and through a combination of hard work, the graciousness of colleagues and bosses, and some luck, I’ve been in the positions I’ve needed to develop professionally and grow my career. I’m thankful for that.

Walking the line between unchallenging safety and ineffective overreach is not easy, but I advise erring on the side of the latter. It’s true there’s no compression algorithm for experience, one has some control over the speed and variety at which experiences are… experienced. And that’s an encouraging thought.

I have no doubt I’m right where I need to be. Looking forward to Monday and the chance to move the needle.