Sign in

MSc. | Tech writer with +1M views. Sharing my opinion and what I learn. .NET backend engineer, ex big4 SC. New YouTube Channel

Opinionated Perspective

Why “write code juniors understand” is terrible advice

Image by Nicklas Millard

“Don’t use that construct (syntax, approach, pattern, or whatever), juniors won’t understand it!”

This makes perfect sense from a management point of view since we can get away with hiring less experienced people.

Continuously dumbing down code only makes sure your junior developers stay dumb.

Dumbing down your code to the point where it requires less language-specific knowledge to understand, or, simply overall lower coding literacy is, in my opinion, terrible advice.

🔔 Want more articles like this? Sign up here.

Typical characteristics of juniors, mid-level, and senior developers.

Give the same task to a junior, mid-level, and senior developer and you’ll (obviously) receive wildly different solutions.


Opinionated Perspective (Short-form)

Clean domain models are persistence agnostic.

Poorly modeled domain class
Poorly modeled domain class

I assume most developers interact with their database thru object-relational mapping (ORM) technology. You rarely write raw SQL as an application developer these days.

This brings along a whole new set of issues.

Mixing concerns often lead to bad things in software development. I've found that marrying your domain model with your persistence logic is one of the worst types of mixed concerns.

You should never compromise your domain design to please an external framework.

This practice has multiple adverse effects. Not only do you need unnecessary library dependencies in your domain project, but you all of a sudden tell…

Opinionated perspective

Don’t write code just to make your ORM happy.

Image by @nmillard

Stop letting your database be in the driver’s seat of your application.

You probably let your database generate your ids. Don’t you? Maybe due to the convenience of it — there’s really nothing convenient about it, though.

How often do you make “pragmatic” decisions about your model? Or slack on some domain invariants because it’ll then be easier to work with your object-relational mapping (ORM) framework?

You let your database or ORM bully you any time you’re concerned with infrastructure while designing your domain models.

Have you ever added properties, or let properties have public setters, only to please the…

Practical programming advice

Having more classes does not equal higher complexity.

Image by Nicklas Millard

So, there is a good chance that you’ve used parametric polymorphism already — it’s basically just generics. But, do you know how generics can help you reduce the use of branching statements, such as if-else and other control-flow statements?

if-else is often a poor choice, especially if you want to follow the Open-Closed principle, making your application easily extensible. We’ll get into why this is, in the following section. (I have a list of articles on this subject as well)

Back as a junior developer, I’d often resort to traditional branching techniques, plastering if-else and switch statements all over the…

How to become a senior developer

Let’s get you up to speed. Fast.

Photo by Alex Haney on Unsplash

Back when I started programming I ran across concepts and terms I really didn’t understand, like middleware, inversion of control vs dependency injection, traditional branching, service classes, business logic, status codes, and many more.

I’d often interrupt my flow to spend time chasing down the meaning of these — and, maybe that’s exactly why you are here right now.

So here I am trying to make life a tiny bit easier for you junior developers, by attempting to explain, or at least somewhat clarify the meaning behind these terms.

Okay, let’s get into it.

Why traditional branching masquerades as “simple code.”

Traditional branching negatively impacts your code…

Opinionated Perspective

Arbitrary, self-imposed constraints in the guise of “good practice” should not limit your ability to express your domain.

Image by Nicklas Millard

So, REST obviously didn’t pan out the way we hoped. Large corporations nicely marketed REST to sell their software, kicking off the so-called API economy.

But we should’ve known it wouldn’t work out as expected.

There were a bunch of telltale signs along the way… The general lack of standard practices. The genericness of it all. Focusing on following arbitrary, synthetic rules rather than building business-specific APIs.

And then we have perhaps the most conspicuous sign REST wouldn’t work in a modern DDD-driven application:

Applying a document-oriented paradigm to the complex reality of business domains doesn’t work (well) in practice.

Opinionated Perspective

So… I heard you worship CRUDy REST interfaces.

Image by Nicklas Millard

Many web developers default to implementing REST APIs in a CRUD-like manner. They’re too focused on sticking with arbitrary, made-up technical rules, losing all sight of the business and its clients.

CRUD over REST might be great for beginner developers and creating PoCs because it’s easy to get started, and you can largely ignore aspects of your business domain.

Alright… so let me state this right off the bat; I (mostly) don’t have an issue with REST.

There’s a general issue with how developers default to creating CRUD-based REST APIs. For some reason, developers have converged on the idea every…

Opinionated Programming Advice

Following a few guidelines and practices goes a long way.

Glasses image by Nicklas Millard

I’ve applied many different programming styles, practices, and approaches to write more readable code throughout the years.

Some initially seemed great but turned out not to be. Others got outdated, and then there are the few practices that I’m still using.

I’ll just enumerate a list of those that have stuck with me and which, in my opinion, works well.

Remove unnecessary code comments.

You do need documentation comments, but most comments are completely unnecessary.

There are many different “kinds” of comments that only increase the noise-to-signal ratio.

Here are some of those typical code comments that you might as well just delete on…

Opinionated perspective

It’s an ancient paradigm better left behind.

Image by Nicklas Millard

I heard about CRUD back when I started learning programming and web development. It was pretty much the approach to use. I’d be spending time thinking about entities as ‘resources’ and how to write awesome CRUD-based applications, where each resource was either created, read, updated, or deleted, and only that. Essentially what’s best described as ‘CRUD-thinking.’

Create, read, update, delete. Simple enough — and that’s exactly the problem.

When did you last think about your domain solely in terms of storage management?

But I can see why beginners like this approach. The CRUD idea translates well into existing programming concepts…

Because no in-memory database provider is good enough to simulate the real thing

Image by Nicklas Millard

There comes a point when unit tests and mocking just won’t cut it.

Writing unit tests with a mocked database may be great when you want to verify that a piece of code runs correctly, given some expected input.

Using an in-memory provider is the natural next step. But while an in-memory provider is useful, it’s only a hollow shell compared to the real thing. For example, queries that succeed when testing with an in-memory database may fail hard when executed on the real database.

In-memory databases provide you with a false sense of confidence.

You’ll eventually need to be…

Nicklas Millard

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store