Table of Contents
- 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.
Top comments (2)
This is such a generous post. The part about reframing progress as "do I understand more today than yesterday" is something I wish I'd heard more in my early days in tech. 🙌
Thank you so much Esin! It's all about the incremental progress!