Alberto van Oldenbarneveld

From Product Code to GTM Engineering

Fri, 06 Nov 2026 00:00:00 GMT

Since October I have been working as our GTM engineer. I still write code for the platform, so I haven’t left the product, but a big part of my week is somewhere else now. In practice that means I work with the sales team on the CRM and on everything that happens between someone hearing about us and someone signing.

Knocking on doors

From the start I wanted context for everything I built. My lead could tell me what to do, and that was fine, but I also wanted to know who it was for and why the business needed it. I wanted to understand how the company actually works: who we sell to, what we help them with and how we bring them value.

I wanted to improve the product, and the same two questions kept coming up. Who is this for? How will it help them? To answer them I kept knocking on doors, and more often than not the answers were in sales. In a team this small, the people who know how customers use the product are a few desks away. I’d ask them what they needed from the platform, or why a deal had stalled. Nobody asked me to do it. It just seemed like the best way to know whether my code was helping anyone.

At some point I started to see that a lot of what the company needed was on the commercial side, and a couple of weeks before October those conversations turned into an offer to work with them on the CRM as a GTM engineer. Saying yes was easy. Connecting the code I write with the business it’s supposed to help is pretty much what I’d been trying to do on my own anyway.

What sales taught me about being a dev

Being a developer is solving problems for users, and users want whatever they came to do to be as easy as possible. So the easiest path through the product should be the one that solves the problem you’re building for. If the thing you want people to do is buried three screens deep, they won’t do it, however well it’s built.

You also have to assume people need a lot of clarity. They don’t know the product the way you do, and they shouldn’t have to. Every screen should make it obvious what to do next and why it’s worth doing, and if using it doesn’t give them something back, they’ll stop.

None of that is new. It’s easy to agree with, and much harder to keep in mind when you’re deep in a component. Sales sees it every day, because they’re the ones explaining the product to people who have never seen it, and listening to them made it a lot less abstract for me.

What the company needs over what I enjoy

I like code. I like cleaning things up and slowly turning a component nobody wants to touch into something you can read. I wrote about that in my six months post, and I still enjoy it.

What I’m after, though, is to be part of a story. I want to work at a company that grows and scales, and to be there while things go well. It matters to me that this one can save costs and improve people’s quality of life, so I want it to get there. If that’s the goal, my time should go where it moves the company forward, and right now a lot of that is on the commercial side. Some weeks that means less time in the editor, and I’m fine with that.

Learning who the customer is

Part of the new job has been going to conferences in different parts of the country. I go there to learn who our customers are, what kind of people we end up talking to, how deals actually get made, how we sell the product and what people get out of it.

In the codebase I see how features work. At a conference I hear how someone describes the problem before they know we exist, and which part of what we do makes them stop and ask more. That’s something I was never going to get from reading code, and it feeds straight back into how I think about the platform.

Studying the pipeline

When you join something that already runs, the first job is understanding it. The sales process works and the people in it know it well. What I wanted to find out was why it works when it works.

So the most engineer thing I’ve done so far is a historical study of our pipeline. I went back through our deals and traced each one from the first contact: where the lead came from, what kind of company it was, when we reached out, how long each stage took, and what happened right before it moved forward or stalled. Then I did the same with the ones we lost, to see what has worked, what hasn’t, and which kind of customer we have the most success with.

Now we’re building a campaign to reach more of the customers who look like the ones that already work for us. Before we judge it, we need to agree on what “working” means and measure it, so we can check our ideas against real numbers instead of gut feeling (mine included). It’s early, and I’ll write about the results once there are some.

Same habit, different codebase

This feels a lot like my first weeks on the product. Back then most of the work was reading and asking “why the hell is this here?” before touching anything. The pipeline is the same exercise with deals instead of components. Every field and stage has a reason behind it, and the work is finding that reason before deciding anything.

That’s the plan, really: treat the pipeline the way I’d treat a codebase. Understand how it works before touching it, measure it, find where it can get better, change one thing and check whether it helped. It’s the only way I know how to work, and so far it fits the job pretty well.

My Claude Code and Codex Workflow on an Existing Codebase

Tue, 20 Oct 2026 00:00:00 GMT

In my six-months post I wrote about AI letting me move faster than my understanding. I have thought about that a lot since, mostly because using these tools at work makes me deal with it every day.

A few weeks ago I was setting up Dependabot on three of our repositories. It’s the GitHub bot that opens a PR when one of your dependencies has a known vulnerability. Part of it needed repository settings changed, and the agent gave me step-by-step instructions to go and change them myself. I didn’t think I was allowed to, so I asked it to check. I wasn’t. Those settings need admin access and I only have the role below it.

So we sent a message to our GitHub admin instead, with a line asking them to check the branch protection rules while they were at it. Afterwards the agent decided that line had been unnecessary. It had asked GitHub, got a 404 back, and concluded there were no rules. I said maybe I just don’t have access. It went and read the docs, and that was it: GitHub returns the same 404 whether the rules don’t exist or you aren’t allowed to see them. It had turned “I can’t see anything” into “there’s nothing there” and reported it as something it had checked.

Nothing broke, and the message had gone out with the right line in it. But it was the second confident wrong answer in the same session, and both times I only caught it because something sounded off to me.

I use Claude Code and Codex. A fair amount of my work now is asking an agent to investigate something, discussing the approach with it, and then checking what it produced. So I wanted to write down what that looks like right now. Partly because it might help someone in a similar spot, and partly because explaining my own process is usually how I find the bits I haven’t thought through.

Writing down the things I kept repeating

The repositories I work in have a lot of history. Shared components, old patterns that are still everywhere, decisions that only make sense once you know what the product was doing when someone made them.

An agent gets moving very fast in that environment. It also happily creates a new component when we already have one, suggests an import that doesn’t work in this particular setup, or cleans up something that turns out to be necessary.

I got tired of making the same corrections, so I keep a shared AGENTS.md across the work repositories. Both agents read the same instructions. Commit conventions live in a separate file, and there’s another one that lists the incidents behind each rule. “Verify it at runtime”, for example, comes with a note that we diagnosed a visual bug from the stylesheet more than once and only found the real cause after checking computed styles in the browser.

The workflow has six stops: trace, options, report, tests, cleanup, and PR description. A slightly formal way of writing down where I want the agent to pause and what I need to know before we carry on.

Understanding the ticket before touching anything

Most tasks start in Zoho Projects, and a lot of what a ticket actually says lives in its screenshots. The bug, or the design someone wants, is in the picture, and the text around it is often a line or two. For a while I was copying tickets into the prompt by hand, which left the images behind.

So I built a skill for it. It talks to the Zoho API with an OAuth token I set up for myself (a “Self Client” in Zoho’s API console), which lets it read tasks, comment on them, create new ones, and download the images embedded in a description. The agent saves those images to a scratch folder and opens them like any other file, so it’s looking at the same screenshot I am. It also caches the access token for its full hour, because Zoho limits how often you can ask for a new one and an early version kept dying halfway through a batch of tasks.

The first thing I want back is the agent’s version of the problem, before it opens any code. What does it think the ticket is asking for? What should happen, and what happens instead? If its reading doesn’t match mine, we’ve found the misunderstanding while it costs one message to fix. It also leaves a written record. When I write the PR description, or someone asks a couple of months later why we changed something, the agent’s reading of the problem and my corrections to it are there, and I don’t have to rely on memory.

If the problem still feels fuzzy after that, I use a grilling skill. It has the agent question me about the request in rounds, each question with its own suggested answer, until we’re sure we understand it the same way. Sometimes I’ve described the symptom badly, or I’m calling something a bug without having checked what it was supposed to do. It feels slow when I think I already know the answer, but finding out I asked for the wrong change after it’s been implemented is a lot more annoying.

Only then does it trace the actual code. Where does the data come from? What transforms it? Which component ends up showing it? Is there already a helper for this? What else uses the same thing?

It reports the path it followed, the files it expects to change, and what it still doesn’t know. File references have to come from code it actually opened, because a plausible filename is very easy to mistake for investigation. That last part, saying what it doesn’t know, is where something like the 404 is supposed to come out.

Picking an approach while it’s still cheap to change

Once we agree on the problem, I want to see the reasonable ways to solve it. Usually there are a couple. A local change might be enough, or the problem might really belong in a shared component. Moving some logic could make the next change easier and also affect callers outside the ticket.

I ask for those costs to be spelled out, including for the cheap option, because agents tend to reach for the bigger refactor. If there’s only one sensible approach, fine. I don’t need three options when two exist just so the recommendation looks good.

After choosing, we sketch how the work should split into commits and start a fresh branch from develop. The split is mostly for the reviewer. With the amount of technical debt we have, someone still has to check every change by hand, and that’s much easier when each commit does one thing: the refactor in one, the behaviour change in another, the cleanup in its own. Planning it this early is also often when I notice that a supposedly small task has several things mixed into it.

Cleaning up as we go

In my first-weeks post I was very careful not to touch anything beyond the immediate request. That made sense when I was new to the codebase. Now we clean up as we go.

If something in the code we’re already working in is worth fixing, isn’t tangential to the task, and still fits in what a reviewer can reasonably check in one PR, it goes in, in its own commit. Reusing a shared component, pulling out a duplicated helper, removing dead code. Ease of review is still the limit.

If it’s worth doing but too big for this PR, we create the ticket ourselves with the same Zoho skill: what we found, where it is, and why it’s worth doing.

Once the agent has implemented the change, I want a report of what it did and why, especially where it departed from what we agreed. I also want to know what it checked and what it didn’t. “I didn’t run that” is useful. A vague “everything works” just makes the review harder.

Tests that would have caught the problem

One incident in the rationale file was a test meant to protect a change involving an email address. The fixture was already lowercase, so it passed against both the old code and the new code. A green test that never exercised the difference it was supposed to check.

That’s why I ask for regression tests to be run against the old code too. A test for the behaviour we changed should fail there. A test for something we meant to keep should pass. It’s a way of checking the test itself, which matters when an agent can write a convincing-looking suite in a minute.

For components with no tests at all, I also want coverage of the states and actions a user can actually reach, starting with the main flows and whatever the change affects. Otherwise you end up with one test around the new line and nothing protecting the old component around it.

Visual work needs a different kind of checking. We’ve had cases where reading the CSS produced a confident explanation that didn’t match what the browser was rendering. So I want computed styles, real interactions, and checks at the viewports the change could affect. Fixing the screenshot from the ticket tells me nothing about whether we broke a narrower screen.

Explaining the result

Dead code only gets removed if we can prove it’s dead. Some styles once looked unused because their names never appeared as literal references, but a component picked them dynamically through styles[variant]. Deleting them would have killed working hover states. Searching for a name helps, but you still have to understand how the code gets to it.

Then the PR description. I use a skill for that too, followed by a humanizer pass, because otherwise I get a lot of text announcing fairly ordinary changes like a major engineering achievement. I just want someone to be able to read it and understand the work.

Visual changes get screenshots, and I got picky about those too. The agent opens the app in a headless browser, fixes the viewport before the first shot so before and after have the same size and the same data, and saves real PNG files. GitHub’s CLI can upload attachments now, so it puts them on the PR itself, and I don’t spend time dragging images into the web editor. Before and after sit side by side in a table, sized by width only, because two screenshots of the same screen are rarely the same height and forcing one height squashes one of them. If a change takes a few steps to see, it records a GIF of the flow.

The reviewer needs the problem, why we chose this approach, and where the verification stops. They weren’t in the conversation while we ruled out the other options, and a description that only narrates the diff makes them do that thinking again. The PR then gets linked back to the task so you can follow the work from either side.

Why we still review every PR by hand

With all that written down, it might sound like we’re close to handing over a ticket and letting the whole thing run on its own. We’re not, and the amount of technical debt is a big part of why.

Too much behaviour still needs investigating. The existing checks don’t describe everything the product is supposed to do, and some dependencies between parts of the code only show up when you follow a specific flow. I wouldn’t be comfortable treating a finished agent run plus green CI as enough to merge.

What we’re working on is making more of the process deterministic through tools and CI. Repeatable checks that run and give results we can inspect, so we depend less on an agent remembering an instruction or a reviewer spotting the same mistake again. Instructions describe how we want to work. Turning a repeated check into tooling is more dependable than asking for it in prose every session, and there’s still plenty to do there.

PRs need manual review today, and I expect they will for a long time. Someone still has to check the behaviour against what the ticket actually wanted, question the scope, and decide whether a new abstraction will make the code easier to live with. Better automated checks should leave more attention for that.

The part I still have to do

All of this costs something. Reading reports takes attention. So does checking whether a confident explanation is backed by evidence. Maintaining the instructions can turn into its own little project, and I have to be careful that I’m improving the work and not just adding process around it.

A typo doesn’t need the same conversation as a change to a shared data flow, so the early stops get skipped for genuinely trivial stuff. For everything else, I’m still working out how much structure earns its keep.

I do like that the workflow gives me specific places to stop and think. I can ask for help tracing something unfamiliar, then check that I understand the explanation before agreeing to change anything. That helps with getting the ticket done and with learning the codebase.

The question from the earlier post hasn’t gone away, though. If I came back to this change in a month without the chat history, would I understand why we made it and be able to work on it again? That’s probably the thing I most need to keep an eye on while I keep changing how I work.

Six Months as a Junior Developer in a Real Codebase

Sat, 11 Apr 2026 00:00:00 GMT

It’s been six months since I started working as a developer. I have tried to write about it a few times, but most drafts sounded more certain than I actually feel. Too much like I had already turned the whole thing into a lesson. I don’t think I have.

Clean code and real codebases

The main thing I keep noticing is the gap between learning to code in a clean environment and working inside a codebase that has been dragged through actual product decisions.

When you are learning, the world is kind of clinical: the examples are small, the problems usually have a shape. Even when a personal project becomes messy, it is still your mess. You know where the bad decisions came from because, most of the time, you made them.

The frontend I walked into has a lot of history in it. Components that are much bigger than they should be. CSS that makes you nervous before you touch it. A lot of debt, basically. Which is kinda normal. A startup needed to ship things, and the product keeps growing, and architecture does not always get to be the first concern.

Seeing the problem is not solving it

Pretty early on I looked at the UI and thought we needed a proper design system. Tokens, consistency, shared decisions, all of that. I pushed for it at a periodical meeting, and people loved it. Made absolute sense, go for it, they said.

But then you have to sit down and think about how you should do it. And that’s the question: How do you introduce that into the repo without stopping everything else? Where do you start? Which pieces do you migrate first? What do you do with the weird old stuff that is half reusable and half extremely specific? How do you avoid turning a good idea into another layer of unfinished work? That was probably the first time the job felt very different from the version of programming I had in my head. That’s when I learned that seeing the problem was the easy part. Implementing the solution without breaking half the house was the work.

Most of the work is understanding

There are days where adding the actual code for a feature is not the part that takes the most energy. The harder bit is understanding where the change belongs, or refactoring the component enough that the new work does not make it worse, or touching the CSS and then checking that you have not quietly ruined some responsive layout three screens away.

I spend so much more time reading than I expected. Not even just reading code line by line. I mean reading around it. Trying to understand why something is shaped the way it is before deciding that it is wrong.

More often than not the question is: why the hell is this here?

Sometimes, after enough digging, the answer is less stupid than it looked at first. A feature started as one thing and became another. Someone reused something because there was no time. A flow that looks strange now solved a different problem six months ago. A bad abstraction exists because the alternative was worse. Other times it really is just a mess.

My taste in code has changed

My taste in code has changed because of that. I am much less impressed by clever code, because clever code is just annoying to deal with.

I like neat solutions and good abstractions. But I care a lot more about whether the code is easy to understand when you are tired, trying to trace a bug or making a small change without wanting to load the entire system into your head.

I have also become more relaxed about duplication. If removing duplication means creating a shared abstraction that everyone has to decode before making a tiny change, I am not sure that is always a win. Sometimes repeated code is ugly but understandable. Sometimes the abstraction is cleaner on paper and worse in the day to day. I’m not sure the tradeoff is always worth it.

That’s another thing, the job is a lot more social than I expected.

I had the headphones-on version of development in my head. Long focus sessions. You disappear into the editor and come back with code. A lot of the actual job is talking to people. Aligning with Design the intent behind the visuals. Asking why something works like this. Negotiating time lines and explaining blockers. Checking whether a change makes sense for the product. Explaining why a quick fix might create trouble later. Realizing that sometimes the blocker is not technical, but timing, priority, or the fact that the team cannot afford to open that whole area right now.

AI changes the learning curve

The AI part has probably made the whole thing feel even less stable. Some days you read someone saying that if you use AI too much, you will never really understand the code. Then you read someone else saying that writing everything by hand is already obsolete, and that the only sensible thing is to move up a level of abstraction as fast as possible. I have been stuck between those two arguments for quite a while.

AI is very useful. Pretending otherwise feels ridiculous. It can speed you up, help you compare approaches, explain unfamiliar code, generate boring pieces, and get you unstuck when you are circling the same problem for too long. But it can also let you move faster than your understanding. There is a difference between using a tool and outsourcing the exact bit of thinking you needed to develop. The hard question for me is where that line is. What do I need to understand deeply? What can I safely delegate? When am I saving time, and when am I just postponing the moment where I have to learn how the thing works?

My guess is that the level of abstraction keeps moving up, whether I like it on any given day or not. More of the value will probably sit in architecture, data flow, product judgment, trade-offs, and knowing which problems are worth solving in the first place. But somebody will always need to understand the ugly details. Somebody still has to trace the weird bug, read the old component, notice the regression, and know when a generated answer is confidently wrong.

I do not know exactly where I land yet. It is just one of the main tensions of learning this job right now.

Code is in service of the product

The other thing I keep thinking about is product.

I like the engineering side, cleaning things up, understanding flows. Taking a piece of code that feels unreadable, slowly building a mental map and turning it into something logical. But software first and foremost has to do something for someone. That may sound obvious, but you would be surprised about how very easy to forget when you are deep in the code. You can spend a lot of energy making something technically nicer and still not move the product much. And the flipside is also true, you can also ship something valuable with code that makes you wince a bit.

In the kind of environment I am in, code quality matters because it protects your ability to hold everything together. It should reduce the chances that every new feature leaves more mess behind, but it is still in service of the product. That is probably the most frustrating part so far. Sometimes it’s easier to see what good code should look like than knowing if the service it enables actually provides value.

Where I am after six months

Six months is not a lot of time. I am still very early in this and the work already looks different from what I imagined. Without talking about how fast the job seems to be changing. I’m happy though. I love solving problems. I love the feeling of taking something that seemed impossible to understand and slowly grasping it. That feedback loop keeps me going. There is always so much to do too. I’m continually turning ideas around in my head, from repo maintenance to reducing friction to new features. It’s an infinite pool to dive in, and I love it.

Very excited to see where the next six months will take me.

My Five-Step Process for Learning as a New Developer

Sat, 15 Nov 2025 00:00:00 GMT

As I’m pretty sure happens to everyone who starts out as a developer, I’ve recently come to realize how much I don’t know. The complexity at work is ramping up fast, and I feel like I am hanging on for dear life. As a result, I’m trying to keep up in my free time, and I’ve been thinking long and hard on how to improve fast.

While learning I’ve been forming this mental model and refining it to improve the structure of my learning in order to accelerate it. I’ve been testing it, and it seems like it has settled into a stable structure, so I thought it might be worthwhile to reflect on it.

Learning things deeply requires a process that goes from receiving information, to understanding it, owning it, and then being able to reproduce it. These for me are the fundamental steps of acquiring knowledge.

I’ve found a way to work through these steps that makes sense for me and would like to share it both so it can be helpful to others, and also as a way to internalize the process for myself (let’s call this the reproducing part of my own knowledge.)

Step 1: Acquiring Information

There is a lot of information out there. YouTube courses, Udemy, Scrimba, The Odin Project, FreeCodeCamp. So many ways to learn how to code. Analysis paralysis is so dangerous here. Even going from course to course without structure can make you lose so much time. Without a clear structure, you end up jumping between resources and losing time.

I myself tried The Odin Project, but found it too text-heavy, and had a hard time bridging the gap from reading to putting into practice what I was learning. I also tried Scrimba, which is a great platform, but felt like it taught snippets in a way that felt too easy and didn’t feel like I was learning a lot. Both of these platforms are absolutely great, but for me they didn’t click in a sustainable way. Other options like FreeCodeCamp are also popular.

After trying lots of resources, what really clicked for me was Frontend Masters. Frontend Masters is an incredibly high quality platform, taught by renowned experts in the industry and their respective fields, with a high efficiency model. They focus on the key things you need to know, and focus on teaching you the mental models you actually use in real development work.

The subscription is pricy, but the value is excellent. The ROI is so high for your professional career that it becomes a no brainer if you can afford it and if you take the time to acquire the knowledge. It’s a platform that will pay for itself a dozen times over. However, being able to get the info from a source is one thing. You still have to fully understand it.

Frontend Masters offers exercises that are good for practicing the knowledge, but there is a previous step that can sometimes be hard and can be lacking. You can replay the videos until you fully get it, but the content can’t answer the specific questions you have. That’s where step 2 comes in.

Step 2: Owning the Information

I call this owning the information because this step requires self-direction in understanding the mental models, especially being able to detect where your understanding is lacking and question it so you can get a complete mental picture. This step therefore requires taking a proactive stance on your knowledge.

As soon as I feel like I am not grasping a concept fully and have to replay a Frontend Masters video a few times, I’ll get the transcription or the main parts that I’m not getting and paste them into ChatGPT. To me ChatGPT is an incredibly powerful tool that needs strict handling, because otherwise it will run away from you, and you’ll need to spend a lot of mental capital to get from it what you really want.

What I use for this is the Socratic method. Rather than reexplaining the concept I’m not getting (which it has a bad habit of doing), I’ll ask it to pick holes in my reasoning. Sometimes I will read the code out loud to it to help myself understand the code, and then reason what I think it is doing.

With closures, I struggled to understand exactly how the inner function retains access to the outer variables. Instead of it telling me how it worked over and over again, I would try to guess how it worked based on my understanding, and I would ask it to tell me where I was wrong and why. Through this progressive method I’ll at some point reach a decent understanding, at least to the point where I am able to explain what I am trying to understand.

This is the hardest part of the entire process, and requires a lot of willpower to get through. Luckily, ChatGPT will never run out of patience, so let’s be thankful for that. Once we have a basic understanding of the concept, the best way to integrate it is putting it in your own words.

Once I feel like I get the concept, it’s time to put it in my own words. For this I use Obsidian MD. It’s a notetaking app, where I store all my personal knowledge in what is called a knowledge vault. The info is easy to format, it uses markdown, and you can relate concepts to each other, so your notes need not be structured, because you can always do that later on.

The structure does not matter anyway; what matters at this stage is being able to write in your own words what you just learned. This helps greatly because just in case you didn’t understand anything fully while handling it with ChatGPT, this will show you your gaps in your knowledge immediately, which you can then use to go right back to talking it out until you get it. Once you can write it out, you can proceed to the next step.

Step 3: Putting It Into Practice

Frontend Masters provides its own coding examples, and you should definitely do them, because they are tied in directly to what you are learning, but I wanted a more structured way to get my problem-solving reps in, in a variety of concepts and while translating text problems to code.

The best way I found to do this is through the platform Exercism. Exercism is a non-profit that creates structured paths of coding exercises that help you integrate your learning, but it is important to understand that it is not a learning platform as such, because explanations are basic — more like brief summaries than full learning material.

The exercises, however, are somewhat difficult if you are a beginner with a surface understanding of the concepts, which is why they are perfect for this stage. This part is hard, because you need to be able to apply what you just learned, but if you did the previous step well, it shouldn’t be as hard as starting from scratch.

How hard this step is depends directly on how seriously you took the previous step. For me personally this has been the hardest part of my experience, but as I am getting more comfortable with the exercises, I’m really starting to like it.

Once you have the exercises done and have a somewhat solid base, it’s time to apply the knowledge in real projects. That’s where the next step comes in.

Step 4: Applying the Knowledge in Real Projects

Now that we’ve practiced the concept in isolated snippets made specifically to apply, we need to be able to use them in bigger contexts, where projects come in.

Projects however can be vague, too big in scope, and therefore make it hard to focus on what you are trying to learn in that specific instance. Here is where Frontend Mentor comes in.

Frontend Mentor is a platform where you can do directed projects, aimed at integrating specific learning but in contexts that reflect real-life work. The beauty of it is that it is self directed but more open ended, and you can see yourself tracing a line from what you learn to its real-world application.

This part of the process also requires some self-direction, because you need to be able to pick projects that relate directly to what you are learning.

Step 5: The Final Optional Step, A Complete Showcase Project

This is the big one. Once you are on solid ground, and especially if you want to show off all your learnings, at some point you will have to pick one ambitious project to work on, and make it as close to a real-world application as possible.

For this you need some reflection. Try to think of a real-life pain point you have, or something that you wished would exist, and try to build it yourself. It could be a todo list app that solves things that you wish the one you use had. Or a better instant messaging app. Or maybe a household organizing platform. Maybe a better budget dashboard. Try to think of any digital services you use, which are good and useful, but you wish they would be better.

The point here is not to make a startup that directly competes with it, but to have a project that personally motivates you, you have a vision for, and most importantly you can work consistently on.

This self directed vision of putting an idea into code is one of the most valuable things you can do. It will help you understand what coding is for, and will make you think about your work as a product. You will have to think about system design, structure, pain points, useful features, and priorities.

Owning a project like this is one of the most impactful things you can do for your career.

The point of it is not to create a perfect product to showcase, but the process you go through while trying to get it to work. It will showcase your thinking, which is the most important part. The product can be unfinished, and not working, but as long as you work on it consistently and try to get it up, it will force you to acquire invaluable skills.

Conclusions

This is my pipeline for learning. It may seem long and complicated, but for me it just streamlines a process that needs to take place in order to fully learn things. This is my way to reduce the chaos that is known as the messy middle in the path of learning as a dev. I wish I could just follow a single course from end to finish, but for me this is the best way to acquire the knowledge I need to advance. The most important part for me is that while slow it builds upon itself, and I don’t have to go back and relearn what I thought I already know as much. As they say, slow is smooth and smooth is fast.

Now that I’ve reached this point I hope I am able to pass this knowledge to the people coming up in this world behind me. If you have any questions, feel free to ask!

What I Learned in My First Weeks as a Junior Developer

Fri, 10 Oct 2025 00:00:00 GMT

I recently started working as a Full Stack Developer, and there are a few things I would like to talk about that just might not be as one would expect when starting to work as a dev, in the hope that it may help someone down the road, but also to put order to a few ideas that have been running around in my head.

Do not try to impress with flashy code

First off, in our eagerness of wanting to demonstrate how right they were to hire us, our first impulse might be to try to get as fast as possible to writing some flashy code to impress our coworkers, equals and superiors alike. While transmitting professionality and a willingness to be productive are obviously good qualities to have, I’ve come to realize that they are not the most important for standing out when starting in a new place.

Writing some clever piece of code to signal your abilities may seem like the right move, but more likely it will demonstrate a lack of care or understanding for the product you will be having to familiarize yourself with. But I get ahead of myself.

Understand your team first

The first days at any new dev job, if thought out right, will be a lot more about getting to know the team you’ll be working with. Your coworkers, their areas of responsibility, knowing who to go to for what, even who you share your desk with, their timings, the hours and their habits. Maybe you need to understand first what the company does, what their products are, what their goals are in the short and mid-term.

It’s easy to narrow our view to the code, but showing a willingness to understand the needs of the company as a whole first, and then tracing a line from those to what you do and understanding how you can support those goals through your work, your code, can put a lot of your peers and bosses at ease fast. If you’ve made a career change from another path, here is where your experience in other jobs may shine. Try to demonstrate nuance in your understanding of what they do. Anticipate possible roadblocks they might have had, or wonder about how they might try to solve future problems that will come up. By doing so you will show an alignment with their work that will be appreciated.

Build rapport early

Once situated a bit more in your role, and with better knowledge of exactly what they hired you to do, it’s time to turn to your peers. They’ll no doubt have some questions in their mind about how it will be to work with you, doubts that you can calm in the short run if you are proactive. Be friendly, and try to build rapport fast without being overeager.

Code is created by humans, and you will have to deal with other humans in your day-to-day so this will be just about as important as your own code. Your coworkers will not only think about what you can do, but also how easy you are to work with.

Study the culture

For this you will need to carefully study what the culture is. Are people reserved and serious and mostly talk about business topics? Is the culture more casual and relaxed and do they place importance on getting along with your peers and thus talk about more topics than work? Can everybody chime in on different topics or do the domain experts only have a say? Are processes strictly followed or are problems solved in a brainstorming manner? Also, try to notice if there are coworkers there that don’t follow the main culture as much and how they are valued. Gauge if isolated but heavily productive individual contributors are encouraged or tolerated. That alone will tell you a lot, and using that information to adapt to the team will give you breathing room in the short run.

What a culture says it values and what it actually values may be two entirely different things. Keep in mind what they say, and contrast with their reality. A company may say they value work-life balance, yet praise people who stay online until midnight and respond to emails on weekends. The message is clear: balance is a slogan, overwork is what gets rewarded. A company might claim they encourage learning and experimentation, but if every mistake is treated like a failure and people are afraid to ask questions, then the real value is risk avoidance, not growth. They may promote teamwork as a core value, but if promotions always go to the loudest voices rather than the people who lift others up, you’re not in a collaborative culture, you’re in a political one.

Get familiar with your tools

Next up I’d say get familiar with your tools. You might need to work with a new IDE, or a different OS, or both. Task planners, messaging apps, email apps. Spend some time watching some brief tutorials about their main features, print out some cheat sheets for shortcuts and practice them. It might seem dumb, and it will slow you down a bit in the short term, but it will improve your productivity and familiarity with them. If you set up the basics right you’ll be a lot faster in the midterm. If you need to use these tools in a public way take some time to consider what is the correct way to use them. Notice how your coworkers use them. If your coworkers write to you to fix something through an IM app instead of submitting a detailed ticket through the specific process, try to understand if this is the appropriate way of doing things in their culture or if your coworker is a bit of a wildcard and adapt your own behavior in consequence.

Learn the pipeline and documentation

Pipelines. To get the code you write in your IDE to Prod there will be no doubt a few steps involved. Understand how PRs should be written, who should be involved and when. Learn if you need to IM someone, or update a task planner or even send an email to someone to get that done.

This is also a nice introduction to talk about documentation. This can vary wildly from place to place. Some places might have such an abundance of information that you’ll have trouble knowing where to find what. In other places there might not be any documentation at all and you will have to learn everything on the go. I’ve read a lot about how new devs can get some wins in fast by improving documentation when they have to use them, because they are in the perfect position to see what is lacking and contribute it, but I’d say honestly try to understand first if it’s something that is valued, because if not you might just give the impression that you are wasting your time on pointless things or might even be afraid to code.

Respect the existing code

As you can see there are a lot of things that are very important in your first few days, a lot more than your coding abilities, and you will need to get a handle on those. But when those are said and done we will still need to talk about your coding. For me, the key insight of my journey is this: your code will need to show respect for the code that is already there.

You can’t just go running wild and implement a big new flashy feature and say, look at how this will improve your product, because by doing so you might break another ten things. Your coworkers will not appreciate that. Your autonomy will be reduced fast if you do so, because they’ll get the impression that you might do more damage than good. When you implement things, start small, but precise. It can be as simple as trying to understand where exactly the best place to perform an operation on a variable would be. Should it be right as it appears from the backend, so you normalize it for the entire flow? Should the operation be done defensively at various points so you increase the robustness of your app? Should it be right before it is shown to the user? One surgical operation in the correct place with a thorough explanation in your PR of why you think that it should be there and not somewhere else will earn you a lot more goodwill than a clever loop, for example. Focus on making thoughtful, high-quality contributions that improve the codebase without causing collateral damage.

Take a simple example: parsing a number that arrives from the backend as a string. It might seem logical to normalize it immediately at the top of the data flow, but doing so can easily introduce hidden bugs if other parts of the system depend on that value being a string. Suddenly, a small “cleanup” creates type mismatches in multiple components and breaks formatting, comparisons, or business logic somewhere down the line. Your eagerness to do things the “correct” way will not be appreciated here.

Ask before changing anything

Small implementations that do not break other things in the code and that adapt to the way things are being done already inside your repos are the way to go here. If you see things that might be improved or that are inconsistent do not, I repeat, do not take the initiative and fix them without being asked. The chances that you will do this perfectly and will thus be appreciated are tiny, and the risk that you’ll break something, step on someone’s toes, or violate an unspoken team convention is huge.

If you see something ask the most appropriate person in a casual way first. “Hey, I’ve seen that this specific part of the code works in this manner, is that something that is intended, is it a quirk or an unintended side effect of something else, or was this implemented this way for a specific reason?”, before even thinking of trying to lobby for a change.

Showing care for the existing code will earn you trust fast, and trust will give you autonomy, with which you will be able to do bigger and better things. For me, that is the key to impressing in your role fast.

Conclusions

At the end of the day, your first dev job is not about trying to look impressive, it is about becoming reliable. Your technical skills got you in the door, but it is your ability to understand the team, respect the codebase and make thoughtful, low-risk contributions that will earn you trust. Trust is everything. It is what gives you autonomy, responsibility and the chance to work on problems that actually matter. Start small, ask why before you change things and show consistency. If you focus on being dependable rather than flashy, your impact will grow naturally, long before you even realise it.

How to Prepare for an AeroPress Championship

Mon, 15 Sep 2025 00:00:00 GMT

I’m a regional AeroPress 2nd place holder (losing against the then current three-time regional champion), and lost in the first round against the then current national AeroPress champion in the national championship. When I’ve spoken about my experience, people have shown some interest, so I thought it might be a good thing to write a little summary of my findings.

What is an AeroPress Championship?

An AeroPress Championship is a competition in which I had to brew a coffee with an AeroPress at the same time as two other competitors. Three judges then tasted the coffees without communicating with each other, and each chose the best-tasting one by pointing to the winning cup. The name of each contestant was written under their cup, and the cups switched places before the judges tasted them, so there should have been no way of knowing whose cup was which.

The Rules

There were three rules I had to observe:

I couldn’t use more than 18 grams of ground coffee.
I had to present a coffee of at least 150ml.
I had to brew and present it within 5 minutes.

I was allowed to grind and heat my water before the timer started. The beans for the competition came from the organizers or sponsors and were the same for everyone. They were made available 10 days before the competition, either for pick-up or by mail. I received one bag of 250 grams of beans then, and another bag of the same size on the day of the competition.

In those 10 days, I experimented with the beans as much as I could. I had to keep in mind that if I used 18 grams of beans each time, I could only brew 13 cups, so I had to be mindful of how I used them.

My Strategy

My first step was picking up a well-renowned bottled water for coffee in my country. I could have tried different waters and done a cupping to really nail down the best option, but that would have required a lot of effort (brewing each water independently), and I didn’t think I would get much out of it at that stage.

From there I used a recipe I was already familiar with: the James Hoffmann Method.

11g beans
200ml water
100°C water
2:00 shake, 2:30-3:00 press

That gave me a baseline for what the coffee tasted like, and from there I could experiment. The good thing was that all the variables were defined and there was somewhat of a golden zone.

Water

I looked for water that was known to be good for coffee in my country. I knew that calcium, magnesium, and alkalinity were important factors for extraction, but I didn’t know the exact proportions. I could have gone deep into it, using a Brita or BWT filter, buying water packets from specialty coffee vendors, or even creating my own with distilled water and mineral additives. But I knew those changes would only give me marginal gains in taste, much less than having a good recipe. So for me, it was enough to try a few easily available and well-regarded waters, and once my recipe was set, see which one worked best.

Temperature

Most recipes recommended brewing between 80°C and 100°C, so I tried three brews changing only the temperature: 90°C, 80°C, and 100°C. Starting with 90°C worked best for me because it was likely to be close to optimal and gave me a good reference point. The general wisdom is that darker roasts are better at lower temperatures and lighter roasts at higher ones. Lately, I’ve found that the claim about lighter roasts always being better at higher temperatures has been questioned, especially with experimental fermentation coffees. In any case, taste was king.

Brew Time

Most recipes started from at least one minute. Since I had a 5-minute time limit to make and serve the coffee, I decided not to brew for more than 4 minutes. I had to keep in mind that I also needed time to prepare the AeroPress, pour the water, and cool down the coffee. Technically, the longer I brewed, the sweeter the coffee became, but I could also speed up extraction with stirring. Stirring, however, was less likely to be consistent brew to brew, so I tried to be careful, especially since I had to go round after round with the same recipe, and consistency mattered.

Grind Size

I started with the grind size recommended for the AeroPress for my grinder, and then went finer until I noticed astringency (it dried out my mouth). From there I went one step coarser, which gave me the perfect grind setting. The competition offered a few different grinders, but since I didn’t know the perfect settings for my recipe on those, I chose not to risk it, even if they were more sophisticated. I’d heard that grinding twice, first very coarse and then to the final size, could reduce ultrafines and create a more even grind. The current AeroPress World Champion had certainly done so, but I didn’t believe she had won solely because of that.

Proportions of Coffee and Water

This part was tricky. The AeroPress can hold at most about 300ml, and that was pushing it. If I brewed normally, some of the water would bypass the coffee without extracting much, which reduced the strength compared to using the inverted method. This wasn’t necessarily a bad thing, just something to account for when trying recipes. Since I could only use 18g or less, and the AeroPress could only hold about 300ml, I had two upper limits, which coincidentally made for a golden zone ratio of 1:16. I could manipulate that by adding more water after brewing, but it was a good reference point. I saw people go as low as 1:20 and as strong as 1:10. So that would be 10 grams or 20 grams of ground beans for 200ml of water, respectively. I noticed that bland coffees sometimes benefitted from stronger ratios, while flowery or experimentally processed coffees worked better with milder concentrations. For me, it was very bean specific, so I adjusted according to taste.

Filters

According to the official rules I could use any kind of filter as long as I used the normal filter cap from the AeroPress itself. I tried official paper filters, the official metal AeroPress filter, and even two paper filters at the same time. I also saw competitors using Aesir filters, a premium type said to provide more clarity.

Other Considerations

It was important to keep in mind that the judges would taste the coffee shortly after brewing it. If it was still too hot, it wouldn’t be judged favorably. With an external thermometer I found that the optimal serving temperature for me was 65°C. I managed to reach this quickly by switching the coffee from mug to mug, letting the heat dissipate into the cold mugs. The optimal drinking temperature has been said to be 60°C, so I kept mine a little higher because I didn’t know how long the judges would take before tasting. The judges sipped from spoons, much like a cupping session, so the whole brew wasn’t judged — just those sips. I tried to optimize for that.

While calibrating my recipe, I reminded myself to change only one variable at a time. For comparative tastings I sometimes used more than one AeroPress to keep the brewed coffee temperatures similar.

On the day of the competition, I saw people spread out their beans to filter out defective ones, which can improve flavor. I also saw Kruve sifters being used to filter out ultrafines after grinding, since they tend to overextract and taste bitter. If I had owned one I might have tried it, but otherwise I didn’t even entertain the thought.

Final Thoughts

I wrote all this down to put a method to my process of optimizing a recipe for a specific bean as a learning experience. But the most important part of participating in an AeroPress competition, at least for me, was having fun, getting to know other people who share the same passion, making new friends, and growing as a person. At the end of the day, I could think I had the best recipe ever, but if it wasn’t according to the judges’ tastes there was nothing I could do. So I learned to relax and enjoy it. I saw people who had been in the industry for years with very expensive tools, but they were just as likely to win or lose as newcomers if the judges preferred someone else’s cup. Everyone there shared the same passion for the beverage, and for me that was the best part — taking the opportunity to make friends in the industry.

I hope this text gives you a little bit of direction in your own search for the perfect AeroPress recipe!

Building My First MERN Stack App Under a Deadline

Tue, 09 Sep 2025 00:00:00 GMT

I recently had to build a small full stack app under time pressure.

It was one of those projects where the assignment sounds simple enough at first, then starts branching out the moment you actually touch it. Backend, database, external API, frontend, deployment, git history, the whole thing. None of it was individually too wild, but putting all of it together in a short time window was enough to make the project interesting.

Now that I have had a bit of distance from it, I wanted to go back over what I built, why I made certain choices, and where I would make different decisions if I had more time.

Requirements

The assignment was pretty clear:

It needed a backend, a database, an external API, a frontend, and a visible commit history.
The backend needed a server with two endpoints: a GET that returned all stored items and a POST that added a new one.
The database had to be NoSQL.
The data model needed at least three fields.
The frontend needed a list of database items, an input to add new ones, and a separate component showing data from the external API.
The design could stay simple.
The whole project had to live in git with clear progressive commits.

That is a fair amount of ground to cover for a small project, which is also why I liked it.

Stack choice

I ended up using the MERN stack: MongoDB, Express, React, and Node.

React, Express, and Node were already familiar to me. MongoDB was not. In fact, I had not worked with a NoSQL database before this project, so part of the appeal was simply that it gave me a reason to stop postponing it.

The main alternative I considered was Firebase Firestore. In the end I went with MongoDB because it seemed easier to reason about for this assignment, and because I wanted to try the full MERN combination properly at least once.

Backend

I started with the backend.

That felt like the right place to begin because once the data model and endpoints exist, the rest of the app has something real to connect to.

I set up a basic Express server and added a healthcheck first, mostly because I like having an early sign that the app is alive before I start piling more things on top of it.

For the database, I used MongoDB Atlas together with Mongoose.

Atlas made the setup much easier than I expected. I could connect through a URI, keep the credentials in an .env, and not have to think too much about running the database locally as part of the same project. Mongoose helped for the same reason: validation lived in one place instead of getting scattered across the route handlers.

That mattered because the project had a time limit, and one of the easiest ways to lose time is to make the same decision five times in five different files.

Once the connection was working, I added the required GET and POST endpoints. If this had been a project without a deadline, I probably would have built the full CRUD set just because it would have made the app feel more complete. But in this case I tried to stay disciplined and do what the assignment actually asked for.

After that, I paused to document the server and the basic setup in the README. I am glad I did, because once the frontend starts moving, it gets easier to tell yourself you will document it later and then never really do it properly.

Frontend

For the frontend, React was the obvious choice.

The assignment already allowed React or something close to it, and since I already knew React, this was not the moment to get adventurous for the sake of it.

I used Vite instead of Create React App. Mostly because it is faster, cleaner, and easier to get moving with. At this point CRA just feels like extra friction unless there is a specific reason to use it.

The main app was straightforward. I used useState to keep local values in memory and useEffect to fetch data when the app loads or after creating a new item. Nothing especially clever there. Just the normal shape of a small React app that needs to stay in sync with a backend.

Then I added a NewItemForm component for the POST flow.

This part of the project was probably the most comfortable because it was the part where I had the clearest idea of what I was doing and what “done” looked like.

External API

This was where I lost the most time.

I wanted the API part to feel relevant, so instead of picking the easiest possible example, I tried to use air quality data. The idea was that a user could enter a location and look up nearby air quality sensors.

That was more ambitious than I had room for.

What slowed me down was not even the coding itself. It was that I tried to get away with not reading the API docs properly at first, which is one of those decisions that always feels like it will save time and then almost never does.

I ran into deprecated routes, missing fields, and the general mess that comes from integrating with someone else’s system when you do not fully understand its current state. In the end I got it working, but not in the way I originally wanted. I hardcoded the coordinates of a specific air station and displayed the sensors available there instead of building a proper location search with richer measurements.

So yes, it met the assignment requirement. But this was also the part that made it obvious where the rushed edges of the project were.

On the backend I created an airquality.js route to proxy requests to the OpenAQ v3 API, and on the frontend I built an AirQualityWidget component that fetched from my own backend instead of hitting the external API directly.

That part of the structure I still feel good about, even if the final feature was more limited than I wanted.

Deployment

Once everything worked locally, I wanted the app online.

Partly because it was one of the project requirements, and partly because I think a full stack app does not really feel done until you have dealt with the annoying deployment part too.

I already had experience using Vercel, so I deployed the frontend there. For the backend, I looked at Render, Railway, and Fly.io. Render won mostly because it looked like the fastest path to getting the server online without fighting the platform too much.

That turned out to be the right call. Both Vercel and Render were easy to set up, including environment variables.

The one small problem I hit was CORS. Locally the app worked fine, but once the frontend was on Vercel and the backend was on Render, the requests were blocked until I explicitly allowed both localhost:5173 and the deployed frontend domain.

Not a dramatic problem, but exactly the kind of thing that reminds you that “works on my machine” is still one of the oldest traps in software.

Testing

At the end, I added a small backend test suite with Jest and Supertest.

The tests covered the healthcheck plus the GET and POST endpoints. It was not a huge test setup, but it was enough to show the basic shape of automated checks for the server and to make the project feel a bit less improvised.

What I would do differently

The main thing I would change next time is simple: I would read the API documentation properly from the start.

That sounds obvious, but this project was a very good reminder that trying to “figure it out as I go” is only efficient when the thing is actually simple. External APIs are often not simple. They just look simple right until they waste half your afternoon.

I would also spend more time on frontend reuse and loading states.

The app worked, but there were definitely places where the UI could have felt more considered. Better loading and error states would have helped. So would a little more time thinking about component reuse instead of just getting each piece over the line.

And visually, I would do more too. The assignment did not require much design work, so I kept it simple, but there is a point where “simple” becomes “I clearly ran out of time here.”

Closing thoughts

What I take from this project is not that I built some amazing app. I did not.

What I take from it is that I got through the whole shape of a full stack project under pressure: server, database, API integration, frontend, deployment, tests, documentation, all of it. And that mattered to me.

It also showed me pretty clearly where I still lose time. Usually not on the basics, but on the parts where I get a little too optimistic, skip a step, and then pay for it later.

That is useful to know.

So no, the app was not perfect. But it did what it needed to do, and it gave me a much clearer sense of what I would tighten up next time.

You can check out the app here.

My First PC Build for €1,000 (Ryzen 7 7700, RTX 5060 Ti)

Mon, 01 Sep 2025 00:00:00 GMT

So recently the stars aligned and I was finally able to build my own PC. This is a project I have been dreaming of for well over a decade, so to say I was incredibly happy to be doing so is quite the understatement.

I’ve been tinkering with computers since I was about ten years old, and during the following decades I’ve been mostly doing gradual improvements on the equipment I had: hogging Hard Disk Drives from broken computers to expand the storage in the one I was using, expanding RAM sticks on laptops to improve performance, etc. I’ve even swapped out the old 2.5 HDD on a Playstation 4 and substituted it for an SSD to improve performance (while reapplying thermal paste to the processor while I was at it).

I actually had to fix the power unit from that PS4 too to get it to be able to run again, but that’s another story. Suffice to say, I’ve always been a tinkerer, but I’ve never had the privilege of building a PC from scratch. So even before starting to think about what parts to buy I had a few clear goals:

First: I wanted the budget to be around €1000. This at some points became like a pipe dream after acquiring knowledge about the current GPU market, but I was able to make the most of it as you will see later on.

Second: I wanted the build to be able to do as much as possible, meaning I was willing to take a few hits in the gaming price/performance, for example, if that meant that I would be able to use more professional applications.

Third: I wanted the build to have as much longevity as possible. This meant building on a stable platform where I could keep the PC current with as few improvements as possible. To keep this goal in check I used a cost per month metric.

CPU & Motherboard

With these things in mind the first big decision is the CPU: AMD or Intel. This will also determine the Motherboard. Looking up the current state of the market it seemed like an easy choice. Intel appears to have had a lot of issues in their latest models and AMD is killing it both in price/performance and in the high end gaming range, with their X3D models. Next up, the platform: AM4 or AM5. AM4 is as of now a little bit more affordable, but barely, and it would severely compromise longevity. Since I want this build to last as long as possible, it was worth it to invest a little bit more in a more modern platform to gain in longevity. AM5 also uses DDR5 RAM, which is faster than the previous DDR4 generation. At the time, AMD had committed to supporting AM5 through 2027 and beyond.

As for specific models, the first CPU I found was the Ryzen 5 7600 for €175. Very decent performance, last gen but the increases for current gen don’t really justify the higher price and the CPU is more than enough for almost all everyday tasks. Maybe after a few years the 6 cores would’ve been a little bit lackluster, but the beauty of having the AM5 platform is that I can always swap it out later on. In any case, I then found the 7500F for €141 which at the time I thought was a bargain. I could save about €35 that I could spend somewhere with barely any loss (the differences between the 7500F and the 7600 are very small.) But then I found a deal on AliExpress that I couldn’t pass up: the 7700 with 8 cores, 16 threads, for €154. In any other place this CPU rarely gets below €290, not because it’s exceptional value, but because AMD doesn’t want to eat into their own sales for CPUs with fewer cores. Still, great pricing for a CPU with 2 extra cores, which will give it a lot more longevity a few years on. Worth the €14 price increase from the 7500F, and a no-brainer next to the 7600. Very happy with this buy.

Motherboard

Next up, the Motherboard. Once the CPU was settled it was a matter of determining what motherboard was good enough. Online consensus is, unless specific needs, a B650 system is more than enough. Found the Gigabyte B650 Eagle AX for €140. Good price/performance. No luxuries, does the job. Maybe looking a bit harder I could’ve caught a better board for the price, but all in all a perfectly good buy.

RAM

As for the RAM, the AMD sweet spot seems to be 6000Mhz, 2x16Gb, 30CL, so I just bought what RAM was cheapest with these conditions. Saw a deal for €90 from TeamGroup T-Create, a reputable brand so insta-win. No margin for improvement here, at least not without sacrificing performance.

Storage

Next up was storage. I’m not a digital hoarder, and have a few external SSDs lying around, so I thought 1Tb would be sufficient for me. I’m actually surprised how fast storage can fill up when you install big applications and while 1Tb is still enough for my needs, between that and dual booting Ubuntu, I have to say I was overconfident in how much space I would be having left over. Anyways, current PC lore says NVMe is a must, but getting the right one for your needs is trickier than one could think at first glance. TLC, DRAM, IOPS and stuff. Testing and reviews talk about having a fast read rate is enough for most users, but having a snappy PC is something I value dearly, so I went for the Crucial T500 1TB, PCIe4. For €82.90 it was a fair deal. Not amazing value but a fair price for an excellent SSD.

GPU

Now, as for the GPU. My first hunch was that a €300 would be enough for a GPU. Man was I in for a ride. There seems to be an intense debate going on online on if 8 GBs of VRAM are enough for gaming. It appears that, for now, and at 1080p, it is. But some newer games are already maxing this out, and performance tanks when they do. 12GB seems to be a safer bet, and 16GB seems to be the better choice.

My first search pointed at the AMD Radeon RX 7600. It definitely complied with the VRAM requirements, but online reviews rated its rasterization performance as poor value for the current state of the art. While great pricing at approximately €250, it would severely compromise the longevity of the build.
Next alternative: the Intel Arc B580. This seems to be best value at its price point, and with sufficient VRAM for now (12GB), but apparently it had some overhead problems with some CPUs. At the time I still was looking at the Ryzen 5 7600 CPU, so I discarded this option because of the potential headaches.
Then I looked at the 9060 XT, and in terms of price/performance it was a clear winner, but at around €400, it was a lot more money than I had anticipated it would cost, so at first I was hesitant.

After thoroughly investigating the state of the market, it was clear that spending anything less than that would severely compromise my build in some way be it because of VRAM, CPU bottlenecking, or lacking raster performance. It was a tough pill to swallow, but I accepted that I had to reallocate some of my budget to make it work. The 9060 XT for just gaming is a slam dunk, but I also wanted it to be used for professional applications. Apparently AMD GPUs aren’t as good for that, because they don’t have CUDA and some other stuff, but Nvidia GPUs come at a premium and while I wanted the versatility, I wasn’t willing to splurge for it. I found the 9060 XT at €389 and since its Nvidia equivalent, the 5060 Ti, was out of the price range, I was willing to compromise in that. However, at the last moment I was able to find the 5060 Ti 16GB for €434.22, at a €45 price increase. Not a blockbuster deal, but enough to justify the upgrade. An investment in my professional future, I told myself. Heh.

Case

Next up, the case. This was actually fairly simple, because at the time I didn’t really prioritize style and personal expression as much as ease of building and airflow. I ended up buying the Lian Li Lancool 216, because it is very easy to disassemble, and has great airflow. For the price, it also comes with 2 160mm front fans and one rear 140mm exhaust fan, which would otherwise have been a separate part of the budget. An alternative was the 207, which is also reported to have excellent airflow, and is a bit smaller, but the quirk of having the PSU front mounted and the smaller case made me veer off of it in case the building got too tricky. Now that I’ve built it though, it would maybe have been better to not have a huge case sitting next to my screens, but oh well. It’s not like it’s a sore sight. At €85.90, a good price/value pick.

PSU

Finally, the PSU. PSU picking can get very technical very fast, so there are tier lists out there that make picking one easy for you. I initially went with the Corsair RM850e, but had to return it due to insane coil whine, a high pitched electrical noise. I actually went to this one over the MSI MAG A750GL precisely because the latter was reported to be noisier. Definitely not in this case. So the MSI MAG A750GL was my second pick. After thinking about longevity, if in the future I wanted to put a beefier GPU in, 750W might not have been enough, so I wanted to swap it out for the 850W version. I bought the MSI MAG A750GL third party through Amazon, and since returning it was a hassle, Amazon customer support just refunded me the money. It’s not the PSU I wanted, but it seemed unwise to spend again on a PSU because of the possibility that it might be needed in the future. Technically you can use up to an NVIDIA RTX 5080 GPU on 750W, especially if you undervolt the CPU and GPU (make them more efficient, essentially), but the little headroom doesn’t seem optimal to me. In any case, I could go on and on about the decisions for this build, but I don’t want this post to get too long.

Longevity

Before I summarize the parts and total of the build, I wanted to make a point about the longevity: With this build, it is very possible to make this PC last for about 10 years. The only two parts that will really need updating are the GPU and CPU. GPU demands rise fast, and in 3-5 years, especially considering that my goal is to be able to handle 4K, a new GPU will be necessary. Ideally I’d like to spring for an 80 tier Nvidia GPU, if available and pricing not exorbitant. As I’ve said, this may require a new PSU but we’ll evaluate when we get there, because we can’t know wattage demands of future GPUs. On the other hand, when the last batch of AM5 processors come out, I will buy the top CPU available. Not necessarily because it will improve performance significantly over its predecessors (we can’t know yet), but because it will be the last true bottleneck and upping it will significantly increase the longevity of the build. Trying to get an AM6 CPU would require a new motherboard and most likely DDR6 RAM, and at that point you’re just building a new PC.

Final Build Summary

CPU: AMD Ryzen 7 7700 – €154.23
CPU Cooler: Thermalright Peerless Assassin 120 SE ARGB – €37.90
Motherboard: Gigabyte B650 EAGLE AX ATX AM5 – €139.95
Memory: TEAMGROUP T-Create Expert 32 GB DDR5-6000 CL30 – €89.99
Storage: Crucial T500 1TB PCIe 4.0 NVMe SSD – €82.90
GPU: ZOTAC NVIDIA GeForce RTX 5060 Ti 16GB – €434.22
Case: Lian Li LANCOOL 216 RGB ATX Mid Tower – €85.90
Power Supply: MSI MAG A750GL PCIE5 II 750 W 80+ Gold Modular – €0.00

Total: €1,025.09

Closing Thoughts

I went a little over budget, but thanks to the free PSU, I don’t think I would’ve been able to beat this setup for the price, unless going second hand with some parts.

Building this PC wasn’t just about performance or saving money, it was about finally getting to design and assemble something of my own after years of tinkering with scraps and upgrades. For me, it represents independence, curiosity, and a little bit of stubbornness in making the most of my budget, as well as truly a dream come true.

I’m sure I’ll keep tweaking, undervolting, and maybe swapping parts down the line (that’s just who I am), but right now I finally have a machine that feels like mine, thought out from top to bottom.

If you’re reading this because you’re planning your own build, I hope walking through my decisions gives you some ideas, or at least shows that the process doesn’t have to be perfect to be satisfying. And if nothing else, it’s proof that after more than a decade of waiting, you can finally make that dream build happen.

Alberto van Oldenbarneveld

From Product Code to GTM Engineering

Knocking on doors

What sales taught me about being a dev

What the company needs over what I enjoy

Learning who the customer is

Studying the pipeline

Same habit, different codebase

My Claude Code and Codex Workflow on an Existing Codebase

Writing down the things I kept repeating

Understanding the ticket before touching anything

Picking an approach while it’s still cheap to change

Cleaning up as we go

Tests that would have caught the problem

Explaining the result

Why we still review every PR by hand

The part I still have to do

Six Months as a Junior Developer in a Real Codebase

Clean code and real codebases

Seeing the problem is not solving it

Most of the work is understanding

My taste in code has changed

The job is more social than I expected

AI changes the learning curve

Code is in service of the product

Where I am after six months

My Five-Step Process for Learning as a New Developer

Step 1: Acquiring Information

Step 2: Owning the Information

Step 3: Putting It Into Practice

Step 4: Applying the Knowledge in Real Projects

Step 5: The Final Optional Step, A Complete Showcase Project

Conclusions

What I Learned in My First Weeks as a Junior Developer

Do not try to impress with flashy code

Understand your team first

Build rapport early

Study the culture

Get familiar with your tools

Learn the pipeline and documentation

Respect the existing code

Ask before changing anything

Conclusions

How to Prepare for an AeroPress Championship

What is an AeroPress Championship?

The Rules

My Strategy

Water

Temperature

Brew Time

Grind Size

Proportions of Coffee and Water

Filters

Other Considerations

Final Thoughts

Building My First MERN Stack App Under a Deadline

Requirements

Stack choice

Backend

Frontend

External API

Deployment

Testing

What I would do differently

Closing thoughts

My First PC Build for €1,000 (Ryzen 7 7700, RTX 5060 Ti)

CPU & Motherboard

Motherboard

RAM

Storage

GPU

Case

PSU

Longevity

Final Build Summary

Closing Thoughts