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.

Page load dropped from about one second to under 300 ms, the stack cost went to zero, and I finally owned every part of the experience.

This is why I left Ghost and rebuilt the blog from the ground up.

Why I Left Ghost

Ghost is a great product. If you want a managed blogging platform with a clean editor and built-in newsletter support, it does the job well.

My reasons for leaving were not about quality. They were about control and fit.

Since my goal this year is to start publishing weekly, I wanted my blog to feel completely mine: faster, simpler, and shaped exactly to my preferences. Ghost did not allow the level of customization I wanted without workarounds.

The bigger issue was scope. Ghost Pro is not cheap, and self-hosting Ghost means running a server, a database, and ongoing upgrades. For a personal blog with one post a week, that stack felt like overkill.

I expected the newsletter to be the hardest part to replace. It turned out not to be.

Choosing the Stack

I did not spend weeks evaluating frameworks, like I would in the past. The decision was pretty simple.

Lately I heard a lot about Astro and I wanted to try it out. It ships hardly any Javascript by default, supports Markdown and MDX natively, and gives you full control over the output. No hydration overhead, no client-side routing unless you explicitly opt in. Just HTML and CSS.

Cloudflare Pages for hosting. Free tier, global CDN, automatic deployments using GitHub Actions. The site builds in seconds and deploys to edge locations worldwide. No servers to manage, no bills to worry about.

Markdown files instead of a database. Like we all know, lately everything has been about Markdown files, so why not put every post in a Markdown file in a Git repository. I can make changes to it in any editor, preview locally, and publish by pushing to main. Version history comes for free.

For my newsletter, with the full 12 subscribers, I first thought to not include it anymore. But then I found Kit, 10 000 subscribers for free. Perfect for my use case.

The entire stack costs me nothing beyond the domain name, and my time of course.

Performance Results

The page load numbers are the clearest win.

In real usage the Ghost site felt reasonably fast, around one second to visible content. However, Lighthouse mobile simulation revealed much heavier rendering costs, especially LCP. The Astro rebuild reduces both perceived and measured performance costs.

The architecture shift from dynamic rendering to static edge delivery shows up clearly in performance metrics.

Lighthouse snapshot (single run, mobile emulation, default throttling).

Here is a Lighthouse snapshot (single run, mobile emulation) comparing the old Ghost site with the new Astro build:

The largest improvements come from removing heavy images and client-side scripts. Total page weight dropped by over 18x, which directly improved Speed Index and LCP.

Design + UX Updates

The better question would be, what did not change. Well, the content.

The homepage moved from a stock template to a focused, branded entry point with clear hierarchy and fewer distractions.

Beyond speed, the design is entirely mine. The goal was a calmer, more intentional experience with room to grow. I can now iterate quickly and add new features without fighting the platform.

The new list view trades heavy thumbnails and whitespace for tighter hierarchy and faster scanning. Smaller images, consistent metadata, and clearer contrast mean you can find a post at a glance without hunting for it.

The reading view moves from a template-heavy page to a focused editorial layout. Better line length, calmer typography, and fewer competing elements keep attention on the text and reduce cognitive load.

The CTA experience is now integrated into the reading flow instead of floating over it. Recommendations feel like a natural next step, not an interruption, which keeps the page focused while still nudging the next click.

The newsletter now feels like part of the site, not a third-party embed. The form is lighter, the spacing is calmer, and the CTA matches the rest of the system, so it reads as an invitation rather than a modal ad.

The benefit of building this site myself is being able to introduce more features to improve the experience:

• Search across every post (full text, fast).
• An About page that actually explains what I write about.
• Dark/light mode that preserves the brand tone.
• One-click code copy for snippets.
• Dedicated tag pages so topics are easy to follow.
• Posts grouped by year for quick scanning.

The Takeaway

If you are a developer blogging on a managed platform, ask yourself what you are getting in return for that convenience. If the answer is "less control and a monthly bill," it might be time to build your own.

It does not need to be complicated. A static site generator, a CDN, and Markdown files will take you further than most platforms. And the process of building it will teach you more than any blog post about blogging ever could.

Including this one.

I have kept features like that alive for years. Not because they added value, but because removing them felt like more work than leaving them in place. They worked. They were not hurting anyone. Why bother?

That reasoning felt pragmatic at the time. I have since learned it is the most expensive form of laziness in software.

The lie we tell ourselves

“It works, so it is free to keep.”

This is what we say when we do not want to think about it. And for a while, it’s true. The features sit there, untouched, collecting dust. Nobody complains. Nobody celebrates. They just exist.

But software does not work like this. Dependencies shift. Frameworks update. Security patches ripple through layers you forgot were connected. Those quiet features are not free. They are accumulating debt.

I learned this the hard way many times. A release went out, and three weeks later a bug report came in from a single user clicking a button I had forgotten existed. Someone had to context-switch, investigate, trace the regression, fix it, and report back. Half a day of engineering time for a feature that served one person who probably would not have noticed if the button had simply disappeared.

That was one feature, one bug report. Now multiply it across every neglected corner of a product.

The weight you stop noticing

One unused feature is manageable. You barely think about it. But products do not collect one. They collect dozens, quietly, over years. A toggle nobody clicks. A report nobody reads. An export format nobody requests. Each one seemed harmless when it shipped. Each one still seems harmless on its own.

But collectively, they change the shape of every conversation. A design review takes longer because the interface has no space left. A dependency upgrade touches code paths nobody remembers writing. A new engineer spends their first week building a mental model of a system where a third of it serves no one.

In some occasions, removing unused features is not even on the table. Not because anyone defends them, but because nobody can confidently say which ones are unused. The tracking might not be there. Or maybe the institutional knowledge had left with the people who built them.

That is how it compounds. Not through any single decision, but through the absence of decisions. The features you never question become the ones that define your constraints.

Why we still keep them

I think the real reason we keep unused features is not pragmatism. It is discomfort.

Removing a feature feels like admitting failure. Someone built it. Someone approved it. Maybe it was your idea. Deleting it means acknowledging that the effort was, in some sense, wasted.

I have felt that discomfort. I have argued to keep things I built, not because they mattered to users, but because they mattered to me. That is not product thinking. That is ego dressed up as engineering judgment.

There is also the fear of the edge case you cannot see. What if that one user depends on it? What if removing it breaks something downstream? These fears are real, but they are also answerable. Usage data exists. Conversations can be had. The fear of finding out is not a reason to avoid looking. And certainly not, when you can just bring the feature back if complaints come in.

When keeping is the right call

I do not think the answer is to remove everything with low usage. Some features serve a small audience that depends on them deeply. Some could exist because of contractual obligations or regulatory requirements. Some are niche but genuinely valuable for power users.

There is a difference between keeping a feature because you evaluated it and decided it still earns its place, and keeping it because nobody bothered to ask the question.

The discipline of subtraction

Every feature has a rent. Some pay for themselves through usage, through value, through the problems they solve. Others just accumulate cost quietly, making everything around them a little harder, a little slower, a little more constrained.

Adding features is easy to celebrate. Shipping feels good. But the products I admire most are not the ones with the most features. They are the ones where every feature earns its place. Where someone had the discipline to ask: does this still serve the people using this product?

The discipline is not in building more. It is in being honest about what deserves to stay.

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.

I’ve also been on teams that delivered value fast and consistently.

The difference wasn’t talent. It was something harder to define, and harder to build. I spent years assuming I’d figure it out eventually, that experience would make it obvious.

It took longer than I expected. But I believe I can finally name it.

The best teams I’ve worked with share four traits.

Not methodologies. Not tools. Traits. Ways of being together that make everything else work.

1. They commit fully to decisions they disagree with

You’ve heard “disagree and commit” before. I believe most teams get it wrong.

They think it means: voice your objection, get outvoted, then quietly comply.

That’s not commitment. That’s resignation.

Real commitment looks different. It means putting your all your energy into an approach you wouldn’t have chosen. It means actively trying to make it succeed, not waiting for it to fail so you can say “I told you so.”

I’ll be honest: I’ve failed at this more times than I’d like to admit. Early in my career, I’d disagree with a decision, get overruled, and then just follow blindly. I wasn’t sabotaging anything (at least not consciously), but I wasn’t helping either. That’s a terrible way to work. And it’s a terrible way to be on a team.

I watched an engineer do the opposite. Arguing passionately against an architectural change for weeks. Good arguments, valid concerns. The team decided to proceed anyway.

What did he do? He became the biggest champion. He found edge cases the rest of us missed. Started looking at improvements to actively make the idea better, and started supporting it even more. From that point I understood disagree and commit.

2. They separate ideas from identity

Here’s a pattern I see constantly: someone proposes an approach, another person critiques it, and suddenly we’re not talking about the approach anymore. We’re talking about who’s right or wrong, not what is right or wrong.

High-performing teams have figured out how to argue about ideas without making it personal. They can say “I think this approach has problems” without anyone hearing “I think you’re incompetent.”

This goes both ways. You need people who can give direct feedback without being cruel. And you need people who can receive direct feedback without feeling attacked.

Neither skill is natural. Both can be learned. I’m still constantly learning them, if I’m being honest.

The teams that figure this out move fast. The teams that don’t spend half their energy managing emotions instead of solving problems.

3. They’re pragmatic without being careless

There’s a certain kind of engineer who treats every decision like a thesis. Every choice needs to be the theoretically optimal solution, fully considered, perfectly designed and 17 confluence pages along side of it.

There’s another kind who just wants to ship something, anything, and deal with the consequences later.

The best teams live in between these two. They care about doing things well, but they also understand that a good solution today beats a perfect solution next quarter. They also realize that everything has it’s price. And that they might be building something that is not needed in 6 months.

But (and this matters) pragmatic teams like this don’t use “move fast” as an excuse for sloppy thinking. They make quick decisions, but informed ones. They cut scope, not corners.

Finding that balance is hard. But the teams that find it tend to build things that actually get used, while keeping stakeholders and, most importantly, users happy.

4. They have informed captains

Every decision needs an owner. Not a committee. Not “the team.” One person.

Netflix popularized the term informed captains, but the name doesn’t matter. What matters is this: someone has the context, the authority, and the accountability to make the call.

The key word is “informed”. A captain who doesn’t understand the problem is just a bottleneck. A captain who understands deeply can move fast because they don’t need to ask for details or approval before every decision.

To be clear, informed captains aren’t dictators. They gather input. They listen to concerns. They genuinely consider alternatives (and I mean genuinely, not the kind where the decision was already made before the discussion started). But when it’s time to decide, they decide. And the team commits.

This only works if you’ve already built the first three traits. Commitment requires trust. Trust requires the ability to disagree without damage. And the captain needs pragmatic judgment to know when good enough is good enough.

The uncomfortable truth

None of this is a process you can implement. You can’t mandate commitment. You can’t enforce the separation of ideas from identity. These are cultural traits, and culture is built one interaction at a time.

I used to think the answer was hiring - find the right people and everything clicks. But I’ve seen great individuals form dysfunctional teams, and average individuals form extraordinary ones. It’s not about who’s in the room. It’s about what happens between them.

That’s the thing about these four traits. You don’t notice them when they’re present. Everything just works and you assume it’s because the people are talented or the project is well-scoped. You only notice their absence - in the meetings that drag, the decisions that unravel, the slow bleeding of momentum that no retro seems to fix.

I’m still learning how to build these types of teams. I suspect I always will be.

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.

Looking back, that makes sense. Clean code is an attractive idea. It promises clarity, maintainability, and a sense of control over growing complexity. Back then, I approached the topic mostly from the perspective of an individual contributor trying to write better software.

Five years later, I still agree with the intent of that post. What has changed is my understanding of when and how those ideas should be applied.

This is not a rewrite of the original article. It is a reflection on what still holds up, what feels incomplete today, and what experience added that rules alone could not.

If you want to read the original version first, you can find it here 👇

Clean Up Your Code by Applying These 7 Rules - In this post, I will go over some of the rules that you can apply to improve your code. Every developer on the team, regardless of their skill level, has to be able to understand the code by reading it. This helps young developers to be more confident in writing code.

What still holds up

Several ideas from the original post aged well in my day-to-day, mostly because they are rooted in communication rather than technique.

Readable code is still one of the best investments you can make. Clear naming, simple control flow, and small, focused units of logic make it easier for others to understand what a piece of code is trying to do. That has not changed, or at least not yet.

The idea behind the Boy Scout Rule also still resonates. Leaving code slightly better than you found it is a healthy mindset. Small improvements compound over time, and a codebase benefits from care and attention rather than neglect.

These principles work because they are not tied to tools or trends. They are about helping the next person, which often turns out to be your future self. Or create a path for some LLM to write readable code based on yours.

Where my view has changed

What feels incomplete today is the assumption that cleanup is always the obvious next step.

Earlier in my career, I treated cleanup mostly as a local activity. I saw something I did not like, applied a rule, and moved on. Over time, I learned that cleanup is rarely just about code. It is about context, ownership, timing, and intent.

Refactoring without understanding why code exists can be risky. A piece of logic that looks redundant or overly defensive might be protecting against a constraint you are not yet aware of. Removing it can introduce subtle bugs or undo decisions that were made deliberately. It can also be a costly exercise, when you come to the realization that after refactoring in, you ended up with the same solution because of these unknown constraints.

I also underestimated how often technical decisions are driven by product needs, deadlines, or organizational constraints. In those cases, “clean” was not the primary goal. Shipping something that worked was.

The rules were never wrong, but they were incomplete without context.

What experience added

Working on larger and older systems changed how I look at cleanup. Inheriting code I did not write forced me to slow down. It became clear that understanding usually creates more value than immediately improving aesthetics.

I also started to see cleanup as a shared responsibility rather than an individual one. In a team, even well-intended refactoring can have side effects. Changes that feel small locally can ripple outward and affect others in unexpected ways.

That is where context becomes crucial. Knowing why something exists matters more than knowing how to improve it.

Principles over rules

If I had to summarize how my thinking evolved, it would be this: clean code is not a checklist, it is a byproduct of understanding.

Rules are helpful starting points, but judgment is what makes them useful. Sometimes the right choice is to refactor. Sometimes it is to document intent. Sometimes it is to leave things as they are and revisit them later.

The goal is not perfection. The goal is stewardship, and delivering value to the customers.

Closing thoughts

I still believe in writing clean code. I also believe that respecting what came before is part of that responsibility. Code is a record of decisions made under pressure, with the information that was available at the point of writing it and often under constraints we no longer see.

Revisiting my old post reminded me that learning is not always about new ideas. Sometimes reframing old ones can be even more valuable.

In general, I can say that these rules have helped me write better code over the past 5 years, however, experience taught me when to apply these rules.

These systems were throwaway by design. Longevity was not a requirement, so architecture was not a concern.

Later, I moved into product development. We were building for real users, real usage, and real growth. Architecture suddenly mattered a lot more. But the underlying forces stayed the same.

Deadlines still controlled the decisions. Budgets still mattered. The main difference was that scale entered the picture. Not as an ambition, but as a concrete question: what does this system actually need to handle?

Scale Is a Constraint, Not a Goal

This is where architectural discussions often go wrong. Scale turns into a goal instead of a constraint. Future growth becomes a justification for present-day complexity.

As a part-time freelancer, I have worked with early-stage founders at the very beginning of their journey. Small teams, limited budgets, and often no users at all. Yet it is common to see architectures designed for a future that does not yet exist. Kubernetes clusters, microservices, event-driven pipelines. Not because the product requires them today, but because it might need them someday.

Most of the time, it does not. Certainly not early on, and if you do, it’s a good problem to have!

What Most Products Actually Need

What these products usually need is something that works. A monolith and a Postgres database can go very far. Vertical scaling is often sufficient for years. Adding complexity early rarely buys safety. It mostly buys cost.

Cost in infrastructure.

Cost in development speed.

Cost in cognitive load.

What We Really Mean by Requirements

When we talk about requirements or constraints, we are not just talking about features. Architectural decisions are shaped by multiple types of constraints:

• Business requirements like deadlines, budget, and time to market.
• Non-functional requirements like latency, throughput, availability, and consistency.
• Organizational constraints like team size, experience, and operational maturity.
• Product reality like current usage, realistic growth, real customers, and actual revenue.

If you cannot point to a concrete constraint in one of these categories, you are not solving a problem. You are guessing.

Premature Complexity in Practice

Consider a small product team of four engineers building a B2B SaaS product. At this stage, the product has fewer than fifty active users and only a handful of paying customers. Despite this, the team invests early in a microservices architecture.

The system consists of eight services, a message broker, distributed tracing, and a managed Kubernetes cluster. Every feature requires changes across multiple services. Local development is slow and brittle. Deployments are frequent but risky, rolling back is even worse. A significant portion of engineering time goes into keeping the system running rather than improving the product.

Infrastructure costs alone exceed a few thousand dollar per month. More importantly, development speed suffers. Simple product changes take weeks.

Eventually, the system is consolidated into a simpler architecture. Fewer services, fewer moving parts, and fewer failure modes. Deployment becomes boring and simple. Development speeds up. Nothing about the product’s requirements has changed. Only the architecture has.

Microservices are not the wrong choice in principle. But they can be the wrong choice for that moment.

Pragmatism as an Architectural Strategy

This is why pragmatism is an architectural choice.

Pragmatic architecture optimizes for:

• speed of change,
• low cognitive load,
• controlled costs,
• and the ability to learn from real usage.

It deprioritizes:

• theoretical scalability,
• architectural purity,
• and solutions to problems that have not yet materialized.

Let Architecture Earn Its Complexity

This does not mean ignoring the future. Successful products do outgrow their initial designs. Re-architecture is sometimes necessary. But those changes are justified by evidence. Usage patterns, performance bottlenecks, revenue growth, or operational pain.

They happen because the product has earned them.

Architecture should evolve with the product, not ahead of it.

Honesty Over Hypotheticals

Good architecture is less about preparing for every possible future and more about being honest about the present. Build systems that serve the product as it exists today and can grow based on evidence, not assumptions. Leave room to change when reality demands it.

That kind of pragmatism is not a compromise. It is a responsibility of every software engineer.

There is a myth I used to believe. You might believe it too.

It sounds something like this: “I am a developer, I write TypeScript, computers are incredibly fast now, and I mostly move JSON from an API to a UI. Big O notation is for low-level engineers who write databases or do game development.”

It is a comforting idea. It lets us focus on frameworks, state management, crud operations and component libraries. It suggests that performance is somebody else’s concern.

I built Stacksmith to test that belief. I wanted a practical way to re-learn Data Structures and Algorithms after years of neglect, so I spent the past few months revisiting them during my personal development time at DataCamp.

I decided to read and process the theory, and translate the exercises into code. This was also the perfect opportunity to try out a different programming language, Go. To make it easier for most people to understand, I also wrote everything in Typescript, so you get to choose your preference.

Is it perfect? Most likely not!

Is there room for improvement? Always! Feel free to raise a PR at any time.

Is it enough to start your learning journey? 100%!

The Universal Laws of Speed

Stacksmith ships with a small CLI. You can clone the repo, run yarn start, pick a chapter, and watch different algorithms race each other.

In Chapter 2, I compare Linear Search and Binary Search on the same dataset.

Linear Search checks items one by one → O(N)

Binary Search repeatedly cuts a sorted list in half → O(log N)

Binary vs Linear Search

This table clearly shows how the checks change based on the data.

The surprising part wasn’t the difference between Go and TypeScript. It was how insignificant that difference became once the algorithm changed.

Yes, Go’s Linear Search was faster than TypeScript’s in raw milliseconds.

But the gap between O(N) and O(log N) completely dwarfed the gap between languages.

If you pick an O(N) solution where O(log N) is possible, no compiler, JIT, or runtime can save you.

That’s the universal law: algorithms scale, languages don’t.

Where Bad Performance Hides In Your Code

Most of us are not writing search functions from scratch. Our actual work looks more like “fetch data, filter it, merge two arrays, update the UI”. That feels harmless.

Take this very common pattern:

const activeUsers = users.map((user) => {
  const details = userDetails.find((d) => d.id === user.id);
  return { ...user, ...details };
});

It is short, readable, and easy to review. It is also secretly O(N²). If both lists contain around 1 000 items, this friendly looking code performs about 1 000 000 comparisons.

On small datasets you will not notice. But on a page where users can filter, sort, or search, it starts to add up. Suddenly a simple dropdown freeze feels “mysterious”. We reach for useMemo, or we blame the backend, or we start worrying that React is just slow.

If we rewrite the same code to build a small hash map of userDetails first, the cost of each lookup becomes O(1) instead of O(N). The total cost drops from roughly 1 000 000 operations to something closer to a few thousand.

Same feature. Same framework. Same browser. Completely different experience for the person using it, and completely different performance.

Once you start to see patterns like this, you cannot unsee them. They appear in every language: in Python scripts, in Java microservices, in SQL queries, even in infrastructure code.

Becoming a Stacksmith

That is why I picked the name Stacksmith.

A blacksmith learns the character of their materials. Iron is strong but brittle. Steel can bend. They choose the right one for the job.

As developers we work with different materials: arrays, maps, sets, trees, graphs, stacks, queues. Each one has a character. Some are great for random access. Some are great for inserting in the middle. Some are built for fast lookups.

Stacksmith is my workbench to explore that craft:

• Around twenty chapters of exercises, from arrays and linked lists to graphs and dynamic programming.
• Every solution written side by side in TypeScript and Go. (sidenote: the code is not production-grade, and that’s fine!)
• A CLI to run the algorithms, print timings, and feel how they behave under different input sizes.
• A “KB Assistant” where you can paste your own code and get a quick, human readable “Big O audit”. (If it doesn’t have AI, is it even real nowadays?)

The goal is not to create perfect implementations. The goal is to give you a safe place to experiment and to build an intuition for how your choices in data structures and algorithms show up in real performance.

The Dual Language Advantage

Even if you mostly write TypeScript today, I would still invite you to look at the Go implementations in the repo.

TypeScript gives you many helpful abstractions. It hides pointers and most memory allocation details. It lets you resize arrays and objects without thinking too much about what happens behind the scenes.

Go is a bit more explicit. When you build a linked list, you wire together nodes that point to each other. When you create a slice and append to it, you see how capacity comes into play.

Writing the same algorithm in both languages forces you to reconcile the two views. You start to see that the “magic” behaviour in your high level language is still bound by the same low level rules.

You do not have to become a Go expert to benefit from this. Seeing how a few core structures are built in a different ecosystem is often enough. After that, you carry the mental model with you, no matter what language you are using at work.

Why This Matters For Your Day Job

So what is the practical outcome of caring about this?

First, there is the obvious one: speed. A list filter that runs in O(N) instead of O(N²) will feel smooth on devices that are older, slower, or busy doing other things. That is a quiet kind of inclusivity. You are respecting the time and patience of your users.

Second, there is cost. On the backend, more efficient algorithms and data structures usually mean less CPU time and more throughput, which slows down the need for scaling, which in turn reduces infrastructure cost (even if it’s negligible at a small scale). That might not show up on your personal credit card, but it does matter for the teams and companies that pay for the infrastructure (no matter how negligible).

Finally, and maybe the most important, it is foundational knowledge. The exact frameworks and libraries you use will change over your career. The core ideas behind stacks, queues, maps and graphs are not going anywhere.

How To Try Stacksmith

If you are curious, here is a simple way to get started:

Clone the repo: git clone https://github.com/joachimzeelmaekers/stacksmith.

Install the dependencies and run the CLI with yarn start.

Pick a chapter that sounds familiar, like arrays or maps.

Run a benchmark a few times, then change the input size and see what happens.

If you feel brave, paste a piece of your own code into the Knowledge Base Assistant (because what’s a post in 2026 without some AI attached to it?) and see what it says about your current approach.

Note: Make sure to read the README if you wish to use this!

You do not have to go through all twenty chapters. Even spending an evening with two or three of them can give you a strong sense of how much impact “small” algorithmic choices can have.

Conclusion

Performance is not a niche concern for low level specialists. It is part of building software that feels respectful, reliable, and enjoyable to use.

You can switch languages, frameworks, or hosting platforms, and those choices do matter. But underneath all of them, the same rules still apply.

If you want a practical way to explore those rules, take a look at Stacksmith.

Clone it. Run yarn start. Race a few algorithms. Bring your own snippets.

Most of all, use it as a reminder that you do not need to become a “low-level engineer” to write performant code. You just need to take a step back to the foundation, and treat data structures and algorithms as tools in your craft, no matter which language you use.

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! 🎄

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.

After some advice that I received from another developer, who also has a blog, I started to use Ghost. Ghost is a full-stack, modern publishing platform to create your personal blog. With their Medium-like editor, one-click mailing list feature, optional paid subscriptions for members and much more Ghost offers a complete solution for building your audience.

Now let me explain why I chose Ghost and why I did not continue using Strapi headless CMS with Gatsby.

Editor

I used to write my blogs in Markdown, which is a formatting language often used by developers. And I love Markdown, don’t get me wrong. But editors, like the ones from Medium or Ghost, offer easy solutions to drag and drop images, add code-snippets, embed external media, etc…

By using this editor, I have the ability to schedule posts for a future date without having to be online. This approach allows you to write multiple posts and schedule them for the upcoming weeks. Of course, this is also possible when you build your own blog, but this will cost you some time to make sure it works properly.

Integrations

Speaking of time, I love publishing my content on Dev and Medium. And I used to write my articles in Markdown, and copy-paste them to all the platforms. This is fine in the beginning, but it’s pretty time-consuming and prone to error.

This hassle is solved by using the Zapier integration from Ghost. Zapier is a platform that helps you automate workflows by creating a Zap. An example of a Zap is tweeting your published article automatically on Twitter. By creating these workflows, you can automate a lot of the process, and focus simply on creating new articles. Zapier has about 2000 integrations with other apps, so this is a powerful tool to use. It’s also free for the first 5 zaps, which is all you need!

Ghost also offers about 30 events to listen on. If you want to create custom integrations, you can easily set up a service and configure your webhook in the platform. If you want more information about the available events, visit the docs.

Subscribers

When you try to start a mailing list, there are a couple of questions that pop up. My main question was, which tool do I use, and how do I manage the list easily?

Well, Ghost offers a solution to this problem. By toggling on the member-functionality, you get a subscribe option on your website. When anyone subscribes, they are added to your member list. Once someone is subscribed, you can send your new articles via mail on publishing without extra costs.

You can also export your members into another tool like MailerLite or Mailchimp so you can send additional emails that are not linked to your articles. For example, sending an email with your newest podcast or a survey!

Customisation

As a developer, I find it important to be able to customise the theme. In the beginning, it’s not that important. But when you progress, you have to be able to change the design, improve user experience and add some additional features.

When you use Ghost, you can buy a theme that fits you or create your own theme. Ghost uses a combination of Javascript and handlebars. This allows you to customise the whole theme and add features on the go. You can integrate your Github with Ghost to keep track of your versions, and you could even sell your theme if you like.

Don’t want to use handlebars and Javascript? No problem! Ghost offers an API to use the platform as a headless CMS. This means that you can connect any frontend to the platform without using the themes provided by Ghost or the community. This allows you to use the powerful features from Ghost together with your preferred frontend platform.

Maintainability

When you create your own blog, you will always have to maintain the code. Some APIs will change over time and some of your integrations will stop working for some reason. When you use Ghost, you pay the monthly fee to maintain the platform and add additional features. If your blog is very successful, you might also want to create other content. Using a platform like Ghost will save you time in the long run by simplifying the process.

When you have some experience as a developer, you will know that building a great application takes time. In my case, I don’t have the amount of time to work on a platform and put out content. When you’re already working as a full-time developer and run a side business, it’s challenging to maintain the code for your personal blog without sacrificing all your time.

Metadata configuration and SEO

In creating a publishing platform, SEO and metadata configuration is important. You have to be able to configure the title and the description and make sure it’s properly displayed in Google. It takes some time to configure this, and platforms like Ghost already have this in place. You get the configuration options for every post with a preview available.

Conclusion

I know I focused on Ghost as the go-to platform. The reason for this is that it’s the platform that I use and I know most about. There are other platforms out there, which might be even better, but for this article, I wanted to focus on this platform.

I could go on and on about why you should consider using a platform like Ghost. But it’s all a matter of the amount of effort you want to put it. If you have no other projects except for your own blog, you might want to consider building your own platform because you will learn a lot in doing so!

But when you consider a blog as one of your side projects, you might want to pick an existing platform. You do have to take into account that you have to pay the monthly fee of 36$/month or 29$/month if you pay annually. But in my case, it’s more than worth it. When you build your own platform you also have to pay for monitoring, hosting, some paid integrations and other things. So before you start building, consider all the options. One of them being Ghost!

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.

In this post, I will go over some of the rules that you can apply to improve your code. All code samples are Javascript.

I find that Readable code is maintainable code.

The goal for me as a developer is to write quality code. Every developer on the team, regardless of their skill level, has to be able to understand the code by reading it. This helps young developers to be more confident in writing code.

Remove unnecessary code comments

Of course, some code can be very complex. I know that and I have seen that many times. Here where I would add proper documentation and code comments. Don’t get me wrong. I’m not a fan of code comments or in Javascript JSdoc. Or at least not as long as I don’t need them.

I don’t need any comments to read that this function takes X amount of arrays and merges them together into a new array.

function mergeArrays(...arrays) {
  let mergedArray = []
 
  arrays.forEach(array => {
      mergedArray = [...mergedArray, ...array]
  })
 
  return mergedArray
}

Adding JSdoc to this code does not improve the readability. I expect that my team members know what the spread operator is. And if they don’t, they should ask about it during the code reviews.

And let’s not forget the commented code blocks. Only one solution for that: DELETE THAT CODE. Git has the amazing feature to checkout old code, so why leave it in the comments?

Please stop making a junkyard of your codebase.

Focus on naming

If you look at the name mergeArrays, it should be very clear that this function combines X amount of arrays into a new one.

I know that naming things is hard. And the more complex the function, the harder the naming part will be… I use a rule to make naming easier for myself. Here’s how I do it.

Imagine a function that merges 2 arrays of numbers and generates a new unique list of numbers. How would you name it? Something like this?

function mergeNumberListIntoUniqueList(listOne, listTwo) {
  return [...new Set([...listOne, ...listTwo])]
}

The name is not that bad, because it does what it says. The problem is that the function is doing 2 things. The more a function does, the more difficult it is to name it. Extracting it into 2 separate functions will make it much easier and more reusable at the same time.

function mergeLists(listOne, listTwo) {
  return [...listOne, ...listTwo]
}

function createUniqueList(list) {
  return [...new Set(list)]
}

Of course, it’s easy to create a beautiful one-liner without calling a new function. But sometimes, one-liners are not that readable.

If statements

I could not find a name for this problem… See! Naming is hard…

But I see this a lot.

if(value === 'duck' || value === 'dog' || value === 'cat') {
  // ...
}

By doing this, you create a readable piece of code that looks like an English sentence.

const options = ['duck', 'dog', 'cat'];
if (options.includes(value)) {
  // ...
}

If options include value then …

Early exit

There are a dozen ways of naming this principle, but I picked the name “Early exit”. So let me show you a piece of code. I’m sure you saw something like this before.

function handleEvent(event) {
  if (event) {
    const target = event.target;
    if (target) {
      // Your awesome piece of code that uses target
    }
  }
}

Here we are trying to check if the object event is not falsy and the property target is available. Now the problem here is that we are already using 2 if statements.

Let’s see how you could do an “early exit” here.

function handleEvent(event) {
  if (!event || !event.target) {
    return;
  }
  // Your awesome piece of code that uses target
}

By applying the “early exit” here, you check if event and event.target is not falsy. It’s immediately clear that we are sure that event.target is not falsy. It’s also clear that no other code is executed if this statement is falsy.

Destructuring assignment

In Javascript, we can destructure objects and arrays.

According to the documentation, found on developer.mozilla.org, the destructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables.

Some code samples

// Destructuring an object
const numbers = {one: 1, two: 2};
const {one, two} = numbers;
console.log(one); // 1
console.log(two); // 2

// Destructuring an array
const numbers = [1, 2, 3, 4, 5];
const [one, two] = numbers;
console.log(one); // 1
console.log(two); // 2

The problem with destructuring is that it sometimes creates a bad name for a property. The perfect example is fetching data from an API and receiving a response object which has a data property.

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name} = response.data

This code sample indicates that you are fetching an organizer with id 1. The organizer object has a name, and you destructure it. Nothing wrong with that.

This code works and is fine. But why is the name still name? Will that be the only name property in the whole scope? And from which object is it the name again?

Avoid these questions by renaming the property.

const url = "http://localhost:8080/api/v1/organizers/1"
const response = await axios.get(url)
const {name: organizerName} = response.data

This code becomes more readable. Everyone will know that the variable is the name of the organizer.

The boy scout rule

Ever heard of the phrase: “Leave it better than you found it”?

Well, this is exactly what the boy scout rule is. Leave the code better than you found it. Did you find a code smell? Refactor it! Did you find an unused variable? Remove it!

I like to compare it with a room cleaning situation. Let’s imagine that everyone in your house leaves the dishes on the sink, puts all garbage in the hallway, and leaves all the laundry in the bathroom. But every Sunday, you have to clean up the whole house and it takes well over 4 hours. Would you like that?

I’m sure that the answer is no. So if everyone immediately cleans up little parts of the house, the work will be smaller on Sunday.

This is the same with codebases. If every small code smell is left in the codebase, no one deletes unused variables, the linter is going crazy and has about 77 warnings. There will be a lot of clean-up to do, but if everyone takes his responsibility and applies the boy scout rule, a lot of the problems will be solved.

Code style

Last but not least. Determine a code style in your team.

I don’t care if you like single quotes or double quotes, spaces or tabs, trailing comma or no trailing comma. Pick 1 style and stick to it. You can do this with a linter and/or a prettier.

There are so many tools to use to fix this kind of issue. My favorite is a pre-commit hook using Husky. Prettier also has a page in their documentation about pre-commit hooks.

This pre-commit hook always runs the configured command before every commit. If you configure it in the correct way, it runs the prettier and applies all the rules on all files. This makes sure that the team always has the same code style without any bad code.

Conclusion

I know that some rules are obvious and others are not. But as a full-time developer, I get to work on different codebases. The importance of these rules only become clear in larger codebases. But that doesn’t mean that you should not apply it in your smaller projects. Improving your code quality will help you to be more efficient in your smaller projects. It will also help your team with reading the code and approving your pull requests. As I said, readable code is more maintainable, but it also has many more advantages.

If you wish to learn more about clean code, you should read Clean Code by Robert Martin. If you like my content, make sure to follow me on Twitter where I post all the links to the blogs I release. I try to release 1 every week on various topics.

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.