My own experience has mostly been positive. I worked with managers who took these conversations seriously. The good one-on-ones were never a ritual to survive. They helped me think clearly, get unstuck, and leave with a better plan.

When I asked people about their experience, I heard the same split, and you can see it in the replies here:

Working on a new post about 1 on 1 meetings, and how they can be extremely valuable for one, but worthless for the other.

I'm lucky that I've had great mentors and managers, so in my experience they have been extremely valuable, but I hear different experiences.

What is your...

— Joachim Zeelmaekers (@joachimz_me) February 27, 2026

Some one-on-ones genuinely shaped careers. People felt seen, challenged, and supported. They still reach out to former leaders because those conversations mattered.

Others felt like calendar fillers. Status updates disguised as coaching. A manager trying to track activity instead of improving conditions.

The difference was intent.

The best one-on-ones happened when the manager showed up curious. Curious about what was blocking me, what was slowing me down, and what I needed to grow. The worst ones happened when there was no preparation.

That is why one-on-ones are powerful, even though not all of them are perfect, they give YOU the perfect opportunity to grow.

The question is, will you take that opportunity?

Preparation

The one-on-ones that failed for me were predictable:

• no clear goal or agenda
• no evidence of progress
• no concrete ask

In short, no preparation.

When that happens, the conversation defaults to updates, logistics, and whatever fire happened that week.

None of that is bad. Some one-on-ones should be casual like this. But I am talking about the ones that are meant to help you grow.

The meeting is not where growth happens

I used to think one-on-ones were where growth happened.

Now I think they are where growth is evaluated.

The real work happens before and after the meeting:

• pick a skill to improve
• practice it in real work
• ask for targeted feedback
• adjust based on what you learned

Your manager can support this process. But they cannot run it for you.

What to bring to every one-on-one

Once a one-on-one is properly structured, they get much better. So make sure to structure them. You don’t like the format? Change it.

Here are the four things that worked for me.

1. A short wins list

Not for ego. For evidence.

What did you deliver? What improved? What impact did it have?

You can shortly discuss it with your manager, and at the same time you can use it for future evaluations. Win-Win!

2. One blocker

Not a list of complaints. One blocker that matters.

Maybe your pull requests take too long to merge. Maybe stakeholder alignment is messy. Maybe you freeze in architecture discussions.

Pick one. Make it specific. That way it can be talked about, reviewed and actioned.

A good manager does not need this meeting to track your tasks. There are better systems for that. The meeting is more useful when it focuses on what is preventing good work.

3. One skill gap you are working on (optional sometimes)

This is the part most people skip.

Say it directly: I need to improve at X. Here is how it shows up and this is what I’ll be doing about it.

Examples:

• turning ambiguous tasks into executable plans
• giving clear technical updates to non-technical stakeholders
• writing smaller, easier-to-review pull requests

This will be a way to keep yourself accountable on the next session. Did you really improve, or were these just meaningless words?

4. One concrete ask

This one depends on the frequency of your one-on-ones. If you have a weekly one, asking for something every week can feel very needy.

But a general rule of thumb should be if your one-on-one ends without an ask, do not expect much to change.

Your manager is busy. They cannot read your mind, so if you don’t ask for anything, expect nothing.

Ask for something actionable:

• Can I lead the next retrospective?
• Can we define what senior-level ownership looks like for my scope?
• Can you review my design doc and challenge my assumptions?

The least you can get is a no. So ask what you want to ask, and make it clear.

Development plans that actually survive

Most development plans start strong and then disappear. It’s easy to create a plan, but it’s hard to execute it.

Not because people are lazy. The opposite actually.

I struggled with this a lot. I always prioritized my work over my personal development time. Not because I didn’t want to do it, but more because I felt I had to work harder, do more. But ultimately, it makes you do less in the long run.

What worked better for me was treating growth like a real project, because real projects are exciting and make me want to work on it. You also have something to show for, which gives that same dopamine as finishing tickets, or implementing new features.

So where can I start, you might ask? Build a six-month plan, then break it into trackable pieces.

Six months is long enough to change behavior and short enough to stay grounded.

A simple structure:

• Pick one growth theme for six months.
• Define what “better” looks like in observable terms.
• Break it into monthly focus areas.
• Create one monthly opportunity to practice.
• Review monthly and adjust.

“Become a better leader” is not a plan.

“Over the next six months, lead one cross-team technical discussion per month, write a short recap, and ask two stakeholders for written feedback each time” is a plan.

The uncomfortable part

It is easy to say my manager is not helping me grow.

Sometimes that is true. Some managers are not the best coaches. Some environments are genuinely limiting. Some organizations split people management and technical leadership, which is makes you focus on one or the other, instead of working on both.

But in many cases, the harder truth is this: we expect growth to happen around us, not through us.

We wait for better projects, better timing, better guidance, better recognition.

Meanwhile, weeks pass, then months.

One-on-ones do not create progress by themselves. They reveal whether progress is happening. If every meeting feels the same and something is not moving. That is the moment to reset expectations and change the inputs.

Final thought

One-on-ones matter. Development plans matter.

But they are not magic.

If you’re not coming up with anything, and your manager is not delivering what you’re expecting, you will stay where you are indefinitely.

It’s up to you to make things happen.

I hear a lot of complaints about it. It’s harsh, it demotivates people, it slows down shipping. And in some case, that’s true. When code reviews are used to gatekeep or show superiority rather than improve the work, they’re genuinely harmful. That’s not okay, and I’m not going to defend that.

But I think something gets lost in those complaints. Something worth examining.

The woodworker’s table

Imagine you’re a hobbyist woodworker. You’ve spent weeks building a table. In your mind, it’s perfect. Exactly how you envisioned it. But before you let your family sit around it at dinner, you invite a professional woodworker to take a look. Someone with ten-plus years of experience creating tables. You ask for their honest opinion.

They walk around the table, run their hand across the surface, check the joints. Then they give you their feedback.

The leg structure isn’t positioned to distribute weight evenly. The wood hasn’t been treated properly, so the color will fade within a year. The technique works for a shelf but not for something that needs to bear this kind of load.

Your first reaction? Frustration. Maybe even anger. This is my first table. I’m not a professional. Why are they being so harsh?

Then you take a breath. You realize you asked for their honest feedback. And you know that if you use the table as is, it might collapse one evening with your kids sitting around it.

The story is fictional, but I think it maps pretty well to what happens in a code review (give or take). Someone with more context (not always more experience, but more context about that specific area) looks at your work and tells you what they see. Not to be cruel. Only to protect the thing you’re building from the things you couldn’t see yet.

The code review protects us from ourselves

The code review is there to catch what we miss when we’re too close to the problem. Our excitement about a clever solution. Our limited knowledge of a system we’ve only touched for a few days. Our frustration with a task that’s taken longer than expected, pushing us to just get it over with.

I’ve been on both sides of this. I’ve submitted code I knew wasn’t ready because I was tired of looking at it. And I’ve reviewed code where the problems were obvious to me because I’d made the exact same mistakes six months earlier.

That’s the thing people forget. The reviewer isn’t judging you from some position of superiority. They’ve been where you are. Most of the feedback they give comes from their own past mistakes and experience.

Taking it personal

The first challenge I’ve noticed is that engineers take review feedback personal.

This is a completely natural response, especially when you’re not used to receiving direct feedback on your work. But it limits your thinking. When you’re focused on defending what you wrote, you stop being able to see what you could improve.

I remember at least a dozen of reviews early in my career where senior engineers left a comment saying my approach was “unnecessarily complex” or way too brittle. At first, I’d try to often prove them wrong. But after a while I realized I was compensating for my ego, instead of trying to create the best solution for the problem. This type of compensating often cost me hours, hours that I could’ve put towards other work. Nowadays, a code review for me is a learning opportunity, where I want people to find the things I missed, so that we as a team can deliver the highest possibly quality.

Respecting the reviewer’s time

The second challenge is one that doesn’t get talked about enough: respecting the reviewer’s time.

This is partially driven by delivery pressure. There’s always a deadline, always a stakeholder asking when it’ll be done. But that pressure doesn’t change the reality that someone is about to spend their time reading your code, understanding your decisions, and giving you thoughtful feedback. That’s a gift, not an obligation. And it comes with a cost.

I’ve seen too many pull requests where the author clearly didn’t review their own code before requesting a review. Leftover debug statements. Commented-out blocks. TODO comments that should have been addressed. An entirely broken CI. Things you’d catch in thirty seconds if you just read through it one more time.

My approach is simple. Once I think I’m done, I step away. I go get a coffee or work on something else for a bit. Then I come back and review my own pull request as if someone else wrote it. I leave comments explaining trade-offs I made. I catch the obvious stuff before anyone else has to. This does two things. It shows the reviewer that I value their time as much as my own. And it often catches problems I would have been embarrassed to have someone else find.

A learning opportunity, not a chore

The third challenge is maybe the most important one: code reviews have become a chore instead of a learning opportunity.

A review comment you don’t understand isn’t an interruption. It’s the start of a conversation. An approach you’ve never seen before isn’t confusing, it’s a chance to learn something new or understand something better.

I’ve learned more from asking “why did you suggest this?” in a code review than from most technical articles I’ve read. Those conversations, where someone walks you through their reasoning, where you push back and they explain further, where you both arrive at something better than either of you started with. That’s where real growth happens.

And it goes both ways. Some of the best technical discussions I’ve ever had started with a junior engineer asking me “why?” on a review comment I left. Forcing me to articulate my reasoning made me realize that sometimes I didn’t have a good reason. I was just pattern-matching against habits I’d never questioned. I also might have not explained it properly, because if I make a comment, it should be obvious to the reader be that comment. Otherwise it’s just noise.

Shipping still matters

I want to be clear about something. I understand that shipping matters. Deadlines are real. Business pressure is real. I’m not arguing that every pull request needs a three-day philosophical discussion.

But catching issues early in the process is significantly less painful than a 2 AM incident with four people on a call trying to figure out what went wrong. The code review is one of the cheapest places to find problems. Cheaper than staging. Cheaper than production. Infinitely cheaper than a postmortem.

The thirty minutes a reviewer spends on your pull request might save your team ten hours later. That’s not slowing down. That’s investing.

I’ve been doing code reviews for years now, on both sides of the table. I still learn something most of the time. Not always something technical. Sometimes it’s about communication, about how to give feedback that helps instead of hurts, about how to receive feedback without letting my ego get in the way.

The code review isn’t perfect. But when it’s done with mutual respect, genuine curiosity, and a shared goal of making the work better, it’s one of the most valuable things we do as engineers.

Titles!

A title is just a label to define the role of an employee. Some companies might use Software engineers and others might use developers or programmers. “Potayto, potahto”. But be aware, whatever the title may be, this doesn’t necessarily represent the knowledge or skill level that this person has.

You might be thinking, why is this important? It’s not, but that’s the point.

What I’ve learned is that I should consider everyone as equal, whatever the title the person may have, and ask those questions that might sound dumb. In the end, you should treat an intern with the same level of respect as your CEO.

Pick tasks that scare you!

We’ve all been there… New team, a new way of working, 15 new tools to explore and learn, and a whole new business to get accustomed to. This is pretty scary, certainly when some tasks on the board involve talking to different teams within the organization…

These tasks are the ones that help you learn the most. Don’t pick up the tasks to change the color of a button because they look small and easy. Pick the tasks that require you to step out of your comfort zone, even if you need 3 times the estimated time. This doesn’t mean that you should blindly pick big and complex tasks but you should try to coordinate with your team in order to pick these types of tickets. If anything, it will give you a great introduction to the organization.

Learn concepts, not syntax

A classic, but such an important lesson that should never be forgotten. In 5 years I’ve used MongoDB, PostgreSQL, MySQL,… as databases. I’ve written projects in Spring Boot, Python, Nodejs, and even C#… Used Google Cloud, AWS, and Azure as a cloud platform. This is not bragging or anything that I’m proud of. This will likely happen to you as well when you’re working on short-term projects as a consultant and that’s perfectly fine. As long as you stick to learning concepts and not syntax.

Don’t get me wrong. I do understand that syntax is important and sometimes you need to focus on specific technologies, but technologies are ever-changing and this won’t stop. Most concepts will not change at the pace technologies are changing, which gives you the ability to adapt better to difficult situations. All of these concepts that you learn on the way will potentially help you solve your next big problem.

Before undertaking his craft, the artisan first sharpens his tools

We as engineers are constantly working on our computers, and it’s invaluable to know as much as you can about it. This goes from learning a bunch of shortcuts while writing code to getting used to navigating servers via the command line. Every tool that you use on a daily basis should be sharpened before undertaking your craft.

This of course doesn’t mean that you can’t use tools that you don’t know well. I’m just saying that you shouldn’t be cutting 5000 trees with a blunt ax. If you’re looking for this specific challenge, don’t let my advice stop you from trying!

Adding value

Adding value, as far as I know, is what employers want you to do the most. You should always try to add value to the project that you are working on. Adding value could mean increasing revenue for a product, improving user experience, streamlining processes, you name it. But it will not be easy since it might require you to speak up in tough situations or be silent in others but the outcome should stay the same.

I’m not just sharing this so that your employer is pleased with you, but this can also help you to prove your own value to the company in performance reviews. If you continually add value and improve at what you’re doing, it’s very difficult for employers to ignore it.

Stick to your values

This might be confusing, but we’re talking about different kinds of values here.

I have a few values that are very important to me in my work. I want my work to be challenging, I want to learn new things, and I want to contribute by helping others within or outside of my team.

We all need money to survive, but I try to stick to the values that I think are of most importance to me, and if my job is no longer in line with these values, I should do something about it. I either search for a way to fit my values within my current role, or look for a new role within or outside the organization.

Breathe, Think, Execute

Early on in my career, I used to immediately start executing tasks before creating a blueprint in my brain or on a piece of paper of what the task involves. I would even say that I took the acceptance criteria (if the task had any) and started building on a solution for it, without thinking about the future of this piece of code or solution. Most of the questions came after the “completion” of the task.

A few of my favorite ones were:

• Can we deploy this proof of concept to production tomorrow?
• Will there be any problems if a lot of users are using it?
• Did we add the ability to support French, Dutch, and English interfaces?

You get the drill. Don’t over complicate everything you build, but make sure you anticipate the future of your solution in a pragmatic manner. It will reduce the headaches, long hours at the office, and projects that go over budget by a significant amount.

Sidenote: Make sure to try and ask these questions as soon as possible in the process, certainly before making estimates.

Learn to say no

This is something that I struggled with and still do, but it’s important to say no to things. Doing 4 extra hours of work a day for an extended period of time can cause tremendous issues to both your mental and physical health. It’s great that you want to help the company, but those 4 extra hours (where only one hour is likely to be productive) won’t fix the problem when you are out for 6 months due to burnout.

Feedback

One of the things that is often taken for granted is feedback. I’m very quick in giving someone a positive comment about something they did, and that’s something I love to do. Positive feedback is great. Everyone loves to hear positive comments about their work every now and then.

Positive feedback is only valuable when there are multiple types of feedback. If you’re not receiving constructive feedback, positive feedback is adding less value to you, which often makes it more difficult to process.

This feeling is normal since not all feedback is fair, but get used to receiving feedback by asking for it regularly. If you ask for feedback often, you’ll be able to adjust and improve and if you don’t, you’ll eventually receive feedback that might be much harder to digest if you didn’t ask for it yourself.

I could go on and on about the lessons that I learned in only 5 years, and I hope it helps you with navigating your first years as a software engineer (or whatever your title might be 😉). You might disagree completely with everything that I said here, and that’s totally fine but I hope at least one of these points can help you improve your career or serve as an affirmation for you. I think this blog post is also perfectly in line with my values to try and contribute positively to or help others.

Let’s see what the next 5 years bring!

Developers should discover their passions before chasing financial gain. Since 2018, I have prioritized growth over higher-paying opportunities at other companies, and I advocate this approach for junior developers entering the field.

Money

Financial compensation, while initially appearing critical, should not dominate your first job decision. Earning money is not the most important part of your life. Discovering what fulfills you professionally offers greater long-term value than immediate salary increases. Your inaugural role provides a low-risk environment to explore your interests and capabilities without significant consequences.

Personal Development

When evaluating positions, prioritize companies offering either clear advancement pathways or training budgets aligned with your role. This investment in your growth yields greater returns than marginally higher wages as a junior developer.

Atmosphere

Research workplace culture by speaking with current employees rather than recruiters. A healthy environment where colleagues feel comfortable sharing concerns matters significantly. If employers won’t arrange employee conversations, consider this concerning.

Development Process

Growth accelerates in teams with experienced developers who conduct code reviews and quality checks. These practices strengthen foundational coding abilities essential for long-term development.

Don’t Expect Everything

Prioritize strategically since no position offers everything:

• Personal development
• Technologies utilized
• Development process
• Atmosphere
• Money

Your Time Is Valuable

Working consumes approximately 22% of your annual hours. Poor job satisfaction wastes substantial life energy. Selecting positions aligned with your values maximizes overall life satisfaction.

Conclusion

Knowing your priorities increases likelihood of finding a fulfilling first role. While perfection remains elusive, matching positions to your checklist significantly improves outcomes.

Where do you see yourself in 5 years? ~ every interviewer or manager ever

My answer to this question was something like this: I want to be a full-stack developer that can create a deployment pipeline for the backend and frontend of a production application.

Well, let’s say that that is not the kind of answer people are looking for. It says nothing about your goals or ambition. It only shows that you want to progress, but then again, who doesn’t?

To construct a clear answer to this, you first have to know your dream job. This is something that one of my colleagues told me, and I keep on telling everyone because it’s just an amazing way to find out what you should focus on.

Phase 1: Find your dream job

The first step in this process is selecting your dream job. Let’s say that I want to become a Software Developer at Google. The first thing I should do is find a job description or an open application at Google so that I can find out what skills I need to complete my goal. Most of the large companies have a careers page where you can find job descriptions. The page for google is https://careers.google.com. Let’s say that I want to become a software engineer for Waze. A job description would look something like this.

I know this description can look intimidating at the start of your career, but just ignore the work that has to be done, and just try to understand it. Once you understand it, you can see which things are completed and which require some more work. A checklist should look like this:

✅ Bachelor’s degree ✅ Experience with mobile application development for Android ✅ Programming experience in Java ✅ …

⛔️ Experience with Kotlin ⛔️ Programming experience in C++ ⛔️ Knowledge of UI frameworks (either Android, iOS, XML), MVP,… ⛔️ …

With this checklist, you know everything you need to know to get into phase 2.

Phase 2: The proof

Your checklist shows clear that you have some kind of skills, but things like “experience in” are really vaguely described. That’s why you need projects to proof your experience because talk is cheap. And certainly when you’re talking to technical interviewers.

This proof could be a side-project you created or a project that you worked on at your full-time job. As a student, you could even use a school project that you worked on for a couple of weeks. Something is better than nothing.

Remember that those projects have to be up-to-date. A project that is stale for 7 years on Github, will not be enough to show your experience in a subject, since the whole subject could have changed. Certainly when you’re in web or mobile development.

If you don’t have any proof of experience, you will have some work to do. But that’s the whole point of creating your plan for the next 5 years.

You should now have an updated checklist:

✅ Bachelor’s degree 🧾 Find your degree and make sure you digitalise it once and for all ✅ Experience with mobile application development for Android 🧾 Project on Github with a link 🧾 App in the Play Store with a link 🧾 … ✅ Programming experience in Java 🧾 …

You might notice that we forgot all other points, but let’s dive into them in phase 3.

Phase 3: Growth

This might be the most difficult but also the most important phase of them all. In this phase, we will focus on the work that has to be done. In this phase, we will tackle the unchecked parts of our checklist and determine what we can do to acquire the skills that are needed for our dream job.

I will only discuss 1 of the checkpoints as an example. Let’s discuss experience with Kotlin. As previously said, experience is very vague, but it’s clear for everyone that it’s more than creating a hello-world application in a certain language. That’s why I would suggest starting with the basics, as you would in any language and work your way up. Once that’s done, I would build multiple projects and even write about the things you learned on the way. Writing about certain topics is very beneficial as a developer for job applications because it shows your passion, interest and knowledge about the topics. In addition to writing, you could get certified for certain programming languages. This is not a necessity, but it’s more like a confirmation on your experience.

Remember that a job description describes the perfect fit. You don’t have to be perfect, but you have to be close to that. That’s why you can certainly apply for a job that requires 5 years of experience with only 4 years of experience.

Phase 4: Plan

Well, as I said before, talk is cheap. Now it’s time to create a plan of execution. For me personally, I like to learn before I get to work. This means waking up early, first learn for 1 or 2 hours and then start working my full-time job. This is something that works for me, but you should find a schedule that works for you.

A goal without a plan is just a wish. ~ Antoine de Saint-Exupéry

Phase 5: Execute

This phase is all about execution.

Conclusion

By applying these 5 phases, you should get a better understanding of where you will be going over the next 5 years. Or at least where you are working towards. Of course, it’s all about executing your plan. Don’t expect to be able to complete your plan, if you’re not putting in the work. Also, remember that your dream job can change over time. You might like Javascript today, but next year you might be love Python. That’s why it’s important to refactor your plan like you would refactor your code. If you have any questions regarding this topic, feel free to contact me via Twitter.

My solution to this problem was always working out, but this is not for everyone. That’s why I wanted to find a way for every developer to break up the workdays and get the rest you deserve. Best case scenario, you will even get more work done by working less. Crazy right?

As a developer, we work very goal-oriented. Every feature has acceptance criteria and has to be finished within a certain period of time. This can put a lot of pressure on the developer and certainly more junior ones. In the beginning, it’s difficult to complete the issues within this timeframe and you get the feeling you have to work on it in your free time. And as we all know, that’s not the thing you should do during your free time.

While working from home, I find it’s even more difficult to close up the workday. Let’s discuss some things you can do to break up your workdays while working from home.

No-code day

The first thing that really works for me, is a no-code day. This day is either Saturday or Sunday for me. On this day, I write blog posts, listen to audiobooks, and sometimes even read about new technologies, but I don’t write a line of code. This helps me to remove the focus on the pile of work that is waiting for me and allows me to do other things that I enjoy.

I never knew that it would even improve my productivity by giving programming a rest. And what I also saw, is that it gives me a motivation boost. Certainly during these difficult times of Covid where we work from home and don’t have a real break from the working environment.

What also works for me is to create a plan of attack for the next week during the no-code day. A good schedule will be beneficial in the long run, because you can simply focus on executing the plan, instead of wasting your precious coding time figuring out what to do.

Take breaks like you would at the office

If you’re used to working at the office, you probably take some breaks during the day and a pretty long lunch break. But when you have a pile of work waiting for you, you tend to take fewer breaks when you’re sitting at home. I tend to do this as well.

Things like eating during a video call to avoid “wasting time” or even skip breakfast, because you have a call at 9 AM and still have to finish your demo. I solved this problem by scheduling three breaks at certain hours. When you plan out your days in the week, you can easily see where breaks can fit in. These breaks will reduce your stress levels by a lot.

Create a separate workspace

I know this is not always possible for everyone, but for those of you who can, make sure to separate your working environment from your private environments. I turned a bedroom into an office to be able to work from home and I only sit there while working. I never work from any of the other rooms.

This helps me to set the mindset to relax once I get out of my office. Leaving the office finishes off the day and allows me to start doing something else. I choose to go for a run or a walk and start my evening.

Sleep

This is not a specific tip for working from home, but it’s so important that I have to put it in here. You might be coding at night and it could carry you away. When I get in the zone, it could result in staying awake till 2 AM, and that’s not good when you’re waking up at 6 AM.

To make sure you sleep well, try and put away all devices 1 hour before going to bed. Maybe you could pick up a book and read some pages to finish off your workday.

Turn off your notifications

I know the FOMO (Fear Of Missing Out) is very high. Certainly when you have an active and interesting Slack in your company. But try turning off your notifications for 1 day and check it 3 times a day. You will thank me later.

This improved my productivity by at least 20% on the first day. I also figured out that checking my emails only 3 times a day has the same impact because mails are not that urgent. When the matter is urgent enough, they will just call you. That’s why I check my emails at 7 AM, 11 AM and 4 PM.

I tested out these tips over the last couple of months, and I must say it helped me a lot and I hope they can help you as well. If you want to read more on this topic, you should certainly check out my blog The 6 Things I Do to Motivate Myself Every Single Day.

I began my first full-time role two and a half years ago, taking on an internship project that required building a competitive workout dashboard. This involved technologies I hadn’t used before: Angular, Ionic, NodeJs, and MongoDB. Stepping outside your comfort zone creates the best learning opportunities, despite the stress involved.

Speak Less, Listen More

Remember that you know nothing. By absorbing insights from experienced colleagues, newcomers can avoid repeating mistakes and benefit from their broader professional experience.

Ask Questions Strategically

Rather than interrupting frequently, collect your questions and schedule dedicated time with senior developers. This shows genuine interest while respecting colleagues’ schedules and maintaining productivity.

Accept Feedback Gracefully

Code reviews and constructive criticism shouldn’t be taken personally. Every developer produces imperfect work, this is where real learning happens. Viewing feedback as growth opportunities rather than criticism helps accelerate skill development.

Take Ownership of Mistakes

I once deleted a database table in production by accident and instantly reached out for help to resolve it. It’s hard, because you instantly worry about what’s going to happen to you, but the goal is to restore the systems. Taking responsibility for errors demonstrates maturity and creates learning moments that prevent future incidents.

Accumulate Knowledge Through Multiple Channels

There are countless blogs about all technology you want. Books, podcasts, and blogs all contribute to expanding professional knowledge.

Learn Core Concepts Over Specific Frameworks

Understanding fundamental principles, like how browsers function, transfers across multiple technologies. Framework-specific knowledge matters in specific roles, but conceptual foundations can be carried over in every role.

Document Your Goals

Writing daily objectives maintains focus and reduces anxiety about pending tasks.

Develop a Side Project

Personal projects provide experimentation space and mental relief from workplace demands.

Prioritize Physical Exercise

Your body is the temple. Exercise provides therapeutic stress relief requiring maintenance alongside professional development.

Conclusion

No universal formula exists for early career success. Developers must experiment, read extensively, and build their own personalized set of professional principles. Defining the rules and applying your knowledge will give you the confidence you need to achieve the things you want and overcome your challenges.