Why I Think We Shouldn't Be Recommending Unity To New C# Developers
Often times, someone will come into the subreddit and ask where to start with learning C# development. While most people will not recommend Unity, there will often still be someone recommending Unity. There's also beginners who start with Unity as a gameway into C# development. I get that. Lets be honest, making your own game is a fun pathway to software development.
Unity is one of the most popular engines for game development, has a fairly approachable interface and a huge ecosystem of resources. It's been (up to the license debacle from last year) a go-to framework for both indie developers and seasoned professionals. But despite its accessibility, I still think Unity is not a good choice for someone just starting out with C# development - and here’s why.
1. You're Learning Unity Development
When starting out with Unity and C#, you’re not just learning programming; you’re diving deeply into Unity's ecosystem. While that’s great for game developers, it’s not ideal for beginners looking to build a solid foundation in C#.
1A. You're Learning to Build a Game
First argument is obvious; while building a game, you probably also come into contact with a lot of other skills that at best, only indirectly translate to make you a better developer, like 3D modelling or deeper geometrics by forcing new developers to interact with Quaternions. But this has little practical application in enterprise non-game development.
1B. You're Learning the Unity Ecosystem
New developers are obviously pushed towards Unity specific packages/standards/libraries, and whatever they've learned will be deeply integrated with the Unity ecosystem - and the Unity ecosystem, in my eyes, has little application in enterprise .NET development that isn't game development.
I personally used it as a "build once, deploy everywhere" framework once, and once for an AR application for a client, but the former feels like shoving a round peg in a square hole (especially since .NET MAUI is pretty decent, and we can natively build for Linux now) and the latter is not an everyday occurrence.
1C. You're Not Learning to Build an Enterprise .NET Application
Enterprise-level development requires a broad range of foundational skills that Unity simply doesn’t teach;
- The importance of automated tests and test-driven development (TDD). Hobbyist game developers rarely test their code systematically, and automated testing in game development is significantly different from enterprise approaches.
- Building REST APIs, database-backed applications, or cloud-native solutions with technologies like ASP.NET Core, Entity Framework Core, Azure, or Docker.
- Essential DevOps skills, like pipeline management, Infrastructure-as-Code (IaC), and CI/CD.
If you're learning to write your first Blazor app, any decent guide will touch on automated testing and deployments. But while some of these tools and skills are vital in larger game-development studios, they’re not emphasized when you’re just creating a game in Unity. Even skills that have a degree of overlap, like performance testing, will not translate well.
1D. You're Not Learning the C#/.NET Standards
Under the hood, Unity relies on the .NET Standard 2.X runtime instead of .NET Core, which in my eyes is not ideal if you ever want to familiarize yourself with commonly used packages, libraries, and frameworks in mainstream C# development. In inverse, developers who have an existing .NET background or are using general .NET guides might be surprised when they attempt to learn or use standard .NET packages and tools and find them unsupported in Unity. That can lead to fragmentation and confusion about what is or isn’t "typical" in .NET development, and even experienced developers will inevitably hit a frustrating wall when certain industry-standard packages and libraries are unavailable.
This doesn't necessarily mean you're stuck on older C# versions! There's a difference between Framework version and Language version, and Unity supports C#, so the beginners are still learning most C# language features. You can configure the LangVersion and compiler to support modern C# versions. But maybe that's a bit much to ask for a beginner.
1E. You Might Be Learning Bad Habits (or not Learning Good Habits)
Unity also has different standards and habits than non-Unity enterprise development. An example is that a lot of habits in Unity will violate OOP standards, which I'll dive a bit deeper into the next section.
I'm not looking to call those habits "bad". Within Unity, they're sometimes unavoidable. What I'm saying is that Unity doesn't provide guidance in explaining why it does things in certain way, and why you shouldn't be doing things that way outside of Unity.
The editor will also not push developers to learn good habits. This is kinda obvious, it's an editor, of course it won't teach you and will allow you to break stuff, and the Unity C# tutorials do touch on it. But I do think we should still consider this as an argument;
- Unity requires fields instead of properties for values editable in the editor, contradicting conventions that promote encapsulation. Even Unity’s own API exposes fields (
GameObject.name) instead of properties (GameObject.Name), so this may subtly encourage the wrong behavior. - Beginners often rely on Unity’s duck-typed features—like retrieving objects by name or tag—without a deep understanding of type safety.
- Unity supports interfaces, but its workflow rarely encourages their use. As a result, many beginners miss out on learning this key programming concept.
- Automated testing in Unity is vastly different from enterprise .NET development. Many hobbyist developers never learn to write tests, and those who do may struggle to apply those skills outside of Unity.
2. Unity Promotes a Scripted, Event-Driven Style Over True Object-Oriented Programming (OOP)
At its core, Unity’s programming model prioritizes event-driven or scripted approaches rather than true Object-Oriented designs. While you can still do Object-Oriented programming in Unity, and even then scripted approaches are accessible and even appealing to a beginner, it fosters poor habits and creates challenges when transitioning to professional, enterprise-level .NET development. Even if you try to adhere to proper OOP principles in Unity, you’ll quickly find Unity itself nudging you in the opposite direction.
2A. Tightly Coupled Architecture
Unity revolves around the MonoBehaviour class, which serves as the base for almost every script, along with numerous Unity-specific framework features. This coupling enforces a dependency-heavy architecture that contradicts the SOLID principles of software engineering. For a new C# developer, this tight coupling stifles the opportunity to explore modular programming, interfaces, or robust dependency management.
2B. Magic Methods Trump Object Lifecycle Management
A fundamental part of writing clean C# code is understanding constructors and controlled object instantiation. Unity bypasses this entirely by relying on "magic methods" such as Start, Update, and OnDestroy. These methods, often invoked via reflection, run automatically without explicit calls from the developer. While these shortcuts simplify initial learning, they prevent a foundational understanding of object lifecycle management, leading to minimal control over how and when objects are initialized or cleaned up.
2C. Explicit Composition Is Harder Than Inheritance
Unity leans heavily on inheritance, and it's sometimes harder to work with Composition. If you need to compose objects (e.g., adding dependencies to a parent object), you’ll frequently have to use the Unity Editor to pre-assign child components by dragging and dropping them into fields. This manual approach makes Composition less intuitive and forces developers into editor-specific workflows, which don’t naturally translate to regular C# development.
2D. Lack of Dependency Injection
Dependency Injection (DI) is poorly supported in Unity. The Unity alternative is actively rely on the Service Locator pattern, which is widely considered an anti-pattern within enterprise .NET development. In my eyes, inversion of control and Dependency Injection is a cornerstone of modern .NET development, so we should be teaching it as such.
2E. Global State Through Singletons
Unity fosters the use of Singletons for state management, a global state technique that is convenient but error-prone. New developers are often unaware of its pitfalls, such as poor testability and hidden side effects.
2F. Limited Exposure to Core OOP Concepts Like Interfaces
I touched on this before as that Unity doesn't force you into good habits, but for example, while interfaces are fully supported and the tutorials touch on them, there's still a fair chance new developers overlook or avoid them. The architecture rarely forces developers to use it, while I consider it a backbone of modern C# development.
3. Unity's "Language Abuses"
Some of Unity’s quirks go so far as to "abuse" standard C# paradigms. One standout example is its behavior around Destroy() and operator overloading.
Destroying a GameObject makes it behave as if it’s null according to Unity's overridden == operator. However, C#’s native null-coalescing operators (?. or ??) are impossible to override and still check the actual reference.
So you can get some baffling and inconsistent behavior:
lang csharp
GameObject a = new GameObject();
a.name = "test";
a.Destroy();
if (a == null)
Debug.Log("GameObject has been destroyed");
if (a.Equals(null))
Debug.Log("GameObject has been destroyed");
if (!string.IsNullOrWhiteSpace(a?.name))
Debug.Log($"GameObject {a.name} exists");
In this example:
- Unity overrides == to treat destroyed objects as null. The first Debug.Log wil print, as a is treated as null.
- Unity overrides the Equals() method. An experienced C# developer would spot a bug: if the first statement confirms that a is null, the second if check will normally throw a NullReferenceException since you're calling .Equals() on null. But thanks to the override, this doesn't happen, and instead it will print this statement too.
- The null-coalescing operator (?.) uses actual references and ignores Unity's overrides. The third Debug.Log wil also print.
- But the example might be inconsistent: Because Unity has a custom object lifecycle management and garbage collection, depending on the state of Unity’s garbage collector, the second statement might throw a NullReferenceExceptions as expected and the third statement could not print. This is rare, but it can theoretically happen.
So for a typical .NET developer not experienced with Unity, the example above will be baffling and inconsistent.
A Better Approach Towards Learning C#
Game development may still good starting point to get someone excited about software development. I'll admit that much. But after that first step, rather than learning further development with Unity, encourage new C# developers to build foundational skills first.
Teach the basics of Core C# development, OOP, SOLID principles, and design patterns, and encourage new developers to explore the .NET ecosystem, like ASP.NET, Blazor, EF, or Azure.
When Should You Recommend Unity?
Unity can still be a good tool when used by developers who already have a strong programming foundation or those who are specifically aiming to explore game development.
So sure, recommend Unity to: - Developers who already have a strong foundation in C# and OOP, and are looking to branch into game development. - People explicitly interested in game development, AR/VR, or interactive applications. - Artists and designers wanting to learn basic programming as a bonus to their creative skills, instead of entering enterprise full-stack C# development.
By recommending Unity to beginners, they risk being lead them down a path that unnecessarily limits their broader development potential. Advocate for foundational learning first - Unity will be there when they're ready to make something amazing.