DEV Community: Lou Creemers

European Law for .NET Developers: What the GDPR Means for Your Code

Lou Creemers — Sat, 10 Oct 2026 14:28:19 +0000

Hey lovely readers,

The GDPR has been around since 2018, and most of us have heard of it. But when I ask developers what it actually means for the code they write, they often don't know. Usually someone mentions an annoying cookie banner and that's it.

So I'm starting a small series. I'm taking three European laws that affect developers and making them as simple as I can. This first post is about GDPR. After that, I'll cover the European Accessibility Act (EAA) and the AI Act.

Quick note before we start: I'm a developer, not a lawyer. Even though I'm really interested in this topic, I even did a thesis on it, I do not have a law degree. This post will help you understand what GDPR means for your code but if your company handles a lot of personal data, please also talk to someone who does this professionally.

What is GDPR?

GDPR (General Data Protection Regulation) is a European law that protects the personal data of people in the EU. It decides what you're allowed to collect, how you have to store it, and what people can ask you to do with their data.

Personal data is anything that can be linked to a real person. Names and email addresses are the obvious ones, but the list is longer than most people think:

A phone number or home address
A date of birth
An IP address
A user ID, if you can connect it back to someone
Location data

But not all personal data is the same. A first name or an email address is personal data, but some data is much more sensitive and risky when it leaks. GDPR calls these special categories:

Health data
Sexual orientation and sex life
Ethnic origin
Religious or philosophical beliefs
Political opinions
Union membership
Genetic data
Biometric data used to identify someone, like a fingerprint

For these categories, the starting point is different. You're not allowed to process this data at all unless one of a few exceptions applies, like the user giving explicit consent. And if you process a lot of it, you need a risk assessment called a DPIA (more on that later). Criminal records have their own, similar set of rules.

And why should you care as a developer? Because the fines are big. A company can be fined up to 20 million euros or 4% of its worldwide yearly revenue, whichever is higher. But honestly the biggest reason here is trust. Your users give you their data, and it's our job to treat it well.

Does it apply to me?

Probably yes. GDPR applies when your app handles personal data of people in the EU. It doesn't matter where your company is based. If you build a webshop in the United States and people in Germany can order from it then the GDPR applies to you. So if your app has user accounts, a contact form, a newsletter sign up, or even just logs with IP addresses in them, this post is for you.

But what if your project is really small? Maybe you have a SaaS with four users, or just a newsletter sign up on your blog. Then GDPR still applies. There is no minimum number of users, and no minimum revenue. One person from the EU in your database is enough.

But here's the good news. What GDPR asks from you grows with your size and your risk. A small project with simple data needs a small, simple setup. Let's look at two examples.

A small SaaS

Let's say you have a SaaS with four users who pay you a few euros a month. Here's what you do need:

A privacy policy. What you collect, why, how long you keep it, and who you share it with.
Agreements with the services you use. Your hosting and payment provider handle personal data for you. Most of them have a standard data processing agreement you can simply accept.
Decent security. HTTPS, hashed passwords, and backups.
A simple overview of your data. One page with what you store and why is enough. There's an exception for companies with fewer than 250 employees.
A way to handle requests. If someone asks to see or delete their data, you need to be able to do that.

And here's what you probably don't need:

A risk assessment, since your processing isn't high risk
A data protection officer
An EU representative, if your business is based in the EU
Special features in your code. If someone emails you to delete their account, doing it by hand is completely fine at this size.

A newsletter on your blog

Maybe you just have a blog with a newsletter sign up, and you store the email addresses in your own database. GDPR still applies. There is an exception for "purely personal" use, but a public newsletter isn't that.

Here's what you need:

Consent. Someone has to actively sign up. A double opt in where people confirm their email address is stored in your system is the best way to do this.
Proof of that consent. Store when and how someone signed up.
An unsubscribe link in every email.
A short privacy notice at your sign up form.
Deleting the data when someone unsubscribes.
An agreement with your email service if you use one to send your newsletter.

In code, that's a timestamp for the consent and an unsubscribe action. That's really it.

The rule of thumb

GDPR asks for results, not for features. When your project is small, a privacy policy, a simple overview of your data, and handling requests by hand is often enough. Build features for it once doing things by hand starts to hurt.

But what if you have a whole backend running with lots of users, well then there's some more work to do.

GDPR is more than code

Recently I helped a client who wanted to become GDPR compliant. When I wrote down all the work in tickets, something stood out: most of them weren't about code at all. They were about research and documentation.

So before we open our IDE, let's look at the work that comes first. You don't have to do all of this alone as a developer but you will be part of it. And honestly, you're often the person who knows best where the data actually lives.

Step 1: Find out what you have

Map all personal data you collect. Every table, every form field, every log should be on there. This becomes your data inventory.
Map how data flows. Where does it go after it enters your app? Think of your database, your email service, your analytics tool, and your payment provider.
Check what you receive from others. Partners or third parties might send you personal data too. That counts as well.

Step 2: Know why you have it

Write down the purpose for each type of data. Why do you store a phone number? "Maybe we'll need it someday" is not a purpose.
Pick a lawful basis for each purpose. GDPR has six of them, like consent, a contract with the user, or a legal obligation. Every purpose needs one.
Document legitimate interest when you use it. It's the most flexible basis, so you have to explain why your reason is fair, and why it doesn't hurt the rights of your users too much.

Step 3: Check the risk

Find your high-risk processing. Think of large amounts of sensitive data, tracking people, or making automatic decisions about them.
Decide if you need a DPIA. A Data Protection Impact Assessment is a document where you describe the risks and how you reduce them. For high-risk processing, it's required.

Step 4: Write it all down

This is the biggest part, and the least exciting one. But it matters, because GDPR asks you to be able to prove what you do.

Records of processing activities. An overview of what you process, why, and for how long.
A data retention schedule and a deletion policy. How long you keep each type of data and what happens after that.
A data breach response plan. If something leaks, you usually have to report it to the data protection authority within 72 hours. That's not the moment to start figuring out who does what. You want that decided and written down somewhere.
Procedures for user requests. What do you do when someone asks to see, change, or delete their data?
Consent documentation. If you use consent, you need to be able to show when and how someone gave it.
A vendor register and data processing agreements. Every service that handles personal data for you needs an agreement with you.
Privacy notices. One for your users, and don't forget your employees. Their data counts too.

Step 5: Check if you need a representative

If your company is not based in the EU but you do you do collect data from people that live in there, you might need to appoint an EU representative. The UK has its own version of GDPR after Brexit, so the same goes for the UK.

Where this meets your code

Here's the nice part. A lot of these documents turn straight into work for developers:

The data inventory tells you which properties to mark as personal data.
The retention schedule becomes a background job that deletes or anonymizes old data.
The user request procedures become a "download my data" and a "forget me" feature.
The breach response plan only works if you have good logging and monitoring.

So let's get to that code.

Keep personal data out of your logs

Let's start with the mistake I see the most. Something goes wrong in production, so someone adds this:

logger.LogInformation("User signed up: {@User}", user);

It works great for debugging. But now the user's name, email address, and maybe even their phone number are sitting in your logs. And logs get copied everywhere: to a log service, to a colleague's screen, to a support ticket. You lose control over that data very quickly.

.NET has a built-in way to fix this, with the Microsoft.Extensions.Compliance.Redaction package. You mark which data is personal, and .NET removes it from your logs for you.

First, install these packages:

dotnet add package Microsoft.Extensions.Compliance.Redaction
dotnet add package Microsoft.Extensions.Telemetry

Next, you create a small "taxonomy". That's just a fancy word for a list of the types of data you want to treat differently:

using Microsoft.Extensions.Compliance.Classification;

public static class DataTaxonomy
{
    public static string TaxonomyName => typeof(DataTaxonomy).FullName!;

    public static DataClassification PersonalInfo => new(TaxonomyName, nameof(PersonalInfo));
}

public class PersonalInfoAttribute : DataClassificationAttribute
{
    public PersonalInfoAttribute() : base(DataTaxonomy.PersonalInfo) { }
}

Now you can use that attribute on your model:

public class User
{
    public int Id { get; set; }

    [PersonalInfo]
    public string Name { get; set; } = string.Empty;

    [PersonalInfo]
    public string Email { get; set; } = string.Empty;
}

Then you turn on redaction in your Program.cs:

builder.Logging.EnableRedaction();

builder.Services.AddRedaction(redaction =>
{
    redaction.SetRedactor<ErasingRedactor>(
        new DataClassificationSet(DataTaxonomy.PersonalInfo));
});

The last step is logging with the logging source generator, so .NET knows which properties to look at:

public static partial class Log
{
    [LoggerMessage(Level = LogLevel.Information, Message = "User signed up")]
    public static partial void UserSignedUp(ILogger logger, [LogProperties] User user);
}

And you call it like this:

Log.UserSignedUp(logger, user);

Now the user's ID still shows up in your logs, so you can still debug. But the name and email are erased before they ever reach a log file. You get the information you need, without the personal data you don't.

Quick side note: ErasingRedactor removes the value completely. If you'd rather still be able to see that two log lines belong to the same person, you can use the HmacRedactor instead, which turns the value into a hash.

Protect sensitive data with the Data Protection API

Some data you do need to store, like a phone number. But that doesn't mean it should sit in your database as plain text. If someone ever gets access to your database, plain text is the worst possible situation.

How strong should the protection be?

Remember the special categories from the start of this post, like health data? You might expect GDPR to say exactly how you should encrypt that kind of data. It doesn't. GDPR asks for "appropriate" security, based on the risk. Encryption is mentioned as an example, but there's no required algorithm or key size.

In practice, it comes down to this: the more sensitive the data, the stronger the protection should be. For something like health data or sexual orientation, encryption is really the minimum. If that data leaks and it wasn't encrypted, then that's very hard to defend.

And there's a nice bonus. If data leaks but it was properly encrypted, you often don't have to inform every affected user because the data is useless to whoever has it.

Good to know: some sectors have extra rules on top of GDPR. In the Netherlands, for example, healthcare organizations have to follow a security standard called NEN 7510. So if you build apps for a specific sector, check if something like that applies to you too.

Encrypting data in .NET

ASP.NET Core comes with the Data Protection API, which can encrypt and decrypt values for you. Here's a small class that protects a phone number:

using Microsoft.AspNetCore.DataProtection;

public class PhoneNumberProtector(IDataProtectionProvider provider)
{
    private readonly IDataProtector _protector =
        provider.CreateProtector("Users.PhoneNumber");

    public string Protect(string phoneNumber) => _protector.Protect(phoneNumber);

    public string Unprotect(string protectedPhoneNumber) =>
        _protector.Unprotect(protectedPhoneNumber);
}

The string you pass to CreateProtector is called a purpose. Values protected with one purpose can't be unprotected with another, so your phone numbers and, say, your password reset tokens stay separated.

One important thing to know: the Data Protection API uses keys, and those keys need to be stored somewhere safe and permanent. If you lose them, you can't decrypt your data anymore. So make sure you configure where the keys live, for example:

builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo("/keys"))
    .SetApplicationName("MyApp");

Keep in mind that Microsoft built this API mainly for data that doesn't live forever, like cookies and tokens. For sensitive data that you store for years, it's worth looking at options like Always Encrypted in SQL Server or keys in Azure Key Vault. But for getting started and understanding the idea, the Data Protection API is a great first step.

The right to be forgotten with EF Core

Under GDPR users can ask you to delete their personal data. This is called the right to be forgotten.

Sounds easy, right? Just delete the user. But here's where it gets interesting. Say this user has placed orders in your webshop. You often have to keep those orders for your bookkeeping. In the Netherlands, for example, that's seven years.

GDPR allows that. When the law says you have to keep something, then you can keep it. But you should remove everything that points to the person. That's where anonymizing comes in:

public async Task ForgetUserAsync(int userId)
{
    var user = await db.Users.SingleAsync(u => u.Id == userId);

    var orders = await db.Orders
        .Where(o => o.UserId == userId)
        .ToListAsync();

    foreach (var order in orders)
    {
        order.UserId = null;
        order.CustomerName = "Removed";
        order.ShippingAddress = "Removed";
    }

    db.Users.Remove(user);
    await db.SaveChangesAsync();
}

The user is gone, and the orders stay, but nobody can tell who placed them anymore.

Here's something I see very often in different web apps. Many apps use soft delete: an IsDeleted column that you set to true. That's great for "undo" buttons but it's not deleting. The data is still in your database. So if a user asks to be forgotten, a soft delete is not enough. And don't forget the places outside your main database: backups, logs, analytics tools, and third-party services you send data to. Those count too.

What about backups?

You can't delete one person from a backup. A backup is a snapshot of your whole database, so you'd have to change every backup you have. That's not realistic, and luckily it's not what's expected either.

What I'd advise instead:

Put a retention period on your backups. Old backups expire and get deleted automatically. On Azure SQL, for example, you choose how long point-in-time backups are kept, between 1 and 35 days. If you also use long-term retention, keep it as short as your legal obligations allow.
Don't use the data in the meantime. Until a backup expires, nobody should touch the data of a deleted user.
State it clearly in your privacy policy. Something like: "Deleted data is removed from our backups within 35 days."
Keep an erasure log. This is a small table with the user IDs of everyone who asked to be forgotten, and the date. Store it outside the database you back up, otherwise a restore rolls it back too.

That last one matters when you restore a backup. Without it, deleted users might come back without anybody noticing. With it, you simply run your "forget me" logic again before the database goes live:

public async Task ReapplyErasuresAsync()
{
    var erasedUserIds = await erasureLog.GetAllUserIdsAsync();

    foreach (var userId in erasedUserIds)
    {
        await ForgetUserAsync(userId);
    }
}

Anonymization vs pseudonymization

In the example above, I anonymized the orders. That word comes up a lot when you work with GDPR, and so does a word that sounds very similar: pseudonymization. They sound alike, but GDPR treats them very differently.

Pseudonymization: you can still go back

With pseudonymization, you replace something that identifies a person, like a name or an email address with a code. The information to link that code back to the person is stored somewhere else.

For example, your analytics tool only sees user_8f3a2c. A separate table or a key tells you who that is. This is still personal data, so GDPR still fully applies. But it lowers the risk a lot. If your analytics data leaks, nobody can see who user_8f3a2c is. That's why GDPR actively encourages it. The HmacRedactor I mentioned in the logging section is a good example. You can still see that two log lines belong to the same user, without seeing who that user is.

Anonymization: there's no way back

With anonymization, you change the data so nobody can find out who it belongs to anymore. Not your colleague, not a hacker, and not even you.

For example: "32 orders were placed in Amsterdam in March." There's no link to any customer at all. Data that is truly anonymous is no longer personal data. That means GDPR doesn't apply to it anymore.

The trap developers fall into

"Anonymous" is a high bar, and it's easy to think you've reached it when you haven't. Two common examples:

Hashing an email address. That's pseudonymization, not anonymization. Anyone with a list of email addresses can hash them too and look for matches.
Only removing the name. A postal code, a birth date, and a gender together can often point to one specific person. Each piece looks harmless, but together they're not.

This also goes for the "forget me" example above. Anonymizing the orders only works if nothing else on the order, like a postal code or a phone number, still points to the person.

Here's my advice after spending a lot of time thinking about this: if you're not 100% sure your data is anonymous, treat it as pseudonymized, and keep protecting it like personal data.

Only collect what you need

The easiest personal data to protect is the data you never collected. GDPR calls this data minimization.

A very common example is an endpoint that returns the full user entity:

app.MapGet("/users/{id}", async (int id, AppDbContext db) =>
    await db.Users.FindAsync(id));

That sends everything to the frontend, including the date of birth, the address, and the phone number, even if the page only shows a name. Let's fix that with a small DTO:

public record UserSummary(int Id, string DisplayName);

app.MapGet("/users/{id}", async (int id, AppDbContext db) =>
{
    var user = await db.Users
        .Where(u => u.Id == id)
        .Select(u => new UserSummary(u.Id, u.DisplayName))
        .SingleOrDefaultAsync();

    return user is null ? Results.NotFound() : Results.Ok(user);
});

Now only the data the page actually needs leaves your API.

The same idea works for your forms. Do you really need someone's full date of birth? Or do you only need to know that they're 18 or older? A simple checkbox might be all you need.

What about outside of Europe?

Before we wrap up, one more thing. GDPR is the most famous privacy law, but it's definitely not the only one. Many countries looked at GDPR and built something similar. Here are a few you might run into:

Where	Law	Good to know
United Kingdom	UK GDPR	After Brexit, the UK kept its own copy of GDPR. It's almost the same, with a few small differences.
Switzerland	FADP	Switzerland isn't in the EU, so it has its own law. It's very close to GDPR.
Brazil	LGPD	Strongly inspired by GDPR, with similar user rights and its own data protection authority.
California, USA	CCPA	Focuses a lot on letting users opt out of their data being sold or shared.
Canada	PIPEDA	Canada's federal privacy law for companies.
South Africa	POPIA	Also close to GDPR in how it treats personal data.
India	DPDP Act	One of the newer ones, focused on consent.

If you build your app with GDPR in mind then you're already in a good place for most of these laws. The ideas are often the same. Know what data you have, collect only what you need, protect it, and let users see and delete it.

But "similar" doesn't mean "the same". The details can be different like how users can say no, or how fast you need to report a data breach. So if your app has a lot of users in one of these countries, check that specific law too.

Your GDPR checklist

A short list you can bookmark:

Map your personal data, where it goes, and why you have it.
Make sure the documentation exists, and help turn it into code.
Mark personal data in your code, and turn on redaction so it never ends up in your logs.
Encrypt sensitive data you store, especially special categories like health data, and keep your keys safe.
Build a real "forget me" flow: delete what you can, anonymize what you have to keep.
If you're not sure data is truly anonymous, treat it as pseudonymized and keep protecting it.
Remember that soft delete is not deleting.
Use DTOs, and only collect and send the data you actually need.

That's a wrap!

GDPR can feel like a big scary law, but a lot of it comes down to good habits you can build right into your code. Start small, maybe with the logging part, and go from there.

In the next post of this series, I'll talk about the European Accessibility Act. It has been in force since June 2025, and it might apply to your app more than you think.

If you have questions, or tips on how you handle GDPR in your own projects, feel free to leave a comment or reach out to me on my socials.

See ya!

Emotional Intelligence: The Developer Skill AI Can't Replace

Lou Creemers — Sun, 04 Oct 2026 14:23:31 +0000

Hi lovely readers,

A few months ago I wrote about how AI is making English a must-have skill for developers. The idea was simple: when you spend more of your day describing problems instead of typing code, the way you communicate becomes much more important.

Recently I sat in on a talk by Manuela Beltrami at a women in tech event for Rotterdam University of Applied Sciences that I help organize. Her talk was all about failure, and one slide stuck with me. It called emotional intelligence your superpower in the age of AI. That slide kept going round in my head, and it made me realize there was a second half to my English post that I had not written yet.

Writing a clear sentence is one thing. Knowing what the other person actually needs to hear, how they are feeling, and how you are feeling yourself is something else. That something else is emotional intelligence, and I think it might be one of the most underrated developer skills right now.

What is emotional intelligence?

Let me try to explain this term in the easiest way possible. Emotional intelligence is the ability to notice and understand emotions, both your own and other people's, and to use that understanding to handle situations well.

The term became popular through psychologist Daniel Goleman and his 1995 book Emotional Intelligence. He breaks it down into five components:

Self-awareness: recognizing your own emotions and how they affect your work.
Self-regulation: managing those emotions instead of reacting on impulse.
Motivation: being driven by more than external rewards.
Empathy: understanding what others feel and need.
Social skills: building relationships, communicating, and handling conflict.

The first three are about you. The last two are about the people around you. You will see all five come back in this post.

At work, it looks like this:

Noticing that you are frustrated before you send that message in Teams or Slack
Understanding that a stakeholder who keeps changing their mind might be under pressure from their own manager
Seeing that a colleague has gone quiet in meetings and asking if they are okay
Giving feedback in a way that helps someone grow instead of making them defensive

None of this involves code. But all of it affects how well software gets built.

AI does the typing, not the understanding

AI tools are getting better every day. They can generate an endpoint, write tests, and explain an error message. Tasks that used to take an hour now take a few minutes.

But if you look at why projects actually go wrong, it is rarely because someone could not write a for loop. It is because the team built the wrong thing. Because two people misunderstood each other. Because someone was afraid to say they were stuck. Because a disagreement about architecture slowly turned personal.

AI does not fix any of that. It can transcribe a meeting and maybe even guess at the mood in the room, but it misses the context that gives those signals meaning. It does not know that the client who says "that's fine" said exactly the same thing right before the last project went sideways. It does not know your colleague just had a really hard week, or that your stakeholder's manager is breathing down their neck. It can sound friendly and understanding, but sounding kind is not the same as actually understanding.

So as the technical part of our work gets faster, the human part becomes a bigger piece of what makes you valuable.

Empathy helps you find the real problem

The more clearly you describe a problem, the better the answer you get from AI. But there is a step before that. You first need to understand what the problem actually is.

That is where empathy comes in. When a user says "this page is annoying," the real problem might be that the button is hard to find, that the page is slow on their phone, or that they are simply stressed and this page is the last thing standing between them and going home. You only find out by putting yourself in their shoes and asking the right questions.

Accessibility is empathy you can ship

This is also why I care so much about accessibility. For me, it is the most practical form of emotional intelligence in our field.

Accessibility means thinking about people who are not in the room. The person using a screen reader. The person with shaky hands who struggles with tiny buttons. The person reading your UI in their second language, or on a bad day when their focus is gone.

AI can help here. It can suggest alt text, point out missing labels, or check your color contrast. But it only does that when someone asks. If you never thought about those users in the first place, no tool will do that thinking for you. The empathy has to come first, and the tooling comes after.

Managing your own emotions matters too

Emotional intelligence is not only about other people. It is also about you.

Let's be honest, working in tech right now can be stressful. There is a lot of noise about AI replacing developers, the job market is harder than it used to be, and it is easy to feel like you are always behind on the newest tool. On top of that, working with AI can be frustrating in a very specific way. You explain something three times, it confidently gives you the wrong answer again, and you feel your patience disappear. By the end of the day, these situations can really get to me.

Being aware of those feelings helps a lot. When you notice "I am frustrated right now," you can take a break instead of accepting code you do not understand just to be done with it. When you notice "I am anxious about my future," you can talk about it with someone instead of letting it quietly stress out your work and your sleep. In Goleman's terms, noticing the feeling is self-awareness, and choosing what to do with it is self-regulation.

It also helps to know what keeps you going. If your only motivation is keeping up with every new release, you will always feel behind, because there will always be another one. Maybe for you it is curiosity, or the moment a hard concept finally clicks, or building something that actually makes someone's day easier. That is what Goleman means by motivation: being driven by something deeper than the next shiny tool or a pat on the back. It is also what gets you through the weeks when the hype is exhausting.

Failure builds emotional intelligence

Here is something Manuela's talk made me realize: every time something goes wrong, you are training your emotional intelligence, whether you notice it or not.

Dealing with disappointment when a release breaks. Asking for help when you are stuck, even though it feels embarrassing. Supporting a colleague who just took down production. Reading the room in the meeting after something went wrong. All of that builds the same muscle.

When I look back at my first years as a developer, the moments that taught me the most about myself were not the successes. They were leaving a job that undervalued me, working somewhere that just did not click, and getting let go before I had even started. None of that felt good at the time. But it taught me how to handle disappointment, how to stop blaming myself for everything, and how to recognize what I need.

AI can help you avoid some mistakes. It cannot go through them for you. And the growth that comes from getting through a hard moment, and helping others get through theirs, is still something only you can do.

Emotional intelligence in PR reviews

AI means more code gets written, which also means more code needs to be reviewed. And reviewing is one of the most emotional parts of our job, even if you think that it is not. This is where Goleman's social skills come in.

When you review a pull request, try to be curious instead of harsh. "Can you walk me through why you chose this approach?" lands very differently than "Did AI write this?" Even when AI did write it, the person who opened the pull request is still a colleague, and they are still the one who will learn from your feedback.

The same goes for receiving feedback. Your code is not you. A comment on your pull request is about the code, not about your worth as a developer. That is easy to say and hard to feel, and learning to feel it is part of emotional intelligence.

Emotional intelligence is not the same as being outgoing

I want to be clear about this one, because I think a lot of people get it wrong. Emotional intelligence does not mean being the loudest person in the room, loving networking events, or being friends with everyone.

As I shared in an earlier post, I struggle with busy social events and open offices. That does not make me bad at understanding people. Quiet people are often very good at this, because they spend more time listening and observing. And knowing your own limits, like knowing when you need a quiet space to recharge, is emotional intelligence as well.

Emotional intelligence and neurodiversity

There is a stereotype I want to push back on: that neurodivergent people, for example autistic people or people with ADHD, are "bad" at emotional intelligence. That is not true, and it is not a helpful way to think about it.

A lot of what we call emotional intelligence is based on one specific way of communicating. Making eye contact, reading between the lines, picking up on tone of voice, understanding what someone means when they actually say something else. If your brain works differently, those signals might not come naturally. But that does not mean you do not care or do not feel. Many neurodivergent people feel emotions very strongly, including other people's.

There is a term for this: the double empathy problem. The idea, which comes from autism researcher Damian Milton, is that when an autistic and a non-autistic person misunderstand each other, the problem goes both ways. It is not that one person lacks empathy. It is that two different communication styles meet, and both sides find the other hard to read.

That changes what emotional intelligence looks like in a team. It is not only about reading others well. It is also about making yourself easy to understand, and accepting that people show things in different ways.

In practice, that can look like this:

Say what you mean. "Can you fix this before Friday?" is much clearer than "It would be nice if someone looked at this soon."
Do not read tone into short messages. A one-word "ok" in Slack is usually just an "ok."
Ask how people like to work instead of assuming. Some people prefer a quick call. Others want things in writing so they can process them in their own time.
Make room for different energy levels. Cameras off, quiet spaces, and meetings with a clear agenda help more people than you might think.

Interestingly, AI can help here too. Some neurodivergent developers use AI tools to check how a message might come across, or to ask "what could this person have meant?" That is a nice example of AI supporting human connection instead of replacing it. Still, it is a tool, not the solution. The real work is people meeting each other halfway.

Emotional intelligence was never about everyone communicating the same way. It is about understanding that we do not, and making it work anyway.

Teaching and mentoring are changing

As someone who teaches and mentors, I notice that what learners need from me is changing. They can ask an AI to explain a concept at 2 AM, as many times as they want. What they cannot get from it is someone who notices they are overwhelmed, who tells them that being confused is a normal part of learning, or who helps them believe they can actually do this.

Knowledge is easier to get than ever. Encouragement, trust, and feeling seen are not. Those still come from people.

How to get better at it

The good news is that emotional intelligence is not something you either have or do not have. You can practice it, just like any other skill.

Listen to understand, not to reply. In your next meeting, try to repeat back what someone said in your own words before you answer.
Ask one more question. "What would make this a success for you?" often tells you more than the whole requirements document.
Pause before you send. Reread your message as if you are the person receiving it. How does it sound on a bad day?
Name what you feel. Just saying "I am frustrated" or "I am nervous" to yourself makes it easier to handle.I sometimes even say it out loud at conference talks in front of an audience.
Ask, do not assume. How someone communicates tells you about their style, not about how much they care.
Ask how you come across. A trusted colleague can tell you things about your communication that you will never notice yourself.

That's a wrap!

AI is changing how we write code, and that is exciting. But software is still built by people, for people. The better you understand the humans around you, and yourself, the more valuable you become, no matter how good the tools get.

Or, as Manuela put it on that slide: "AI is a tool. You are the strategy."

Thanks for reading! If you have thoughts, disagree with me, or want to share your own experience, feel free to leave a comment or reach out on my socials. I am always happy to talk about this stuff.

SQL Database Projects and AI: A Match Made in Heaven

Lou Creemers — Thu, 24 Sep 2026 15:34:09 +0000

Hey lovely readers,

If you have ever asked an AI tool to write some SQL for you, you have probably seen this happen. You ask for a query, you get something that looks great, and then you run it and find out it uses a column that does not exist. Or a function your SQL Server version does not support. Or it quietly drops something you really wanted to keep.

I wrote before about how AI tools are confident even when they are wrong. That is annoying in C#, but at least the compiler yells at you. With databases, there often is no compiler. There is just you, a script, and a database that is about to find out.

That is exactly why I think SQL Database projects and AI are a match made in heaven. Let's talk about why.

If you have worked with SQL Database projects before, feel free to skip to "Why AI and SQL projects get along so well". If you have never heard of them, don't worry, we will start from the beginning.

What is a SQL Database project?

A SQL Database project is a local representation of your database schema. Your tables, views, stored procedures, and functions all live in .sql files inside a project on your machine, right next to your application code and in the same Git repository.

If you are a .NET developer, you can think of it as a .csproj, but for your database. You write files, you build the project, and you get an output you can deploy.

Here is what a table looks like in a SQL project:

CREATE TABLE [dbo].[Customers]
(
    [Id] INT NOT NULL PRIMARY KEY,
    [Name] NVARCHAR(100) NOT NULL,
    [Email] NVARCHAR(256) NOT NULL
);

Nothing special, right? The special part is what happens when you want to change it.

Declarative instead of step by step

Most of us learned to change databases step by step. First you create the table. Then, a bit later, you write a script that adds a column. Then another script that changes a data type. After a year, you have a folder with 80 scripts that need to run in exactly the right order.

SQL projects work differently. They are declarative, which means you describe what the database should look like, not how to get there. Each object is declared once, in one file. Want to add a phone number to your customers? You do not write an ALTER TABLE script. You just edit the same file:

CREATE TABLE [dbo].[Customers]
(
    [Id] INT NOT NULL PRIMARY KEY,
    [Name] NVARCHAR(100) NOT NULL,
    [Email] NVARCHAR(256) NOT NULL,
    [PhoneNumber] NVARCHAR(20) NULL
);

Think of it like a blueprint of a house. You do not hand the builder a list of "knock down this wall, then add a window here". You hand them the blueprint of what the house should look like, and they figure out what needs to change.

Build and deploy

When you build a SQL project with dotnet build, two things happen.

First, the project gets validated. The build checks that every object you reference actually exists. A view can't use a table or column that is not in your project. The build also checks your syntax against a target platform, which is the SQL version you are targeting. For example, if your project targets SQL Server 2017, you can't use JSON functions that were added in SQL Server 2022.

Second, you get a .dacpac file. That is the build artifact, a package that contains your whole schema.

To deploy it, you use a tool like SqlPackage. When you publish a .dacpac to a new database, it creates everything in the right order, so a table with a foreign key is created after the table it points to. When you publish to an existing database, it compares your .dacpac to that database and only generates the changes that are needed. Missing two columns? You get an ALTER TABLE. Changed a stored procedure? You get an ALTER PROCEDURE.

So the blueprint is yours, and the builder is SqlPackage.

A quick note on project formats

If you worked with SQL projects years ago, you probably remember the original format, based on .NET Framework and mostly tied to Visual Studio on Windows.

The newer format is SDK-style, using the Microsoft.Build.Sql SDK. It runs on modern .NET, works cross-platform, supports NuGet package references for database references, and automatically includes all .sql files in your project folder. Microsoft recommends it for new development, and it is the format that will be supported in the future.

Tooling support is different per IDE, so here is where things stand right now. SDK-style projects are generally available in the SQL Database Projects extension for VS Code. JetBrains Rider supports them since version 2025.2 through a bundled plugin, with project templates, importing from an existing database, schema compare, and publishing. In Visual Studio 2022, they are available as a preview component. Visual Studio 2026 only supports the original format for now, so if Visual Studio is your IDE of choice, keep that in mind when picking your tools.

Getting started with the SDK-style format looks like this:

dotnet new install Microsoft.Build.Sql.Templates
dotnet new sqlproj -n MyDatabase
dotnet build

Why AI and SQL projects get along so well

Now for the fun part. Here is why I think this combination works so well.

The whole schema is right there as context

AI tools are only as good as the context you give them. If your schema lives only inside a running database, the AI either has to guess what your tables look like, or you have to give it a connection to your database. Please do NOT give an AI agent a connection string to production.

With a SQL project, your entire schema is plain text in your repository. One object per file, easy to search, easy to read. An AI agent in your editor can open Tables/Customers.sql and see exactly what columns exist, what the types are, and what the foreign keys point to. No guessing, no database access needed.

And if you already have a database without a SQL project, you can extract one. You can do this from VS Code, or from the command line:

sqlpackage /Action:Extract /SourceConnectionString:"<your connection string>" /TargetFile:MyDatabase /p:ExtractTarget=SchemaObjectType

This works no matter how the database was created, even if you use an ORM like EF Core. That means you can give AI tools a readable picture of your schema without changing how your team works.

The build is a fact-checker

This is my favorite part. Remember the AI that confidently used a column that does not exist? In a SQL project, that is a build error.

Say you ask an AI to create a view, and it comes up with this:

CREATE VIEW [dbo].[CustomerContacts]
AS
SELECT [Name], [Email], [Phone]
FROM [dbo].[Customers];

Imagine that our column is called PhoneNumber, not Phone. Run dotnet build, and you get an unresolved reference error (SQL71501) pointing right at the problem. Same for syntax your target platform does not support.

This gives AI agents something they are really good at using: a feedback loop. Make a change, build, read the errors, fix them, build again. The agent can find its own mistakes before you ever have to look at them. The database finally gets something that feels like a compiler.

AI describes the destination, not the route

Migration scripts are where things tend to go wrong. The order matters, the current state of the database matters, and one wrong assumption can break everything.

With a SQL project, the AI does not have to write migration scripts at all. It only has to edit the file that describes what the object should look like. Figuring out how to get the actual database from its current state to that new state is SqlPackage's job, and SqlPackage has been doing that reliably for a long time.

So the AI does the part it is good at (writing a clear description of what you want) and a deterministic tool does the risky part (calculating the changes). I love that split.

You can review every change like normal code

Because everything is a file in Git, every AI change to your database shows up as a normal diff in a pull request. You see exactly which column was added, which view changed, and which procedure got rewritten. Your teammates can review it the same way they review C# code.

That also means your normal CI/CD pipeline can build the project on every pull request. If the AI (or a human, let's be honest) broke something, the pipeline catches it before it gets merged.

Code analysis adds extra guardrails

SQL projects can also run code analysis during the build. You turn it on in your project file:

<PropertyGroup>
  <RunSqlCodeAnalysis>True</RunSqlCodeAnalysis>
</PropertyGroup>

Now you get warnings for common bad practices, like using SELECT * in views and stored procedures. AI tools love SELECT *, so this one alone is worth it. You can customize which rules apply, and if you want to go further, you can even write your own rules.

You see the plan before anything touches a database

Before you deploy, you can ask SqlPackage to generate the script it would run, instead of running it right away:

sqlpackage /Action:Script /SourceFile:bin/Debug/MyDatabase.dacpac /TargetConnectionString:"<your connection string>" /OutputPath:deploy.sql

Or use /Action:DeployReport to get an overview of the changes. That way there are two review moments: the diff of the SQL files, and the actual script that will run against your database. Nothing reaches a real database without you seeing it first.

Making it work in practice

A few things that help a lot when you let AI work on a SQL project.

Tell your AI tool how your project works. Most AI coding tools support an instructions file in your repository. Add a small section about your database, something like this:

## Database changes
- The database schema lives in /database as a SQL Database project.
- Each object is declared once, in its own file. Never write ALTER statements or migration scripts.
- After every schema change, run `dotnet build database/MyDatabase.sqlproj` and fix all errors before continuing.
- The target platform is SQL Server 2022. Do not use features from newer versions.

Set the right target platform. The build can only protect you from unsupported syntax if the target platform matches the SQL version you actually deploy to.

Keep the AI away from real databases. Let it work on files and run builds. Deploying stays a human decision, or a pipeline decision with a human approving it.

What it does not solve

I do not want to pretend this is magic so here are a few honest limitations.

Renames are tricky. If an AI renames a column by just editing the file, the deployment can see that as "drop the old column, add a new one", and that means data loss. By default, SqlPackage blocks deployments that might lose data, which is great. However, you still need to handle renames properly. SQL projects have a refactor log for this, which the tooling creates when you use the rename refactoring. An AI editing text files will not create that for you, so keep an eye on renames in reviews.

Data changes are also a different story. SQL projects describe the schema, not the data. If you need to move or transform data, you still write that yourself, for example in a post-deployment script.

And of course, a green build does not mean the change is a good idea. The build tells you the schema is valid, not that the design makes sense. Reviewing is still your job.

That's a wrap!

SQL Database projects give your database the things we take for granted in application code: files you can read, a build that catches mistakes, and changes you can review. It turns out those are exactly the things AI tools need to be actually useful instead of confidently wrong.

If you are a junior developer, this is a really nice way to learn database development with a safety net. If you have worked with SQL projects for years, you might find they suddenly got a lot more interesting now that an AI agent can use that same build to check its own work.

Thanks for reading! If you have thoughts, questions, or your own experience with AI and databases, feel free to leave a comment or reach out to me on my socials.

See ya!

My JetBrains Rider Setup for Surviving Live-Coding Demos

Lou Creemers — Sat, 15 Aug 2026 14:57:16 +0000

Hey lovely readers,

If you've read any of my Public Speaking at Tech Events 101 blog posts, you already know I take demo prep very seriously. What I haven't written about yet is my IDE setup. I spend most of my working hours in JetBrains Rider, and I also spend most of my stage time there. Over the years I built a setup that helps me get through a live demo without fighting my own tools on top of fighting my nerves.

This post is that setup written down. That way it can help you too if you ever want to challenge the demo gods.

A quick note before we start: I'm writing this as a Rider user, since that's where I live most days. But almost everything here works the same way in WebStorm, IntelliJ IDEA, PyCharm, and the other JetBrains IDEs, since it's mostly the same underlying platform.

Presentation Mode and light theme

The first thing I do before any talk is turn on Presentation Mode. You'll find it under View > Appearance > Enter Presentation Mode. It makes the editor fill the whole screen and it makes the font bigger automatically. That way you don't have to change font sizes by hand right before you walk on stage.

You can also set a fixed zoom level ahead of time. Then it's already right the moment you turn Presentation Mode on, instead of adjusting it in front of a room full of people. Go to File > Settings (or Preferences on macOS), then Appearance & Behavior > Appearance and look for the Presentation Mode settings there.

The second thing I do is switch to light theme. I know, most of us live in dark mode (me included). But dark themes often look washed out under conference lighting and projectors. Light backgrounds are simply easier to read from the back of the room. Your eyes might need a minute to adjust, but your audience will thank you.

Markdown-powered slides with MARP

This one changed how I build talks completely. Instead of switching between PowerPoint and Rider during a demo, I now write my slides in Markdown. I preview them right inside the IDE, using MARP (Markdown Presentation Ecosystem).

Here is the short version of the setup. Add a package.json file next to your presentation file:

{
  "scripts": {
    "marp": "marp index.md -w --html --allow-local-files"
  },
  "devDependencies": {
    "@marp-team/marp-cli": "^4.5.0"
  }
}

Then create an index.md file in the same folder. Write your slides in Markdown, and separate each slide with ---. Run npm install, and Rider will show a small run button next to your script. Run it, and the -w flag keeps watching your Markdown file. It rebuilds the HTML every time you save.

To show the presentation, right click the new HTML file and choose Open In > Browser > Built-in Preview. Now your slides live in a tab right next to your code. You can switch between them using Rider's normal tab shortcuts, instead of switching to a completely different app.

A few things that are worth knowing. Press P while previewing to open a window with your speaker notes, which you can keep on a second screen. If you use the --html flag like in the script above, you can also add things like Mermaid diagrams straight into your slides. Unfortunately I don't get lots of opportunities to add Mermaid Diagrams to demos but I do love them :)

I like this setup because my whole talk, slides and demo code both, lives in one place. That's one less app to manage, and one less thing that can go wrong.

Quick side note if you do JavaScript or Vue talks: I use Slidev for those instead. It's also Markdown powered, but it's built with the JS ecosystem in mind, so it fits that kind of talk a bit better. Same idea, just a different tool depending on the stack I'm presenting.

Switching files and projects quickly

During a demo, the last thing you want is to search through 5 different projects, trying to remember where you put a file. Search Everywhere (press Shift twice) is your best friend here. Type a few letters of a file, class, or action name, and you jump straight to it. No scrolling needed.

Recent Files (View > Recent Files, or Ctrl/Cmd+E) and Recent Locations (View > Recent Locations, or Ctrl/Cmd+Shift+E) are both super useful in addition to Shift + Shift. Recent Files just shows you the files you had open recently. Recent Locations goes a step further and shows you actual code snippets from the places you edited, which is handy if you remember what the code looked like but not which file it was in.

All three of these search options help you move fast between the two or three files a demo actually uses. And if something goes wrong and you need to switch from a working project to a backup project, being able to jump between run configurations or entire projects fast matters just as much as knowing your code.

dotnet run and .http files

Since .NET 10 we can now use single C# files without setting up a full project first. This is great for quick demos. I often skip run configurations completely and just use dotnet run from the terminal. It's fast, it's predictable, and there is less to explain if something looks unfamiliar to the audience.

For live API demos, .http files are one of my favorite Rider features. Instead of switching to an API client and breaking the flow of your talk, you write the request right there in your project:

GET https://localhost:5001/api/dadjoke
Accept: application/json

Click the small run icon next to it, and the response shows up right there. No separate tool, no window switching, no explaining why you suddenly switched apps.

Live templates

The live templates might be the best thing ever for demos. They are one of the best tools for reducing what can go wrong on stage. A live template is a code snippet you can insert with a short name and a press of Tab.

You'll find them under File > Settings (or Preferences on macOS), then Editor > Live Templates. From there you can create a new template group, or add templates to an existing one, each with its own abbreviation, description, and body.

I use these a lot, but especially for two of my talks: Minimal APIs and modern C# features. Both involve a lot of boilerplate. If I had to type every endpoint or every record from scratch during a session, I would be typing the whole time instead of talking to the room.

This is where a naming format helps. Instead of picking random short abbreviations, I group mine by talk topic with a short prefix. api-get, api-post, and api-delete are all Minimal API templates. csx-record and csx-pattern are all modern C# templates. That way I'm not stuck remembering fifteen unrelated abbreviations, I just remember the prefix for the talk I'm giving, and Rider's autocomplete shows me the rest as I type.

Less typing under pressure means fewer mistakes. That's really the whole point.

Shortcuts worth knowing by heart

I'm not going to give you a giant list of every Rider shortcut that exists. That's not useful in the middle of a talk. These are the ones I actually know by heart, the ones that help when your brain isn't at its sharpest:

Shift Shift for Search Everywhere
Ctrl/Cmd + Shift + F10 (or the run icon) to run the current file or test
Shift + F9 to debug
Ctrl/Cmd + Alt + L to reformat code, handy if a live edit gets messy

That's the list. You don't need fifty shortcuts. You mostly need these four to get you out of trouble.

That's a wrap!

None of this actually removes the nerves before a talk. I still feel them every single time, and that's completely normal. What this setup does is remove the things you can actually control. That way your nervous energy can go into the talk itself, instead of into fighting your IDE.

I hope this helps you for your upcoming presentation or talk. If you have questions about anything above, feel free to leave a comment or reach out to me on my socials.

See ya!

How Being a Junior Developer Taught Me More About Myself Than About Code

Lou Creemers — Sat, 18 Jul 2026 12:55:34 +0000

Hey lovely readers,

My 3-year anniversary of graduating from university with my bachelor's in Applied Computer Science is coming up. It feels like 5 centuries and 5 minutes ago at the same time.

I started working right after graduation, and let me tell you, I learned a lot about the working field, and even more about myself. I quit a company that offered me a contract barely above minimum wage. I experienced a company not liking me, and me not liking them back. I even got fired from a job before my trial period had properly started.

None of that felt great at the time. But looking back, it all led me to where I am now. So let's talk about it. Let's talk about why it is completely okay to still be figuring yourself out, and what you actually want, as a junior developer.

Before I go on, I do want to be honest about one thing. I started looking for my first dev job in 2023, and the junior job market looked very different back then compared to now. Getting a first developer job in 2026 is a lot harder. Entry-level job postings have dropped a lot over the past few years, and companies now ask junior candidates for more experience and a stronger portfolio than they used to. On top of that, I already had my Microsoft MVP title back then and was speaking at events, so companies already knew who I was before I even applied. That gave me an advantage that most junior developers simply do not have, and I do not want to pretend otherwise. So please read the rest of this post with that in mind. The lessons still hold, but walking away from a bad offer, or leaving a mismatch, was easier for me in a market, and with an advantage most people do not get. If you are job hunting right now, it makes complete sense if some of this advice is harder to apply, and that is not a reflection of you doing anything wrong.

Underpaid does not mean grateful

When you are fresh out of university, it is easy to feel like you should be grateful for any offer at all. You do not have much experience yet, the job market can feel scary, and a company offering you a contract feels like a win, even if the salary for it is not great.

I want to gently disagree with that feeling.

Being a junior developer does not mean your work has no value. It means you are early in your career, not that you should accept barely above minimum wage for a full-time developer role. When I quit that company, it did not feel like a great moment. It felt scary. But it was also the first time I really understood that walking away from something that undervalues you is not bad.

If you are in a similar position right now, please know this: it is okay to say no. It is okay to negotiate. And it is okay to leave, even as a junior, even if it feels early to make that kind of decision.

Sometimes it just does not click, and that is fine

Not every company and developer are a good match, and that is nobody's fault.

I have been in a situation where a company simply did not like me, and if I am honest, I did not really like them either. That is an sad thing to accept, especially early in your career when you assume that if something is not working, it must be you.

But work relationships are a two-way fit, just like any other relationship. Communication style, expectations, pace of work, sense of humour, all of it plays a role. A mismatch does not mean you are difficult to work with, and it does not mean the company is bad either. It just means that particular combination was not right.

Recognising this early saved me a lot of unnecessary guilt later on. If a place does not feel right, it is worth asking why, without immediately assuming the answer is something wrong with you.

Getting let go before you even started

This one is a strange story, but I will tell it simply: I got fired from a job before my trial period had even started, just a short time before I was supposed to begin. The reason was not about me at all. The company made a business decision that had nothing to do with me, my skills, or my fit for the role, and that decision meant my contract could not go ahead.

It still stings, even when you know exactly why it happened. There is something oddly personal about being let go before you even get the chance to prove yourself, even when the reason has nothing to do with you as a person or as a developer. In my case, it genuinely had nothing to do with my skills or fit. Sometimes it really is that simple: a company makes a decision for its own business reasons, and it happens to affect you directly, even though it is not about you at all.

But not every story like this comes with such a clear reason. Sometimes it is about fit or timing on the company's side, and you never get a clean explanation. Either way, the lesson stays the same: one mismatch, or one company's decision, does not decide your whole career.

Learning what you actually need from a work environment

One of the biggest things I have figured out over these 3 years is how much my environment affects how well I can do my job.

I have learned that I struggle with things like busy social events and open offices, and that this is not something that gets easier just because I push through it a few more times. It is a pattern, not a bad day here and there. For a long time I assumed I should just be able to handle it, the way it seemed like everyone else could. It took a while to understand that some environments just don't work for me, no matter how much I want them to.

Once I understood that about myself, it changed the way I looked at job offers and company cultures completely. I started paying attention to things like: is there a quiet space to work if I need one? Are social events something I am expected to attend, or something I can choose to join when I have the energy for it? Is the office open-plan, and if so, is there a way to get a break of it?

None of this means those environments are bad, or that people who thrive in them are doing something wrong. It just means I learned that my own needs are specific, and that ignoring them does not make them go away. It only makes work harder than it needs to be.

If there is one thing I would want every junior developer to take from this, it is that learning how you work best is just as important as learning how to code. That kind of self-knowledge is not something you are handed on day one. It is something you build, often through experiences that are uncomfortable at the time.

You do not need to be everyone's friend

This is one of the harder lessons, but also one that calms me down: you cannot be friends with every single colleague, and some people will simply dislike you without there being a clear reason why.

That used to bother me a lot. I would try to figure out what I did wrong, replay conversations, wonder if I said something strange or looked at somebody wrong. Sometimes there really is no answer. Personalities just clash sometimes, and it does not always come with a clear explanation.

What helped me was realising that being liked by absolutely everyone was never actually the goal. What matters is being respectful, doing good work, and being someone people can rely on. That is a very different thing from being everyone's favourite person in the office, and it is a much more reasonable standard to hold yourself to.

So if there is a colleague who just does not seem to like you, and you cannot figure out exactly why, it is okay to let that be. Not every relationship needs to be solved. Some things simply are what they are.

What I know now that I wish I knew as a fresh graduate

Looking back at all of this from where I am now, a few things stand out that I wish someone had told me sooner:

Pay attention to how a company communicates with you during the interview process. It tells you a lot about what working there will actually be like.
Trust how you feel in the first few weeks of a new job. If something feels off, it is worth paying attention to that feeling instead of ignoring it.
Leaving a job, or having a job not work out, is not failing. It is part of figuring out what you actually want, even if the timing or the market makes that decision harder than it sounds.
Your first job does not have to be your dream job. It is allowed to just be a step that teaches you something about yourself.
Learning how you work best, like what kind of environment helps you and what kind of environment drains you, is just as valuable as learning a new framework or language.
Not everyone has to like you, and you do not have to like everyone either. That is not a failure on your part or theirs.
If the market right now means you have less room to walk away than I did, that is not a personal failure either. It is a reflection of a genuinely tougher market, not a lack of drive or talent on your part.

That is a wrap

3 years in, I do not have it all figured out, and I do not think that is the goal anymore. What I do know is that every one of these experiences, the good ones and the uncomfortable ones, taught me something about what I want and what I do not want in my career.

If you are a junior developer still finding your way, please be patient with yourself. It is a marathon, not a race.

Thanks for reading! If you have thoughts, questions, or your own stories from early in your career, feel free to leave a comment or reach out to me on my socials.

C# Async/Await Made Simple

Lou Creemers — Sun, 12 Jul 2026 19:39:07 +0000

Hi lovely readers,

Today we are looking at async and await. If these two words have ever shown up in your code and made you a little nervous, do not worry. This post is written for people who are seeing async/await for the very first time, so we will take it slow and build things up step by step.

The problem async/await solves

Let's start with why this exists at all, using a simple example from real life.

Imagine you are cooking dinner and you put a pot of water on the stove to boil. If you just stood there, staring at the pot until it boiled, you would waste a lot of time. A better approach is to start the water boiling, and while you wait, you chop vegetables or set the table. When the water is ready, you go back to it.

That is exactly what async/await lets your code do. When your application needs to do something that takes time, like reading from a database or calling a web page, it does not have to freeze and wait. It can start that task, do other useful work, and come back to it once it is done.

Without async/await, your program has to wait for one task to fully finish before it can do anything else. This is called blocking, and it can make an application feel slow, especially when many people are using it at the same time.

The two keywords, explained simply

async is a label you put on a method to say: "this method contains something that might take time, and it is allowed to pause halfway through."

await is the actual pause. It is the exact place where your code says: "wait here until this is finished, but do not block anything else while you wait."

Here is a small example:

public async Task<User> GetUserAsync(int id)
{
    // This is where we "wait" for the database to respond
    var user = await _dbContext.Users.FindAsync(id);

    // Once the database has answered, we continue from here
    return user;
}

Notice three things:

The method has async in its signature.
It returns a Task<User> instead of just User. This is normal for async methods. Think of Task<User> as a promise that a User will be delivered eventually.
The await keyword is placed right before the slow operation, FindAsync.

How do you call an async method?

To call an async method, you also need to use await, and the method that is calling it usually needs to be async too.

public async Task PrintUserNameAsync(int id)
{
    var user = await GetUserAsync(id);
    Console.WriteLine(user.Name);
}

This is a pattern you will see everywhere in C#. Once one method becomes async, the methods that call it usually become async as well. This is completely normal, so do not worry if it feels like async spreads through your code. That is simply how it works.

A few beginner-friendly rules to hold onto

Always return Task or Task<T> from your async methods, never void. The only exception is event handlers, which is a more advanced topic you will run into later. If something goes wrong inside a method that returns void, the error can get lost and your application might crash without a clear reason.

// Avoid this
public async void ProcessOrderAsync(Order order)
{
    await _repository.SaveAsync(order);
}

// Do this instead
public async Task ProcessOrderAsync(Order order)
{
    await _repository.SaveAsync(order);
}

Never call .Result or .Wait() on a task. It might be tempting to use these when you are not in an async method yourself, but they force your program to block and wait, which is exactly what async/await is trying to avoid. In some situations, this can even cause your application to freeze completely. Stick to await.

// Avoid this, it can cause your app to freeze
var user = GetUserAsync(id).Result;

// Use this instead
var user = await GetUserAsync(id);

If you have several tasks that do not depend on each other, you can run them at the same time. Waiting for them one by one when you do not need to is a common beginner habit, and it is an easy thing to improve once you notice it.

// One after another, even though they do not depend on each other
foreach (var order in orders)
{
    await ProcessSingleOrderAsync(order);
}

// All at once instead
var tasks = orders.Select(order => ProcessSingleOrderAsync(order));
await Task.WhenAll(tasks);

What's next?

Once you feel comfortable with the basics, there are a few more advanced topics worth exploring later on, like ConfigureAwait, the difference between Task and ValueTask, and async streams with IAsyncEnumerable. You do not need any of that to get started, though. For now, focus on getting comfortable with async, await, and Task, since that foundation will carry you a long way.

That's a wrap!

Async/await can feel a bit strange the first time you use it, and that is completely normal. Give yourself time to get used to it. The short version to remember: async marks a method that can pause, await is where it pauses, and Task is the promise that something will be ready eventually.

If you have thoughts, questions, or you are working through your own first async method right now, feel free to leave a comment or reach out to me on my socials. I remember exactly how confusing this felt at first, so do not hesitate to ask anything.

Bye AZ-204, hello AI-200: What you need to know about the new Azure developer certification

Lou Creemers — Tue, 23 Jun 2026 11:10:15 +0000

Hi lovely readers,

If you have been working toward your AZ-204 certification or have been thinking about starting, there is something important you need to know. Microsoft has officially announced that AZ-204: Developing Solutions for Microsoft Azure will retire on July 31, 2026. Its replacement is AI-200: Developing AI Cloud Solutions on Azure, and this is a much bigger change than just a new name.

What is actually changing?

AZ-204 has been the main certification for Azure developers for years. It covers the topics you would expect from a solid Azure developer: App Service, Azure Functions, Cosmos DB, Blob Storage, API Management, and authentication through the Microsoft Identity platform. It is a broad and practical exam, and many developers specializing in Microsoft have this certification or have tried to get it.

AI-200 replaces that entirely. The new exam leads to the Microsoft Certified: Azure AI Cloud Developer Associate credential, and the focus has moved strongly toward building AI-powered applications. Think vector databases, retrieval-augmented generation (RAG), Azure Cosmos DB with semantic search, PostgreSQL with pgvector, Azure Managed Redis for similarity search, and containerized applications on Azure Kubernetes.

This is not a small update. Microsoft is making something very clear here: being an Azure developer in 2026 means knowing how to build with AI, not just around it.

What carries over and what does not?

Around 60% of AZ-204 content carries forward into AI-200. That sounds alright, but it is important to look at what is being removed.

What is gone in AI-200:

Blob Storage SDK
Microsoft Identity platform
Microsoft Graph
API Management
Azure Event Hubs
Azure Queue Storage
Application Insights SDK (replaced by OpenTelemetry)

If you have been studying those topics, they will not be tested in AI-200.

What is new in AI-200:

Vector search across Cosmos DB NoSQL, pgvector on PostgreSQL, and Azure Managed Redis
Kubernetes Event-driven Autoscaling (KEDA) in Container Apps
Full AKS deployment and management using manifest files
OpenTelemetry for distributed tracing, instead of the Application Insights SDK
KQL queries for logs and metrics
RAG pattern implementation

The difference between the two exams is large enough that you cannot assume your existing study materials for AZ-204 like books or online courses will work for AI-200.

From C# to Python

AZ-204 is designed for developers working in C# or Python. The audience profile mentions Azure SDKs broadly, and the prerequisites name both languages.

AI-200 is different. The official study guide lists Python programming as a required skill, and it is the only language mentioned. If you are a .NET developer who mainly works in C#, that is worth knowing before you start preparing. It does not mean you cannot take the exam, but the exam is written with Python in mind.

Should you still take AZ-204?

It depends on where you are in your preparation.

If you are close to being ready for the exam, taking AZ-204 before July 31st still makes sense. The credential stays valid through its full renewal period even after the exam retires, so you are not losing anything by taking the exam.

If you are just getting started with studying, moving to AI-200 now is the better choice. There is no reason to spend time on topics that will not appear on any future exam. The AZ-204T training course retired on May 29, 2026, and AI-200 training course is now the replacement, so the official learning path has already changed.

If you are starting from scratch: skip AZ-204 entirely and go straight to AI-200.

One thing to keep in mind: the AI-200 exam is currently still in beta. That means practice exams are not available yet, and beta exams are not scored right away while Microsoft collects data on question quality. This might mean that you have to wait for a bit if you prefer to have more practice materials before sitting the actual exam.

A bigger picture

AZ-204 is not the only certification going through this kind of change. Microsoft is retiring several familiar exams this year and replacing them with AI-focused alternatives. AZ-500 is being replaced by SC-500 (Cloud and AI Security Engineer), DP-100 is being replaced by AI-300 (Machine Learning Operations Engineer), and AI-900 was already updated to AI-901 in March 2026.

That's a wrap!

If you have thoughts, questions, or experiences you would like to share, feel free to leave a comment or reach out to me on my socials.

AI Is Making English a Must-Have Skill for Developers

Lou Creemers — Tue, 09 Jun 2026 16:29:05 +0000

Hi lovely readers,

If you have spent any time online lately, you have probably seen the endless debates about which programming language you should learn next. Should it be Rust because everyone keeps saying it is the future? Should you stick with C# and .NET? Is JavaScript still worth it, or is it finally time to pick up Python because of all the AI tooling?

These are fair questions, and I love a good language debate as much as the next developer. But after spending the last couple of years watching how AI tools changed the way I actually work day to day, I have come to a slightly different conclusion. The most important language for a developer in the age of AI is not C#, JavaScript, or Rust.

It is English.

You are not writing code anymore, you are describing it

For most of my career, the gap between an idea in my head and working code was filled by me typing that code out, line by line. I knew the syntax, I knew the patterns, and the language I used to get from idea to result was C#.

That gap looks very different now. A large part of my day involves explaining what I want to an AI tool, reviewing what it gives back, and then explaining what was wrong or what I want changed. The bottleneck is no longer "do I know the syntax for this LINQ query." The bottleneck is "can I describe this problem clearly enough that something else can solve it."

That is not a coding skill. That is a communication skill.

If you ask a vague question, you get a vague answer. If you describe the wrong problem, you get a solution to a problem you do not have. The clearer you can express what you actually need, the better the result. And the language most of these tools were trained on, the language most documentation is written, the language most of the prompts and examples online use, is English.

I learned this the hard way in my second language

If you have read some of my other posts, you already know that English is not my first language. I am Dutch, and during university my teachers regularly pointed out how I would lose my train of thought halfway through a sentence. Writing clearly in a second language took me years of effort, which I learned mostly through blogging. That effort turned out to be one of the best investments I ever made, and I did not even realize it at the time.

When you work with AI tools, the quality of your output is tied directly to how clearly you can phrase things. A messy, half-finished thought gives you a messy, half-finished answer. A precise description, with the right context and the right constraints, gives you something you can actually use. The skill of taking a fuzzy idea and turning it into clear sentences is exactly the same skill I had been practicing for years without knowing how useful it would become.

So if English is not your first language either, I want to be honest with you. Yes, this puts a little extra weight on something that is already harder for us. But it is also a skill you can build, the same way you built your ability to read a stack trace or debug a null reference exception. It just takes practice.

Communication was always a huge part

Here is something that I think a lot of us already knew before AI made it impossible to ignore. The hardest parts of software development were rarely the code itself.

The hard parts were understanding what a stakeholder actually wanted instead of what they said they wanted. Writing a pull request description that your reviewer could understand without three follow-up messages. Explaining a technical decision to someone who does not write code. Leaving a comment that your future self would thank you for. Writing documentation that someone could actually follow.

All of that is language. All of that is the ability to take something complicated and make it understandable for another human being. AI did not create this skill, it just turned up the volume on how much it matters. The developers who can clearly explain a problem, give good context, and describe what "done" looks like are the ones getting the most out of these tools right now.

Reading is half of the skill

It is easy to focus only on the part where you describe what you want, but there is another half that matters just as much. You also have to read carefully.

AI tools are confident even when they are wrong. They will happily invent a method that does not exist, suggest a package that was deprecated years ago, or solve your problem in a way that quietly breaks something else. If you cannot read the answer critically and notice when something is off, you are going to have a bad time.

That critical reading is, again, a language skill. It is the ability to follow an explanation, spot the part that does not make sense, and ask a sharp follow-up question. The same way a good code reviewer reads a diff and immediately senses something is wrong, you now need to read generated answers the same way. The better you are at reading, the less likely you are to copy something into production that you did not actually understand.

Programming languages do not stop being important

I want to be clear, because I can already see the comments online. I am not saying you should stop learning programming languages, or that syntax no longer matters, or that you can ship software without understanding what the code does. You absolutely still need to understand your stack. You need to know enough to tell when an answer is nonsense, to debug the thing when it breaks at 4 PM on a Friday, and to make real decisions about architecture and trade-offs.

Programming languages are still the thing the machine runs. But English has quietly become the thing you use to get there. One does not replace the other. They sit next to each other, and right now, a lot of developers are not putting enough effort into the second one.

How to actually get better at it

The good news is that this is a skill you can practice, and you probably already have the perfect tools for it.

Write more. Write blog posts, write detailed pull request descriptions, write proper commit messages, write documentation for the thing you just built. Every time you force yourself to explain something clearly in writing, you are training the exact muscle that makes you better at working with AI.

Pay attention to your prompts. When you get a bad answer, do not just try again with the same vague request. Ask yourself what context was missing, what you assumed the tool already knew, and how you could have phrased it more precisely.

And if English is not your first language, do not let that stop you. Read in English, write in English, and let yourself be a little uncomfortable while you improve. I promise it gets easier, and it pays off in more ways than you expect.

That's a wrap!

Thanks for reading! If you have thoughts, disagree with me, or want to share your own experience, feel free to leave a comment or reach out on my socials. I am always happy to talk about this stuff.

Vue Composition API: Computed and Ref Properties Explained

Lou Creemers — Thu, 19 Feb 2026 20:44:41 +0000

Hey lovely readers,

If you are working with Vue 3 and TypeScript, you have probably seen ref and computed many times. They appear in tutorials, real projects, and even job interviews. When I first started using Vue 3, I kept wondering why everything had to be wrapped in ref, and what made computed different from a normal function.

I would consider myself more of a backend developer, and I spent a lot of time in 2025 trying to wrap my head around frontend development. So if you are using Vue 3 with TypeScript now, or planning to start learning Vue, this guide will help you clearly understand these two important concepts.

What is state?

Before we talk about ref and computed, we need to understand one important concept: state.

State is simply data that can change over time and affects what the user sees on the screen. If the data changes and the UI must update because of it, that data is state.

Examples of state in a frontend application include a counter value, a list of users fetched from an API, whether a modal is open or closed, the content of an input field, or the currently logged in user.

State from a backend perspective

If you come from a backend background, you are already familiar with state. You work with database records, request and response objects, session data, and cached values. That is all state too. The difference is where it lives.

In traditional backend driven applications, the flow usually looks like this:

The client sends a request
The server processes data
The server returns HTML or JSON
The page reloads with updated data

In this model, most of the state lives on the server.

In modern frontend frameworks like Vue, state often lives in the browser. There is no full page reload. Instead, a user clicks a button, data changes in memory, and the UI updates automatically. This automatic update is what we call reactivity.

Vue needs a way to know which data should trigger UI updates. That is exactly what ref and computed help with.

What are `ref` and `computed` in Vue 3?

In Vue 3, reactivity is managed with the Composition API. Two key features are ref and computed. You can think of ref as reactive state and computed as derived state.

`ref` as reactive state

You use ref to create reactive values such as numbers, strings, and booleans. This should be a value that you want to change when some action happens in the template.

Here is a simple example in Vue 3 with TypeScript:

import { ref } from 'vue'

const count = ref<number>(0)

function increment() {
  count.value++
}

Here is what is happening. ref<number>(0) tells TypeScript that this ref contains a number. The actual value is accessed using .value. When count.value changes, Vue automatically updates the user interface.

In backend terms, you can think of ref as a variable stored in memory that Vue is actively watching. When the value changes, Vue reacts and updates the UI.

In the template, you do not need to use .value because Vue unwraps it for you:

<template>
  <p>{{ count }}</p>
  <button @click="increment">Increment</button>
</template>

We use .value in the script because ref does not return the raw number. It returns a reactive wrapper object that allows Vue to track changes.

`ref` with objects

You can also use ref with objects, especially when working with TypeScript interfaces:

interface User {
  name: string
  age: number
}

const user = ref<User>({
  name: 'Lou',
  age: 27
})

To update it:

user.value.age++

If you mainly work with objects, you will also come across the reactive function, but the core idea stays the same. Vue tracks changes and updates the UI when the state changes.

Derived state and `computed`

If ref represents your source of truth, then computed represents values derived from that source.

Derived state is data that is calculated from other state, should always stay in sync, and should not be manually updated.

Here is an example:

import { ref, computed } from 'vue'

const price = ref<number>(10)
const quantity = ref<number>(2)

const total = computed<number>(() => {
  return price.value * quantity.value
})

In this case, price and quantity are source state. total is derived state.

From a backend perspective, this is similar to a calculated column, a DTO field built from other fields, or a value computed from query results. You would not store total separately in a database if it can always be calculated from price * quantity, because that would create duplication and possible inconsistencies.

The same idea applies here. computed helps you avoid duplicated state and keeps your data consistent.

`computed` vs a function

You could write a normal function instead:

function fullName() {
  return `${firstName.value} ${lastName.value}`
}

And use it in the template like this:

<p>{{ fullName() }}</p>

So why use computed?

The main difference is caching and dependency tracking. A normal function runs every time the component re renders. It does not remember its previous result. Even if the underlying values have not changed, the function will still run again.

A computed property is cached. Vue tracks which reactive values it depends on and only recalculates when one of those values changes. If nothing changes, Vue reuses the previous result.

In small examples, the difference is not very noticeable. In larger components with complex logic or expensive calculations, computed makes your code more efficient and easier to reason about.

A simple rule that helps

When deciding between ref and computed, ask yourself one question:

Is this the source of truth, or is it derived from something else?

If it is the source of truth, use ref. If it is derived from other state, use computed.

This mental model is especially helpful if you come from a backend background where you already think in terms of data consistency and single sources of truth.

`computed` with getters and setters

Sometimes you want a computed property that can both read and update data. In that case, you can use a getter and a setter:

const fullName = computed<string>({
  get() {
    return `${firstName.value} ${lastName.value}`
  },
  set(value: string) {
    const parts = value.split(' ')
    firstName.value = parts[0]
    lastName.value = parts[1]
  }
})

Now you can assign a value directly:

fullName.value = 'Lou Creemers'

This is useful in forms where one input field represents multiple pieces of state.

TypeScript tips

When using Vue 3 with TypeScript, it is good to think about types early. TypeScript often already recognizes the type automatically:

const isVisible = ref(true)

But you can also define it explicitly:

const isVisible = ref<boolean>(true)

For computed, the return type is usually recognized automatically. If needed, you can define it:

const total = computed<number>(() => {
  return price.value * quantity.value
})

Being clear about types helps prevent subtle bugs, especially in larger projects or team environments.

Common mistakes

Here are some common mistakes that I've made dozens of times include:

Forgetting to use .value inside the script
Trying to change a computed property without defining a setter
using computed for something that should just be a normal constant.

If something is not updating in your template, the first thing to check is whether you are actually working with a reactive source.

That is a wrap

ref and computed are central parts of Vue 3’s reactivity model. Once you understand the difference between source state and derived state, your components become much easier to reason about. If you are building applications with Vue 3 and TypeScript, mastering these two concepts will give you a strong foundation for everything that follows.

If you have any questions or comments, feel free to reach out (louella.dev/socials) or leave a comment down below.

See ya!

Public Speaking at Tech Events 101: Being Uncomfortable Is Worth It

Lou Creemers — Tue, 10 Feb 2026 15:06:25 +0000

Hey lovely readers,

If you have been following this series from the start, you now know how to get started with speaking, how to apply to conferences, and how to prepare once you get accepted. You might have even stood on stage already, or you might be right at the point where you are thinking about submitting your first abstract. Either way, there is a very big chance you have already felt uncomfortable at some point in this process.

Your heart rate goes up, your hands feel shaky, and your brain suddenly starts questioning every decision that led you here. Maybe that happens right before you walk on stage, or maybe it happens much earlier, when you are staring at a submit button and wondering if you should really go through with it. This post is about that feeling, not about getting rid of it or pretending it does not exist, but about understanding it and learning why it might actually be a good sign.

Even “good speakers” feel weird before a talk

One of the most comforting things I learned after getting more involved in the speaker world is how many experienced speakers still struggle with the same things beginners do. Not just the people doing their first talk, but also the ones you see on big stages at well-known conferences. The difference is not that they do not feel it, but that they no longer see it as a reason to stop.

A lot of speakers that are 1000 times better than me at speaking openly talk about how they can barely eat breakfast or lunch on the day of their talk. Their stomach is upset, adrenaline takes over, and food just does not sound appealing at all until everything is done. Others mention that they delay working on their slides or demos until the last moment, even though they care deeply about their talk, simply because their brain refuses to fully engage until there is pressure. And almost all of them will admit that they are nervous in the minutes before they walk on stage, even after years of experience.

What matters is that these are also the same people who say they love public speaking. They keep submitting abstracts, they keep traveling, and they keep going back on stage again and again. Being nervous, procrastinating a bit, or not being able to eat beforehand does not mean you are bad at this. It means your body is reacting to something that matters to you.

Discomfort is not a warning sign

A lot of us grow up learning that discomfort is something to avoid. If something feels scary, awkward, or stressful, we assume it must be wrong or unsafe, and we look for ways to back out. That reaction makes sense in many situations, but public speaking is usually not one of them.

Standing on a stage, sharing your ideas, and letting people form opinions about your work is scary by nature. Your nervous system reacts because it thinks you are about to do something important and unpredictable, not because you are in danger. Feeling uncomfortable in that moment does not mean you are unprepared or incapable. More often, it simply means you care about doing a good job.

Your body knows before your brain does

That tight feeling in your chest before walking on stage, the restless energy while waiting to be introduced, or the sudden urge to back out even though you practiced and prepared are all very common reactions. Your body is responding before your brain has time to rationalize what is happening. It is not trying to sabotage you, it is trying to keep you alert.

Your brain, on the other hand, might start listing reasons why you should not be there. Someone else is more experienced, you might forget something, or someone might ask a question you cannot answer. In reality, your body is reacting to the importance of the moment, not to the outcome. Once you start seeing discomfort as a signal instead of a problem, it becomes much easier to move forward while feeling it.

Five uncomfortable minutes can change years

Most of the truly uncomfortable parts of speaking are surprisingly short. The walk to the stage, the introduction, and the first few minutes where your voice might shake and your thoughts feel scattered are often the hardest part. After that, something usually shifts and you settle into your rhythm. That’s also why you should practice the beginning more often than the rest.

Those first minutes can feel intense, but they are nothing compared to what can come out of them. Speaking can lead to opportunities like traveling to places you might never have visited otherwise, meeting some very smart and generous people, getting invited to share knowledge you already care about, or being offered jobs and freelance work because someone saw you speak. None of those things happen without those uncomfortable moments at the start.

Confidence is not a prerequisite

One of the biggest misconceptions about public speaking is that you need to feel confident before you start. In reality, confidence is something that slowly builds because you keep showing up, even when it feels uncomfortable. You do not wait for confidence and then act, you act and let confidence catch up later.

You are allowed to be nervous, to doubt yourself, and to feel like you do not fully belong yet. You can still submit the abstract, accept the talk, and walk on stage anyway. Every time you do, you show yourself that you can survive the discomfort, and that is where confidence comes from.

Loving speaking and being nervous can exist at the same time

This is something I wish more people talked about openly. You can genuinely love public speaking and still feel nervous before every session. You can enjoy being on stage and still struggle to eat beforehand, or procrastinate on slides until the deadline is uncomfortably close.

These things do not cancel each other out. They are simply different ways your body and brain deal with adrenaline, pressure, and expectations.

A small reminder before you click submit

If you are reading this while hovering over a submit button, of a Call for Papers or wondering if you are really ready, it helps to remember that discomfort is not a stop sign. More often, it is a sign that you care about the stuff you put out to people. Feeling uncomfortable does not mean you should wait, it usually means you are growing.

Five uncomfortable minutes are a very small price to pay for the experiences, connections, and confidence that can follow. You do not need to get rid of the discomfort to move forward. You just need to decide that it is not in charge.

That is a wrap

Public speaking will probably always come with some level of discomfort, even after years of experience and many talks. If it matters to you, your body will react, and that is completely normal. Feeling uncomfortable does not mean you are failing, it means you are paying attention.

Thanks for reading! If you want to share anything or have any questions, feel free to leave a comment or reach out on my socials.

Why Blogging Still Matters in the Age of AI

Lou Creemers — Sun, 28 Dec 2025 20:07:56 +0000

Hi lovely readers,

If you’ve ever thought about starting a blog but stopped because “no one reads blogs anymore,” you’re not alone. With AI changing how people consume content, it’s easy to assume blogging has lost its value. I started blogging in 2021, and since then I’ve published 45 posts, with my most read one reaching 40 thousand views. That experience has shown me that blogging is still incredibly important and worth pursuing today. Here’s why.

For yourself

We only save a limited amount of information every day in our heads. In my case, that limit is very noticeable. My brain often feels like a strainer. All my loved ones know that if they want me to remember something, they need to write it down for me. Telling me while I am doing something else guarantees I will forget it within minutes.

I sometimes get the opportunity to talk to some of the smartest people in the tech field. People who know far more about the subject than I ever will, and that is completely fine. What frustrates me is when someone explains something clearly, and five minutes later I realize I have already forgotten most of it.

That is where writing things down becomes important. Whether it is a reminder, a to do list, or a personal knowledge base, writing forces you to slow down and think about what you just learned. Instead of just listening and moving on, you actively process the information.

Writing things down also helps with memory. When you put something into your own words, your brain has to revisit the concept instead of letting it fade away. Writing on paper is generally better for remembering the concept, but writing a blog post is a great alternative. You can even start on paper and later turn it into a digital blog post.

Over time, your blog becomes a manual for your future self. You will forget things, especially technical details. Having blog posts that you wrote yourself means you always have an explanation that already made sense to you once. Often these posts include examples, demos, or code snippets that you can reuse or quickly understand again.

Another benefit is language development, especially if English is not your first language. My native language is Dutch, and during university my teachers often pointed out how I would lose my train of thought halfway through a sentence. Writing technical blog posts in a non-native language takes time and effort, but that effort adds up. I now notice awkward sentences much faster and make far fewer grammar mistakes than I did in 2021. That improvement also carries over into my work life, where clear written communication through Slack, Teams, or email is essential in an international environment.

For others

If you learn something interesting or feel genuinely excited about a topic, sharing it can help others while trying to understand it or practicing it yourself.

When I started blogging, I was still in university. By spending a lot of time on Twitter, I slowly realized that going to university is not something everyone has access to. In many countries, studying is extremely expensive. Others choose not to pursue it because of family responsibilities or personal circumstances. Meanwhile, I was 22, living in a country where university cost around 2500 euros a year, and I was learning a lot of genuinely interesting things.

That realization became a big motivator for me. Besides all the personal benefits blogging gave me, it felt good to share knowledge that I had easy access to. I would go to class, take notes on my laptop or on paper, put everything into Notion, and then turn those notes into a blog post or sometimes a short series of tweets if I felt it could be useful to others.

I still do this today. I learn from public speakers at conferences, from colleagues, and even from students I teach who are deeply interested in topics I know very little about. Someone mentions a concept or explains something new to me, and I write it down so I can explore it further later.

Some of those notes stay in Notion forever. Others turn into blog posts. Either way, writing and sharing creates a way to pass knowledge forward. AI is not always reliable for this yet. A concept might be too new for it to know about, it might hallucinate features or solutions, or it might explain something in a way that simply does not click for people. That is where you can make a real difference.

For your career

Blogging also plays a role in your career, even if that is not the reason you started in the first place.

When you write blog posts, you are not just sharing knowledge. You are showing how you think. You show how you break down problems, how you explain concepts, and what you find important enough to spend time on. That is very different from listing skills on a CV or LinkedIn profile.

A blog gives context to your experience. It shows what you actually do with the tools and technologies you work with. Someone reading your post can see how deep you go, how you approach learning something new, and how you communicate technical ideas.

Another important part is visibility. Your work normally stays within your team or your company. A blog moves that work into the open. People outside your immediate circle can find it, learn from it, and form an opinion of you long before you ever speak to them.

This can lead to opportunities you did not actively chase. Conversations start more easily when someone already knows what you’re interested in and what you know. Sometimes people reach out because a post helped them. Sometimes it becomes a reference point during an interview or a collaboration. None of this is guaranteed, but it is something you would not have without blogging.

For me, blogging never felt like a career strategy. It felt like documenting what I was learning. Over time, it simply became part of how I work and how I grow. And that visibility is something that helps just as much as the knowledge itself.

Your keystrokes are precious

Once you start working in a team and someone asks you to explain something over text, you usually have two options. One is writing a long Teams or Slack message that only one or two people will ever read. The other is writing a blog post so that many people can benefit from the same amount of effort.

At that point, it is worth asking yourself whether those keystrokes are really worth your time and energy.

I first learned about this idea in 2024 when Scott Hanselman spoke at a meetup near me. He mentioned his website keysleft.com and his blog post Do they deserve the gift of your keystrokes. One quote from that post really stuck with me:

If you email someone one on one, you are reaching that one person.

If you blog about it, or update a wiki or something similar, your keystrokes travel farther and reach more people.

You only have so many hours in the day.

That idea is absolutely true. Why put the same amount of effort into a one to one message when you can help more people with that same effort. Writing a blog post forces you to think more clearly about the concept, allows you to reuse it later, and gives future colleagues or random people on the internet something useful to learn from.

I do this for students as well. In their first year, my students have to learn PyGame and Python Flask. Instead of explaining the same concepts from scratch every year, I wrote blog posts like How to Build Your First Python Game: A Step-by-Step Guide to Creating a Simple Shooter with PyGame and Build a To-Do List App Using Python Flask, Jinja2, and SQL. They also struggled with topics like SSH keys and Git Tags, so I wrote blog posts on those as well. All of these blog posts are public. I need to explain these concepts every year anyway, so it makes sense to put them online where they can help more than just one group of students.

The work stays the same. The reach does not.

That’s a wrap!

Blogging does not have to be about algorithms, monetization, or chasing numbers. At its core, it is about learning, documenting, and sharing in a way that works for you. It helps you remember what you learn, makes knowledge more accessible for others, and allows your effort to reach further than a single message or conversation ever could.

You do not need a big audience to start. You do not need a perfect writing style or a niche figured out from day one. What matters is that you write things down, in your own words, and put them somewhere you can come back to later. Everything else grows from there.

If you have been on the fence about starting a blog, I hope this gave you a different perspective. And if you already have one, maybe this is your sign to keep going.

If you have thoughts, questions, or experiences you would like to share, feel free to leave a comment under this post or reach out to me on my socials. I am always happy to talk about blogging, learning in public, and all things tech.

Public Speaking at Tech Events 101: From Acceptance to the Stage

Lou Creemers — Mon, 22 Dec 2025 19:39:00 +0000

Hey lovely readers,

So you submitted your abstract, refreshed your inbox a little too often, and got the email you were hoping for. You have been accepted. That is exciting, and also a tiny bit terrifying, because now it is real.

I remember being afraid to click the confirmation button for the first time. It felt like I was signing a contract I might not be ready for. That feeling passed quickly, but I still remember the moment.

If you are new here, this post is part 2 of a series about getting into public speaking. In part 1, I talked about how to get started, how to write talk abstracts, how to use Sessionize, and how to apply to meetups and conferences.

If you already read part 1, welcome back. This is the next step.

In this part, we will go through what happens after the “yes”: what to check right away, how to plan your prep time, how to build slides and demos in a way that makes you feel comfortable on stage, and what to do on the actual day of the event so you can focus on having fun instead of feeling stressed.

Table of content

I’ve been accepted, now what?
Confirm the details
Plan it out
Make a rough sketch
Presentation
Demo Code
Prepare, prepare, prepare
The fun part: the event
- Planning your trip
- Just before leaving the house
- The night before your session
- Waking up
- At the event
- Just before your talk
- After your talk
Other questions answered that I could not put anywhere else
- Do I need a new talk for every event?
- Do speakers get paid?
- What if my demo fails during the talk?
- How do I deal with nerves or stage fright?
- How do I grow visibility as a speaker?
That’s a wrap!

I’ve been accepted, now what?

Have you been accepted to your very first conference or meetup talk? Congratulations, now the real work begins.

Confirm the details

When your session is accepted for a conference through Sessionize, you will receive an email with the subject “[Session title] has been accepted” with an email from the organizer and a confirmation button. Once you receive this email, immediately check the event date in your calendar to make sure you are not double booked.

Take a moment to read through the email carefully and make sure you understand what is expected from you. Things to double check include:

The exact length of your session
Whether there is time reserved for Q&A
If the session will be recorded and shared publicly
How travel and hotel arrangements work, or how reimbursement is handled

If anything is unclear, reach out to the organizing team and ask. It is completely normal to have questions, especially for your first conference. Most confirmation emails include a contact email address for the organizers, and they are usually happy to clarify things early rather than deal with confusion later.

If you think you have a clear vision of what they expect of you, feel free to click ‘confirm participation’. This way the organizer knows that you’ve confirmed too.

Plan it out

Sometimes you will be accepted 8 months before the conference or event takes place. Sometimes it will be only 2 months beforehand. You need to think about when you are going to make time to build your talk, prepare a demo, and practice. Try to do this when your mind has the most energy. If you are a night person, try working on it after regular work hours. If you are a morning person, prepare before your day starts.

How long it takes to finish your talk is really up to you. Did you promise demos in your abstract? Then you will have to code something. Just a presentation? In theory, that should take less time. It also depends on your time slot. A 20-minute talk takes less time to prepare than a 60-minute talk.

Make a rough sketch

Begin with a rough sketch. Read your abstract again to see what you promised, and decide what you want to talk about and for how long. AI can help with this part if you need some outlining. You usually start with an intro, then a bit of information about yourself and how you got interested in the topic. Then you add some background information on what people need to know before the talk starts, then the actual talk itself, a demo, and finally a conclusion with resources and your socials.

What you actually talk about depends on your topic. Keep in mind that you usually talk faster when you are nervous, and if the conference wants you to do Q&A at the end, keep 5 to 10 minutes available for that as well.

Presentation

Your presentation should not do the talking for you. Use it to explain things and to support your story. Do not put long sentences in your slides. Try to have a maximum of six items on a slide, such as bullet points or images.

Keep in mind accessibility and visibility. Use images that look good on small screens and large screens. Use code snippets and text with enough contrast and make sure the font size is big enough. If you use videos, be sure they have subtitles. Many conferences put talks online, so be careful with copyright for videos, images, and music.

Go through your rough sketch and make slides that fit your style or vision. Most likely, you already have an idea of what they should look like. Everyone has their own way of creating presentations, so I will not tell you exactly what yours should look like.

If you are having a hard time deciding which tool to use, a lot of people use PowerPoint or Google Slides. If you prefer making slides from code, check out Slidev

Demo Code

You should prepare your demo code well before your talk and have backups ready. If I am live coding, I always have a fully working project as well as video recordings as a backup. I also have a brand-new or halfway-finished project that I can start building on stage. In the past, I had a project that I wanted to create live on stage, until something in my project template suddenly decided to update. Do not let that be you. Be prepared for the unexpected.

Also have code snippets ready. If you need to type a big chunk of code, you might forget something due to adrenaline or the noise of the room. If you use a JetBrains IDE like I do, you can use live templates, where you can add code snippets and use them with just a shortcut name and a press of the Tab key.

Prepare, prepare, prepare

Before you leave your house to go to the event, rehearse your presentation and your code until you feel comfortable. Time it, and see where you need to add or remove slides. Keep in mind that you will talk faster under pressure, and try not to wander off in your story.

Once you think you are 80 percent done, present it to something or somebody. Preferably a real person. Even if they do not know what you are talking about, ask them to focus on your timing, filler words you repeat a lot, and how often you say “uh.” Knowing they are listening for these things will help you improve.

If you don’t have anybody near you, then record yourself. Once you’re done giving your talk in front of the camera, you’re going to watch and listen to it separately. For listening, turn your screen around so that you can’t see the video and just listen. See where the ‘uh’ moments and filler words are. For viewing, turn off your sound and just watch what you do with your body posture and with your hands.

Are you using those hands too little or too much? are you saying ‘uh’ a lot in a certain part of the talk? Are you sloughed over? Notice what you would like to do better, focus on that when you record yourself again and only rehearse the bits you were unhappy with, especially when it’s a longer (45 minutes or more) talk.

If you feel fully comfortable with your talk, you can decide to only rehearse the first few minutes of your talk. Starting is always the hardest part. Once you get past that first hurdle, your brain will take over if you have practiced the full talk a few times.

The fun part: the event

What are you going to do just before you arrive at the event? What are you going to do while you are there? Here are the ins and outs.

Planning your trip

Normally, when you are accepted to a conference that pays for your travel, there are two possible ways they will handle it. They might have a travel agent who will contact you and book your plane ticket, or you might book the ticket yourself and they will reimburse you after the conference. In most cases, the ticket will be an economy seat without checked luggage, so do not pack too heavy.

Also keep in mind that the evening before the conference, there is usually a “speaker dinner.” This is a dinner with all the speakers, where you can network and enjoy some local food near the hotel where the rooms were booked. It is great fun, so I recommend booking a flight that arrives at least a couple of hours before dinner time.

Just before leaving the house

Make sure you have your laptop with your slides and code on it. Also have a backup on the cloud or on GitHub, just in case. If you have a laptop without an HDMI port, bring an USB-C to HDMI adapter. If you need internet for your session, consider bringing an USB-C to ethernet adapter as well. Finally, take your laptop charger and a presentation clicker if you have one.

The night before your session

During dinner and the night after, try to stay away from too much alcohol. Speakers really love to drink after or before conference days. However, having a hangover during your talk, especially with bright lights on stage, is not fun. Eat enough so that you sleep well, and do not stay up too late if your talk is early.

Rest before your talk is very important for your memory, patience, and focus the next day. Try to get the amount of sleep you normally need.

Waking up

Do your usual morning routine and eat breakfast like you normally do. After that, rehearse your talk a couple of times, either completely or partially, just before leaving for the venue.

At the event

If you are speaking at a meetup, try to be there early and stay for a while if there are other speakers that day. People at meetups really appreciate it if you stay a bit longer for drinks, to have a conversation about your talk or to ask additional questions.

If it is a multi-day event, it is important to spend some time at the venue before and after your talk. Organizers put in a lot of effort to make the event comfortable for you, often with a speaker room where only speakers are allowed to relax, work, or chat without the busy conference noise. Walk around and talk to attendees, other speakers and sponsors. You can learn a lot from people who are interested in the same topics and it is a great way to connect.

Also, if it feels like it would help your nerves, go check out the room you’ll be speaking in.

Just before your talk

This is usually the moment where my nerves peak. Everything is ready, there is nothing left to change, and my brain suddenly wants to change everything anyway. But trust me, you’ll be fine.

Open your laptop and check your slides one more time. Close all software that you do not need. Double-check that Slack, Teams, Discord, or anything similar is not open, and keep your slides ready.

If you are showing code in an IDE, switch your IDE theme to light mode because it is easier to see on screens. Increase the font size for the IDE and the terminal. JetBrains IDEs have a presentation mode built in that works very well once you learn how to use it.

If you’re at a bigger event, also be prepared to get a microphone attached to a headband from somebody. You will need space in one of your pockets for the sender.

After your talk

You just gave your (first) talk. Congratulations! Do you want to do more? If so, write down what went well and what did not. That way, you can improve your presentation or demo if you give it again at another event.

Some events collect feedback from attendees. Some give you that feedback automatically. Others give it to you only if you ask. I still find negative, unhelpful feedback difficult to deal with, so I do not request feedback forms. But positive feedback and constructive criticism can be incredibly helpful, so if you want those forms, ask someone on the event team.

That’s a wrap!

Getting accepted is a big step, but it is only the beginning of the journey. Preparing your talk, dealing with nerves, and standing on stage are all part of learning how public speaking really works. Every single talk will teach you something new, about your content, your timing, and yourself.

Do not aim for perfection. Aim for feeling prepared and confident enough to enjoy the moment. Your slides do not have to be perfect, your demo does not have to be flawless, and you do not need to sound like a professional keynote speaker. What matters is that you show up, share your knowledge, and do your best.

If this is your very first accepted talk, take a moment to be proud of yourself. Enjoy the experience, talk to people, and learn from other speakers. If you have done this before, you already know that every event feels different, and that is part of what makes speaking interesting and fun.

Public speaking is something you grow into over time. With every talk, it gets a little easier, a little more comfortable, and a lot more rewarding.

If you have questions, experiences to share, or things you are unsure about, feel free to leave a comment under this post. You can also find me on my socials if you would rather reach out there.