DEV Community: Johan Maes

With a little help from my peers

Johan Maes — Thu, 10 Apr 2025 12:02:57 +0000

Lend me your eyes and read this article about the importance of code reviews.

In a recent job interview, I mentioned that I tend to be a bit of a nitpicker when reviewing pull requests, albeit in an ever-gentle manner. As a follow-up, I was asked why I thought code reviews were so important. Unfortunately, I only managed to blurt out a few phrases like code quality and knowledge sharing – job interviews bring out the best deer-in-the-headlights version of me. In this article, I'll try to elaborate on my out-of-tune answer.

The most obvious reason to do code reviews is to catch errors, enforce codebase standards and suggest improvements related to efficiency, readability, or maintainability. To put it slightly more dramatically: unless it's part of a deliberate strategy to deliver quickly and refactor later, it's your last chance to stop technical debt from piling up. For some developers, that's all a code review is – a gatekeeper for quality. But guess what? There's a lot more to it. Otherwise, this article would be ridiculously short.

Are you sad because you're on your own?

Have you ever been on a team where everything grinds to a halt because the one VID¹ who knows how to fix the broken service is out? Yes, I'm certain that it happens all the time. Code reviews are a simple way to break down developer silos – though it might take a bit of patient persuasion to get that VID to open pull requests and tag reviewers.

Whether it's about getting to know a project, dipping your toes into a new technology, or understanding an unfamiliar algorithm, I see every PR I review as a learning opportunity – and so should you. This, along with having backup developers, falls under the umbrella of knowledge sharing.

Could it be anybody?

Code reviews can be a powerful democracy-enabler within teams. There's often an imbalance between team members, whether due to seniority or codebase knowledge. This can lead to both conscious and unconscious beliefs that one opinion matters more than another². While code reviews don't erase these hierarchical differences, they do help soften them.

Reviewing also promotes shared ownership: the quality of the work is the responsibility of both the author and the reviewer(s). This fosters better team collaboration, reduces finger-pointing and increases pride in the work. Dare I say it? Two (or more) brains working together are generally better than one.

What do you see when you turn out the light?

Where pair programming is clearly the extrovert's playing field, the pull request is a natural habitat for introverts (like me). While I see the value in occasionally working together on the same task, I think I'd find it rather stressful as a structural approach³. One could also argue that pair programming isn't a substitute for code reviews, since the setups are different: when you're pair programming, you might be biased towards your partner's view, while you normally approach a code review with a fresh perspective.

In that light, I should also briefly mention tests. On the one hand, they are absolutely necessary and offer a certain degree of trust; on the other, they're still code that could contain bugs or fail to cover all use cases. To ensure a healthy codebase, you need both a comprehensive test suite and proper code reviews. Two things are true.

Would you believe in approval at first sight?

Of course, you can't achieve any of the above if you don't take code reviews seriously. That means putting in the time and effort to run the code and understand the changes – always approving without comments quickly becomes suspicious. Everyone approaches them a little differently, but it's a good idea to define a baseline within your team – both for reviewing and creating pull requests. A few pointers on the latter: keep the PR size limited, make small and meaningful commits, and provide context when needed.

As a curious end note, I've always wondered why the practice of reviewing is so ingrained in the world of software yet often absent in other fields. Wouldn't everyone benefit from a second pair of eyes checking their work? Either way, the next time they ask me this question in a job interview, my answer should be ever so slightly more robust.

Gonna try,

Johan

Very Important Developer. ↩
Unfortunately, I've worked in teams where only the lead or senior developers could review (or even merge) pull requests. ↩
To be clear, I've never done extreme programming, so the jury's still out on that one. ↩

Mama, ooh, I am not AI

Johan Maes — Sat, 22 Mar 2025 12:23:54 +0000

Why equating AI to a junior developer is misleading at best.

After listening to the latest Reqless episode with Kurt Schrader – insightful as ever – there’s one thing I need to get off my chest. I get why people compare AI to junior developers, but it doesn’t sit right with me. AI might be great at churning out code, but juniors bring something AI simply can’t: growth, reasoning, and the ability to develop real understanding over time. The comparison isn’t just misleading – it undervalues what junior developers actually bring to the table.

So you think you can stone me and spit in my eye?

From the moment I started as a developer – though I wasn’t exactly a straight-out-of-school junior – I noticed a certain condescension toward junior developers in our industry. Sometimes it’s framed as a joke, but the underlying sentiment is still there.

I’ve never quite understood why. Plenty of so-called senior developers occasionally write bad code or make poor decisions – myself included – while many juniors often produce great work – my former self included, I hope. A good engineering culture should foster growth, not diminish those who just starting out. Worse, this attitude skews how we mentor and hire developers.

Is this the real life? Is this just fantasy?

What even is a junior or senior developer? Usually it's tied to years of experience – whatever experience that may be. I won't dig too deep here; it's enough to say that a person is so much more than just their time in a specific field.

I'm afraid these titles have more to do with sales and marketing than any real meaning. Another buzzword that never fails to send shivers down my spine – especially in consultancy – is expert. But let's not open that can of worms.

Mama, just killed the junior developer

While I’m not denying that there’s a difference between a junior and a senior developer, equating AI to a junior dev is misleading at best. AI lacks reasoning, intuition, and context awareness – essential traits of even a beginner developer. This comparison oversimplifies things and undervalues human learning and adaptability. AI is a tool, and like any tool, its effectiveness depends on how it’s used.

Maybe I just have a knee-jerk reaction to the culture of dismissing juniors. The comparison might sound less like an insult if it simply means: work once given to a junior is now given to an AI agent. But if that’s the case, juniors can now take on other tasks – more than they used to. Bismillah! The end of the junior developer as we once knew them.

Goodbye, everybody, I’ve got to go

Which brings me to what may be a surprising conclusion: AI could actually bridge the gap between junior and senior developers. We won’t have junior and senior developers any longer; we’ll only have superior developers, more powerful than ever now that they are supported by AI.

Any way the wind blows, I’d love to hear your thoughts on this.

Easy come, easy go,

Johan

I Want to Ride My Bicycle (Stage 1)

Johan Maes — Fri, 14 Feb 2025 10:45:43 +0000

This is part 1 of a write-up of my practice project: displaying all 2025 UCI road cycling races on a map.

I'm currently reinventing myself as a developer¹ and learning a bunch of new stuff: PostGIS, Python, Django, some AI shit ², etc. Since the best way to learn is by doing - and because I don't want to lose the joy I get from coding - I set out to find a suitable open-source project on Github.

There are plenty of interesting ones out there, but getting started always feels a bit unnatural. Jumping into a project isn't easy, and it's often unclear which issues are actually up for grabs or truly wanted.

I've never had any hobby projects to show off - free time is scarce with two little ones hopping and bopping around. But since the unemployed have all of the time in the world to kill, now seems like a good time to start.

Prologue: Introduction to the project

I'm just a farmer's son from Belgium³, which means I'm a huge cycling fan. I also happen to be a maps enthusiast, so why not combine these two passions into an IT project⁴? Let's display all the UCI road cycling races on a map!

Datasette seems like the perfect fit since it handles the heavy lifting of spinning up a website and even displaying items on a map. That means I can focus on getting the data ready: fetch it, clean it up, and normalize it.

I didn't end up using all technologies and tools I'm currently learning⁵ but I did put together an interesting list:

sqitch - database migrations
PostGIS - geospatial data
SQLFluff - SQL formatting and linting
pgtap - testing
Datasette - data visualization

As you can see, these tools are all heavily focused on Postgres. I'll let the migthy, wise blue elephant be my guiding anchor on this adventure. On your marks! Get set! Go!

Stage 1. Fetch the data

Your data is only as good as its source. When it comes to cycling data, the most complete website is definitely ProCyclingStats. However, since the UCI⁶ is the official governing body of cycling, I wanted to try getting the data from the UCI website first.

For my first attempt, I had Claude generate a Python script⁷ that uses an XHR call from the calendar page to fetch all World Tour races. I decided to start with the World Tour as a sample set.

However, this API call was clearly designed specifically for their calendar page, and it left me unsatisfied for several reasons:

It only returned upcoming races.
The data structure made it a bit of a pain to extract what I needed.⁸
Key race details were missing, though there was a link to a UCI race page with more information.

So there I was, digging through the details link and other API calls, trying to piece together the information, until I noticed the DOWNLOAD SEASON button to download the entire road race calendar as an XLS file. D'oh!

I first created a new database pro_cycling, initialized sqitch with sqitch init, and created a separate schema uci_road_raw for the source data. Then I defined the raw races table as simple as possible - all text fields:

CREATE TABLE uci_road_raw.races (
    date_from text,
    date_to text,
    name text,
    venue text,
    country text,
    category text,
    calendar text,
    class text,
    email text,
    website text
);

And after converting the XLS file to CSV, psql did the rest:

\copy uci_road_raw.races FROM '/home/johan-maes/source/uci-road-races-map/data/UCICompetitions_ROA_2025.csv' WITH (FORMAT csv, HEADER true);

Talk about a sprint to the finish line! A quick inspection of the data showed 711 road races in the 2025 season - covering all classes (World Tour, Pro, etc.) and categories (Men, Women, etc.). Interestingly, it also includes 16 races from the end of 2024.

That's it for part 1 of this trilogy in five parts⁹. Part 2 (aka Stage 2) will focus on creating the lookup tables to normalize the data.

Thanks for reading - and apologies for the footnotes overload¹⁰.

This is marketer speak for I quit my IT consulting job and now have some time to explore what I would like to do next. ↩
There's no escaping it. ↩
I'm not actually a farmer's son. The phrase is a reference to Yves Lampaert's legendary post-race interview after he won the prologue in the 2022 Tour de France. ↩
Because every problem can be solved with IT, even the ones that don't exist yet. ↩
I'm a data person at heart. If I can do something in the database (and it's not completely stupid), I will. ↩
Union Cycliste Internationale - it was founded in France. ↩
See how fast I'm learning Python? ↩
Even though the new PostgreSQL 17 JSON_TABLE feature proved to be very effective. ↩
Not my joke: https://www.goodreads.com/book/show/372299.The_Hitch_Hiker_s_Guide_to_the_Galaxy. ↩
Who reads footnotes anyway? ↩

Hey Hey, AI (Into the Black?)

Johan Maes — Thu, 30 Jan 2025 14:17:20 +0000

Is there more to the picture than meets the eye? How AI has affected my life as a backend developer.

As developers, we've always used — and often enjoyed — productivity-boosting tools. I still remember the excitement back in my .NET days when we finally convinced our boss to buy us a ReSharper license. Bless its squiggly line suggestions, refactoring features, and enhanced code completion! Then along came AI, offering code completion on steroids and a seemingly infinite knowledge base. No other tool has impacted my work as a developer quite like this one.

I joined the party a little late. In early 2023, I was mentoring an intern who used ChatGPT for almost everything — right down to drafting emails to me in an excessively formal tone and crashing the application he was working on with AI-generated code he didn’t fully understand. Behold the dangers of AI! But he also introduced our team to this new tool. It wasn’t nearly as good as it is now, but it could already do some pretty impressive things. Clearly, it was time for us to start experimenting with it in our daily work.

Since then, I've been using AI for solving well-defined, small tasks — whether it's adding a new function, tweaking a few lines, or debugging an issue. Most importantly, it’s become my go-to for asking all those “stupid” questions I might hesitate to ask a colleague. It’s like having a senior developer at my constant disposal — without the intimidation or embarrassment that can come with talking to a real person.

Do we need to learn new skills to get good results? Yes and no. You need to know when to stop iterating on a problem and turn to good old Stack Overflow or a classic search — or when not to start at all. Giving clear instructions is also a skill that takes practice. The good news? There’s always room for correction (unless you’re out of quota). What hasn’t changed is the need for a critical eye when using AI-generated code — thoroughly reviewing and understanding it. Fortunately, I enjoy this part of being a developer. Skepticism comes naturally to me, and I had already honed this skill long before AI entered the picture.

Once you learn to navigate it, AI makes it much easier to dive into a new project or pick up a new language. It doesn’t just boost my productivity — it also improves the overall quality of my work, something that’s often overlooked. After all, you’re tapping into the collective knowledge of thousands of developers — how could that not lead to better code?

Am I worried that AI could take my job or change it beyond recognition? Of course — and we all should be. As developers, we like to think we’re special, but why would we be any different from other professions where AI has been introduced to support or even replace humans? Optimization is happening everywhere.

I like to think AI will reduce the need for so-called "experts". As Paul Ford puts it in the excellent Reqless podcast:

... so there is a pleasure in replacing consultants that maybe there isn't in replacing other kinds of roles.

Who hasn’t had an external consultant parachute into a project, do little more than write a report repeating what you've been saying for the past five years — while getting paid five times more?

However, with the rise of AI, a new breed of consultants is emerging: the AI/low-code consultant. As we speak, low-code solutions are being force-fed to developer teams far and wide. I’m not saying these tools have no value — the real issue is using them in the right context and for the right reasons. Not just to cut developer headcount or because a big tech firm wooed you with a free team-building day and catered lunch.

Of course, many developers are hesitant to embrace AI-driven platforms for building applications. Developers have feelings too: we don’t want to become drag-and-drop monkeys, we want to touch and feel the code. In my view, bridging the gap between developers and business expectations remains one of the biggest challenges in our industry. Nothing new there.

To complete my Neil Young analogy: while AI has (sort of) come out of the blue, it remains to be seen — hence the question mark in the title — whether it will go into the black or into the red. Meanwhile, developer rock and roll can never die, but it will definitely change (and already has). Let’s just hope we don’t skip the classic rock era and dive straight into the abyss of reggaeton and the like.