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.

If you know me, you know I measure things. Not obsessively. I’m not tracking my sleep cycles or optimizing my morning routine. But I’ve learned that if you don’t measure anything, you’re just guessing. And guessing gets old fast.

This year I rediscovered something I’d forgotten I loved: writing. And that interest pulled me into territory I’d mostly avoided for years. Social media. “Personal branding.”

I know. I felt the cringe too.

But here’s the thing about curiosity, it doesn’t care about any of that. Once the experiment took shape in my head, I couldn’t let it go.

The Plan Was Simple

Write and publish one article every week. No exceptions. Or at least, not yet. Life has a way of interrupting even the best intentions.

The writing part? That came naturally. The distribution part? That’s where things got interesting.

LinkedIn was always my default. I’d post something, it would disappear into the void, and I’d move on. But this time I wanted to understand how the platform actually worked. So I started reading. And one concept kept surfacing over and over again.

Commenting.

The Thirty-Minute Comment

Sounds easy, right? Leave a thoughtful comment on a relevant post. Show genuine interest. Engage with your network.

I thought the same thing. Then I tried it.

Finding a post that actually resonated with me. Something worth responding to beyond “Great insights!”, took longer than I expected. Sometimes thirty minutes or more. Thirty minutes of scrolling through doom-and-gloom AI predictions and recycled productivity advice, looking for something that sparked a genuine thought.

When I finally found one, I had to truly understand it. Then craft something valuable for me and for the person who wrote it.

This “simple” daily habit turned out to be one of the hardest parts of the whole experiment. And I have to say, I missed two days when I was sick.

The Domain Problem

Somewhere in the first week, I realized my blog URL was working against me.

https://blog.webtric.be isn’t exactly memorable. Try telling someone that URL over coffee and hope they remember. So I switched to joachimz.me shorter, cleaner and actually writable.

But now I had a new problem: how do you redirect traffic without breaking everything?

If you’ve ever migrated a site, you know this can be a nightmare if not done properly. Fortunately, Cloudflare’s free tier makes it almost trivial. One redirect rule, and all the old traffic flows to the new domain. Done.

If you’re interesting in knowing how, reach out and I’ll gladly help you!

Actually Measuring What Matters

Next step: tracking. I went with Heap, which offers a generous free tier (up to 10,000 sessions per month). For a blog my size, that’s more than enough. And if I ever exceed it? That would be a wonderful problem to have.

Integration took about five minutes. Add a few lines of code, similar to Google Search Console, and you’re capturing data. (No, I’m not sponsored. I’m just showing you that this stuff isn’t as complicated as it seems. If you’ve been putting off starting a blog because the technical side intimidates you, it shouldn’t.)

The Numbers

Now the part you’re actually here for.

I had no baseline. I hadn’t posted anything meaningful on LinkedIn in months. So these numbers exist in a vacuum, but they still surprised me.

LinkedIn Performance:

• ~8,500 impressions (I’m discounting some repost noise)
• ~4,000 members reached
• Posts published weekly, typically Monday through Wednesday

I didn’t expect this. I expected some growth, sure. But not this trajectory. The curve kept climbing in a way that felt almost suspicious.

Of course, comparing this to “nothing” isn’t exactly scientific. But it’s a start.

Blog Traffic (since December 21st, when the new domain went live):

• 213 unique visitors
• 294 page views
• 233 sessions

These are fine, but they’re not what I actually cared about. I wanted to know: are people reading?

Time on page by article

The longer posts held attention longer. No surprise there. But seeing actual minutes spent on something I wrote? That landed differently than I expected. In a positive way!

The last one stings a little. Zero newsletter signups. But it’s also honest data. People visited, some of them read, but nobody was compelled to stick around for more. That’s useful information. It tells me the content might be interesting enough to click, but not yet valuable enough to subscribe. Another learning.

What One Month Actually Taught Me

Here’s what I didn’t anticipate: the hardest part wasn’t the writing. It wasn’t the technical setup. It wasn’t even maintaining the weekly cadence.

The hardest part was engaging authentically in a space that is unknown to me for the most part.

Thirty minutes to find one post worth commenting on. That ratio tells you something about the signal-to-noise problem on LinkedIn, or maybe my feed is the problem. But it also tells you something about the opportunity.

If most people are leaving “Great post!” or AI-generated comments, the bar for standing out isn’t actually that high. It just requires effort most people aren’t willing to give.

The numbers are encouraging, but ultimately they don’t matter too much. Also, one month is nothing. It’s a spark, not a trend. The real question is whether I can sustain this through month three, month six, month twelve, when the novelty wears off and the weekly deadline starts feeling like a weight instead of a challenge.

What I can say: I’m writing more than I have in years. I’m thinking more carefully about what I want to say. And for the first time in a long time, I’m actually clicking publish consistently instead of letting it sit in drafts because the posts might not be perfect.

That alone feels like progress worth measuring.

That attitude tends to disappear when the subject is software.

Taking over an older codebase is a familiar experience for most engineers. You open a project that has been around for years, start reading through the code, and quickly form an opinion. The structure feels outdated, patterns look odd, and choices stand out that you would never make today. The quiet conclusion often follows: this is a mess.

I have had that reaction myself more times than I care to admit. Part of that reaction comes from confidence. We see the code through the lens of what we know now, with better tools, more experience, and the benefit of hindsight. That makes it easy to assume we would have done better, given the same situation.

I remember opening a project like that more than a dozen times. A few minutes in, I was already mentally rewriting large parts of it. At the time, it felt obvious that starting fresh would be easier than understanding what was there.

What we tend to forget is that code is only the visible part of the story. It captures decisions, but not the context in which those decisions were made. Deadlines, team size, available tools, business pressure, and technical limitations rarely survive in the repository. All that remains is the outcome.

When we judge old code without understanding its context, we are judging with incomplete information.

One reason context disappears so easily is that we are rarely intentional about preserving it. Code tends to outlive conversations, whiteboards, and Slack threads. Sadly, even pull request descriptions rarely include the decisions that were made.

This is where things like Architecture Decision Records can help. Not because they enforce structure, but because they capture intent. A short note explaining why a decision was made, what alternatives were considered, and which constraints mattered at the time can make a huge difference years later.

The same is true beyond architecture. Many technical decisions are driven by product choices, timelines, or business realities. When that context is missing, the code can look arbitrary or careless, even when it was neither.

Writing these things down is not about justifying the past. It is about giving future readers a chance to understand it.

It is also worth turning that lens inward. The code I write today feels reasonable and well structured to me now. Given enough time, it will not. Someone else will open it years from now, without the benefit of my assumptions or constraints, and wonder why certain choices were made. In that sense, none of us write timeless code.

Experience in people earns respect because we understand that learning happens over time. We accept that earlier decisions were made with less information, different priorities, or under pressure. Code deserves the same generosity. It is not a monument to perfection, but a snapshot of understanding at a particular moment.

The urge to rewrite is understandable. Rewriting feels productive, clean, and decisive. Understanding takes longer, and it rarely comes with the same sense of progress. But skipping that step often means repeating mistakes rather than learning from them.

Respecting old code does not mean defending every decision or avoiding change. It means starting from the assumption that the people who worked on it were solving real problems as best they could. It means reading before rewriting, asking why something exists before removing it, and assuming rational intent instead of incompetence.

Most of the time, the code is not the problem. Missing context is.

When we approach older code with curiosity rather than judgment, we give ourselves a better chance to improve it responsibly. More importantly, we acknowledge that we are part of a longer story, not the first chapter and certainly not the last.

Respect, in software as in life, is not about agreement. It is about understanding what came before.

Commuting again meant space. Not just physical space between home and work, but mental space. Audiobooks slowly made their way back into my routine. Not as a productivity hack or a yearly challenge, but simply as a way to think, learn, and sometimes just listen.

Looking back, the books I listened to say more about this year than any list of achievements ever could. They reflect curiosity about how we build software, how we work with others, how we endure hard things, and how we prepare for becoming a parent for the first time.

This is not a ranked list, and it is not a recommendation post. It is a reflection.

Dark Wire by Joseph Cox

Cybersecurity has long been an interest of mine. Although the book is not directly about cybersecurity, it does offer a sobering look at surveillance, law enforcement, and the unintended consequences of technology. It made me think more carefully about where software ends up, and how far removed developers can be from the real-world impact of their work. Not a comfortable listen, but a valuable one.

The Pragmatic Programmer by David Thomas and Andrew Hunt

Some books age well because they are not tied to trends.

Listening to this again was a reminder that good software development is still about fundamentals. Responsibility, communication, curiosity, and ownership matter more than tools. What stood out most was how relevant the advice still feels, even decades later. Now in the “Age of AI”, I believe, these core principles will become even more important.

The Art of Resilience by Ross Edgley

I picked this up out of curiosity after hearing Ross Edgley on this podcast, where he talked about swimming 510 kilometers without stopping.

The examples in this book are extreme, but the underlying message is grounded. Resilience is built through exposure, consistency, and choosing discomfort in controlled ways. While the book focuses on physical endurance, the ideas translated surprisingly well to work and life. Growth rarely comes from comfort, but it also does not come from chaos. This book reminded me of a quote by Mike Tyson that I keep coming back to:

Discipline is doing what you hate to do, but do it like you love it.

The Positive Birth Book by Milli Hill

Becoming a first-time father has a way of reshuffling priorities quickly.

This book was recommended to us by our Doula, and I approached it with curiosity rather than expectations. What it offered was not certainty, but understanding multiple perspectives. It helped frame the birth process as something that can be approached with confidence rather than fear.

Building Microservices by Sam Newman

This felt like revisiting familiar ground, but with a sharper lens.

Microservices are often discussed as a goal rather than a tradeoff. This book does a good job pulling the conversation back to reality. It focuses on boundaries, change, and failure, not just deployment diagrams. It reinforced the idea that tools shape how we see problems. As the saying goes, to the man with a hammer, every problem looks like a nail.

The Manager’s Path by Camille Fournier

I am not a manager, and I do not have any plans to become one. Still, I have always been interested in understanding how perspectives shift in various different roles.

This book helped me see management less as a promotion and more as a change in problem space. Many decisions that can look strange or frustrating from the outside start to make sense when you understand the constraints behind them. Listening to this made me think more about the different levels of challenges people are trying to solve in their respective role. It is easy to get absorbed in your own challenges and lose sight of the problems others are navigating.

Platform Engineering by Camille Fournier

This one aligns perfectly with my day-to-day life as a Software Engineer, and being part of a growing company.

As systems and teams grow, complexity tends to spread quietly. Platform engineering is often mentioned as a solution, but the term itself is vague enough to be misused.

What I appreciated most here was the emphasis on platforms as products. Internal teams are users, not obstacles. The book reinforced that building a platform is less about technical elegance and more about reducing friction for others. That framing stuck with me far longer than any specific architectural pattern.

Looking back

I am struck by how naturally these books aligned with where I was in life. Questions about systems, responsibility, resilience, and care all showed up in different forms, both professionally and personally.

Audiobooks did not make this year more productive. They made it more reflective.

And that was enough for me. Staying curious has served me well this year, and I am looking forward to an interesting year ahead.

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!

For all the people who struggled through this year, I want to tell you that you made it! You broke some of the walls that were set for you and made way for a better and more positive year.

As you might have noticed this is not just a post, but a message that I think we all need. We all have ups and downs, and we all need a hug or a listening ear every now and then. Sometimes we even need to hear that it’s okay to be ourselves. And that’s what I want to tell you in this special post.

It’s okay not to be okay!

Failing doesn’t mean that you’re a loser, failing is learning!

You are enough!

Asking for help doesn’t make you weak. It makes you strong!

You don’t have to agree with everything!

I want to wish everyone all the best and a positive year in 2022. Also, I hope you achieve everything you want to achieve and crush every goal you set! And remember that there is light at the end of the road! 😉

Happy holidays! 🎄

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 don’t like reading things that are longer than 15 minutes. Ever since I was young, I thought reading books was a waste of time. The subjects that were offered at school for our presentations were not appealing to me, to say the least. But this was 10 years ago. A lot has changed in those years, including my interest in self-development.

For the last 2 years, I loved podcasts, and I still do, but I feel like I get more value from audiobooks. This value is knowledge. Not overall knowledge, but knowledge of topics that are interesting to me. This previous month I finished 4 audiobooks and a paperback.

• Atomic Habits - James Clear
• How to win friends and influence people - Dale Carnegie
• Extreme Ownership - Jocko Willink & Leif Babin
• The Compound Effect - Darren Hardy
• Can’t Hurt Me - David Goggins

But I’m not writing this article to show you how many books that I read or listened to, I’m here to show you a way to fit in books in your life, without sacrificing a lot of time. And I think that if you want to try broadening your horizons, you will learn so much by listening to self-development audiobooks.

Realizing the value of a book

Most of the books take at least 6 months up to even 2 years. In self-development books, most of the authors write to share their life stories or experiences. Most of these stories are success stories because that’s the attractive part to most people. I love to read success stories, how some authors came from nothing, had no parents, or were bullied in their young years, and managed to write a best-selling book.

I think of a book, like a thoughtfully written summary of the author’s experience. When I started reading Extreme Ownership, I realized that Jocko Willink and Leif Babin summarised their entire leadership experience from their years in the Navy Seals. This amazing experience was summarised in only 9 hours and 33 minutes of audio or 320 pages of paper.

Think about it, 9 hours and 33 minutes of your attention, for a summary of more than 10 years of leadership experience. That should be a no brainer. But I never thought about books like this, I thought it was a waste of time because it takes so long to finish it… But 10 hours is nothing in your life. In fact, by listening for 1 hour a day, you would finish it in 10 days. 10 days for 10 years of experience, still not a bad deal.

The authors have lived it, felt the ups and downs, and managed to conquer all the challenges on their path. And of course, you can’t become a great leader by only reading about being a leader. That’s the same as the fact that you can’t be a writer by reading a lot of articles about writing. You have to put the work in and practice the craft.

But there are some challenges in this approach.

The challenge with audiobooks

Many people that listen to audiobooks have the feeling that they can’t remember everything as well as when they read it. I had the same issue. I listen to audiobooks while cooking, driving, working out, and even when I’m taking a bath. But in the beginning, I could barely remember what I heard. And that bothered me a lot. Usually, I can pretty much remember the majority of the podcasts I listen to, but not here… Why?

At first, I thought it was due to the fact that I listened to the book in a hundred pieces. This could be 10 minutes in the morning, 5 minutes in the afternoon, and 1 hour in the evening. But that was not the problem, the problem was my accountability.

Remember when the teacher asked you to read a book in high school, and you just read the summary right before class? Well, in your daily life, there are no teachers expecting you to remember it. That’s why I introduced my personal accountability moment.

The personal accountability moment can be used for many things, and I do so, but in this case, I will focus on my audiobooks. I schedule a maximum of 15 minutes of my time on Sundays to write about the book I read during the week. Every Sunday I open my Book Tracker and write about the topics that really stuck with me from the book. This could be 150 words or 1000. And you can also do this on a daily basis. But it’s not important how much you write about it, it’s important to write down the value that the book has given you. Your notes should be your reminder in a couple of years, without having to read or listing to the book again.

I used Extreme Ownership as an example because it’s so applicable to everyday life. Many of us will have to lead a team or a group of people, maybe you might even become a CEO. If this happens, you might just want to read the fundamentals every day, to remind yourself that you have to take ownership of everything from your company. If your employees fail, you fail. But this is not a leadership article, so let’s get on with the audiobooks.

But books are expensive!

Well, I don’t think that’s necessarily true. With Audible, you can buy 1 premium book a month for $14.95 per month. In addition to that, you will have access to a lot of free books and podcasts.

But I’m not here to sell you Audible. What I do want you to do is invest in yourself and your self-development. Everyone wants to become better, but few are willing to put the time and effort into it. That’s where you can make a difference.

Where do I start

This part of the article is only for people who actually want to start reading and don’t know where to start. If you know which books you would like to read, there’s no reason to read keep on reading this article. Get yourself an audible subscription and start enjoying!

If you’re still looking for interesting books, I can suggest all the books in this article.

The books Atomic Habits and The Compound Effect are comparable. They will give you a broader perspective on habits and how small and consistent changes can improve your life and success.

I think that Extreme Ownership is a book that every one that is interested in leadership, should read. In addition to that, add “How to win friends and influence people” to your list! These books will give you a basic set of rules that you can apply to become a great leader.

And finally, Can’t Hurt Me by David Goggins. Well, this book is not for everyone. In this book, David shows you his hard life. If you don’t know David Goggins, this guy has run over 60 ultra races, was a Navy Seal, and finished 3 Hell Weeks.

I hope any of these books can help you as well as they helped me.

Are you ready for a change?

One of my colleagues recently asked me how I find the motivation to do what I do. “What I do” is a little vague, so let me elaborate on that. I’m a full-time developer (40 hours/week), a freelancer on the side for various companies (15-20 hours/week) and I write at least 1 blog a week (varies in time). I work out about 5 times a week (at least 5 hours). Since recently, I also started to finish 1 audiobook a week. I’m not saying that I have the busiest life, but it fills my days.

Dealing with negative situations

Now and then, things will happen that will disrupt your life. You might fail the interview for your dream job. You might be training for a marathon and break your leg one week before the contest. So many things can happen that will demotivate you.

The way I deal with this is something that I learned about a year ago. There’s the “5-minute rule” which is best explained by Hal Elrod on Impact Theory.

The 5-minute rule allows you to be negative for 5 minutes after something bad happens. It’s okay to be negative during these 5 minutes. But after these 5 minutes, you say 3 words: “Can’t change it!”. If there’s something to remember from this article, it’s this rule. By applying this rule, you can accept the negative situation and go on to the next challenge.

Schedule and forget

Remembering all the tasks that you have to complete for the day is very hard. Remembering all the tasks that you have to complete for a week is impossible. That’s why it’s important to write down your tasks. Not only because you will not forget them, but also because you will stop thinking about it. Once you write it down in a to-do list and schedule it, you can completely forget about it. This helps you to keep the focus on your current task.

It’s important to create a clear schedule that works for you and your partner. Use a calendar to schedule a time for work and your partner. Work is silver, your partner is gold.

You can find all my productivity tools in my previous blog on the 10 productivity apps that I use.

Healthy body, healthy mind

Working out is an underestimated form of therapy. It’s not only underestimated, but it’s also a lot cheaper. You don’t have to go to the gym and workout for 2 hours every single day. Working out can be as simple as going out for a walk or a run. Doing 50 push-ups each day is fine too. Do something!

Besides working out, you should also eat healthily. Does that mean to go on a diet? NO! Replace your soda with water, your biscuit with an apple, and your 4th coffee with tea. I’m kidding about the tea, I love coffee.

Your brain is a part of your body. How do you expect your brain to work, if the fuel of your body is bad?

Get up early

This is something that will not work for everyone. I get up pretty early, not always 5 AM but I’ll be ready to start working by 6:30 AM. You might think, well that’s not early at all! I get up at 4:30! Well even better!

4 years ago I never woke up before 7 AM… On the weekends I even struggled to wake up before 10 AM… Can you imagine? The thing to remember here is that you can become better at something if your “why” is big enough. If waking up early means that I get to spend more time doing what I love and maintaining my relationship… Sign me up!

Start your day by doing something you don’t like

This is a real game-changer. You need to do stuff that you don’t like, so better get it over with at the start of the day. Working out first thing in the world can be something awful to do. But once you’re done working out, you don’t have to look back on it. Workout finished and done for today.

This is something that kinda works for me, but not always. I like to do my workouts as a break from my computer. I actually enjoy working out, so I don’t need to do it first thing in the morning.

For me, cleaning is much worse. So I start the morning by unloading the dishwasher, taking out the trash, and cleaning the rooms. I even vacuum the living room and kitchen, just to annoy myself. And if I’m done with that, every other task will be enjoyable. I won’t have to clean up after work and I will be able to enjoy a nice walk with my girlfriend in the evening.

Find a challenge

Once I get bored with something, this can be anything, I find a new challenge. As a developer, it’s important to keep learning. Every year, month, week, or even day some new technology pops up. We need to scan the technology related to our work to see if we can improve existing projects by using it.

I’m a full-stack developer. I focus on the frontend, but I keep up with the backend and DevOps. One of the things I do is learning new frontend frameworks like Svelte. I try to write a blog about it and open-source the code so that others can learn from it. This helps me to remember it better and I learn so much from comments from other enthusiasts.

Conclusion

A source of motivation is something that everyone needs. Some people have it naturally, other people struggle with it. But everyone needs something that drives them. Some people want to work a steady job with 40 hour work weeks. And that’s fine.

But even when you don’t want to become a freelancer or a runner, you can still apply these rules to your daily life. Some of these rules might help you to relieve the stress in your day job. This could benefit your relationship because you reduce these infinite bad days. Which will generally lead to a better life.

I’m not saying that I have the answer to every negative situation. I will also have bad days. I will have stress in the workplace and I will have difficulty to workout some days. But being able to handle these negative situations the proper way, by thinking clearly and looking for a solution, instead of looking in the abyss. That will help you to become happy. And for me, happiness eventually leads to motivation.