Kristijan Kralj
@kristijankralj.bsky.social
Helping .NET developers master the latest tech and industry best practices.
90% of C# projects don’t need Kubernetes, microservices, or separate read/write DBs early on.
Start simple. Ship fast. Get feedback.
Then evolve.
This repo shows how:
github.com/evolutionary...
Simple scales. Complexity fails.
Start simple. Ship fast. Get feedback.
Then evolve.
This repo shows how:
github.com/evolutionary...
Simple scales. Complexity fails.
October 15, 2025 at 6:23 AM
90% of C# projects don’t need Kubernetes, microservices, or separate read/write DBs early on.
Start simple. Ship fast. Get feedback.
Then evolve.
This repo shows how:
github.com/evolutionary...
Simple scales. Complexity fails.
Start simple. Ship fast. Get feedback.
Then evolve.
This repo shows how:
github.com/evolutionary...
Simple scales. Complexity fails.
The hidden cost of "enterprise" .NET architecture:
Debugging hell.
13+ years in .NET, and I keep seeing this pattern:
Teams add layers to solve problems they don’t have.
Change one rule = go 5 layers deep.
Fix a bug = 7 files open.
Good abstractions hide complexity.
Bad ones ARE the complexity.
Debugging hell.
13+ years in .NET, and I keep seeing this pattern:
Teams add layers to solve problems they don’t have.
Change one rule = go 5 layers deep.
Fix a bug = 7 files open.
Good abstractions hide complexity.
Bad ones ARE the complexity.
October 14, 2025 at 6:02 AM
The hidden cost of "enterprise" .NET architecture:
Debugging hell.
13+ years in .NET, and I keep seeing this pattern:
Teams add layers to solve problems they don’t have.
Change one rule = go 5 layers deep.
Fix a bug = 7 files open.
Good abstractions hide complexity.
Bad ones ARE the complexity.
Debugging hell.
13+ years in .NET, and I keep seeing this pattern:
Teams add layers to solve problems they don’t have.
Change one rule = go 5 layers deep.
Fix a bug = 7 files open.
Good abstractions hide complexity.
Bad ones ARE the complexity.
Git merge be like:
August 9, 2025 at 6:11 AM
Git merge be like:
3 days of debugging can save you 5 minutes of reading documentation.
August 1, 2025 at 1:36 PM
3 days of debugging can save you 5 minutes of reading documentation.
.NET developers:
Want to avoid painful bugs, security holes, and spaghetti code?
Here are 10 silent killers I see over and over - even in "enterprise" apps:
#dotnet
Want to avoid painful bugs, security holes, and spaghetti code?
Here are 10 silent killers I see over and over - even in "enterprise" apps:
#dotnet
July 30, 2025 at 6:23 AM
.NET developers:
Want to avoid painful bugs, security holes, and spaghetti code?
Here are 10 silent killers I see over and over - even in "enterprise" apps:
#dotnet
Want to avoid painful bugs, security holes, and spaghetti code?
Here are 10 silent killers I see over and over - even in "enterprise" apps:
#dotnet
I used to think microservices were the modern way to start.
But they add pain early on:
– Debugging hell
– Infra overhead
– CI/CD complexity
Most apps don't need that upfront.
Start with (modular) monolith:
Clean boundaries, fast loops, easier debugging.
It's a launchpad. Not legacy.
#dotnet
But they add pain early on:
– Debugging hell
– Infra overhead
– CI/CD complexity
Most apps don't need that upfront.
Start with (modular) monolith:
Clean boundaries, fast loops, easier debugging.
It's a launchpad. Not legacy.
#dotnet
July 29, 2025 at 6:10 AM
I used to think microservices were the modern way to start.
But they add pain early on:
– Debugging hell
– Infra overhead
– CI/CD complexity
Most apps don't need that upfront.
Start with (modular) monolith:
Clean boundaries, fast loops, easier debugging.
It's a launchpad. Not legacy.
#dotnet
But they add pain early on:
– Debugging hell
– Infra overhead
– CI/CD complexity
Most apps don't need that upfront.
Start with (modular) monolith:
Clean boundaries, fast loops, easier debugging.
It's a launchpad. Not legacy.
#dotnet
Most .NET devs ignore this.
But it makes debugging 10x easier.
Instead of {Namespace.ObjectName}, you can show:
Order ORD-2025-001: Alice Smith - 249.99
The trick?
Add [DebuggerDisplay] to your class.
Next time you're confused in the watch window, remember: it can be readable.
#dotnet
But it makes debugging 10x easier.
Instead of {Namespace.ObjectName}, you can show:
Order ORD-2025-001: Alice Smith - 249.99
The trick?
Add [DebuggerDisplay] to your class.
Next time you're confused in the watch window, remember: it can be readable.
#dotnet
July 28, 2025 at 8:06 AM
Most .NET devs ignore this.
But it makes debugging 10x easier.
Instead of {Namespace.ObjectName}, you can show:
Order ORD-2025-001: Alice Smith - 249.99
The trick?
Add [DebuggerDisplay] to your class.
Next time you're confused in the watch window, remember: it can be readable.
#dotnet
But it makes debugging 10x easier.
Instead of {Namespace.ObjectName}, you can show:
Order ORD-2025-001: Alice Smith - 249.99
The trick?
Add [DebuggerDisplay] to your class.
Next time you're confused in the watch window, remember: it can be readable.
#dotnet
Me after switching from a mapping library to manual mapping:
April 20, 2025 at 11:37 AM
Me after switching from a mapping library to manual mapping:
What you think solving tasks is:
- Skim in 3 seconds
- Start coding
- Ask AI when stuck
- Finish without understanding
- Spend 3 days fixing bugs
What it should be:
- Read the task
- Think through solutions
- Code, test, refactor
If you write code you can’t explain,
Customers will complain.
- Skim in 3 seconds
- Start coding
- Ask AI when stuck
- Finish without understanding
- Spend 3 days fixing bugs
What it should be:
- Read the task
- Think through solutions
- Code, test, refactor
If you write code you can’t explain,
Customers will complain.
April 1, 2025 at 1:57 PM
What you think solving tasks is:
- Skim in 3 seconds
- Start coding
- Ask AI when stuck
- Finish without understanding
- Spend 3 days fixing bugs
What it should be:
- Read the task
- Think through solutions
- Code, test, refactor
If you write code you can’t explain,
Customers will complain.
- Skim in 3 seconds
- Start coding
- Ask AI when stuck
- Finish without understanding
- Spend 3 days fixing bugs
What it should be:
- Read the task
- Think through solutions
- Code, test, refactor
If you write code you can’t explain,
Customers will complain.
Stuck in a legacy .NET monolith?
No Clean Arch, no CI/CD, no minimal APIs?
Start where you are.
Write one SRP class.
Decouple one method.
Rename one thing.
You can’t choose the codebase.
But you can choose how you improve it.
No Clean Arch, no CI/CD, no minimal APIs?
Start where you are.
Write one SRP class.
Decouple one method.
Rename one thing.
You can’t choose the codebase.
But you can choose how you improve it.
March 31, 2025 at 7:45 AM
Stuck in a legacy .NET monolith?
No Clean Arch, no CI/CD, no minimal APIs?
Start where you are.
Write one SRP class.
Decouple one method.
Rename one thing.
You can’t choose the codebase.
But you can choose how you improve it.
No Clean Arch, no CI/CD, no minimal APIs?
Start where you are.
Write one SRP class.
Decouple one method.
Rename one thing.
You can’t choose the codebase.
But you can choose how you improve it.
The busyness paradox:
Developers don't have time to write unit tests.
But they have time to fix bugs that the tests would have prevented.
#dotnet
Developers don't have time to write unit tests.
But they have time to fix bugs that the tests would have prevented.
#dotnet
February 13, 2025 at 3:30 PM
The busyness paradox:
Developers don't have time to write unit tests.
But they have time to fix bugs that the tests would have prevented.
#dotnet
Developers don't have time to write unit tests.
But they have time to fix bugs that the tests would have prevented.
#dotnet
Been told you must use long-running feature branches?
That’s a lie.
🚩 Successful teams use Feature Flags:
- Deploy early
- Avoid merge conflicts
- Hide unfinished features from users
Ditch the long-lived branches.
Shorten and simplify your dev process.
#dotnet
That’s a lie.
🚩 Successful teams use Feature Flags:
- Deploy early
- Avoid merge conflicts
- Hide unfinished features from users
Ditch the long-lived branches.
Shorten and simplify your dev process.
#dotnet
February 12, 2025 at 3:31 PM
Been told you must use long-running feature branches?
That’s a lie.
🚩 Successful teams use Feature Flags:
- Deploy early
- Avoid merge conflicts
- Hide unfinished features from users
Ditch the long-lived branches.
Shorten and simplify your dev process.
#dotnet
That’s a lie.
🚩 Successful teams use Feature Flags:
- Deploy early
- Avoid merge conflicts
- Hide unfinished features from users
Ditch the long-lived branches.
Shorten and simplify your dev process.
#dotnet
February 11, 2025 at 3:30 PM
Want to build apps on Azure?
Know these 3 cloud types:
☁ IAAS – You manage apps & data; the provider handles hardware & networking.
☁ PAAS – The provider manages infra & OS; you focus on code.
☁ SAAS – Fully built apps; least flexible but easiest to use.
#dotnet
Know these 3 cloud types:
☁ IAAS – You manage apps & data; the provider handles hardware & networking.
☁ PAAS – The provider manages infra & OS; you focus on code.
☁ SAAS – Fully built apps; least flexible but easiest to use.
#dotnet
February 8, 2025 at 3:30 PM
Want to build apps on Azure?
Know these 3 cloud types:
☁ IAAS – You manage apps & data; the provider handles hardware & networking.
☁ PAAS – The provider manages infra & OS; you focus on code.
☁ SAAS – Fully built apps; least flexible but easiest to use.
#dotnet
Know these 3 cloud types:
☁ IAAS – You manage apps & data; the provider handles hardware & networking.
☁ PAAS – The provider manages infra & OS; you focus on code.
☁ SAAS – Fully built apps; least flexible but easiest to use.
#dotnet
"I've already set the wedding date. The only thing left to do is to ask the girl out."
Estimations and software projects in a nutshell
#dotnet
Estimations and software projects in a nutshell
#dotnet
February 7, 2025 at 3:30 PM
"I've already set the wedding date. The only thing left to do is to ask the girl out."
Estimations and software projects in a nutshell
#dotnet
Estimations and software projects in a nutshell
#dotnet
Your ULTIMATE clean code checklist
7 code tips to have better code in 2025
1) Unit testing
2) Refactor every day
3) Eliminate dead code
4) Use the DRY principle
5) Eliminate God classes
6) Minimize using null references
7) Always have in mind that you are writing code for humans
Anything else?
7 code tips to have better code in 2025
1) Unit testing
2) Refactor every day
3) Eliminate dead code
4) Use the DRY principle
5) Eliminate God classes
6) Minimize using null references
7) Always have in mind that you are writing code for humans
Anything else?
February 6, 2025 at 3:30 PM
Your ULTIMATE clean code checklist
7 code tips to have better code in 2025
1) Unit testing
2) Refactor every day
3) Eliminate dead code
4) Use the DRY principle
5) Eliminate God classes
6) Minimize using null references
7) Always have in mind that you are writing code for humans
Anything else?
7 code tips to have better code in 2025
1) Unit testing
2) Refactor every day
3) Eliminate dead code
4) Use the DRY principle
5) Eliminate God classes
6) Minimize using null references
7) Always have in mind that you are writing code for humans
Anything else?
1 simple productivity hack for smart C# developers:
(that I recently discovered)
Create multiple classes at once in Visual Studio 2022.
How to do it?
In the "Add New Item" window, type multiple class names separated by a comma.
P.S. See the below video of this in action.
#dotnet
(that I recently discovered)
Create multiple classes at once in Visual Studio 2022.
How to do it?
In the "Add New Item" window, type multiple class names separated by a comma.
P.S. See the below video of this in action.
#dotnet
February 5, 2025 at 3:30 PM
1 simple productivity hack for smart C# developers:
(that I recently discovered)
Create multiple classes at once in Visual Studio 2022.
How to do it?
In the "Add New Item" window, type multiple class names separated by a comma.
P.S. See the below video of this in action.
#dotnet
(that I recently discovered)
Create multiple classes at once in Visual Studio 2022.
How to do it?
In the "Add New Item" window, type multiple class names separated by a comma.
P.S. See the below video of this in action.
#dotnet
Lack of simplicity, not lack of time, is a true enemy in every .NET project.
You don't need more complexity.
You need more simplicity.
If you want to learn how to evolve .NET projects, here's a useful GitHub repository:
https://buff.ly/3CzSE2u
Start simple.
Evolve as needed.
#dotnet
You don't need more complexity.
You need more simplicity.
If you want to learn how to evolve .NET projects, here's a useful GitHub repository:
https://buff.ly/3CzSE2u
Start simple.
Evolve as needed.
#dotnet
February 4, 2025 at 3:30 PM
Lack of simplicity, not lack of time, is a true enemy in every .NET project.
You don't need more complexity.
You need more simplicity.
If you want to learn how to evolve .NET projects, here's a useful GitHub repository:
https://buff.ly/3CzSE2u
Start simple.
Evolve as needed.
#dotnet
You don't need more complexity.
You need more simplicity.
If you want to learn how to evolve .NET projects, here's a useful GitHub repository:
https://buff.ly/3CzSE2u
Start simple.
Evolve as needed.
#dotnet
When do you have less chance to screw up?
A → when you release 10 lines to production.
B → when you release 1000 lines to production.
If your answer is A, why are you still doing B?
A → when you release 10 lines to production.
B → when you release 1000 lines to production.
If your answer is A, why are you still doing B?
February 3, 2025 at 3:30 PM
When do you have less chance to screw up?
A → when you release 10 lines to production.
B → when you release 1000 lines to production.
If your answer is A, why are you still doing B?
A → when you release 10 lines to production.
B → when you release 1000 lines to production.
If your answer is A, why are you still doing B?
Sometimes, a junior developer will finish the task faster than a senior dev.
Here's why...
Junior (8h): Makes the change.
Senior (16h): Makes the changes, writes tests, improves the code.
RESULT
Junior: Fixing 3 bugs.
Senior: Happy customers.
To ship fast, you go slow.
Here's why...
Junior (8h): Makes the change.
Senior (16h): Makes the changes, writes tests, improves the code.
RESULT
Junior: Fixing 3 bugs.
Senior: Happy customers.
To ship fast, you go slow.
January 27, 2025 at 3:30 PM
Sometimes, a junior developer will finish the task faster than a senior dev.
Here's why...
Junior (8h): Makes the change.
Senior (16h): Makes the changes, writes tests, improves the code.
RESULT
Junior: Fixing 3 bugs.
Senior: Happy customers.
To ship fast, you go slow.
Here's why...
Junior (8h): Makes the change.
Senior (16h): Makes the changes, writes tests, improves the code.
RESULT
Junior: Fixing 3 bugs.
Senior: Happy customers.
To ship fast, you go slow.
Things you don't need:
- Kubernetes
- Microservices
- Separate read/write DBs
Things you need:
- Unit tests
- CI/CD pipeline
- Healthy coding habits
- Monolith architecture to start with
Lack of simplicity, not lack of time, is a true enemy in every software project.
- Kubernetes
- Microservices
- Separate read/write DBs
Things you need:
- Unit tests
- CI/CD pipeline
- Healthy coding habits
- Monolith architecture to start with
Lack of simplicity, not lack of time, is a true enemy in every software project.
January 26, 2025 at 3:30 PM
Things you don't need:
- Kubernetes
- Microservices
- Separate read/write DBs
Things you need:
- Unit tests
- CI/CD pipeline
- Healthy coding habits
- Monolith architecture to start with
Lack of simplicity, not lack of time, is a true enemy in every software project.
- Kubernetes
- Microservices
- Separate read/write DBs
Things you need:
- Unit tests
- CI/CD pipeline
- Healthy coding habits
- Monolith architecture to start with
Lack of simplicity, not lack of time, is a true enemy in every software project.
The biggest benefit of TDD is not the code covered with tests.
Instead, it's the ability to think SMALL.
The SIZE of a problem you are trying to solve without TDD:
- Implement the complete login functionality.
The SIZE of a problem you are trying to solve with TDD:
⬇️ ⬇️ ⬇️
Instead, it's the ability to think SMALL.
The SIZE of a problem you are trying to solve without TDD:
- Implement the complete login functionality.
The SIZE of a problem you are trying to solve with TDD:
⬇️ ⬇️ ⬇️
January 25, 2025 at 3:30 PM
The biggest benefit of TDD is not the code covered with tests.
Instead, it's the ability to think SMALL.
The SIZE of a problem you are trying to solve without TDD:
- Implement the complete login functionality.
The SIZE of a problem you are trying to solve with TDD:
⬇️ ⬇️ ⬇️
Instead, it's the ability to think SMALL.
The SIZE of a problem you are trying to solve without TDD:
- Implement the complete login functionality.
The SIZE of a problem you are trying to solve with TDD:
⬇️ ⬇️ ⬇️
Instead of having a big method with 5+ parameters,
Do this:
1. Create a new class.
2. The properties on the class are the same as method parameters.
3. Replace the parameters with the new class.
4. Update the method calls.
This will quickly improve the maintainability of your code.
Do this:
1. Create a new class.
2. The properties on the class are the same as method parameters.
3. Replace the parameters with the new class.
4. Update the method calls.
This will quickly improve the maintainability of your code.
January 24, 2025 at 3:30 PM
Instead of having a big method with 5+ parameters,
Do this:
1. Create a new class.
2. The properties on the class are the same as method parameters.
3. Replace the parameters with the new class.
4. Update the method calls.
This will quickly improve the maintainability of your code.
Do this:
1. Create a new class.
2. The properties on the class are the same as method parameters.
3. Replace the parameters with the new class.
4. Update the method calls.
This will quickly improve the maintainability of your code.
10 lines changed = 10 comments
1000 lines changed = 0 comments, LGTM (looks good to me)
Code reviews in a nutshell
1000 lines changed = 0 comments, LGTM (looks good to me)
Code reviews in a nutshell
January 23, 2025 at 3:30 PM
10 lines changed = 10 comments
1000 lines changed = 0 comments, LGTM (looks good to me)
Code reviews in a nutshell
1000 lines changed = 0 comments, LGTM (looks good to me)
Code reviews in a nutshell