Learning software engineering best practices and reading tips from experienced developers is what can help you make your job a little better, even starting tomorrow.

The best practices and tips listed below will benefit the vast majority of software developers looking to be better today than they were yesterday.

Application Performance

1. Your code might work very slow on a large dataset that you don’t have on your local environment, but that might be in production. Ask yourself the question, “Do the algorithms and data structures I use scale well as my data grows?”.

2. Don’t waste time on implementing highly efficient…

Typically, software developers try to avoid working on legacy projects due to reasons such as low code quality, pure documentation, lack of unit tests, large amounts of technical debt, etc.

However, in my opinion, every software developer should try working on a true legacy project at least once in their life in order to gain experience that other types of projects may never give you to become a senior developer.

You Learn How Things Shouldn’t Be Done

Software developers learn best practices, coding techniques, design patterns throughout their careers to know how to do things right. However, this is usually not enough to become mature experts, because…

For those interviewers who might want to extend their list of interview questions, or those interviewees who might want to become more confident before the next interview, or just all .NET developers looking to learn something new, I’ve prepared some interesting questions.

1. Can a singleton object depend on a scoped/per-request object?

Or, the question could be rephrased as “Will the following piece of code work?”:

public class Controller
{
    public Controller(UserService userService) { }
}public class UserService
{
    public UserService(IUserRepository userRepository) { }
}public class UserRepository : IUserRepository
{
}//DI registration:
public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<UserService>();
    services.AddScoped<IUserRepository, UserRepository>();
}

This code will compile, but developers…

The rules for choosing the number of repositories for a monolithic project are usually very simple — put the entire codebase in one repository, and that’s it.

However, as the project grows, developers may decide to split the monolithic project into microservices. Choosing the number of repositories becomes a little more difficult. Developers need to answer questions that they never had when working with monolithic projects:

Should I put each microservice in a separate repository, or should they all remain in the same repository, but in different modules / folders?

Are there any rules, guidelines, or best practices that I…

Software development is a complex process with so many nuances that almost every developer has had or currently has one or more misconceptions in object-oriented design, unit testing, asynchronous programming, or other areas.

While some misconceptions may be innocent, others may even prevent developers from doing their job properly, so it’s best to get rid of them now.

Mocking is Only Possible with Interfaces

The tight coupling between classes can lead to testability issues. Let’s take a look at an example that demonstrates the tight coupling problem:

public class Storage
{
    public string GetData() => "Data from the storage.";
}public class Parser
{…

Software developers may face the following error message when using MS SQL Server in their projects:

Transaction (Process ID 69) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

While in some cases deadlocks can simply be fixed with one change, often deadlocks can be the result of inefficient database design or even application architecture and can require many efforts from developers to minimize them.

· What is Deadlock?
· Retry Logic for Victim Transactions
· How to Minimize Deadlocks?
∘ Improve the Database Performance
∘ Downgrading the Transaction Isolation Level
∘…

Choosing the right transaction isolation level is an important part of the design and development process for a relational database because it eliminates a wide range of concurrency issues.

In this article, we’ll focus on those transaction isolation levels that address concurrency issues using locking such as read uncommitted, read committed, repeatable read, and serializable.

· Shared (S) vs Exclusive (X) Locks
· Read Uncommitted
∘ Dirty Read Problem
∘ Read Uncommitted vs NOLOCK Table Hint
∘ When to Use Read Uncommitted?
· Read Committed
∘ How Does Read Committed Solve the Dirty Read Problem?
∘ Non-Repeatable Reads Problem
∘ Lost…

Software developers spend most of their time reading code, not writing it. Due to this fact, the code should read like a book so that it can be easily understood not only by compilers but also by other developers.

I will not share with you the standard and well-known naming conventions here. I’ve put together some common intrusive naming violations that static code analyzers usually don’t report and how to fix them.

Weasel Words in Names

Programmers often use weasel words like “Temp”, “Dto”, “Info”, “Item”, “Base”, etc., which do not add any value to the names.

Usually, it is enough to simply remove…