DEV Community: Lou Creemers

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.

Modern C# Development: Custom Exceptions Made Simple

Lou Creemers — Sat, 20 Dec 2025 21:00:13 +0000

Hi lovely readers,

Errors happen. Sometimes they are simple, and sometimes they are very specific to your domain. C# gives us many built in exceptions, but they do not always tell the full story. That is where custom exceptions come in.

In this post, we are going to look at how to create your own custom exceptions in C#. We will keep it simple, practical, and easy to use in real projects.

Why custom exceptions exist

Imagine you are building an ordering system. A user tries to place an order, but the business rules say no. You could throw something like this:

throw new InvalidOperationException("User cannot place this order");

This works, but it does not say much. Later on, when you read logs or handle errors, you have to rely on the message string.

Now compare it to this:

throw new OrderNotAllowedException(userId);

This tells a clear story. Something specific went wrong, and it belongs to your domain.

Creating a basic custom exception

A custom exception is just a class that inherits from Exception.

Here is the smallest useful version:

public class OrderNotAllowedException : Exception
{
    public OrderNotAllowedException(string message)
        : base(message)
    {
    }
}

That is all you need to get started.

Adding useful information

The real power of custom exceptions comes from adding context. Instead of putting everything into the message, you can add properties.

public class OrderNotAllowedException : Exception
{
    public Guid UserId { get; }

    public OrderNotAllowedException(Guid userId)
        : base($"User {userId} is not allowed to place an order")
    {
        UserId = userId;
    }
}

Now your logs and error handlers can access UserId directly. No string parsing needed.

Do you need serialization constructors

In older .NET versions (.NET Framework 4.x and earlier), you often saw extra constructors for serialization. If you are using a modern version of .NET, a simple exception class like the ones above is enough.

When not to create custom exceptions

Custom exceptions are useful, but they are easy to overuse.

Try to avoid these situations:

Using exceptions for normal control flow
Creating very generic custom exceptions that add no value
Exposing internal exception details from public APIs

If a built in exception already describes the problem well, use it.

A quick checklist

Before creating a custom exception, ask yourself:

Does this represent a real exceptional case
Does it add meaning beyond a message string
Does the name clearly describe the problem

If the answer is yes, a custom exception is a good fit.

That is a wrap

Custom exceptions are a small feature, but they can make your code much clearer and easier to maintain. Used well, they tell a story about what went wrong and why.

I hope this post gave you a quick introduction to creating your own exceptions in C#. If you have thoughts or questions, feel free to leave a comment or find me on my socials.

See ya!

Public Speaking at Tech Events 101: How to Start Your Speaker Journey

Lou Creemers — Mon, 15 Dec 2025 16:51:58 +0000

Hey lovely readers,

If you don’t know me, I’m Lou, and I’ve been public speaking for over 3 years now internationally, giving about 10 speaker sessions a year. But if you're just starting, you might be wondering: how do you get to speak on big stages? Do you need a completely new talk every time? And what about getting paid?

Some speakers have a big following on Twitter (X) or YouTube, or they work for companies like Microsoft or Apple, so getting a spot at big conferences is easier for them. For the rest of us, it takes a bit more effort, and a lot more applications.

Let's dive in and figure it out together. I'll break down how I got started, answer your questions, and share all the practical tips and advice of things I’ve learned over the years.

Table of content

How to get started
Creating your first session
- Brainstorm
- Talk abstract
- Talk title
- Speaker bio
- Picture
- Getting inspired
Getting on Sessionize
- Sessions
- Public Profile
Finding Conferences
- What to keep in mind
- Finding conferences

How to get started

I got started with speaking just after COVID because I was super active on Twitter, and got invited to talk at WeAreDevelopers Congress that has about 15,000 attendees every year. It was an awesome experience, but I’d never suggest doing your first tech talk in a country where you don’t speak the native language, especially in a packed room of 500 people.

Instead, start small. Practice in a more relaxed setting, like local meetups. Unless you live in the middle of nowhere, there’s probably a group near you. Attend a few events, watch how speakers handle their flow, gestures, and tone.

Maybe even more important, get to know the organizers. Ask them what inspired them to start the group, and when/if you feel comfortable, mention that you’d love to speak too. Since many meetups host events 6 to 12 times a year, chances are they’ll welcome you with open arms. Don’t stress too much about having the perfect session; everyone starts somewhere. Even if your first talk isn’t flawless, most people won’t remember the rough spots for long.

To find local meetups, head over to meetup.com, look up the biggest city near you as the location, and filter by category “Technology” with event type set to “In person.”

Creating your first session

Did the meetup organizers say yes to you speaking at their event, or did you find another event for your debut talk? That’s awesome!

Most events will need three things from you: a talk abstract, a speaker bio, and a picture of you.

Brainstorm

Of course, the first thing that you’ll do is brainstorm what you actually want to talk about. What is your favorite tech stack? Are there any new features in your favorite coding language that you want to learn more about? Did you learn something really interesting while working on an open source project? Is there something that developers do that you think could be done better?

Think about these kinds of things and make a short list for yourself. Don’t worry if the topic sounds ‘too beginner’ to you. In my experience, the ‘introductory’ level sessions are the ones that fill up rooms the quickest.

Talk abstract

Now that you have some ideas in mind, you’re going to write an abstract for a couple of them. Talk abstracts explain what you'll cover during your session. It lets attendees know what they'll learn and helps organizers decide which sessions to include in their schedule if they have multiple sessions to choose from.

Everyone has their own style for writing abstracts. Here’s my approach:

First paragraph: Grab attention with a question or a bold statement (e.g., “Does X annoy you?”, “Imagine a world where Y is possible,” or “Have you ever wondered about W?”).
Second paragraph: Give a brief introduction to the tech or topic you’re discussing.
Third paragraph: Explain what the audience will learn and how, maybe through live coding demos or interactive examples.
Final paragraph: End with a call to action (e.g., “Join me if you want to solve X once and for all” or “Attend this session to dive deep into Y”).

Here’s an example abstract that I’ve written about rubber duck debugging:

“Do you ever get stuck on a bug and wonder if a simple chat could solve it? Imagine if your trusty rubber duck could help you solve those coding challenges.

In this session, we’re diving into rubber duck debugging, a silly, yet super effective way to troubleshoot your code. I’ll share how talking through your problems with a rubber duck can reveal hidden issues and helps you find fresh insights.

You’ll see live demos where I break down the debugging process, show real-world examples, and explain how this simple method can save you time and frustration. Join me, grab a rubber duck, and let’s turn this fun technique into your solution for cleaner, more efficient code.”

The most important thing to note here is not to let AI generate full talk abstracts for you. If you’re sending this in for a conference, these people will notice that it’s AI-generated within seconds and decline your session. Use AI for inspiration for the structure of your talk abstract, let it help you with grammatical errors, but do not let it take over the abstract completely.

Talk title

Now that you have your abstract, you need to come up with an attention-grabbing title. I normally always format it like this [Core idea] : [Short phrase to explain the session]. A couple of examples of of talk titles I use:

Modern C# : A Dive into the Community's Most Loved New Features.
Azure functions: From Zero to Hero.
Minimal APIs vs Controller-Based APIs: Finding the Best Fit for Your .NET Projects.

If I had to come up with a talk about rubber duck debugging. It would probably be something like “Let’s go rubber ducking: How a little duck can help you solve coding challenges”

I often let AI come up with a list of ideas and then mix and match until I find something that I’m happy with. Also, notice that every single one of them is in title case? That makes it look more professional. Some websites can help you with transforming text into title case, like this title case converter website.

Speaker bio

The speaker bio is just the introduction to who you are, so that the attendees have an idea of who they’re listening to and what your experience level is like.

Speaker bios must be short, to the point, informative, and written in third person.

Here’s an example of a format that I would recommend:
”[First name] [Last name] is a [career title], with a passion for [whatever tech you’re interested in]. While working in tech, they really enjoyed working on [whatever project you’re proud of].

Apart from being a [career title], they love to share knowledge about [topics you want to talk about].”

Of course, feel free to add hobbies that might be interesting, events you might organize or are part of, volunteer work, awards you have, information about content creation, etc. Most importantly, keep it short and to the point.

Picture

For speaker pictures, the same rules count as pictures on LinkedIn. It should be a professional-looking picture, no obvious selfies, no group picture cutout. And your face should be clearly visible, also as a small profile picture format on a phone, for example.

Getting inspired

Do you need more inspiration for your speaker bio or talk abstracts? Take a look at my GitHub repository: https://github.com/lovelacecoding/awesome-sessionize-profiles

Getting on Sessionize

If you want to get into conferences or bigger meetups, you will need a Sessionize account. Sessionize is the biggest platform for public speakers. You can put all your talk abstracts on here and your speaker bio, and easily apply those to multiple conferences.

If you go to Sessionize.com, you will be greeted by this homepage:

As a speaker, you can click on ‘Try For Free’ and choose a way to start your account. I would advise using ‘Classic login’ in case you want to get rid of your social media accounts at some point. Most importantly, pick an email address that you check quite often.

Once you’ve done that, Sessionize will ask you for a picture and a speaker bio. You already made those if you followed this blog post, so add them in there.

Once you have everything filled out on your account, your overview will look something like this:

Sessions

On the sidebar, there’s a ‘Sessions’ tab.

On the session tab, you can add a session by clicking the “Add Session” button. You can also edit, archive, or delete sessions on there once you’ve added some sessions later on.

Click on “Add Session” and add those sessions you’ve written abstracts for earlier.

Once added, you will see it appear under ‘Active Sessions’ and later it will also show you at which conferences you submitted it for.

Public Profile

If you click on ‘Your Public Profile’ in the sidebar, it will take you to your public profile page.

This page is what other people see if they visit your Sessionize account through an abstract submission or through a search engine like Google.

Your sessions, where you selected 'Show in my public profile' in the Session tab while adding it, show up here, as well as your speaker bio, and your profile picture. You can add a banner and socials in here as well.

This is my public account. Keep in mind that you will not get the ‘Most Active Speaker’ badge and/or the Microsoft MVP badge. Those are both because I’ve been public speaking a lot. You will not have any badges starting out.

Finding Conferences

So you’ve given a couple of sessions at meetups now, and now you want to try bigger stages or get out there internationally. There are a lot of conferences every year for every possible tech stack. Some are huge (up to 20k attendees), while some are smaller (200 attendees). Some are close by (car distance) and some are far away (12 hours by plane). Some are online, while others are offline. In this chapter, I’ll help you find conferences, apply, and hopefully get approved.

What to keep in mind

There are a lot of conferences for lots of different developers, to filter out some of these conferences there are some things you have to decide for yourself:

Most conferences will pay for you to fly over and stay in a hotel near the conference if you’re speaking at their event, but not all of them do. Are you willing and able to pay for your own stay and/or travel?
There are conferences around the world, so how far away are you willing or able to travel?
There are online and offline conferences. Do you feel comfortable giving a talk in front of just a webcam, or do you only want to do an offline audience?
There’s always a timeslot. When starting, it’s important to decide if you feel comfortable giving longer sessions. Are you okay with 60-minute talks, or do you only feel comfortable with 15-20 minutes

The more flexible you are, the more places you can apply to. However, keep in mind what you’re comfortable with and what your boundaries are. I only did talks up to 30 minutes for well over a year, just because 60 minutes sounded intimidating to me. Personally, I also would never talk at a conference that makes its attendees pay for a ticket but is not willing to pay for at least my hotel. But those are my boundaries; you should decide what works for you.

Finding conferences

Once you've made those decisions for yourself. The first way to find conferences is through Sessionize itself. If you look at the sidebar, you will see a ‘Discover events’ tab.

In here, you can find conferences or meetups that fit your interests that are open to receiving applications. If you click on one of the conferences, you can find info like their location, the date, what kind of sessions they are looking for, and if they pay for travel and / or the stay.

Not every conference has a submission page on Sessionize. If you want to see what else is out there, I recommend taking a look at the following websites:
https://cfp.watch/
https://nexttechevent.com/

Decide what you want to talk about

Every conference has different tracks and different kinds of developers attending. You need to keep this in mind before you apply. Of course, you’ve already decided what kind of timeslots you feel comfortable with, and what kind of financial compensation you expect, so that’s the first thing you look at. If that's all what you expect it to be, you select the session abstract that you want to submit with.

You can apply with the abstracts you just added to your sessions page by selecting 'session from your speaker profile' and then selecting the abstract you want to apply with in the dropdown.

Put some time and effort into putting it on the correct track, and make sure it fits the conference. Don’t submit .NET talks for a Java conference. Don’t try to submit with Python talks if it’s an Azure conference unless it’s Python with a bit of Azure. Altering an existing abstract to fit a conference more (I changed a talk from React to VueJS before for a VueJS conference) is totally fine.

Keep in mind not to spam conferences with session abstracts unless they explicitly say otherwise. I have had conversations with conference organizers who mentioned that some people apply with 10 or more abstracts. In those cases, they are often automatically rejected because it comes across as spamming. Giving program committees options is great, but three to four abstracts is usually the sweet spot.

Some other tips

There are some other things I’ve learned over the years that can help with applying. The first thing is to look at the schedule of the event last year, look at what kind of talks were selected a lot, and let that decide what abstract you’re going to apply with. You can pick an abstract similar to what was very popular last year, or pick something that you haven’t seen at all yet in their schedule.

Another tip is to always leave a supportive note or extra comments for the conference organizers to look at if that option is available. Very often when you apply, there’s an ‘additional notes’ section at the very bottom that only organizers can see.

Tell them, ‘best of luck with selecting the best sessions’ for some extra support. Tell them that you've been to this conference before as an attendee if that's the case. Add a link with recordings, demos, blogs, or slides for them to look at what you’ve done before. Program committees do hard work, checking and rating a lot of abstracts, so a nice comment or extra information for them to make good informed decisions, is really appreciated.

Dealing with rejection

Some conferences will never tell you whether you were accepted or rejected, and you will figure it out through their speaker page on their website. Others will reject you multiple times in a row. Getting into the speaker world is not easy, especially when you start applying internationally. That is why starting with local meetups is such a good first step.

Even if you've done meetups, getting accepted to conferences is, and always will be, difficult. Most of the time you will be rejected, sometimes close to every submission you send out, and that is normal. It is something every speaker has to get used to.

There are many reasons for rejection that have nothing to do with you. A conference might already have too many talks on the same topic, your session might not fit the focus of that specific edition, or it might simply come down to limited slots and tough choices.

It is not personal. Keep applying, keep refining your abstracts, and keep going.

That’s a wrap!

Now you know how to write abstracts, how to find conferences, how to apply to conferences, and how to deal with rejections.

In part 2, I will talk about what happens after you get accepted. We will look at preparing your talk and demos, dealing with nerves, and what the actual day of the event looks like.

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.

Modern C# Development: User Defined Increment and decrement

Lou Creemers — Sat, 22 Nov 2025 21:37:51 +0000

Hi lovely readers,

C# 14 just arrived with .NET 10, and it brings a fun little feature that makes custom types feel even more like built in ones. You can now decide what happens when someone writes myValue++ or myValue-- on your type.

This was possible before, but only with static methods that returned a new instance. C# 14 adds a new way to do it. You can now write instance operators that update the object directly. It is simple, it is clean, and it can help performance too.

In this post, we are going to take a friendly look at this feature and how you can try it out. Keep in mind that you need to have .NET 1- installed in order to test this out.

What this feature gives you

If you have ever created a numeric style type, you probably have used ++ to increment the number by one, or -- to decrement the number by one. Now you get to decide what these postfixes do, creating more freedom.

C# 14 still supports the classic static operator, but it also lets you write an instance version to change it for specific classes or structs like this:

public void operator ++()
{
    // Update this
}

and the same idea works for --.

A simple example

Imagine you have a small type that keeps track of a score. Maybe every time the score grows, it should go up by 2 instead of 1.

Here is how you can do that:

public struct Score
{
    public int Value { get; private set; }

    public Score(int value)
    {
        Value = value;
    }

    public void operator ++()
    {
        Value += 2;
    }

    public void operator --()
    {
        Value -= 2;
    }
}

Now you can write:

var score = new Score(10);
score++;
Console.WriteLine(score.Value); // 12

Nice and smooth.

What about `score++` inside expressions

When you write score++ alone, the instance operator works fine. But if you write something like:

var old = score++;

the compiler needs both the old value and the new one. For that, you also need the classic static operator.

Here is the complete version:

public struct Score
{
    public int Value { get; private set; }

    public Score(int value)
    {
        Value = value;
    }

    public void operator ++()
    {
        Value += 2;
    }

    public static Score operator ++(Score s)
    {
        return new Score(s.Value + 2);
    }
}

With both operators in place:

var score = new Score(10);
var old = score++;

Console.WriteLine(old.Value);   // 10
Console.WriteLine(score.Value); // 12

Prefix uses the instance operator. Postfix inside an expression uses the static one. The type now behaves just like built in ones.

Why this is nice

Better performance
The instance operator updates the value directly, so structs avoid extra copies.

Cleaner code
Your custom type feels more natural to work with.

Full control
You decide how your type increments or decrements.

That is a wrap

I hope this post helped you understand how user defined increment and decrement operators work in C# 14. If you give them a try, I would love to hear what you come up with. You can find me on almost every social platform at louella.dev/socials, or you can leave a comment below.

See ya!

New File-Based Apps in .NET 10: You Can Now Run C# in Just 1 File!

Lou Creemers — Mon, 17 Nov 2025 18:25:46 +0000

Hi lovely readers,

Sometimes you just need a quick script in the language you are most comfortable with, C# for example, but then you have to go through the hassle of creating a solution with a project and a bunch of extra files you probably do not need, just to run ten lines of code. Using C# for a small task has always felt like overkill.

.NET 10 now fixes this with file-based apps. It introduces a new lightweight execution model that lets you run a C# program contained in a single file with no project or solution setup at all.

In this blog post, we are going to take a look at file based apps and how to use them.

Why file-based apps

No project overhead

Write your C# code in one .cs file and run it directly. That is all you need. There is no .csproj file, no solution, and no boilerplate. This simplicity means you can get started right away when you want to build a quick tool or demo.
Great for prototyping and scripting

File-based apps are perfect for prototypes, one off console utilities, CI or CD scripts, or quick data processing tasks. Instead of creating a full project for a ten line script, you can just run a single file. It makes C# feel competitive with traditional scripting languages like PowerShell or Bash.
Full power of C# and .NET

You are still writing a real C# program. You get the strong type system, performance, LINQ, the full .NET libraries, and even NuGet packages. Nothing is limited just because you are using one file.
Full-on CLI support

This feature is built right into the .NET CLI. No extra tools or interpreters are required. Just run dotnet run <YourFile>.cs and the CLI takes care of the rest. On Unix like systems, you can even add a shebang so you can run your file like a regular script.
Easy to scale up

A file-based app is not something you will outgrow. If your single file script becomes something larger, the .NET 10 SDK includes a tool that converts it into a full project with a .csproj, keeping your package references and settings.

How to use file-based apps

Create and run a single file program

To get started, all you need is the .NET 10 SDK installed. You can install it from dotnet.microsoft.com. In whatever text editor or IDE you want write your code in a single C# file. You can use top-level statements that were introduced in the past so you don’t need a Main method.

For example, create a file called DiceThrow.cs:

// DiceThrow.cs
var rng = new Random();
int roll = rng.Next(1, 7);
Console.WriteLine($"You rolled a {roll}!");

Then open your terminal in the same folder and run:

dotnet run DiceThrow.cs

The CLI creates a temporary project in the cache, compiles your file, and runs it. The first run takes a moment, but after that it launches almost instantly.

Using NuGet packages with `#:package`

Sometimes you will need some extra help from a NuGet package. You can add those to your script too. If your script needs a NuGet package, you can add it at the top of your file.

For example, here is a script that uses Figgle to create ASCII art. Save it as ASCIIArt.cs:

#:package Figgle@0.6.5
#:package Figgle.Fonts@0.6.5

using Figgle;
using Figgle.Fonts;

Console.WriteLine(FiggleFonts.Standard.Render("Hello World"));

The version numbers after the at sign are required. If you are not sure which version to use, the NuGet Gallery page shows a ready to copy snippet under the File-Based Apps tab. For example, the Figgle NuGet Gallery page looks like this:

Running your C# file as a script on Unix

If you like the convenience of running scripts directly, you can add a shebang to the top of your file.

#!/usr/bin/env dotnet run
Console.WriteLine("Hello from shebang!");

Make it executable:

chmod +x Shebang.cs

And finally run it like this:

./Shebang.cs

It feels just like running any other script.

To keep in mind

Only one file is supported right now. Multi file support is coming in .NET 11.
These are compiled C# programs, not interpreted scripts.
You can debug your script in your IDE by opening the file and setting breakpoints.

That is a wrap

File-based apps in .NET 10 make C# feel more flexible and accessible for small tasks. You no longer have to switch to Python or Bash when you want to automate something quickly. Now you can stay in the language you love, with your favorite NuGet packages available right away.

I hope this post helped you understand file-based apps in modern C#. If you have any questions or comments, feel free to reach out on almost every social media platform (louella.dev/socials) or leave a comment down below.

See ya!

How to Create a Git Tag With Github

Lou Creemers — Wed, 05 Nov 2025 15:47:16 +0000

Hi lovely readers,

Have you ever made a new release of a project and wondered how to mark that version properly in Git? Maybe you heard about tags, or maybe someone told you to create one, but you were not sure how. The good news is that GitHub makes this very easy. You can create a Git tag directly from the GitHub web page, without using the command line.

In this guide, we will look at what a tag is, why you might use one, and how to create a tag on GitHub step by step.

If you like clean versioning, simple releases, or just want to keep your project organised, keep reading.

Why create a Git tag

Keep track of versions

A tag is like a label that points to a specific commit. When you release version 1.0, you probably want to tag it as v1.0.0 or something similar. This makes it easy to find the code for that version later.

Great for releases

Tags are often used when publishing release notes or downloadable builds. GitHub will even bundle your source code and make it available as a download.

Clear project history

With tags, you can quickly see when major versions were created. This helps you and your team understand the history of the code.

How to create a tag on GitHub

You can create a Git tag directly from the GitHub web interface. Here is how to do it.

1. Open your repository

Go to the GitHub repository where you want to create a tag. Make sure you are logged in and have the right access.

2. Go to Releases

At the right of the repository, Look for Releases.

Click Create a new release.

3. Choose or create a tag

At the top of the release form, you will see Choose a tag.

If the tag already exists, you can select it.
If you want a new tag, type a name like v1.0.0.
GitHub will show an option to Create new tag.

Click it.

4. Add release details (optional)

You can give your release a title and a description. Many people write a short changelog or a summary of what is new.

You can also upload files, such as compiled builds or release assets.

5. Publish

Click Publish release.
Your tag now exists in the repository.

Where to see your tags

Once you clicked Publish release the release page should pop up. In here you can download all your code as a ZIP or TAR.GZ and share it easily with others.

You can find the release page after closing on the right side of your repository page where you clicked create a new release just moments ago.

You can also fetch tags in Git:

git fetch --tags

Quick summary

Go to GitHub repository: Releases > Draft a new release > Type tag name
Tag a specific commit: Choose branch or commit in dropdown
Add release notes: Fill title and description

That is a wrap

Creating Git tags on GitHub is simple and clear. You do not need the command line at all. Tags help you mark important versions, share releases with users, and keep your project history organised.

I hope this guide helped you understand how to create a Git tag from the GitHub web page. If you have questions or comments, you can reach me on @lovelacecoding on most social media platforms, or leave a comment.

See ya!

Modern C# Development: Target-Typed `new`

Lou Creemers — Fri, 31 Oct 2025 13:07:25 +0000

Hi lovely readers,

Have you ever found yourself typing the same type name twice when creating an object in C#? For example Person person = new Person(); feels a little repetitive, doesn’t it?

Modern C# fixes this small annoyance with a simple but powerful feature called target-typed new. It helps you write cleaner, shorter, and more readable code while keeping everything strongly typed.

In this blog post, we are going to explore target-typed new, when to use it, and how it can make your code a little bit nicer to look at.

Does your application create a lot of objects? Do you like tidy syntax and less typing? Continue reading and I’ll show you how.

Why target-typed `new`

Cleaner code

Target-typed new lets the compiler infer the type from the context. You no longer have to repeat it.

   // Before
   Person person = new Person("Alice", 30);

   // Now
   Person person = new("Alice", 30);

The compiler already knows the type on the left side, so you can safely skip it on the right.

Works with fields and properties

You can use it for field or property initialization too.

   private readonly HttpClient _client = new();
   private List<string> _items = new();

Great for readability with long type names

It really shines when dealing with complex or generic types.

   Dictionary<string, List<int>> data = new();
   Queue<(int Id, string Name)> queue = new();

Still fully typed

This is not dynamic or weak typing. The compiler still checks everything, exactly like before.

How to use target-typed `new`

Target-typed new works whenever the compiler can infer the type of the object from context. That includes variable declarations, field initializers, property initializers, and even return statements.

Variable declarations

Person person = new("Bob", 25);
Car car = new("Tesla", "Model 3");

Properties and fields

public class Library
{
    public List<string> Books { get; } = new();
    private readonly HttpClient _client = new();
}

Return statements

When the method return type is known, you can use target-typed new in returns too.

static Point CreatePoint() => new(10, 20);

Limitations

Target-typed new only works when the compiler can clearly determine the type. If the type is ambiguous, you’ll get an error.

var item = new(); // ❌ Error: cannot infer the type

It also doesn’t work with anonymous types or cases where there’s no obvious target type.

Comparing `var` and target-typed `new`

Both var and target-typed new reduce repetition, but they do it differently.

Style	Example	How type is inferred
`var`	`var p = new Person("Alice");`	From the right-hand side
Target-typed `new`	`Person p = new("Alice");`	From the left-hand side

Use whichever makes the code clearer in that context. var is great when the type on the right is obvious. Target-typed new is better when you want to make the type explicit but avoid repeating it.

A few more examples

List<int> numbers = new() { 1, 2, 3, 4 };
CancellationTokenSource cts = new();
Tuple<int, string> pair = new(1, "hello");

Each of these lines is shorter, cleaner, and easier to scan.

That’s a wrap

Target-typed new helps remove small bits of repetition and keeps your codebase neat. It’s one of those small features that doesn’t change how C# works but makes writing and reading code more enjoyable.

Whether you’re defining data models, initializing services, or just cleaning up long generic types, target-typed new makes your code look modern and elegant.

I hope this post helped you understand target-typed new in modern C#. If you have any questions or comments, feel free to reach out on @lovelacecoding on pretty much every social media platform or leave a comment down below.

See ya!

DEV Community: Lou Creemers

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

What is actually changing?

What carries over and what does not?

From C# to Python

Should you still take AZ-204?

A bigger picture

That's a wrap!

AI Is Making English a Must-Have Skill for Developers

You are not writing code anymore, you are describing it

I learned this the hard way in my second language

Communication was always a huge part

Reading is half of the skill

Programming languages do not stop being important

How to actually get better at it

That's a wrap!

Vue Composition API: Computed and Ref Properties Explained

What is state?

State from a backend perspective

What are ref and computed in Vue 3?

ref as reactive state

ref with objects

Derived state and computed

computed vs a function

A simple rule that helps

computed with getters and setters

TypeScript tips

Common mistakes

That is a wrap

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

Even “good speakers” feel weird before a talk

Discomfort is not a warning sign

Your body knows before your brain does

Five uncomfortable minutes can change years

Confidence is not a prerequisite

Loving speaking and being nervous can exist at the same time

A small reminder before you click submit

That is a wrap

Why Blogging Still Matters in the Age of AI

For yourself

For others

For your career

Your keystrokes are precious

That’s a wrap!

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

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!

Modern C# Development: Custom Exceptions Made Simple

Why custom exceptions exist

Creating a basic custom exception

Adding useful information

Do you need serialization constructors

When not to create custom exceptions

A quick checklist

That is a wrap

Public Speaking at Tech Events 101: How to Start Your Speaker Journey

Table of content

How to get started

Creating your first session

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

`ref` as reactive state

`ref` with objects

Derived state and `computed`

`computed` vs a function

`computed` with getters and setters

What about `score++` inside expressions

Using NuGet packages with `#:package`

Why target-typed `new`

How to use target-typed `new`

Comparing `var` and target-typed `new`