Tag: Learn And Be Curious

Show Me The Data

Show Me The Data

For Christmas back in 2020 my daughter got me a daily crossword puzzle calendar. That started a streak of completing a puzzle every day for two years. I tracked data on how fast I was able to complete each one, curious if I would get measurably better over time.

Today I finally sat down, put all the data into Excel, and crunched some numbers. Here’s a couple interesting results (interesting to me, at least):

Normally I aimed to complete a puzzle in about 15 minutes. For the most part my results clustered around that value, though my overall average across 623 puzzles was 15.9 minutes thanks to the occasional outliers in the 30-ish minute range. Fastest solve time was 6 minutes, which I accomplished 7 times.

This graph of rolling average (with a 30 day window) pretty clearly shows I got better over time as I suspected, going from a 20-ish minute average at start all the way down to 13-ish minute average towards the end. I’m happy with those results!

In total, I spent 165 hours working crosswords in 2021 and 2022, and while it’s not exactly the world’s most productive activity, there’s enough mental benefit that I don’t regret it.

Routinely Solicited Inquiries

Routinely Solicited Inquiries

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

For All The World To See

For All The World To See

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.

Remix

Remix

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.

In Medias Res

In Medias Res

I appreciate people who open up about difficult emotions they’ve experienced in the past. But I appreciate even more people who are willing to discuss them as they are feeling them in the present.

In that spirit, I must confess that this week I’ve experienced considerable Imposter Syndrome. Starting a new job can be overwhelming; doing so when you’re expected to be in charge, even more so, as I’m learning (this is my first time in the latter situation). There’s so much new information to absorb, new people to meet, new customers to understand, and a new culture to internalize. Literally everyone else I talk to knows more than me, and while there’s certainly a grace period, at some point I’ll be expected to earn my salary and contribute, and it’s hard to see when that will be.

Let this serve as a reminder to us all that feelings of inadequacy are normal, especially at times of transition like a new job or getting laid off (which, if that’s you right now, I’m so sorry). I’m telling myself that I’ve been here before, and it’ll be okay. Though I’ll be happy when onboarding is behind me, for sure.

Don’t Repeat Yourself

Don’t Repeat Yourself

Technologists are generally pretty bad at understanding their own history. Understandable, given how quickly the industry moves, but still regrettable.

If you’ve ever written a line of JavaScript or called an API that returned JSON (and who hasn’t, they’re about as ubiquitous as tech can get), you should get to know Douglas Crockford. This interview with him covers a wide range of topics, including how JSON came to be (spoiler: as the antidote to XML), his perspective on JavaScript as a whole (and how it changed from his first impression), what it was like to work through the dot com bubble, and much more.

I also suppose I should study my own history better, because I’ve written on the topic of studying history several times before. Though not all forms of repetition are bad, right? Right?

Spirit And Truth

Spirit And Truth

As I was reading Things they didn’t teach you about Software Engineering, I found myself frequently nodding along. There’s a fountain of wisdom here. Seriously, go read it, or at least go read the headers, which are helpfully summarized along the side of the page.

One worth a deeper dive is this: domain knowledge is more important than your coding skills. I cannot agree more. If you don’t know your customer, it’s unlikely anything you build will add value, no matter how perfectly it’s constructed. And given that the typical end-user is rarely going to be a developer themselves, this knowledge won’t come automatically. It needs to be pursued intentionally.

I’ll go even further, though: knowledge isn’t enough. When the going gets tough (and it will, because programming is hard), a team needs more than information about their customers to keep them moving forward. They need an emotion powerful enough to overcome diverse roadblocks. They need empathy.

The best engineers don’t just seek to know about the problems they’re solving. They internalize those problems, engaging their emotions alongside their intellect. When a customer has a challenge, they feel it in their bones (it’s not by accident that we use the metaphor of a “pain point” when describing problems). When a customer is angry at a missed deadline or poor quality outcome, they lean in, acknowledging failure. And when a customer is overjoyed at the success of a new product launch, they get to share in that happiness.

Empathy is the key that unlocks the willpower to achieve great things. Regardless of technical prowess, show me an empathetic developer, and I’ll show you a good one.

No Easy Answers

No Easy Answers

I’ve been managing technical people for a while now, but when it comes to asking good questions and listening well, I’m always learning. One thing I’ve discovered is that questions needn’t be complex to be effective. Here’s three I use regularly:

How do you feel about that?

Giving someone space to express their emotions is usually a good place to start when beginning a conversation. This is doubly true in the workplace, where there’s a misperception that feelings have no place. But we’re all human, and our effectiveness is predicated on aligning our emotions to the task at hand.

What could you do about that?

Once a person feels safe describing how they feel about a situation, it’s time to explore options for how to move forward. The word could here is critical, it’s a word about possibilities. Usually with just a little nudge, people will be able to come up with a variety of potential solutions on their own.

What do you want to do about that?

Too often people are asked to consider all sorts of factors when weighing options, but never their own desires. And especially not just surface desires, but what they truly want based on their own complex (and often competing and contradictory) web of values. It’s a powerful question; simple to ask, but hard to answer truthfully. Though once it is, I’ve found one often has all the data at hand to make a high quality decision.

All The Things

All The Things

I agree with this article that there’s a special joy that comes from building something to suit your own needs. But that doesn’t mean you shouldn’t share the results. You’ve got to store your artifacts somewhere, so might as well stick them in a public spot like Github. Perhaps someone else will find your work interesting and useful, not the least of whom might be an interviewer who needs examples of your code to do a proper evaluation.

Here’s a rundown of projects for which I am either the primary author or significant contributor, grouped roughly by subject matter. I capture them here for the value of having such an index, but also because some of it I believe has value. If any of you find such value, would you let me know?

Lambda Functions & Tools

Buy Me A Coffee Webhook – I wrote about this project two weeks ago, it’s a CDK-deployed Lambda function with an HTTPS endpoint that can receive webhook notifications from Buy Me A Coffee.

Temperature Collector – Another Lambda function, but this one deployed using terraform. It gathers temperature data from heterogeneous sources and publishes it to CloudWatch. I’ve also written about this one before; if nothing else it’s a reference example for how to use terraform modules.

Selenium Lambda Layer – It’s tricky to get all the right bits in place to get a headless browser working with Selenium in Lambda. Given how browser tech evolves, I doubt this still works, and if I have to do it again, my first choice would be CloudWatch Synthetics Canaries instead.

Lambda Layer Builder – When packaging dependencies, I prefer keeping them in a layer vs including them in the Lambda deployment package itself. It keeps the deployable package small, and ensures I can edit code directly in the console when I need quick turnaround. This script makes it a one-liner to construct and upload a layer that contains a set of either Python or Node.js dependencies.

Blockchain Constructs

Managed Blockchain Document Ledger – As part of a customer workshop I built this fully-functional example of using Amazon Managed Blockchain to write and read documents to Hyperledger Fabric. It illustrates how to create the network, set up users, load chaincode, front with an API Gateway and Lambda function, and deploy Hyperledger Explorer for visualizing the contents of the blockchain. It’s all automated using CDK and bash scripts.

Hyperledger Fabric CDK Construct – As I was developing the above, I realized there could be value in porting the capabilities provided by the bash scripts into custom resources, and packaging it all up into an easily installable CDK construct. This was my first foray into publishing a construct, and I learned a ton about it, in particular how to use projen to deploy a full CI/CD pipeline and get support across all CDK-supported languages.

Ethereum CDK Construct – Essentially the same as the above, but for Ethereum-based blockchain networks. I can only take minor credit for this one; while I gave them the idea, most of the implementation was done by an early career cohort as a capstone project.

Math, Music, and A/V Tools

Lilypond Music Files – Analogous to LaTeX for academic whitepapers, Lilypond is a text-based markup language for engraving (i.e. typesetting) sheet music. I created this repository as a place to collect my own by-ear transcriptions of bass guitar lines. There’s not much in there; consider it an aspirational life goal to add more (what would be extra rad is if this could be automated via AI/ML, with a tool like melody.ml).

Mix Maestro – I’ve been mixing live audio for nearly 20 years, on both analog and digital consoles. Back in 2013 I was doing so on a Roland mixer that had an RS-232 interface for remote control, and I wanted a way for musicians to adjust their own levels without buying an entire Aviom setup. So I grabbed a Raspberry Pi and wrote an HTTP server that abstracted the details. This repository contains the server code; I also wrote a companion Android app.

Light Maestro – Similar to Mix Maestro, I needed a way to control stage lighting, but without any budget to buy a console that had an app. Not only was I able to get a DMX interface built on top of another Raspberry Pi, but I was able to synchronize scenes to ProPresenter via its ability to trigger audio file playback, which I detected using Linux atime changes. Kinda hacky, but it worked more reliably than the bargain basement light board and the inexperienced volunteers that ran it.

Project Euler Solutions – If you want a fun and nerdy way to practice coding, Project Euler is a great resource (and more fun than Leetcode in this mathematician’s opinion). This repository contains my solutions to all the problems I’ve solved to date.

Docker Images

Buildozer – I love Python a lot, and sometimes that means I want to use it for projects where it isn’t typically considered, such as cross-platform GUI app development. With Kivy, it turns out to be quite possible. Buildozer is a framework for building Kivy apps for Android and iOS. Getting its dependencies right is a pain, especially on MacOS, but Docker to the rescue!

LaTeX – Back in graduate school I earned money by typesetting academic papers for mathematicians (such as the esteemed George Andrews) using LaTeX, a typesetting system built by none other than Donald Knuth, one of the giants of computer science (if you haven’t read The Art of Computer Programming, you really should; those folks were geniuses in ways modern developers rarely appreciate). Anyhow, LaTeX is also one of those tools that’s tricky to get set up, so it’s a perfect fit for running in Docker.

Development Utilities

AWS CLI Profile Credential Helpers – Early in my tenure with AWS, I was working with several customers simultaneously, each of which had its own single-sign on solution for their accounts (e.g. Azure SSO, Okta, Shibboleth). In order to abstract away the details of each provider’s mechanism for getting temporary credentials, I built this wrapper, along with a handful of other useful utilities. I’ve used them daily ever since.

Amazon CloudWatch Publisher – Another tool that came directly out of customer work, I needed a way to publish basic CloudWatch metrics (like CPU usage, disk space, network traffic) from Apple hardware, which would not (at the time) run the CloudWatch agent. I decided to build it in Python (natch), which has the added benefit of allowing it to run on other platforms such as the Raspberry Pi.

Kubernetes Tools – It took me a couple months of regular usage to get comfortable with kubectl. Once I could rattle off most commands from memory, I found myself doing similar things over and over. Hence these wrappers. I stuck them on Github for posterity, and am glad I did.

MacOS Dotfiles – Since I made the switch to MacOS (and its Linux-like terminal) in early 2014, I’ve had 4 employer owned and 2 personally owned Apple computing devices. Not changing that any time soon, and looking forward to a rumored 15″ Macbook Air, which I’ll probably buy for its portability (don’t really need the raw power of the Pro when I’ve got the cloud). When I do, I’ll use this set of scripts to automate its setup just how I like it.

Résumé Builder – An example of using LaTeX and my associated Docker image to build a PDF résumé via a continuous deployment pipeline implemented on Github and Travis CI. The résumé is the résumé, if you follow me?

Software Packages

Chrome Local Storage – Yet another project I’ve blogged about, this is a Python package for importing and exporting local storage from a Chrome browser. I built it to move Wordle stats from my laptop to my phone.

Output Scrubber – Writing sensitive information to application logs is generally a bad idea, but it’s easy to do so inadvertently. Include this package in your Node.js application, and it will insert itself into stdout and stderr and remove any pre-configured patterns it finds, such as social security numbers and email addresses. Of course if you’re logging in AWS, there’s some additional tools at your disposal.

Requestium – I’m not the original author of this package, but found its “best of both worlds” tremendously helpful when building some automation around an internal website, because it let me get logged in via Selenium and then switch over to the requests module to interact with APIs. When I needed a few new features, I offered to write the PRs, and discovered the creator was looking for a new owner for the project, and I decided to say yes, at least on a best effort basis. So far it hasn’t required more than a few hours a month at most.

Other Applications

Garage Envoy – This is another “build an HTTP API on top of a thing” project. I took a Raspberry Pi, added a relay that I wired into the opener, and some proximity sensors for detecting the position of the door, and voilà, I had an Internet controllable garage door. The most useful thing here was learning how to control the RPIO pins on the Pi to open/close switches and read sensor values.

Pinochle Scoresheet – In 2013 I went back to school to get a web development certificate from San Diego State. Part of that program was a class on Android app development, and this code was my capstone project. Pinochle is a card game that I’ve been playing since I was a kid, so it was fun to create an app I’d actually use. In retrospect, though, a native app is overkill and a simple mobile-friendly web app would be fine. Also, this app was Pinochle-specific, but I play quite a variety of games regularly, so a general-purpose tool would be nice to have…

Online Scoresheet (coming soon) – … thus this idea was born. Besides being an app I would use myself, I want to use this development to learn a few new things. First, I want to build it within a cloud-based integrated environment like Github Codespaces or Amazon CodeCatalyst. Second, I want to (finally) learn React.js beyond a hello world app. My domain name is bought (onlinescoresheet.net plus a few synonyms) and a sample app is spinning, all I need to do now is build it out.

Living On A Jet Plane

Living On A Jet Plane

Between a job requires a considerable amount of travel, and a whirlwind European vacation this summer, I’ve been to quite a few places this past year:

I’m thankful for the experiences I’ve had to date. Few things are more humbling that the realizing that you are just one individual in a large world; I feel that way from my travels, and I’m far from having seen even a decent fraction of the cultures that fill the earth.

Want to be a better developer, manager, relative, friend, or person in general? Consider travel if you can.