Programming myths I've heard way too often

Lonna — Tue, 02 Jun 2026 16:08:30 +0000

Ever since programming existed there have been misconceptions or arguments about what it means to be a programmer. I’ve gathered a few I believe to be false - and I'd like to say a few things about them.

Myth 1: Programming is dead

Let’s start with the obvious - the rise of AI. I think this is the new “If you don’t code in language X, then you’re not a real programmer”. Which to me has always sounded like saying that if you don’t bring water directly from the spring you haven’t really brought water. The fact that something is evolving doesn’t mean it’s losing its personality. Right now, AI is everywhere. It’s true that many elements of programming which have been an essential part of it seem to be on their way to being augmented at least. Code that took days before is now generated by AI in seconds, often with correct syntax. So the need for people that just code seems to be getting smaller. But does it mean this need is disappearing altogether? The popular new thesis is that programmers need to be architects and need to understand users very well and this would be enough - AI would deal with the rest. It sounds obvious until you ask yourself how those people will become adequate in areas they haven’t faced first hand. There is a difference in reading how to build a house and building one yourself.

Myth 2: If you don’t work in a big company, you’re not a serious developer

That’s a point of view I’ve experienced towards myself. Since I spent years in a small company, I often heard I needed to change my dead-end job as soon as possible. This position lies in a couple of concepts, which are not really related to the work itself. First of all - many small companies are still startups and probably pay less. Many people think financial reward equals professional development. However, to be a programmer you need to be able to program and to produce real results of significance, not just to earn more. Second, small companies tend to have flatter hierarchies. It means there are no clearly defined leadership figures. This approach has its advantages. The opinion even of junior developers gets taken into account, which builds self esteem. But this doesn’t mean anarchy. It’s just that roles become visible organically. When the same senior developer answers adequately your 30th question, you’ll go to them again even if they are not officially a tech lead. But the misconception is without a title, there is no growth. In big corporations the hierarchies are clear with positions like tech lead and team lead, as well as multiple levels of management above them. However the title itself doesn’t bring knowledge or experience - though it does open doors to advancement in the same or similar hierarchy. While at big companies more time can go into calls and administrative processes before getting to the coding itself, in smaller firms you’re often thrown straight into the deep end - which pushes you to develop your skills quickly.

Myth 3: You need/ you don’t need higher education to become a programmer (university degree)

This topic has been revisited many times and both beliefs have been argued by professionals. I think both have merit but as a person who chose to pursue university degree I lean toward the higher education path. Many good developers don’t have a degree, that’s true. But also many of them have studied in high schools with focus on math and programming or have been doing programming since 15 years old. That builds many qualities, which someone in their twenties, who is new to programming may not possess yet. Even for those who already have good understanding of the field I’d recommend a university degree. The reason however is not the programming itself but the math, which is common in many CS programs. It’s just that your brain starts to think about things differently after understanding the 100th theorem proof. And it’s useful. Of course all this could be achieved with a lot of code as well by people who have no such education and are just very motivated. Different approaches can lead to good results. Just because many ways lead to Constantinople, it doesn’t mean we should pretend there is just one right one.

I guess many more such statements exist but those are the ones I’ve encountered the most. Even though many such beliefs don’t have just one side to them, it’s always worth thinking beyond first impressions.

DEV Community: Lonna

Programming myths I've heard way too often