DEV Community: Ifeanyi O.

I Built My Mom an AI Recipe Helper for Mother's Day

Ifeanyi O. — Fri, 08 May 2026 07:53:25 +0000

A project about a fridge, Strands agents & trying to keep up with Mom's seasons.

My Mom's Problem

My mom has a drawer full of recipes. Yes! Not a folder.... an actual drawer. Torn pages from magazines, things written on the back of envelopes and binders that've been around longer than I have. Whenever she's looking for dinner ideas she pulls something out, sighs and puts it back.

The recipe is not the issue here, that's always fine. It's that she's missing one ingredient or four!

And even if she has everything, the recipe might not fit whatever season she's in at the moment because the other thing is, her eating is a moving target.

One month she's a vegetarian because a friend got her into it, a few months later she's watching her sugar because the doctor mentioned it during a checkup, then it's low sodium or she's "just trying to be a little better with dinners." You just never really know which version is going to be at the stove on a given Tuesday.
But the real question she's always asking, underneath the recipe hunt, is...

What could I make with what I already have, that fits how I'm eating right now, that I won't get bored with?

Now that sounds like problem for an agent! So for Mother's Day this year, I built her one and called it AskMom Recipes. You can try it out here.

What it does in 30 seconds

You open a pink website and tell it what's in your kitchen. You can type it, or you can just take a photo of your groceries on the counter and drop it in.

You also have the option to pick how you're eating this week, for eg. no restriction, vegetarian, low sodium, diabetic-friendly or gluten-free. Then hit the "Suggest recipes" button.
A couple seconds later, you'll get three recipes and each one tells you:

What you already have vs. what you'd need to grab
Simple, unfussy steps (the kind of thing my mom actually cooks)
Why it's good for you, with real nutrition numbers from the USDA
One sentence about where the dish possibly comes from

If you don't love the recipes, you can tap "make it healthier" or "something quicker" or "fewer ingredients" and it adjusts on the fly.

That's it! The rest of this blog is how I built it and the design decisions that made the difference between "okay, cool demo that kinda works" and "something my mom would actually use."

Why an agent and not a prompt

An easy version of this would just be to throw the ingredients into a single prompt, ask for three recipes, done. I tried it, it's fine but there's problems that show up the moment you try to use it for real.
First, the model will happily make up nutrition numbers. Ask it how much protein is in chicken and it'll give you a number, confidently and you'll have no idea if it's right.

Second, it'll cheerfully tell you that tomatoes come from Italy or that pasta is a Chinese invention. Third, if you want to say "actually, make that healthier" the prompt has to start over from scratch because there's no memory.

An agent solves two of those three. As for the made up facts we needed something else which we'll get.

I used Strands Agents, which is a refreshingly simple Python SDK for building agents on Amazon Bedrock. You define your tools as functions, write a system prompt and Strands handles the loop of "model decides what tool to call, tool runs, result goes back to model, repeat."

It's the first agent framework I've used that didn't make me want to throw my laptop.

def build_agent(model_id: Optional[str] = None) -> Agent:

    model_id = model_id or os.environ.get(
        "BEDROCK_MODEL_ID", "anthropic.claude-3-haiku-20240307-v1:0"
    )
    region = os.environ.get("AWS_REGION", "us-east-1")

    model = BedrockModel(
        model_id=model_id,
        region_name=region,
        temperature=0.4,
    )

    return Agent(
        model=model,
        system_prompt=SYSTEM_PROMPT,
        tools=[
            extract_ingredients_from_image,
            extract_ingredients_from_text,
            suggest_recipes,
        ],
    )

With Strands, setting up the agent is almost anticlimactic. There's a model, a prompt and a list of tools. That's the whole thing.

I wanted to flag this, because it took me a few iterations to get right, the tools I gave the agent are not "one tool for everything." They're small, single-purpose and named like verbs.

The tools and why there aren't very many

Everyone always goes tool crazy, when they first build an agent. Each tool feels free so why not just add them all, right? Wrong!

The problem is every tool call is another round trip through the model. The model says "I'd like to call X," you run X, hand the result back, it thinks for a second and says "now I'd like to call Y." Each hop is a few seconds but when you add six tool calls, then your recipe helper takes forty seconds and your API times out.

So I decided to split the work in two:

Things the agent handles (because they genuinely need a model's judgment):

Reading a photo and identifying what's in it
Normalizing messy text like "some chicken, rice, maybe garlic" into a clean list
Generating three healthy recipes that fit the user's preferences

Things Python handles (because they just need a lookup):

Looking up real nutrition numbers
Formatting a recipe card for the frontend

Since Python can fetch faster than the model can ask, why would I let a language model guess when there's a real source? USDA has an API with the actual nutrition numbers.

This one design decision cut request latency from ~34 seconds to ~17 seconds. You get the same quality in half the time with way less money spent on Bedrock tokens and it made the agent more reliable with fewer retries and self corrections that eat tokens for no reason.

The lesson is to use the LLM for the things that need reasoning and use code for the things that need answers.

Preference handling

Alright, back to my mom for a second. The seasons thing, vegetarian one month and low sodium the next taught me more about preference handling that I didn't expect.

The naive approach is a freeform text field that ask you to type your dietary preferences. The problem is the model has to figure out what "watching my sugar a bit" means versus "diabetic-friendly" versus "low-carb." Sometimes it guesses wrong and sometimes the recipes it produces have way too much added.

So I made it a dropdown. Five options:

No restriction
Vegetarian
Low sodium
Diabetic-friendly
Gluten-free

Each one maps to a crisp, one sentence guidance block that gets injected into the recipe prompt:

_PREFERENCE_GUIDANCE = {
    "none": "No dietary restrictions. Focus on healthy, balanced meals.",
    "vegetarian": "Strictly vegetarian: no meat, poultry, or fish.",
    "low_sodium": "Low sodium: minimize salt and high-sodium ingredients like soy sauce or canned broths.",
    "diabetic_friendly": "Diabetic-friendly: low glycemic index, limit added sugars and refined carbs.",
    "gluten_free": "Strictly gluten-free: no wheat, barley, rye, or standard soy sauce.",
}

It's five lines of Python.

A dropdown sounds less impressive than "the AI understands your preferences," but the dropdown is more reliable and trust me, reliable is what my mom needs.

When it comes to agent patterns, the more you can constrain the inputs, the better the outputs. Freeform is cool in demos but more structure is better in real life.

The "send a photo of your groceries" part

I wanted to keep the typed-ingredients path simple, but the photo path is where it gets fun. You take a picture of whatever's on your counter and the agent reads the photo, identifies the food and treats it the same as if you'd typed it in.

Under the hood this is one of Strands' best party tricks. Claude 3 Haiku on Bedrock handles vision natively, so the whole thing is one tool call:

@tool
def extract_ingredients_from_image(s3_key: str) -> List[str]:
    """Look at a photo of groceries and return the ingredients visible in it."""
    bucket = os.environ["UPLOADS_BUCKET_NAME"]
    region = os.environ.get("AWS_REGION", "us-east-1")

    # 1. Fetch image bytes from S3
    s3 = boto3.client("s3", region_name=region)
    obj = s3.get_object(Bucket=bucket, Key=s3_key)
    image_bytes = obj["Body"].read()
    media_type = obj.get("ContentType", "image/jpeg")

    # 2. Ask Bedrock Claude Haiku what's in the photo
    prompt = (
        "List only the food ingredients you can clearly see in this photo. "
        "Return a JSON array of short lowercase names, nothing else. "
        'Example: ["tomato", "onion", "chicken breast"]. '
        "If you can't identify any food, return []."
    )
    bedrock = boto3.client("bedrock-runtime", region_name=region)
    response = bedrock.invoke_model(
        modelId=os.environ["BEDROCK_MODEL_ID"],
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 400,
            "messages": [{
                "role": "user",
                "content": [
                    {"type": "image", "source": {
                        "type": "base64",
                        "media_type": media_type,
                        "data": base64.standard_b64encode(image_bytes).decode(),
                    }},
                    {"type": "text", "text": prompt},
                ],
            }],
        }),
    )

    # 3. Pull the JSON array back out (defensively)
    text = json.loads(response["body"].read())["content"][0]["text"]
    match = re.search(r"\[.*?\]", text, re.DOTALL)
    if not match:
        return []
    try:
        items = json.loads(match.group(0))
    except json.JSONDecodeError:
        return []
    return [str(x).strip().lower() for x in items if str(x).strip()]

The prompt is boring on purpose. All is says is "List only the food ingredients you can clearly see in this photo. Return a JSON array of short lowercase names, nothing else." I did not give it a personality or tell it to "please think carefully". I also didn't give it examples of how the model should "reason." I just told it what I want and what format I want it in.

The model is very good at ambitious prompts and very good at literal ones. Ambitious prompts return ambitious, chatty and often wrong answers but literal prompts more closely return what you asked for. For this tool, where the output feeds directly into the next step, literal wins every time.

Also, note that the photo gets uploaded straight from the browser to S3 via a pre-signed URL, so my Lambda never has to deal with multipart file uploads. The agent just gets an S3 key and fetches it.

The Architecture

Here's the whole thing, in the order a request flows:

Browser loads static pink site from S3, served through CloudFront.
User submits text and/or photo. If photo, goes straight to S3 as pre-signed URL.
Browser calls POST /ingredients on API Gateway, which hits a Lambda.
Lambda builds a Strands agent with three tools, runs the agent loop.
Agent extracts ingredients (text + vision), then calls suggest_recipes once.
Lambda enriches each recipe in Python, origin lookup, USDA lookup and format.
Session is saved to DynamoDB with a 24-hour TTL for the "refine" follow up.
Recipes come back to the browser.

The whole thing is deployed with AWS CDK in Python, one stack, one make deploy. No Docker needed, no hand-wiring and definitely no clicking around in the console.

What it costs me to keep it running

For my mom's personal deployment, answering a few requests a week:

Bedrock: Tenth of a penny per recipe request.
Lambda: Free.
DynamoDB: Free.
S3 + CloudFront: Couple cents a month for the static site.
USDA API: Free.

I pay less for AskMom per month than for a single coffee. If I published it and a hundred people used it regularly, I'd still be under a few dollars a month!

Try it yourself

If you want to build one for your mom (or your dad, or anyone whose fridge is a mystery), the whole thing is open source.

Repo: github.com/rextheking/askmom-recipes-sample-for-aws-strands

The README walks through the deploy in six steps. You need:

An AWS account with Bedrock access enabled for Claude 3 Haiku in us-east-1
Python 3.12, Node 20/22/24, AWS CDK CLI and the AWS CLI
A free USDA FoodData Central API key (takes 30 seconds to get)

Then it's:

cd infra
make install
make bootstrap     # one time per AWS account
make deploy        # ~5-7 minutes, most of it CloudFront
# paste the ApiUrl into web/config.js
cd ../web
make deploy
# open the CloudFront URL

Note, the first deploy takes a few minutes because CloudFront is slow to propagate. If you're just kicking the tires, there's a -c with_cloudfront=false flag that skips CloudFront and gets you a working API in about 90 seconds.

The Hug

If you build something for your mom this year, I'd love to see it. Tag me or share the repo of whatever weird thing you shipped.

Happy Mother's Day 💖

Credits

Strands Agents for making agent code actually pleasant to write
Amazon Bedrock + Claude 3 Haiku for the model
USDA FoodData Central for free, honest nutrition data
My mom, for the original problem

How to Survive Your First 90 Days as a Developer

Ifeanyi O. — Mon, 04 May 2026 05:00:00 +0000

Intro
The Psychological Transition
Clarity Through Your Manager
Learning the System
Choose Depth Over Breath
The Codebase
Relationships
A Strong First 90 Days
Final Thoughts

Intro

If you've spent enough time on LinkedIn, YouTube, or X (Twitter) over the past 5 years, it's clear how the tech industry has been positioned to new entrants. You're told that with the right roadmap, bootcamp, course, or resources and enough consistency, you can transition into a high-paying role in a relatively short amount of time. You see titles that promise six-figure salaries without a degree, structured paths to be a full-stack developer or cloud engineer, with step-by-step breakdowns of how others have made the transition successfully. For many, this content is as a powerful entry point into an industry they may have never considered and there's real value in that.

However, there's an issue I have with this messaging, as it often presents an incomplete picture of what the journey actually entails. While there's heavy emphasis on how to learn, build and position yourself to land a role, there's significantly less conversation around what happens once you actually get there. The transition into your first engineering role is not simply a continuation of the learning process you experienced while preparing, it's a complete shift into an entirely different environment, one where expectations, responsibilities and pressures operate at a different level.

When you step into your first role, you're not operating in isolation anymore or within the controlled structure of courses and tutorials, you're part of a team, contributing to systems already in production, with real users, dependencies and consequences tied to the work being done. You're expected to learn quickly, but also to apply that learning in a way that aligns with how the team and organization function.

This is where many new developers encounter difficulty, because they weren't prepared for what the role actually demands beyond the hiring process. The skills required to pass interviews and complete projects in a learning environment don't always translate directly into the skills required to navigate ambiguity, collaborate within a team and operate effectively within an existing system. As a result, the first few months can and will feel disorienting and in most cases, overwhelming.

You have to acknowledge that there's a reason these roles are compensated at a high level. When an organization hires an engineer, particularly into a role that carries a six-figure salary, it's making an investment that goes beyond technical knowledge alone. That investment reflects an expectation that the individual will be able to learn rapidly, adapt to complex systems, communicate effectively with others and contribute to outcomes that have a tangible impact on the business. These expectations are't always explicitly stated, but they are very real and immediately become apparent once you begin operating within the role.

Without a clear understanding of these dynamics, it's not uncommon for new engineers to experience imposter syndrome, uncertainty around expectations and difficulty finding their footing in the early stages of their career. In some cases, this leads to disengagement or burnout and in others, it results in individuals leaving their roles within the first few months, due to a lack of preparation.

This blog is intended to address that gap. We'll focuses on what it actually takes to navigate your first 90 days as a developer. The period that plays a critical role in shaping how successfully you transition from a new hire into a contributing member of your team.

Understanding the Psychological Transition

When I stepped into my first role as a cloud developer, I thought I went in with a very clear expectation of what the challenge would look like. I assumed it would be technical in nature and I thought my days would be spent learning new AWS services, writing code, debugging issues and gradually building up my understanding of how everything fit together. In my mind, the difficulty would come from solving problems I'd never seen before and I was mentally prepared for that. What I was not prepared for was how quickly the pressure would shift from external challenges to internal ones.

Within the first few weeks, I started to realize the real difficulty was the environment I was now operating in. I remember sitting in my first few stand ups and team meetings, listening to conversations that moved at a pace I wasn’t used to. People were referencing systems, pipelines, internal tools and architectural decisions as if they were common knowledge. There was an assumed level of context that I simply didn't have yet. I'd hear terms I recognized individually, but not in the way they were being applied in that specific system and I found myself trying to mentally connect everything in real time while the conversation kept moving forward.

At the same time, I was trying to manage how I was being perceived. I didn’t want to constantly interrupt to ask questions that felt basic because I didn’t want to slow the conversation down so I'd sit there, processing as much as I could, taking notes and telling myself I'd go figure it out later. That combination, high exposure to new information and hesitation to reveal gaps in understanding created a very specific kind of pressure.

It’s hard to fully describe that feeling unless you’ve experienced it, but it’s the moment where you begin to question your own presence in the room. You start to wonder whether everyone else is operating at a level you somehow missed and whether you're the only one trying to catch up. That internal dialogue becomes louder over time, especially when each day introduces something new that you don’t yet understand.

For me, it reached a point where I genuinely considered walking away from the role. It gotten to the point where I felt like I was falling behind in real time and every day felt like a new layer of complexity was being added, but instead of interpreting that as part of the learning process, I saw it as evidence that I wasn’t progressing fast enough. I was measuring myself against an expectation that didn’t align with reality.

Looking back, that was a fundamental misunderstanding of what the first 90 days are supposed to feel like. The discomfort, the uncertainty and even the moments of doubt doesn't necessarily mean something is wrong. I didn't understand that it was actually indicators that I was being introduced to a new level of complexity that I didn't have time to internalize yet.

You're not expected to walk into an existing system and immediately operate with the same level of context as someone who's been contributing to it for years. That expectation only exists if you place it on yourself. What's actually expected of you is the ability to learn, observe, ask questions and gradually build an understanding over time.

The shift for me came when I stopped asking myself whether I fully understood everything that was happening around me and started asking a much simpler question like, do I understand more today than I did yesterday? That reframing allowed me to see progress in smaller, more realistic increments. A concept that felt completely unfamiliar one week, would start to make partial sense the next and eventually it became something I could explain or apply.

That shift didn't remove the challenge, but it made it manageable and over time, my small increments of progress compounded to give birth to confidence.

Establishing Clarity Through Your Manager

One of the biggest mistakes I made early was underestimating how important my relationship with my manager was during that ramp-up period. I approached my 1-on-1 meetings the way I had approached check-ins in previous roles or environments, as something routine and almost procedural. I would show up, give a quick update on what I had been working on, mention anything that felt relevant and then move on. At the time, I thought I was doing what was expected but in reality, I was missing one of the most valuable opportunities available to me.

I didn’t fully understand that those early conversations were one of the only spaces where I could access real context about how the team operated, what actually mattered and how I was being evaluated beyond surface level tasks. Without that context, I was making decisions in isolation, trying to determine what was important based on what I saw around me, rather than what was actually expected of me.

That gap started to show up in subtle ways. I'd spend time going deeper in areas that felt important to me, but didn’t necessarily align with the team’s immediate priorities. I'd second guess whether I was moving fast enough, or focusing on the right things, because I didn’t have a clear benchmark to measure against. There was a lot of effort, but not much direction.

A second shift happened when I started treating those 1-on-1 meetings as strategic conversations. I began coming in with intent, so instead of simply sharing what I'd done, I started asking more direct and at times, uncomfortable questions.

I asked what success actually looked like in my first 30, 60 and 90 days, not in a general sense, but in the context of how my manager would evaluate my progress. I asked where new hires typically struggled so I could anticipate those challenges rather than react to them. I asked what I should be prioritizing right now and just as importantly, what I could afford to ignore without it negatively impacting my performance.

Those questions changed everything!

They gave me clarity that I couldn't have arrived at on my own, no matter how much I observed or how hard I worked. They provided a filter for my decision making. Instead of trying to do everything, I could focus on what actually mattered and instead of guessing whether I was on track, I had a clearer sense of how my progress was being perceived.

What became clear is your manager operates with a level of visibility that you simply do not have as a new engineer. They understand how your work fits into the broader goals of the team, how performance is measured and where the real impact lies. Without tapping into that perspective, it's very easy to spend your time optimizing for things that feel productive but don't meaningfully move you forward.

As you begin to use those meetings intentionally, they naturally evolve into a feedback loop. You bring your current approach, your questions and your assumptions into the conversation and your manager helps refine them. You get early signals on whether you're focusing on the right areas, whether your pace is appropriate and where you might need to adjust. That ability to course correct early is critical, especially in the first 90 days when your direction is still taking shape.

Over time, you begin to build confidence in your understanding of what is expected of you. That alignment reduces a internal friction because instead of constantly questioning whether you're doing the right things, you're able to move forward with more clarity and intent.

Learning the System Before Trying to Prove Yourself

There's a very natural instinct, especially early in your career, to want to prove that you belong. After all the effort it took to get the role, it feels like you need to validate that decision as quickly as possible so you try to contribute early by looking for opportunities to improve things and identifying patterns that seem inefficient or outdated based on what you’ve learned so far.

I experienced this myself as I started getting more exposure to the codebase and the surrounding architecture, I began noticing decisions that didn’t fully align with what I had learned through courses, certifications or best practices. Certain implementations felt unconventional and some workflows didn’t look as streamlined as I expected. My initial reaction was to question whether these were things that needed to be fixed or optimized.

But what I didn’t understand was that I was evaluating a real system through a theoretical lens.

Over time, I started to realize what I was seeing was the result of real world constraints. Systems that exist in production environments are rarely built under ideal conditions. These systems are shaped by deadlines that had to be met, trade offs that had to be made, legacy decisions that still have downstream impact and in many cases, incidents that forced the team to adapt quickly in ways that may not look "clean" from the outside.

So what appears inefficient without context often has a reason behind it. That reason may not be obvious in the code itself, but it exists in the history of how the system evolved.

This is where my approach had to change. Instead of trying to evaluate the system based on what I thought it should be, I started focusing on understanding what it actually was. I became more intentional about asking why before forming an opinion. Why is this service structured this way? Why was this decision made? What problem was this solving at the time? What constraints influenced this approach?

With this mindset, I began spending more time tracing how requests moved through the system from entry point to response. I explored how infrastructure was defined and managed, whether through tools like CloudFormation or CDK and how those definitions translated into real environments. I paid closer attention to deployment workflows, how changes were reviewed and how they were safely released into production. I looked at logs and metrics to understand how the system behaved under different conditions, rather than just how it was intended to behave.

In doing so, I started to see patterns that weren't obvious at first. I began to understand how different components interacted and why certain trade-offs were made. That level of understanding cannot be rushed and it cannot be replaced by external learning. It comes from spending time inside the system and allowing that context to build gradually.

What followed was a noticeable shift in the quality of my contributions. When I eventually did suggest improvements or asked deeper questions, they were grounded in a clearer understanding of the system. They were not longer based on abstract best practices, but on how those practices applied or didn’t apply to the reality of the environment I was working in.

There's also a level of credibility that comes with that. When you demonstrate that you've taken the time to understand before trying to change, your input is received differently. It shows respect for the work that has already been done and signals that your goal is to contribute in a meaningful way.

Choose Depth Over Breath to Narrow Your Focus

Another challenge I faced early on was trying to learn too much at once. Coming from a self taught background, I had built my entire learning process around exploration. If there was a new service, I wanted to understand it, if there was a new tool gaining traction, I felt like I needed to at least be familiar with it. That approach served me well when I was trying to break into the industry, because exposure mattered. The more I saw, the more connections I could make and the more confident I became in navigating unfamiliar concepts.

However, once I stepped into a real engineering role, that approach started to work against me.

Instead of accelerating my progress, it was fragmented my attention. I would spend time learning tools and services that were interesting, but not directly relevant to the environment I was working in. I convinced myself that this would make me more prepared in the long run, but it was slowing down my ability to contribute in the short term. I was increasing my surface level knowledge but delaying the depth I needed to actually be effective on my team.

This became more apparent when I compared what I was learning to what I was actually being asked to work on. There was a clear gap between the two. The work in front of me required a deeper understanding of a smaller set of tools, while my learning was spread across a much wider range of topics.

I then decided to make a deliberate decision to narrow my focus to the environment I was operating in.

I started by identifying the core components of my team’s stack. If observability was handled through CloudWatch, then that became my primary focus for understanding logs, metrics and alerting. If the services I was working with were written in Python, then I invested more time in becoming comfortable with that language, rather than trying to split my attention across others. If infrastructure was defined using CDK, then I focused on understanding how those tools were used within our specific workflows, rather than exploring alternative infrastructure approaches.

This shift toward depth created immediate benefits as the concepts I was learning began to show up directly in my day-to-day work. I could follow conversations more easily and complete tasks with greater confidence because the knowledge I was building was directly applicable.

There's also a compounding effect that comes with depth. As you go deeper into a specific tool or service, you begin to understand how it behaves in different scenarios, how it integrates with other components and its limitations. That level of understanding allows you to move faster and make better decisions, even within a relatively narrow scope.

This is not an argument against breadth in the long term. Expanding your knowledge across different tools and services is valuable and over time, it contributes to your ability to think more broadly about system design and architecture. However, timing matters! In the first 90 days, your priority is to become effective within the environment you're in.

That requires a level of focus that can feel counterintuitive, especially if you're used to learning widely. It may feel like you're limiting yourself by not exploring everything at once but really, you're accelerating your ability to contribute by aligning your learning with what is immediately relevant.

There'll always be time to expand later. Tools and technology aren't going anywhere and your capacity to learn will only improve as you gain more experience. However, in those early stages, depth is what allows you to build momentum in transforming your learning from something abstract into practical.

The Codebase Is Where Everything Comes Together

No course, certification, or tutorial fully will adequately prepare you for what you learn by working through a real codebase. Structured learning environments are designed to teach concepts in isolation, they give you clean examples, controlled scenarios and predictable outcomes, which are necessary when you're building foundational knowledge but production systems don't operate in isolation and they're rarely clean in the way learning environments present them.

I remember the first time I intentionally tried to trace how a request moved through the system I was working on. I expected it to resemble the diagrams I had studied, where a request enters, flows through clearly defined components and returns a response in a way that is easy to follow. What I encountered instead was far more complex. The flow required jumping across multiple services, understanding how different components communicated with each other, and piecing together the path step by step. There were layers of abstraction, integrations I hadn’t seen before and behaviors that only made sense once I looked at them in context.

At first, it felt like I was constantly losing the thread of what I was trying to follow. I would start in one part of the system, only to realize that the logic I was looking for existed somewhere else entirely. It required patience to stay with the process and resist the urge to simplify what I was seeing into something more familiar.

However, as I continued to spend time in the codebase, I started to see how the different layers of the system interacted. Infrastructure definitions began to make more sense when I saw how they supported the application logic. Observability became more meaningful when I connected logs and metrics back to actual execution paths. I finally began to understand how everything functioned collectively as part of a larger system.

Patterns began to emerge and I started to recognize how certain types of problems were approached within my team. I saw recurring structures in how services were built, how errors were handled and how data flowed through the system. That pattern recognition is what allows me to move more confidently because I was no longer encountering everything as completely new.

It's not always the most comfortable form of learning and it often requires sitting with confusion longer than'd prefer but that discomfort is part of the process. The more time you invest in understanding the system directly, the faster you transition from trying to piece things together to actually navigating the system with intent.

Relationships Will Accelerate Your Growth More Than You Expect

One of the most underestimated aspects of your first 90 days is how much your growth is influenced by the people around you. When you're new to a role, it's easy to believe that your success will be determined primarily by how quickly you learn the technology, how well you write code, or how efficiently you complete tasks. While those things are important, they're only part of the equation. The environment you're stepping into is inherently collaborative and your ability to navigate that environment is closely tied to the relationships you build within it.

Early in my career, I made a conscious decision to go beyond purely task based interactions with my teammates. Instead of limiting conversations to stand ups, tickets and code reviews, I began scheduling time to connect with people individually. These were't formal meetings but simple conversations aimed at understanding what each person worked on, how they approached problems and what their experiences had been within the team and the organization.

At first, it felt like an extra effort on top of everything else I was trying to manage. There's always a tendency to prioritize what feels immediately productive and relationship building doesn't always show immediate results but over time, those conversations proved to be some of the most valuable investments I made during that period.

They gave me insights that no documentation or onboarding material could provide. I learned how different engineers thought about trade-offs, how they approached debugging and how they navigated ambiguity. I gained context about why certain decisions were made and how different parts of the system evolved over time. These were perspectives that couldn't be captured in a runbook or a design document, but they were critical to understanding how to operate effectively within the team.

Those relationships also changed how I experienced moments of uncertainty. When you're new, there will be times when you're stuck, whether it's due to a technical issue or a lack of context. Without established relationships, asking for help can feel like an interruption. If you hesitate and try to figure everything out on your own, in the process you'll lose time and momentum.

Once I had built connections with my teammates, reaching out felt more like a continuation of an existing conversation as it felt like I was collaborating with someone I already knew. That reduced friction made it easier to ask questions earlier, unblock myself faster and learn more effectively from the people around me.

Building that trust with teammates takes time, but the foundation can be established early. It comes from showing genuine interest in others’ work, being present in conversations and consistently engaging in a way that signals respect and curiosity.

Another important aspect of relationship building is extending your network beyond your immediate team. As you begin to understand how your team operates, you'll also start to see how it connects with other teams and functions within the organization. Product managers, security teams, site reliability engineers and other engineering teams all play a role in the systems you're working on. Taking the time to understand how these groups operate and how your work intersects with theirs provides a broader perspective on the impact of what you're doing.

These cross-functional relationships become increasingly valuable as you take on more complex work. They provide additional sources of context, open up opportunities for collaboration and make it easier to navigate dependencies that extend beyond your immediate team.

Those relationships you build during your first 90 days create a support system that accelerates everything else you are trying to do.

What a Strong First 90 Days Actually Looks Like

At the end of your first 90 days, there's an unspoken expectation that by this point you should feel fully confident, fully capable and fully independent in your role, but that's not how growth in engineering environments works. The first 90 days are about establishing direction as success during this period is better measured by the clarity you have developed and the momentum you have built.

At this point, you should have a solid sense of how work is prioritized, how tasks move from idea to implementation and how decisions are made within your team. This includes understanding the rhythm of your team’s processes, such as stand ups, sprint planning, code reviews and deployment workflows. By this stage, you should be able to navigate them with a level of confidence and awareness that allows you to participate more actively.

In addition to process, clarity also extends to the technical environment you're working in. You should be familiar with the core tools and services that support your daily responsibilities. This doesn't mean you have mastered every detail, but you should understand how they're used within your team and how they fit into the broader system.

Another important marker is your ability to navigate the codebase. Early on, the system may have felt fragmented and difficult to follow but now you should be able to trace key workflows with greater confidence. You should understand where to look when you're assigned a task, how different components connect and how changes move through the system so you can contribute meaningfully without feeling lost at every step.

Also, by this stage, you should've established connections with your immediate team and have a working familiarity with the individuals you collaborate with regularly. These relationships should make it easier to ask questions, share ideas and navigate challenges.

Alignment with your manager is now a critical component. You should have a clear understanding of what is expected of you moving forward, how your performance is being evaluated and where you should be focusing your efforts in the next phase of your role. This removes much of the uncertainty that exists early on and allows you to move forward with greater intention.

At the end of 90 days is where momentum begins to build. The initial friction that once slowed you down should have started to decrease and your ability to move through problems becomes more fluid. Yes, at this stage you're still learning, but now you're learning from a position with context.

Final Conclusion

The first 90 days of your career as developer will challenge you in ways that'll difficult to fully anticipate. It's a test of how you handle uncertainty, how you adapt to unfamiliar environments and how willing you're to stay committed to the learning process even when progress doesn't feel immediate.

I came close to walking away from my first role because I misunderstood what that experience was supposed to feel like. I interpreted the discomfort, the confusion and the constant exposure to things I didn’t yet understand as signs that I wasn’t ready but in reality, those were all indicators that I was exactly where I needed to be, learning in an environment that was pushing me to grow.

If you can approach this period with patience and intentional focus, you'll also notice the shift. Remember, have grace for yourself and allow yourself the space to grow into the role you've already earned.

Be the engineer you're capable of being.

Amazon S3 Files Is Still Not A File System

Ifeanyi O. — Thu, 09 Apr 2026 21:24:02 +0000

Intro
What is S3 Files
What Changed for Developers
How S3 Files Works at a High Level
Why This Matters for AI
Practical Code Example
Security Operations
Key Takeaways

Intro

If you've spent any real time learning AWS, one of the first storage lessons you probably learned was Amazon S3 is not a file system.

And that mattered because it explained a lot of the weirdness you'd run into early on that might have you asking...

Why can't I just mount S3 like a normal shared drive?
Why can't my application treat S3 data like regular files?

But the answer has always been... S3 is object storage and even though that's obvious, it's a critical distinction because as interesting as S3 Files is, it seems to be confusing a lot of people that only read headlines.

So no... S3 did not suddenly turn into a file system.

So what is S3 Files?

S3 Files is a file system interface for data that lives in S3 and connects AWS compute resources directly with data in S3. It gives applications file system access without the data ever leaving S3 and maintains a view of the objects in the bucket while translating file system operations into efficient S3 requests.

Personally, the simple way to think about S3 Files is S3 remains the storage layer, S3 Files becomes the file-access layer and your apps sees files and directories.

What changed for developers

Before S3 Files, many workloads had a choice to make.

Do you optimize for S3's scalability, durability and cost characteristics, or do you optimize for file system behavior that your applications already understand?

S3 Files aims to remove that tradeoff by making general purpose S3 buckets accessible as native file systems for AWS compute resources and supports NFS v4.1+ file operations like create, read, update and delete.

This is kind of a big deal because it means more workloads can work against data where it already lives instead of forcing you to move it somewhere else first.

How S3 Files works at a high level

At a high level, S3 Files creates a file system view over an S3 bucket.

Your compute resource connects to that file system through a mount target in your VPC. For example, you can create the S3 file system, discover the mount target and then mount it from an EC2 instance using the s3files file system type.

Once mounted, your application can interact with the mounted path using normal file operations.

sudo mkdir /home/ec2-user/s3files
sudo mount -t s3files fs-1234567890abcdef:/ /home/ec2-user/s3files

After that, you can do familiar things like:

echo "Hello S3 Files" > /home/ec2-user/s3files/hello.txt
ls -al /home/ec2-user/s3files/hello.txt

When you create a file through the mounted file system, the file appears in the S3 bucket as an object and the contents remain the same when retrieved through the S3 API.

That is the key idea in action and even thought you're working through the file interface, S3 still stores the data underneath.

Why this matters for AI

S3 Files is clearly positioned for agents, machine learning and collaborative data-heavy workloads.

The announcement page specifically calls out file-based applications, agents and ML teams as beneficiaries. It states that AI agents can persist memory and share state across pipelines, ML teams can run data preparation workloads without duplicating or staging files first and thousands of compute resources can connect to the same S3 file system simultaneously.

That makes sense.

A lot of modern AI and ML tooling still behaves in very file-centric ways. Training inputs, checkpoints, logs, intermediate artifacts and tool-driven workflows often assume files and directories are available. Even when your long-term storage strategy is object-first, the workloads themselves may still be file-first.

Practical code example

Here's a simple way to show the difference conceptually:

Let's look at working directly with S3 objects in Python.

import boto3
s3 = boto3.client("s3")
bucket = "my-data-bucket"
key = "reports/summary.txt"
response = s3.get_object(Bucket=bucket, Key=key)
content = response["Body"].read().decode("utf-8")
print(content)

That works fine, but your code is explicitly written around the S3 API model.

Now let's review working with a mounted S3 Files path.

file_path = "/mnt/s3files/reports/summary.txt"
with open(file_path, "r") as f:
    content = f.read()
print(content)

The second version feels ordinary because it is ordinary from the application's point of view.

Security and operational details worth noting

S3 Files integrates with IAM for access control, supports identity and resource policies at both the file system and object level, encrypts data in transit with TLS 1.3 and supports encryption at rest with SSE-S3 or customer-managed AWS KMS keys. It can also monitor it using CloudWatch metrics and CloudTrail management events.

So we can treat this as a real production service with access control, encryption and observability expectations teams will need.

Key takeaways for developers

The biggest takeaway is that the boundary between object storage workflows and file-based workflows has got much easier to work across.

That matters because a lot of cloud architecture pain comes from interfaces not matching reality forces teams to build adapters, stage pipelines, duplicate storage systems and synchronize logic just to keep things moving.

S3 Files now gives you the option to say, "maybe I shouldn't have to do that nearly as often."

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

If you've got this far, thanks for reading! I hope it was worthwhile.

5 AWS Services New Developers Struggle With (And Why)

Ifeanyi O. — Tue, 07 Apr 2026 10:25:45 +0000

Intro
Identity and Access Management
Virtual Private Cloud
Simple Queue Service Vs Simple Notification Service
CloudFormation
CloudWatch
Why These Services Matter

Intro

Okay... let's be honest for a second.

When you first opened the AWS Console, which service made you pause a little longer than the others? And I don't mean in a curious way but in a “wait… what the heck is actually going on here?” kind of way.

AWS is extremely powerful and that’s part of the appeal. But with great power and limited context, you can feel overwhelmed, especially when you’re no longer working in a personal account.

Yes, there are over 200 AWS services and most teams will rely heavily on a small subset but there are a select few that almost every new developer runs into early on and quietly struggles with.

It's usually not because they’re innately complex to understand, but because they require a mental shift most new developers haven’t made yet.

In this blog, we'll address five AWS services new developers struggle with which includes, AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (VPC), knowing the difference between Amazon Simple Queue Service (SQS) and Amazon Simple Notification Service (SNS) and when to use which, AWS CloudFormation and Amazon CloudWatch.

IAM

AWS Identity and Access Management is the control plane gatekeeper. Every action performed in AWS eventually becomes an API call and every API call is evaluated by the IAM policy engine before it is allowed to proceed.

This is where new developers first encounter friction because IAM is deterministic but not always obvious. When you receive an AccessDenied error, this is the result of a precise evaluation process that has determined the request should not be allowed.

When a request is made, AWS evaluates the principal making the request, the action being requested, the resource being accessed and any conditions that apply. That principal could be an IAM user, an assumed role, a federated identity, or a service role attached to a resources like an AWS Lambda function or Amazon EC2 instance. Developers often forget that once code runs in AWS, it is no longer acting as "you" but actually acting as the role attached to the compute resource.

IAM evaluation considers identity-based policies attached to the principal, resource-based policies attached to the target resource, permission boundaries that may restrict the maximum allowed permissions of that principal and Service Control Policies (SCP) applied at the organizational level. If any applicable policy contains an explicit deny that matches the request, the request fails immediately, even if other policies allow it.

This layered evaluation model is what confuses many developers. A developer may attach a policy granting permission to read from an S3 bucket, but the bucket policy may restrict access to requests originating from a specific VPC endpoint, or the organization may enforce an SCP preventing certain API calls entirely, or the role being assumed in a CI/CD pipeline may not include the permissions the developer tested locally.

To make this more concrete, let's consider a simple identity-based policy that allows reading from an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

At a glance, this policy appears sufficient as it allows the required action on the expected resource. However, IAM does not evaluate this policy in isolation. If a bucket policy restricts access to a specific network path, or an organizational policy blocks the action entirely, or the request is coming from a different role than expected, the final decision may still be a denial. The presence of an allow statement does not guarantee access if another layer introduces a conflicting rule.

IAM also introduces conditional logic. Access can be restricted based on IP address, multi-factor authentication presence, encryption state, resource tags, or request context. Two seemingly identical API calls can produce different results based on environment.

Let's review this updated identity-based policy that introduces an additional requirement:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-app-bucket/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    }
  }
}

The same request will succeed or fail depending on whether it is made over HTTPS.

For most developers, what makes IAM difficult early is that it forces you to think like a policy engine and start asking questions like, “Which principal is making this request and which policies are being evaluated?”

However, once you understand the deterministic evaluation system of IAM policies, your debugging episodes will become more systematic and efficient.

VPC

Many developers don’t think deeply about networking early in their careers. Things usually just connect locally, APIs call databases and everything just works. However, when you join an actual team and start hearing phrases like, “It's in a private subnet,” or “The security group won’t allow that traffic,” or “There’s no route to the NAT gateway,” that's when you realize your lack of depth in cloud networking concepts and resources.

For understanding, a VPC defines the networking boundaries of your AWS environment. It determines which resources are public, which are private, how traffic flows and what is allowed to communicate with what. Subnets, route tables, internet gateways, NAT gateways, security groups and network ACLs all play a role.

The reason new developers struggle with VPC is that networking is often abstracted until things begin to fail. You might deploy a Lambda function and wonder why it can’t connect to a database. Both the function and the database exists but if they’re in different subnets without proper routing or security group rules, they might as well be on separate planets.

On AWS, connectivity explicit. Just because two resources exist does not mean they automatically can talk to each other. Traffic MUST be intentionally allowed.

Let's consider what happens when a resource needs internet access from a private subnet. That path does not exist by default and must be explicitly defined through routing.

Below is an example of a route table entry that allows traffic from a subnet to reach the internet through a NAT Gateway:

Destination: 0.0.0.0/0
Target: nat-0abc123example

This single route determines whether instances in that subnet can reach external services like APIs, package repositories, or external databases. Without it, outbound traffic has nowhere to go, even if everything else appears to be configured correctly.

Similarly, security groups act as virtual firewalls at the resource level. Even if routing is correct, traffic can still be blocked if the security group does not explicitly allow it.

For example, a database security group might only allow inbound traffic on port 5432 from a specific application security group:

Type: PostgreSQL
Port: 5432
Source: sg-0appserver123

In this case, even if another resource is in the same VPC and subnet, it will not be able to connect unless it is associated with the allowed security group so connectivity cannot be assumed. It has to be defined.

As a developer trying to grasp networking on AWS, at first, it might feel like a maze with invisible walls... and that's okay. Once you start visualizing the path a request takes, from the client through a load balancer, into a subnet, through a security group and into a database, understanding VPC will become easier to reason about.

SQS vs SNS

Almost every new developer gets confused by Amazon SQS and Amazon SNS at some point. They both move messages, are used in event-driven systems and are often mentioned together in architectural diagrams. So the question is... what’s the difference?

For starters, Amazon SQS is basically a queue. Messages sit there until something pulls them and processes them. On the contrary, Amazon SNS is a publish-and-subscribe service where messages are pushed to subscribers when they are published.

This sounds simple, but the confusion comes from how they’re used together. You’ll see architectures where an S3 event triggers an SNS topic, which then fans out to multiple SQS queues, then trigger Lambda functions or you’ll see an SNS topic directly invoking endpoints and maybe EventBridge involved somewhere in the mix. As more services are integrated, suddenly, the flow of data feels less obvious.

Let's review what it looks like to publish a message to an SNS topic:

import boto3

sns = boto3.client('sns')

response = sns.publish(
    TopicArn='arn:aws:sns:us-east-1:123456789012:my-topic',
    Message='Order created'
)

The moment this message is published, SNS immediately pushes it to all of its subscribers. That could include multiple SQS queues, Lambda functions, or even HTTP endpoints. The publisher does not need to know who those subscribers are, it simply emits the event.

Now compare that to SQS. Messages are not pushed to consumers, they remain in the queue until something explicitly retrieves (pulls) them:

import boto3

sqs = boto3.client('sqs')

response = sqs.receive_message(
    QueueUrl='https://sqs.us-east-1.amazonaws.com/123456789012/my-queue',
    MaxNumberOfMessages=1
)

messages = response.get('Messages', [])

In this case, the consumer is responsible for polling the queue, retrieving messages and processing them. If no consumer is running, the message simply stays in the queue.

The real struggle here is not in the intricacies of the syntax of the services, it's more about the architectural thinking that's require here. You have to ask questions like, "Do I need multiple consumers?", "Do I need messages to persist until they’re processed?", "What happens if a consumer fails?", "Will this message be retried?", "Could it be processed twice?" and this is where the distinction becomes meaningful.

SQS gives you durability and control over processing. Messages persist until they are handled, which makes it useful when you need reliability and buffering between systems. SNS gives you immediacy and fan-out. It is designed to broadcast events to multiple systems at once without tightly coupling them.

Additionally, messaging introduces distributed systems concepts like at-least-once delivery and idempotency. For many developers, this is the first time they have to think beyond simple request-response patterns like when a message may be delivered more than once, a consumer may fail mid-processing, or systems may process events at different speeds.

This is how SQS and SNS can feel confusing complex early because the real challenge is understanding how they behave when systems are no longer tightly connected and operations don't happen in a single request-response cycle.

CloudFormation

At some point, you’ll try to modify a resource in the AWS Console and get a message telling you that the resource is managed by CloudFormation and that's you'll realize that you’re interacting with infrastructure defined as code.

AWS CloudFormation allows teams to define infrastructure in templates and deploy it as stacks and those stacks become the source of truth. If something is defined in a template, manual console changes are temporary at best and overwritten at worst.

New developers struggle here because it requires discipline and patience. You can’t just click and tweak something quickly, you need to find the template, understand how the resource is defined, update it properly and redeploy the stack. Additionally, when a stack update fails, the error messages can be intimidating.

Let's look at a simple CloudFormation template that defines an S3 bucket:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-app-bucket-123

This template does not describe how to create the bucket step by step. Instead, it defines that a bucket with this name, my-app-bucket-123, should exist. When deployed, CloudFormation creates and manages that resource as part of a stack.

If you later change the bucket name in the template and redeploy, CloudFormation will determine what needs to change to match the new desired state. That might mean replacing the resource entirely, which is why understanding updates is just as important as initial creation.

CloudFormation forces you to think declaratively. Instead of saying, “Create this resource,” you define the desired state and let AWS reconcile the difference. It’s a powerful approach, but it changes how you work. It also means most of what you’re touching likely existed before you arrived and was created intentionally through code.

New developers have to intentionally learn to stop treating the console as the place to make changes and start treating CloudFormation templates as the source of truth. Once you understand that every update goes through the stack, even when something fails, you'll know where to look to fix it.

CloudWatch

As a new developer, you'll be focusing on building features so observability can sometimes feel like a secondary task. However, the minute something breaks in production, then suddenly logs and metrics are all anyone cares about.

Amazon CloudWatch is where you go to understand what your systems are actually doing in real time as it handles logs, metrics, alarms and dashboards but it does not interpret the data for you. What you get is raw signals that you have to make sense of them.

You might open a log group and scroll through hundreds of lines without knowing what you’re looking for, or see a metric spike but not know what "normal" even looks like, or even wonder why an alarm didn’t trigger when you expected it to.

Let's look at what a simple log entry from a Lambda function might look like:

2026-03-31T14:22:10.123Z  ERROR  Failed to process orderId=12345
Traceback (most recent call last):
  File "/var/task/app.py", line 42, in handler
    process_order(order)
Exception: Database connection timeout

At a glance, this tells you something failed, but in a distributed system, this is rarely the full story. The database might be in a different subnet, behind a security group, or experiencing latency issues, so the log gives you a clue, but it's not the complete answer.

Now consider a metric that tracks errors over time:

Metric: Errors
Namespace: AWS/Lambda
Statistic: Sum
Period: 5 minutes

If this metric spikes, CloudWatch can trigger an alarm:

Alarm: LambdaErrorAlarm
Threshold: Errors > 5
Evaluation Period: 1 datapoint
Action: Send notification to SNS topic

Even here, interpretation is required. Is five errors in five minutes abnormal? Is that a real issue or expected behavior during traffic spikes? CloudWatch provides the signal, but it does not define what is meaningful.

The challenge here is that debugging in distributed systems is very different from debugging locally. There’s no single stack trace that tells the whole story and you have to piece together information across services.

The good news is overtime, you will build intuition and learn which metrics matter, how to structure logs and when to create alarms. But early on, CloudWatch can feel overwhelming as it exposes the complexity of production systems in it's full detail.

Why These Five Services Matter

As a new developer, these five services show up early because they sit at the foundation of how systems are built and operated.

IAM teaches you to think in terms of identity and authorization, VPC teaches you to understand network boundaries and traffic flow, SQS and SNS introduce you to distributed and event-driven thinking, CloudFormation forces you to respect infrastructure as code and existing systems and CloudWatch pushes you to think operationally and observe before you optimize.

They represent transitions in how you think as a developer working in the cloud.

If you’re struggling with one of them right now, don't worry. It’s usually a sign that you’re growing. Every developer who works seriously in AWS goes through a growing phase. The difference over time is that what once felt confusing will eventually become familiar.

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

5 Common AWS Errors New Developers Hit (And How to Fix Them)

Ifeanyi O. — Wed, 11 Mar 2026 10:00:00 +0000

Intro
AccessDenied
InvalidClientTokenId
ThrottlingException
ResourceNotFoundException
ValidationException
Patterns Behind the Errors

Intro

You take pride in writing clean code...
You've passed all the technical interviews...
You've shipped features locally without breaking anything...
Then you attempt to deploy in a real AWS environment, and quickly get humbled.

If you’ve read my previous blog post about starting your first developer job in an AWS environment, then you know the moment I’m referring to. You log into the console at work and notice resources that existed long before you arrived, with names that look autogenerated and dashboards that are lighting up.

Then after a few weeks of getting comfortable, you try to deploy a feature or call an API for the first time, and you're stopped in your tracks by an AccessDenied error message.

You feel confused at first because nothing seems obviously wrong. Your code runs, your logic is sound and yet AWS still tells you, "you can't pass through!". That's when you learn the lesson that AWS operates on very strict rules around identity, permissions, configuration, quotas, and validation. It is extremely literal so if something does not meet its expectations exactly, it will reject the request.

Every developer, no matter how experienced, will stumble on AWS error messages so you're not going to avoid them entirely. However, in this blog, we're going to help you understanding what these error messages mean, how to both resolve them and reduce the chances of stumbling into them in the first place.

Now let's walk through these 5 common errors messages, AccessDenied, InvalidClientTokenId, ThrottlingException, ResourceNotFoundException and ValidationException.

AccessDenied (Nope! You're not allowed to do that!)

If there's one error message that will shape your first year working with AWS, it's the AccessDenied error message.

This error does not necessarily mean your code is syntactically wrong, or your logic is flawed. Actually, it means AWS fully understood what you asked it to do but intentionally rejected the request because your identity is not authorized to perform that action.

Most of the time, this traces back to Identity and Access Management. You might be trying to read from an S3 bucket, or invoke a Lambda function, or attach a role to a resource, but the IAM principal you're currently operating as does not have permission to perform that specific API action on that specific resource.

In more subtle cases, you might be in the wrong AWS account entirely, or targeting the wrong region and sometimes the missing permission is not obvious, such as iam:PassRole when a service needs to assume a role on your behalf.

When I first started working in real AWS environments, I thought an AccessDenied error message meant I'd made a personal mistake because I assumed I'd configured something incorrectly. Then, I later learned it was a deliberate guardrail my manager had set to limit what I could do in a specific AWS account, which was a good thing. In case you didn't know, most developers will never have full access to the AWS environment at their jobs.

When resolving an AccessDenied error, your first step is to confirm that you’re actually supposed to have access. Once that’s clear, your next question should be, "who am I right now?" In AWS, access is entirely based on identity, so before you assume the problem is a missing permission, you need to verify which principal is actually making the request. One of the fastest ways to answer that question is to ask AWS directly using the AWS CLI in your terminal:

aws sts get-caller-identity

That command returns the account ID and ARN of the user or role you’re currently authenticated as, immediately telling you whether you’re in the wrong AWS account, assuming an unexpected role, or using a different profile than you thought.

From there, you can ask more specific questions like, "Am I using the correct IAM role?", "Am I authenticated through the expected SSO profile?", or "Am I running this from my local machine, from a CI/CD pipeline role, or from within a Lambda function?" Each of those execution contexts has a completely different permission set, and many AccessDenied errors often result from operating in a context you didn’t intend.

From a reactive standpoint, the fastest way to debug AccessDenied error message is to read the full message carefully. AWS often includes the exact action that was denied and the ARN of the resource involved that tells you precisely which permission is missing. From there, you can inspect the attached IAM policies for your user or role and verify whether that action is allowed on that resource. If you're working in an organization with Service Control Policies, you may also need to check whether a higher-level restriction is blocking the action even if your local role appears correct.

So how can we limit AccessDenied errors so they don't slow you down?

One practical way is to design with least privilege intentionally instead of retroactively. When you're creating a new role for a service, take a few extra minutes to identify exactly which API calls it will need and grant those explicitly. If you're using infrastructure as code, strive to define IAM policies alongside your compute resources so permissions evolve with your application rather than lag behind it.

Another proactive habit is verifying your execution context before running critical operations. Make sure you get comfortable checking which AWS account and region you're currently in and confirming which IAM role your CLI profile or deployment pipeline is using because many AccessDenied issues are a result of operating in an unexpected environment.

InvalidClientTokenId (Yo! I don't know who you are)

InvalidClientTokenId usually shows up when you're working with the CLI, an SDK, or running code from your local environment. At first glance, this error message reads like something is fundamentally broken, but in reality, it's really straight forward.

It means the credentials attached to your request are either invalid, expired, or not the correct identity you think you're using.

Every AWS request is cryptographically signed so when you authenticate, AWS provides credentials that allow you to generate a signature proving who you are. That signature includes your access key and a timestamp and if the token is expired, malformed, revoked, or tied to access a different account than expected, AWS rejects the request immediately before even checking permissions. In other words, this is not about what you're allowed to do but whether AWS trusts who you are.

You’ll often see it surface in even the simplest SDK call:

import boto3

s3 = boto3.client("s3")
response = s3.list_buckets()
print(response)

If your credentials are expired or incorrect, AWS will respond with something like:

An error occurred (InvalidClientTokenId) when calling the ListBuckets operation:
The security token included in the request is invalid.

Notice that this happens before any permission evaluation because the request fails at the identity layer.

Early in my career, I lost more time to this error than I want to admit. I would question my app logic, inspect config files, and re-run deployments but eventually, I realized that whenever AWS complains about tokens, client identity, or security credentials, the problem is almost always contextual.

For a proactive debugging path, first confirm which AWS profile is currently active. If you're using AWS SSO, attempt to refresh your session. If you're using long-term credentials, confirm they haven't been rotated or invalidated and check for environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_PROFILE that may be overriding your expected configuration. If you're inside a container or CI/CD pipeline, verify which role is being assumed and whether it is still valid.

Another common scenario, is accidentally switching accounts. You might have authenticated successfully, but into the wrong AWS account. From the perspective of AWS, your token is valid, but not for the resources you're trying to access.

So before running critical commands, know exactly which identity you are operating as, be explicit about profiles instead of relying on defaults and in multi-account environments, make the current account visible in your prompt or logging output. As for CI/CD pipelines, try to surface the assumed role clearly in logs so it's not ambiguous which identity is making requests.

Lastly, always keep in mind that credential lifetimes are temporary credentials designed to expire so you'll intentionally need to build your workflows around refreshing sessions and not assume they'll last indefinitely.

ThrottlingException (Dude! Slow down!)

When you see a ThrottlingException or TooManyRequestsException error message, understand that AWS is enforcing limits to prevent you from overwhelming a system.

Every AWS service operates with defined quotas and internal protection mechanisms and these limits exist to preserve stability, fairness, and predictable performance across millions of customers. When your request rate exceeds what the service can handle at that moment for your account, AWS responds by throttling you.

New developers often hit this error message unintentionally because it's easy to write code that scales requests unintentionally, like a loop that calls an API hundreds of times per second or a Lambda function that scales concurrency faster than expected. In your local development, you rarely think about rate limits because everything runs in-process but in distributed systems, request pacing is an important part of the architecture.

When a ThrottlingException or TooManyRequestsException error message appears, the first question to ask is whether the throttling is burst-based or sustained. If it resolves quickly, you likely experienced a short spike but if it persists consistently, you may be exceeding configured quotas or overloading a particular resource.

The immediate instinct is often to retry immediately, but that can actually make the problem worse. The fix is to control retry logic using exponential backoff so requests slow down progressively instead of hammering the service.

Most AWS SDKs include retry logic automatically, but you should understand how it works and configure it intentionally when necessary. For example, in Python using Boto3, you can define retry behavior like this:

from botocore.config import Config
import boto3

retry_config = Config(
    retries={
        "max_attempts": 10,
        "mode": "standard"  # or "adaptive"
    }
)

dynamodb = boto3.client("dynamodb", config=retry_config)
response = dynamodb.list_tables()
print(response)

The standard mode applies exponential backoff, while adaptive adds client-side rate awareness. In short spikes, this can mean the difference between graceful recovery and cascading failure. When throttling persists consistently, however, it may indicate that you are exceeding a quota or that concurrency needs to be adjusted. Observability will play a critical role here for have visibility into what's actually happening. Some key metrics you'd want to monitor are, request counts, error rates, and service quotas so you understand whether you’re dealing with bursts or sustained pressure.

ResourceNotFoundException (That doesn’t exist. At least not here)

Few things are more confusing than seeing a resource clearly visible in the AWS Console while your application insists it doesn’t exist. When you encounter a ResourceNotFoundException, the instinct is often to assume AWS is contradicting itself. It usually isn’t.

AWS resources are almost always scoped to a specific region and account. If your Lambda function lives in us-east-1 and your CLI or SDK is configured for us-west-2, AWS is absolutely correct when it says the resource does not exist, because it does not exist in that region.

This is easy to miss in code. For example:

import boto3

lambda_client = boto3.client("lambda", region_name="us-west-2")

response = lambda_client.get_function(
    FunctionName="my-production-function"
)

If that function actually lives in us-east-1, this call will fail with ResourceNotFoundException. Simply being explicit about region can eliminate ambiguity:

lambda_client = boto3.client("lambda", region_name="us-east-1")

The same applies to account boundaries. A resource in one AWS account is completely invisible to another unless explicitly shared through mechanisms like cross-account access.

There are other subtle variations of this issue as well, for example, the ARN might be malformed or the resource ID contains a small typo. Other more nuanced causes are, a resource might been deleted and recreated with a slightly different identified or an application might be running in an execution context that doesn't have visibility into the resource even though it exists.

When you encounter the ResourceNotFoundException error message, resist the urge to immediately question AWS but instead, verify your context. Confirm the AWS account you're operating in, confirm the region config in your SDK or CLI, log the exact ARN or resource identifier being used in the request and check environment variables and configuration files to confirm they are pointing to the environment you expect.

One of the fastest debugging tips here is printing out the region and account identity at application startup. When something fails, you want immediate clarity about where you're operating from. Many “missing resource” errors are simply requests being sent to the wrong environment.

Additionally, try not to rely on defaults and ambiguous configurations that changes between development and production. In team environments, document which accounts and regions are responsible for which workloads and name resources in ways that make their environment obvious. When using multiple accounts, consider standardizing environment variables or deployment conventions so region and account targeting are always intentional.

ValidationException (Your input doesn’t meet the rules!)

ValidationException error messages show up across many AWS services and often feels frustrating because it can appear generic at first. However, they mean your request did not satisfy one or more of the service’s defined constraints.

AWS APIs operate on contracts and every operation has required parameters, allowed values, length limits, formatting rules, and structural expectations. If any part of your request violates that contract, the service rejects it immediately.

This could mean a required field is missing or an ARN is malformed, a numeric value exceeds an allowed range or even something as subtle as incorrect casing in an enumerated value. For example, consider creating a DynamoDB table:

import boto3

dynamodb = boto3.client("dynamodb")

response = dynamodb.create_table(
    TableName="Users",
    AttributeDefinitions=[
        {
            "AttributeName": "userId",
            "AttributeType": "STRING"  # Incorrect value
        }
    ],
    KeySchema=[
        {
            "AttributeName": "userId",
            "KeyType": "HASH"
        }
    ],
    BillingMode="PAY_PER_REQUEST"
)

In this case, STRING is invalid. DynamoDB expects S for string types. That small mismatch causes a ValidationException because the input does not match the expected schema.

A common mistake new developers make is not slowing down enough to read what the error message is clearly telling them. AWS is usually very explicit about what went wrong, like whether a required field is missing, a value doesn’t match the expected pattern, a data type is incorrect, or a maximum length constraint was exceeded.

To solve this error, you can examine the exact request being sent and compare it line by line with the official API documentation, confirm that required parameters are present and verify formats for ARNs and resource identifiers, double-check enum values and numeric limits and if you're using an SDK, log the final constructed request object to confirm it matches your expectations.

I believe it's worth checking whether your configuration has been modified by environment variables or defaults that differ across environments. A configuration that works in development may fail in production if a required parameter is missing or structured differently.

You should also treat infrastructure definitions and service configurations as strongly typed artifacts rather than loosely structured text. I strongly recommend using infrastructure-as-code tools that perform validation before deployment and linters or schema validation tools where possible to validate input early so malformed data never reaches AWS APIs.

Patterns Behind the Errors

As a new developer at your job, you might feel like you're constantly unexpectedly running into AWS error messages, but understand that this is all part of becoming more experienced in the cloud.

Overtime, you'll begin to notice that most error messages fall into the predictable categories of identity and authorization issues, permission boundaries, scope mismatches, validation failures, or scale constraints.

As you gain experience, your debugging process will become much calmer and structured instead of reactive and scattered because you'll be able to classify error messages into one of those buckets within the first few seconds.

I am curious to know though, which one of these AWS error messages trip you up the most or is the most frustrating to see?

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

Everything You Need to Know About AWS for Your First Developer Job

Ifeanyi O. — Tue, 10 Feb 2026 11:12:37 +0000

A real-world guide for day-one developers

Intro
Your First Surprise
AWS Categories
Your Terminal Is Important
It Already Existed
Think Serverless
Changes in Prod
Observe Before You Optimize
Cost Will Show Up
Structure from Certifications
What Really Matters

Intro

You just landed your first developer job! Congratulations!

You’re excited, proud and already imagining what it’ll be like to finally build things for real, not just for personal projects and experimentation.

Day one comes around, you open your new company laptop, join a few team channels, and begin receiving access to an AWS account, or maybe several.

You notice pipelines you didn’t create, services you recognize by name but not by behavior and permissions you don’t fully understand.

You might even see things like Amazon S3 buckets, AWS Lambda functions, Amazon API Gateway endpoints, Amazon CloudWatch dashboards, and a few AWS IAM roles with names that look like they were created by someone in a hurry.

And that’s when it hits you. You didn’t actually know what to expect.

You want to do well and increase the possibility of ramping up quickly to make a good impression and avoid being the person who breaks something important or feels lost for weeks. You start asking yourself, what should you already know, what should you focus on first, and how do people actually work with AWS day to day.

Don’t worry, I’ve got you! This post is for that moment.

This post is for developers preparing to start their first job working with AWS and trying to figure out how to be ready before and after day one. We’ll go beyond theoretical and lean into what’s practical.

We'll tackle what to understand, what to pay attention to, and what should be running in the back of your mind as you start working inside a real company's AWS environment.

Your first surprise comes quickly

One of the first thing you'll notice is that AWS at your job feels very different from the AWS environment you learned tutorials and built projects in.

A mental shift that helps is realizing you didn’t get hired to “learn AWS” in the abstract. There’s no clean starting point. There's no empty account waiting for you to build the “right” architecture. Instead, you’re stepping into an already existing system that includes, accounts, environments, pipelines, permissions, processes, conventions. All of it built for reasons you don’t fully understand yet.

AWS is vast. There are more than 200 services, which is exciting but as a first time developer, can be annoying at the same time. The good news is that most teams don’t use them all. In day-to-day work, AWS usually shows up in a few main technical areas like compute, storage, networking, security, databases, analytics, artificial intelligence, machine learning, observability, and deployment tooling. If you learn how your team uses those areas, the rest starts to feel manageable.

It’s easy to feel behind here. A lot of new developers assume everyone else knows what’s going on and they’re the only one catching up. That assumption is almost always wrong! What matters early is not how much you know but how well you learn the shape of the system you just joined.

AWS categories you need early

It helps to mentally group AWS into the big categories developers actually work in.

Compute is where code runs. This could be AWS Lambda for serverless functions, Amazon EC2 for virtual machines, or containers on Amazon ECS or Amazon EKS. Storage is where files and artifacts live, usually in Amazon S3. Databases hold application state, commonly stored in Amazon DynamoDB or Amazon RDS. Networking is how services connect and communicate safely, which is where Amazon VPC, subnets, security groups, and load balancers like an Application Load Balancer show up. Security sits across everything through Amazon IAM, AWS KMS, and network boundaries. Observability is how you see what’s happening in your systems in production through services like Amazon CloudWatch and AWS X-Ray, and audit trails like AWS CloudTrail.

You absolutely do not have to master all of these in week one, you just want enough familiarity to recognize what you’re looking at so you can ask more effective questions.

You're stepping into your company's AWS environment, not a lesson plan

Know that you got hired to work inside a specific AWS environment that already supports real users and real business needs.

Your immediate objective is to understand how things work well enough to change them without causing damage, how code gets deployed, how services talk to each other, how failures are noticed and handled and how access is controlled.

A simple but powerful habit in your first week is getting clarity on where you are. Answer questions like, which AWS account are you in, which region are you in, are you in a development, staging, or production environment.

AWS Regions and Availability Zones matter because they shape latency, resilience, and where resources physically live. If you hear someone say “this is in us-east-1” or “that workload is multi-AZ,” they’re not trying to test your alphanumeric understanding, they're just giving context to where and how resources are deployed.

When I made my own transition into tech from a completely different career, this took time to sink in. Before the cloud, I was a professional athlete. Progress in that career, came from understanding the system you were competing in and improving inside it. AWS turned out to be similar. Once I stopped trying to know everything and started trying to understand the environment I was in, the learning curve flattened out.

Your terminal becomes important very fast

Early on, you’ll probably write less code than you expected. That’s normal!

Most of your first week is about setup. Getting your local environment working the way your team expects. Installing the AWS CLI. Understanding how authentication works at your company. Maybe it’s AWS IAM Identify Center for Single Sign-On (SSO), maybe it’s using temporary credentials through AWS Security Token Service or maybe it’s multiple CLI profiles tied to different accounts.

However it’s done, you want to understand how requests from your laptop become actions in AWS. That clarity makes debugging easier and gives you confidence when something doesn’t work.

The AWS Console is useful, especially when you’re new but the terminal is where most developers spend their time once they’re comfortable. It’s faster, repeatable, and closer to how things actually run in automation.

Permissions are usually the problem

At some point, something will fail in a way that doesn’t make sense. Your code looks right. The resources exist. You'll try it again and receive the same result.

This is usually where permissions enter the picture. Permissions is one of the first debugging steps to check when you’re receiving errors while trying to read or change resources.

Identity and access controls are at the center of AWS, and they trip everyone up early on. A lot of issues aren’t logic errors at all but they’re actually boundaries set that are doing exactly what they’re supposed to do. In real environments, you’ll run into IAM roles and policies, resource-based policies like Amazon S3 bucket policies, and sometimes encryption rules enforced through AWS KMS.

Once you start thinking in terms of who is making a request, what they’re allowed to do, and which resource is involved, AWS permissions becomes easier to reason about. Treating IAM as a core skill early, and learning to recognize permission failures will quickly save you a lot of debugging frustration.

Most of what you touch already existed before you arrived

At your new job, you will inherit infrastructure before you will design anything new.

That infrastructure is usually defined as code using Infrastructure as Code (IaC) tools like AWS CloudFormation, AWS CDK or Terraform. These tools allow infrastructure to be versioned, reviewed, and deployed like application code. Even if you’re not writing it yet, learning how to read it matters!

You’ll also start noticing where that infrastructure connects to delivery workflows. If your team uses AWS CodePipeline and AWS CodeBuild, or even a mix like GitHub Actions plus CloudFormation, then these are the path your developer changes will follow.

Being able to tell what will change before it changes is how teams avoid breaking production. Developers who take the time to understand existing infrastructure build trust quickly because they’re showing respect for the system.

Serverless may force you to change how you think

There’s a good chance your new role involves serverless, and that’s another adjustment.

You will have to pause to stop thinking primarily about servers and start thinking about triggers and events. For example, an API request comes into Amazon API Gateway and invokes an AWS Lambda function, a file upload lands in Amazon S3 and triggers processing, a message arrives in Amazon SQS or Amazon SNS and kicks off work, an event is routed through Amazon EventBridge, a workflow spans multiple steps using AWS Step Functions and an application’s state that lives in Amazon DynamoDB.

This mindset will affects how you write code and how you handle failure. You'll start caring about retries, idempotency, and visibility earlier because distributed systems fail in messy ways. You'll also start thinking about scalability differently because serverless services scale automatically, but they still have limits and concurrency behaviors you need to understand.

Learn how changes reach production before making one

Before you ship anything meaningful, it helps to understand how a change actually makes it to production.

Figure out what starts the deployment process. Learn whether approvals are needed. Understand how environments are separated. Ask what happens when something fails and how rollbacks are handled.

If your team uses AWS CodePipeline, GitHub Actions, GitLab or a Git-based workflow, watch a few deployments go through before you touch anything major. This will be critical to understand because when things go wrong, the calmest developers are usually the ones who understand the delivery system.

Knowing this upfront will keep you from guessing later, and make you calmer when you do ship your first change.

Observe before you optimize

Production systems don’t always announce problems clearly. Logs, metrics, and traces are how you will figure out what’s happening when you’re not watching. In serverless environments especially, they’re your only way to real visibility.

You’ll likely spend time in Amazon CloudWatch Logs and Metrics, and in some environments you’ll also use AWS X-Ray for tracing. When someone asks “who changed this,” that’s where AWS CloudTrail becomes useful because it shows all API activity to help you understand what happened.

Spending time early just observing how systems behave helps you build intuition. Over time, you start to recognize what normal looks like, which makes it easier to spot when something isn’t.

Cost will show up sooner than you expect

It’s better to learn this early because contrary to the tutorials you’ve done, developing on AWS at your job is not purely technical. There’s an economic side to operating in the cloud that directly affects your company’s business.

Every decision has a cost attached to it. You don’t need to be perfect about this early on, but you should be aware. Leaving things running, misconfiguring resources, or forgetting to cleanup adds up quickly. In most teams, you’ll use AWS Cost Explorer and AWS Budgets, and some will rely on the Cost and Usage Report for deeper reporting. Tagging resources also matters more than people expect because it’s how teams attribute cost to systems and owners.

Developers who pay attention to cost tend to think more carefully about trade-offs, and that mindset shows maturity. It also signals that you understand you’re building for a business, not just for a demo.

Certifications can help if you want structure

You don’t need a certification to be successful in your first AWS developer job. Plenty of great developers never pursue one. That said, certifications can be genuinely useful when you’re feeling overwhelmed and want a structured way to build familiarity with AWS and how things fit together.

The real value is often in the process of studying, not the exam itself. Preparing for an AWS certification forces you to slow down and learn how AWS expects systems to be build and architected well.

During this process, you'll start to see recurring patterns around compute, networking, security, storage, scalability, and fault tolerance. You'll also begin to understand why certain services are paired together and why some designs are preferred over others. That kind of exposure helps you develop better instincts long before you’re asked to design anything on your own on the job.

If you’re early in your journey and want a broad foundation, the AWS Certified Cloud Practitioner can help you build vocabulary and basic cloud context. It introduces you to core services, shared responsibility, pricing concepts, and the global nature of AWS without going too deep too fast.

If you want to go a level deeper into what you’ll actually see in a developer role, the AWS Certified Developer Associate and the AWS Certified Solutions Architect Associate certifications are a natural next steps.

The AWS Solutions Architect Associate focuses on how systems are designed on AWS as a whole. You spend time thinking about cost efficiency, performance, reliability, and scalability. You learn how different services work together and how architectural decisions affect long-term outcomes. For many, this certification is where AWS stops feeling like a collection of isolated services and starts feeling more cohesive.

Studying for the AWS Developer Associate exposes you to how applications are built and deployed on AWS. It includes topics like serverless development, CI/CD workflows, monitoring, and troubleshooting, which will help you understand how code behaves once it leaves your laptop and runs in AWS.

These certifications are accelerators for learning and will help you stay oriented while you’re building experience, but know that they are not the destination. You can always look into pursuing many other AWS or industry certifications offered but remember, the magic only happens when you apply those concepts on the job, one change, one system and one debug session at a time.

Expectations and what really matters

For your first AWS developer job, you're not expected to be an expert. Early success looks like learning how to operate inside a complex system, asking good questions, making safe changes, understanding impact, and improving steadily.

That approach is what helped me move from a completely different career into cloud development, and it’s what I’ve seen work consistently for others. Your journey of a new developer on AWS will depend on how you take the time to understand the environment you’re working in.

If you do that, you’ll ramp up faster than you think and set yourself up for everything that comes next.

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

DEV Community: Ifeanyi O.

I Built My Mom an AI Recipe Helper for Mother's Day

My Mom's Problem

What it does in 30 seconds

Why an agent and not a prompt

The tools and why there aren't very many

Preference handling

The "send a photo of your groceries" part

The Architecture

What it costs me to keep it running

Try it yourself

The Hug

Credits

How to Survive Your First 90 Days as a Developer

Table of Contents

Intro

Understanding the Psychological Transition

Establishing Clarity Through Your Manager

Learning the System Before Trying to Prove Yourself

Choose Depth Over Breath to Narrow Your Focus

The Codebase Is Where Everything Comes Together

Relationships Will Accelerate Your Growth More Than You Expect

What a Strong First 90 Days Actually Looks Like

Final Conclusion

Amazon S3 Files Is Still Not A File System

Table of Contents

Intro

So what is S3 Files?

What changed for developers

How S3 Files works at a high level

Why this matters for AI

Practical code example

Security and operational details worth noting

Key takeaways for developers

5 AWS Services New Developers Struggle With (And Why)

Table of Contents

Intro

IAM

VPC

SQS vs SNS

CloudFormation

CloudWatch

Why These Five Services Matter

5 Common AWS Errors New Developers Hit (And How to Fix Them)

Table of Contents

Intro

AccessDenied (Nope! You're not allowed to do that!)

InvalidClientTokenId (Yo! I don't know who you are)

ThrottlingException (Dude! Slow down!)

ResourceNotFoundException (That doesn’t exist. At least not here)

ValidationException (Your input doesn’t meet the rules!)

Patterns Behind the Errors

Everything You Need to Know About AWS for Your First Developer Job

Table of Contents

Intro

Your first surprise comes quickly

AWS categories you need early

You're stepping into your company's AWS environment, not a lesson plan

Your terminal becomes important very fast

Permissions are usually the problem

Most of what you touch already existed before you arrived

Serverless may force you to change how you think

Learn how changes reach production before making one

Observe before you optimize

Cost will show up sooner than you expect

Certifications can help if you want structure

Expectations and what really matters