The IT industry, just like any other, has its fair share of myths and legends. Today I want to check some of the most frequent I hear.

I need a science degree and ace math problems

This is something I’ve heard ever since I was a kid. “Programming is all math, extremely hard at that” is repeated like a mantra even today. While knowing math will definitely help you spot some patterns (like sigma summation being very similar to a for-loop), it definitely won’t save you the time you need to put to learn to program.

That said, as you go, you will pick up things that are bound in mathematics. If you dive into more, let’s say, scientific part of programming, you will definitely make use of linear algebra, game and complexity theory. If you dive into more visual part, you’ll need some geometry to describe objects you’re working with.

But, do you need a degree to work in IT? No. Simple as that. I don’t have a degree, and a lot of my colleagues don’t have one neither. Sure, people have PhDs and it certainly won’t be a burden, but it’s far from required today.

Some companies, though, will require formal education on principle. This is something you cannot jump through, but, as time goes by, I see even the most stubborn ones are relaxing their requirements and often a degree can be swapped with years of experience. But, you need these years first, right?

Getting a job is hard, but once I land it, I’m golden

It’s 2024 and the tech industry is in a very weird place. Five years ago, getting a job as a junior wasn’t that hard. Companies were more willing to risk hiring someone with lesser knowledge, but great attitude and energy. I myself hired a lot of juniors, because I knew these folks will be productive very soon. Today though, it’s not that simple. Interviews are hard to come by, and when you go to one, it turns out there’s five more ahead, each lasting for at least an hour, three coding challenges and an open panel.

The fact is, landing a job today is hard, even for more senior developers. I spoke with a colleague over the weekend and he told me he’s on the market for three months, and he can count automated rejection emails most likely in hundreds. Companies are using AI tools, which are far from perfect, to screen CVs and LinkedIn profiles, recruiters do the same due to sheer amount of applications.

But if you manage to put your foot through the door, are you golden?

No.

Replacing a developer is easier that it looks, and very often companies will let go people that are crucial to their operations. For me, letting people go was always a huge challenge and I always did my best not to let this happen. But I know managers that will brag about firing twenty-something folks in one day or will boast on how they cut costs by reducing the team from six to two developers.

So, what to do to be safe? I wish I knew. Putting good performance is definitely a good thing, but not a golden rule. As I hate to say it, keeping to yourself is also a safe bet. As a manager I always encourage people to speak up, but I also heard many times that I too open or simply to “quit if you don’t like it”.

But! There’s a line between “speaking up” and “being a toxic idiot”, which I, frankly, understood too late. When I look back at myself, I certainly see that I wasn’t the easiest to work with, and I oftentimes spill my frustration with management on my colleagues. This is something that will get you through the door quicker that you think, because it’s extremely destructive. Having someone who complains daily hinders team’s morale and acts like a rot, consuming everything around.

It’s an easygoing job

So all you need to do is sit calmly and code? Just surf this high payroll wave? In theory, yes. In practice, it’s taxing as hell.

One thing that you need to understand early is that you are not hired for your programming skills. Business don’t care if you know ten languages prominently and can do hard online coding challenges. Business care for your problem solving skills. You are hired to solve problems, such as a need for a particular feature, a bug that needs to be resolved, or a performance issue that needs to be optimized.

Your skills will surely contribute to this, but that’s where interviewing using Leet Code fails: no amount of solved algorithms will teach you to see customer problems.

And once you do finish a feature, your solution gets deployed. All the clients will see it, so if it breaks, they’ll know. They won’t know you did it, but it will hinder the company you work for in their eyes, and this will certainly leave a mark. It’s extreme pressure, and myself, even after over 15 years of doing this, am still stressed whenever my changes are going live.

But the satisfaction that everything works perfect and your solution brings value is unparalleled.

I will work with new libraries and frameworks

You know now what is important at your job. You see tasks and user stories as challenges. You spend your free time researching new stuff that might be useful. And you finally found this one library that can solve the problem you are facing at your day job. So you send it to your lead, asking if you can implement this first thing in the morning.

And they say “no”.

Why is this idiot blocking me? Out of jealousy that I found it? Because they lack knowledge? Or because they are just stupid beyond reason?

All of the above, for sure.

Sometime ago I wrote a piece “Real cost of your new library”, in which I dive deeper into the conundrums of introducing new technology into a project. But the gist is, any code that is not authored by the team needs to be at least known or adaptable by the them. Something perfect for you might not be so for others, and they might see problems you don’t. Perhaps it’s immature, poorly documented or has poor performance under a heavy load?

This is where seniority and experience kicks in. It’s the ability to judge whether a new vendor is a risk worth taking to solve a problem at hand. Cost of choosing poorly is extremely high, as it will plague your application for months, if not years. Let’s go back to what I’ve said earlier: your job is to solve business problems, not to constantly change the insides of the product.

That being said, today’s landscape definitely offers far more battle-tested solutions that it did ten years ago, so you (most likely) won’t be stuck with one framework for your whole career. Unless you work in Java, in which case, happy Spring-ing.

(I really like Spring.)

I’ll be working on cutting edge hardware

Tech industry seems like the place to get your hands on the latest and greatest hardware, right?

Well, yes. And no.

It all depends on the company you’re working for. Startups often won’t have money to get you a brand new MacBook Pro with tons of RAM. Larger companies will fall into two brackets: will give you refurbished computer or will get you a new one. I had two times when a company asked me for specs and just got me the hardware. Certainly a great touch, but doesn’t happen that often.

Most of the times, you’ll get someone else’s computer. Maybe the person that had this position before you. Or just another laptop that sits in that murky room where only technicians are allowed.

Bottom line is, don’t get your hopes up. I worked with both new MacBooks, and some decade-old PCs that struggled with Chrome and Sublime Text running together. There’s no rule telling which you’ll end up using.

—

Tech industry certainly have its fables and legends. A lot of these don’t make much sense though. My only advice is to keep your mind open and expectations in check.

Good luck at your job!