Programming Principles NOBODY Taught Me

Added: 2026-05-09

[00:00:00]I've gone through courses, read many programming books, but still in seven years of writing backend code, the most important principles I learned by making my own mistakes. So adopt any of these five and you'll immediately write much better code. First, write clear code, not clean code. Clean code is written to be beautiful according to standards. I remember I wrote a whole singleton class with metaclass hacker in python and felt like senior. Then an actual senior engineer replaced it with a module level variable because python modules are already singleton. So actually clear code is easy to read when going back to it in 3 months. So you don't curse it yourself. Easily testable because functions are pure and simple. But also it makes assumptions obvious. When writing code, we constantly make assumptions about what the function we use will do. Will the function mutate the state in place, produce side effects, raise errors, or return null?

[00:01:03]The easier it is to assume correct information, the more straightforward the development process will be. Also, much fewer bugs will be created if what you assume will always be right. For example, if you're writing a function transfer orders and assume that the orders parameter is a list of order objects with fully validated fields, you should always get only that. And when using this function in code from the name transfer orders, you assume that orders will only be transferred somewhere, which means they are not going to be mutated. That assumption should always be met. When I started coding, I used to write functions like process, manage, handle, and they are a perfect example of breaking this rule.

[00:01:50]What assumption can you make by looking at this function definition? Does it transform arguments? Does it have side effects? The only accurate assumption to make is that it was written by a junior programmer. A better naming for something like process user would be create user, authenticate user, or send welcome email. But if you're trying to rename it and find you cannot pick one verb, you've just discovered the function does too many things. Here's a cheat sheet for some common ways to name functions and assumptions people usually make about them. Use them. Writing clear code is one of the most important skills of a great software engineer. But it cannot be solved by making everything solid and stuffing it with design patterns. Choose to be consistent over optimal. When I look at the codebase and see two similar things implemented in a completely different way in different places, my brain explodes with questions like what should I use? What should I do with the other one? Should I refactor it or leave it? what was the intention of breaking the pattern? So instead of focusing on my task, I spend time thinking about the past and it's taking two times more cognitive load than following a standardized pattern that is consistent across everywhere. So I joined a new startup and the codebase was clearly half vipcoded. The biggest problem for me was not the amount of bugs but the fact that the same functionality was implemented in line and scattered across everywhere. I've seen a lot of bad code, but this specific on boarding process almost made me quit. So, whenever you feel like breaking the pattern, ask yourself if it's really worth it. And if you decide yes, it's your responsibility to make sure all other places are consistent.

[00:03:41]You get a task, implement it, get the new one, implement it with the same amount of effort. But actually, every time you break stable patterns, the effort needed to implement all future work on a project will scale up. By the way, AI is a great replicator. It will amplify how inconsistent your code is and will run itself into a grave together with your sanity as a developer. But if you invest time into setting up good patterns, your teammates, AI, and you yourself will perform much better. Study paradigms.

[00:04:16]Don't use them. After reading domain driven design, I decided to turn our CRUD API into a clean code paradise.

[00:04:24]Nobody wanted to pay me for it. So after spending 5 hours of my free time, they turned our API code from five files to 25 files. I thought this refactor would make me a 10x engineer in the eyes of my team. But when all simple feature requests started taking two times longer without any good reason, it got reverted. Not only was I not a 10x developer, but I managed to decrease productivity of the entire team. But is the maindriven design really that bad?

[00:04:54]No. But you cannot strictly follow a development paradigm bite for bite. It will make your project unnecessarily complex. But learning about them and stealing things that actually make sense to combine into your own project's development paradigm is beautiful. For example, I believe that small immutable value objects that come from the real world are the best way to express data inside programs. They perfectly follow make assumptions obvious because you don't even need to assume what you get.

[00:05:27]It's a validated immutable value with specific types. It directly comes from DDD and it will increase the quality of any project. So please stop hating or being a fan of a specific design approach. Learn about them to develop your own taste and then use that to make your project better for the team. This is what will actually make you a 10x engineer. Errors are a part of the program, not an exception. Coding in highle languages allows you to disregard errors and not worry about them at all.

[00:06:02]Rookie mistake. So I thought that just handling exceptions is enough to build a robust application. But then we got a desk to implement alerts based on specific errors happening during client request processing. They were not some surface level validation errors and they only happened deep into application code. Also alerting needs to know full context about the error. why it happened, what the parameters were, how many retries happened. So what are the options to do that? You just need to go into the logic and put alerts right there where the error happens so that you can capture context. So I did it, but then I had to update alerts with new data. Um, and I had to go through all the different places where I put it, forgetting some of them because infrastructure code is now scattered across the codebase, which not only makes core business logic functions dirty with side effects, but also makes the alerts system unmaintainable. Here's what I should have done. Define a typed exception for each failure mode. For example, payment declined, inventory empty, rate limit hit. Each one carries the data the alert needs. Business logic raises them and a single top level handler catches them and decides what to do. Log, alert, retry form a structured at HTTP response. This way logic stays clean and pure while monitoring and alerting stays centralized. They are decoupled. Each becomes more testable and easier to work with. If we had to add data to the alert, there is only one obvious place to do that. This one pattern will upgrade every backend project you touch. Remember, in programs, exceptions aren't exceptional.

[00:07:50]Abstractions are depth. And I'm not talking about abstract classes. I'm talking about you having no idea about what's happening inside some of the black boxes you use every day in your code. I'm a backend engineer and I was writing the slowest SQL queries on the entire planet. Even on tables with a couple million rows, they were performing like extremely badly because of silly things like N plus1 queries. At the time as a junior engineer, I had an ORM abstraction and I thought it was enough. But only after learning what actually happens inside the database engine and what makes a query perform well or bad, I started to write optimized queries and stopped producing so many performance issues. We are writing tons of code every day. Some of us even 100,000 lines per day. But how do you know that what you write is correct? Only by understanding exactly what is going on inside. Here's another story on the subject. I was writing a function create comment. The whole function was wrapped into a database transaction and had a couple of update queries that were supposed to run atomically, right? But also it was sending an email to the creator of the post about the comment they received.

[00:09:10]Everything worked fine until one query um after the email was already sent started failing and the whole transaction was rolled back. No comment was created, but the email was already sent for the comment that doesn't exist because it's a side effect that cannot be rolled back, which is again such a rookie mistake. The reason I was confused was that I saw atomic and assumed the whole block of code is somehow atomic without really understanding how it works. But that day, I started attacking my black boxes.

[00:09:44]Open yours or pay the bill later with silly bugs like mine. If you want to remove as many abstractions as possible and build actual senior level judgment, I've built a lab exactly for that. You will read the best programming books while completing challenges like code reviews, system designs, refactors, and get instant feedback with in-depth explanations so that the knowledge sticks. You can find the link in the description. 2026 will be absolutely brutal for juniors and potentially middles. So, if you want to get a highly paid senior level role, watch this video next.