Are you ready to become a programmer

Do you want to become a developer? Then let's get straight to the point without any illusions. Development is not just "writing code." Development is mainly working with what has already been written. To be honest, it's about ~30% new features and ~70% routine. And it's on these 70% that people often break down.

When you first enter the profession, it seems like everything will look like this: you sit, write code, create features, and build something new. In practice, you read someone else's code, understand logic you didn't write, fix bugs, rewrite old code, cover with tests, write documentation. And only occasionally — do you create "something new."

When I first encountered tests, I didn't understand why they were needed at all. It seemed like a waste of time, a complication, "it works as it is." Then I attended a conference where they talked about TDD. And at some point, it hit me: tests are not about "right." They are about controlling the system. Now I almost never write code without tests. Because they catch errors before production, they provide confidence when making changes, and they accelerate system development in the long run. Yes, you spend more time now, but you save exponentially more later. If you find writing tests boring, you are not ready for the profession.

This is one of the most underrated things. When you join a new company, they give you access, explain something verbally, and say: "figure it out." And you sit and read. A lot. For a long time. Without full understanding. At the start, it's exhausting because: there's no context, no complete picture, the code can be of varying quality. But this is a mandatory stage, and there is a turning point here. At first, you just read, then you start to see where things are bad, where improvements can be made, where there are architectural problems, and that's already growth.

Very often it looks like this: you have a task, you're immersed in it, and then a bug from production comes up. You switch. You lose context. You return back—and re-enter the task. This is normal. In mature teams, there are on-call processes (dedicated people for bugs). But even there, it's part of the job. And if you think you'll be "only writing new features"—no. You will be doing a lot of fixing.

The most dangerous phrase in development: "we'll rewrite it later." Almost never does "later" come at the right time. I've seen code grow to a state where changing anything is frightening, everything is interconnected, and performance drops. At some point, a major turnaround becomes necessary. I had a case where the system could no longer cope, search and filters worked poorly, and the load was killing the database. Instead of "patching," we had to change the API structure, switch storage (MySQL → Elasticsearch), and rebuild part of the system. This is not a quick process. But that's the price for accumulating technical debt.

Now the main point. Why is all this important? Because a developer is not someone who just writes code. A developer is someone who maintains the system, develops the system, keeps it operational, and this is almost always routine.

There is a simple test. If you find writing tests boring, reading someone else's code irritating, or don't want to deal with bugs - you are not ready for this profession. And that's okay. It's better to understand this sooner rather than a year later. Conversely, if you accept that you will have to read more than you write, fix others' mistakes, and think about the future of the code, you have a chance to grow.

The good news is that over time it stops being a "routine." You start to understand the code faster, foresee problems in advance, and use tools that simplify the work. And it becomes a normal part of the process. Development is not just about inspiration. It's about discipline. And if you're ready for this, everything else will follow.