profile

Human Who Codes Newsletter

Human Who Codes Newsletter - Opportunity Cost

Published 6 months ago • 4 min read

Thoughts on Opportunity Cost

Every month my credit card bill comes in with a charge of around $0.29 USD from Amazon Web Services. Every month for at least the last three years. I have no idea what I still have running on AWS. At one point, I had a lot of my website infrastructure on AWS, but now, everything is on Netlify. You might be thinking to yourself, “That’s ridiculous, just go in and delete your AWS account!” And you’d be right, except this is a decision I’m purposely making.

How long do you think it would take me to log in, figure out what’s running, shut everything down, and avoid all charges? Optimistically, let’s say that takes five minutes. That doesn’t seem like a lot of time to avoid a monthly charge. But let’s do a little math. Let’s round up and say that AWS is currently costing me $0.01 USD per day. Does that $0.01 USD per day make any impact on my financial well-being? No it doesn’t. It’s effectively zero.

So it will take me five minutes to save $0.01 USD (effectively zero) per day. Why am I not doing it? Because of other things I could be doing with that five minutes. On the ESLint project, I’m paid $80.00 USD per hour, which works out to $1.33 USD per minute. That means if I work on ESLint for five minutes, I’ll make $6.67 USD. If I have five free minutes, which is the better use of my time? Trying to figure out what I’m running on AWS or working on ESLint? The answer is to work on ESLint because I’m making money. And another way to look at it: If I spend those five minutes on AWS, I’m actually losing $6.67 USD, because that’s what I could be making if I chose to work on ESLint instead.

That $6.67 USD lost by working on AWS is called an opportunity cost. Opportunity cost is a term from economics that is defined as, “The cost of an opportunity forgone (and the loss of the benefits that could be received from that opportunity); the most valuable forgone alternative.” In short, opportunity cost is the cost of not doing something so you can do something else. Or to put it another way: When you say “yes” to something you are implicitly saying “no” to something else. That something else has a value that you’ll never receive.

Opportunity cost is helpful in any scenario when you have to decide between two or more alternatives. Which JavaScript runtime should you use? If you choose Deno over Node.js, there’s an opportunity cost of being able to hire expert Node.js developers who don’t want to work on Node.js. Which application framework will you choose? If you choose Next.js, there’s an opportunity cost of being locked into the React ecosystem, therefore limiting your choice of other technologies to use in your application.

Thinking about our decisions in terms of opportunity cost is an important tool in your decision-making process, and one that we often forget to take into account. Any time you’re making a choice, it pays to take a few moments to think about how that decision limits your opportunities.

Every decision has an opportunity cost, and that doesn’t make the decision wrong. But you definitely want to be aware of the opportunity cost before making the decision.

Key Takeaways

  • Whenever you say “yes” to something you are always implicitly saying “no” to something else.
  • Opportunity cost is the cost of an opportunity not pursued and loss of any value that could be achieved.
  • Every decision has an opportunity cost and making decisions without this awareness means you’re not seeing the whole picture.

🤝 1-on-1 Coaching for Software Engineers. I work with senior-level software engineers (and above) to work through the difficult parts of your job. Whether that be leading without authority, improving your productivity, achieving work-life balance, or convincing your VP of your idea, I can help you achieve your goals.


Stuff I've Enjoyed This Month

🎬 The Good, The Bad, and The Web Components by Zach Leatherman (via JSHeroes)
It's been a while since I checked in on the state of web components, and this video gives a nice overview of where we are, including some of the sharp edges that make using web components a bit trickier than necessary.

📝 Blinded by the Light DOM by Eric Meyer
This longish read is a journey that explores how to use web components without the shadow DOM -- only with the "light" DOM, aka, the normal DOM that we all know and use. Very detailed, good read.

🎬 Make FAKE Sets with This AI Tool For VIDEO by Website Learners
This short video shows how to create fake backgrounds for your videos using free tools that are available online. Pretty incredible.

💻 Firefly by Adobe
A free online tool that uses generate AI to create, edit, and augment images. Some pretty amazing examples right on the homepage.

🎬 Using custom CSS properties like this is a waste by Kevin Powell
I haven't done much web development since CSS custom properties were introduced, and this video really helped me expand my thinking about how to use them.

📝Navigation API Explainer by WICG
An exhaustive explainer about the new Navigation API, why it was created, why it's better than the history API, and how to migrate your code.


What I'm Working On

🏠 Real Estate: My latest BRRRR property should have its final hail damage repairs completed by the time you read this. The new roof has been installed and today we're scheduled to start the new siding. Follow my Instagram for photos.

📝 Blog: I published JavaScript WTF: Why does every() return true for empty arrays? in which I explain the logic behind this quirky behavior.

💻 ESLint: I continued working on plans for ESLint v9.0.0, including writing two blog posts. The first explains how the new configuration system will be rolled out, and the second announces our decision to deprecate formatting rules.

Human Who Codes Newsletter

Nicholas C. Zakas

A once-per-month newsletter discussing topics important to senior-level software engineers, with a particular focus on frontend technology and leadership.

Read more from Human Who Codes Newsletter

Thoughts on JSR This past month saw the public release of the JavaScript Registry (JSR), a direct competitor to npm. The folks behind JSR are the same folks behind Deno, a direct competitor to Node.js. While it may not be surprising that a Node.js competitor would also create an npm competitor, Deno actually started with a theory that the JavaScript community didn’t need npm or any other package manager. In fact, in Ryan Dahl’s original talk announcing Deno, he explicitly mentioned npm as a...

about 1 month ago • 5 min read

Thoughts on Burnout As tech layoffs continue to fill up news sites, I’m reminded of how hard I used to work as a full-time employee at companies who could dispose of me without warning. Not only was I giving my all to my work, but then I was working on open source and books in my spare time. For years, I had very little downtime as I bounced from one task to the next, all the while pushing through burnout and not taking any time to recharge. It’s no surprise that I ended up so sick that I’ve...

about 2 months ago • 6 min read

Thoughts on Decision Documents When you start a new project or significant feature, it's likely that you've written a technical specification. Tech specs often lay out the overall design of a system or feature such that it can be implemented by following the spec. Tech specs answer the question, "how?" Knowing how to build something is useful, but there's an equally important question: “why?” That’s where decision documents come in. A decision document outlines the thought process around a...

3 months ago • 4 min read
Share this post