AWS The Good Parts - Notes

I successfully landed my first ever paid gig 🎉 this year, where I was responsible for styling a Web app. The project was using React on the front-end and the backend was powered by AWS Amplify and DynamoDB. The thing is I was talking to the developer that built the backend and he made me very interested in learning AWS. So after I finished the job, I did some research about the best resources to learn AWS and I found The Good Parts Of AWS by Daniel Vassallo. This will be a series of blog posts where I share my understanding of the things I learned from the book. You should definitely check it out.

The Default Heuristic

As a Software engineer you have to make a lot of choices, from deciding which language(s) to use, frameworks, libraries, architectures, etc. So for you to make these decisions, you have to first understand what are the available options. This part requires research, so that you’re able to determine what are the right tools for your specific use case. And with the fast pace of the tech industry, new tools are constantly being invented. The problem is that, while doing your research, sometimes one might fall in the trap of chasing the best tool.

So with each tool you encounter, you try to understand how it works, the different trade-offs you’ll make when using it, who’s using it and maybe try building something with it to test it.

This approach takes a lot of time and effort and it becomes really inefficient when you have a lot of options.

Okay, so how can you avoid this trap? Daniel Vassallo recommends using a technique called the “Default Heuristic”.

“The premise of this heuristic is that when the cost of acquiring new information is high and the consequence of deviating from a default choice is low, sticking with the default will likely be the optimal choice.”

So an important question pops up: “what should be my default choice”?

You should go with something that you already understand, you’re confident that it works and you’ve tested it before. The default choice doesn’t have to be the best, it just needs to be reliable so that it gets you closer to your goals.

When you follow this strategy, you end up being more efficient, because you’re making the majority of your decisions based on your experience. When the defaults you have don’t fit a certain case, that’s when you should do your research and try to find the right tool.

I’m a front-end engineer and I recently faced a situation where I had to make a choice about which tool to use concerning styling the UI of a web app. Should I go with an existing component library or write my own css from scratch? Okay, if I’m going to write my own css from scratch should I use css-in-js? scss? Or maybe I should try tailwind-css, I heard it makes you really efficient when building layouts and UIs. So as you can see, there are a lot of possible decisions for one aspect of the project. There are also different conventions, philosophies, libraries, frameworks, linting-tools, build-tools, CI/CD, etc. So if I would research and try all the possible tools that there is, I just wouldn’t get anything done.

The point of this book is to share “the default choices” of Daniel Vasalllo. He explains each one of them and why it became a default choice when working with AWS.

I will share my learnings from this book here, but definitely I recommend that you buy the book yourself and go through it.

Found this article useful? Make sure you share it with other people on Twitter

Hi! Welcome to my Blog 👋

This is where I write about the things I learn, Front-end Development and share my thoughts. I'm a Learner Advocate at Egghead.io and a Front-end Software Engineer in my 3rd year, studying Computer Science.