Our website uses cookies to enhance your browsing experience.
This article is purposed to be in a friendly spirit manner and carries neither mockery, nor snobbery. It intends to protect from unnecessary stress those who are entering the programming world for the first time. If you are learning to sort arrays, parse strings right now and believe in "oh, yes, this is what I'm going to do at work" — keep reading to find out newbies' common misbeliefs.
We published and translated this article with the copyright holder's permission. The author is Ivan Belokamentsev. The article was originally published on Habr.
There is such a thing as survivorship bias. Put simply, most of us tend to focus on successful people, businesses, or strategies and ignore those who failed — "did not survive". As a result, we perceive the random variable as a stable. This can lead to incorrect conclusions. If you want to dive deeper into this concept, read Nassim Taleb or Daniel Kahneman. Their books are much cheaper than programming tutorials.
I will describe common mistakes of "non-survivors" — of people, who failed to become a part of the programming world. Here you're going to read about what I experienced and observed along my way as a developer.
By the way, if you say that "nothing here is true ", "my friend Mike is succeeded..." or "I'm succeeded!" — that's ok, you can pass by this article. You and your friend Mike are "survivors".
You do expect a lot from programming, but you are soon disappointed when reality does not measure up. That's one of the most common case. On the one hand, you might seem, I introduced my idea rather vaguely. It demands more specifics. On the other hand, you can put any real story behind it.
The only expectation from getting into programming that will not be deceived: you will have a lot to overcome. Really, a lot. And all this will take a lot of time.
It's a wrong solution to rely on courses as a stepping stone to programming. The courses may help you catch up or sharpen your skills. For example, you can learn a new programming language or get hang of a new technology.
The majority of tutorials is just a marketing ploy. No one will buy a tutorial that is called "it wouldn't help you much". These courses create inflated expectations.
The second problem stems from the first — the duration of courses and the amount of information they provide. Tutorials cannot cost as much as SUVs and contain the information that would be learnt over 5 years. Knowledge is like a pie, the slice of which needs to be the right size — it should be sufficient but still swallowable.
Those who started with courses in fact, still can't code. They get into the programming world after a month's courses and sure, that the basic constructions of the programming languages are enough for them.
Those who take programming courses just to hone the skills usually survive.
In most respected professions, if we don't consider executive positions, people leave thoughts of work behind after the end of their working day. Over the years, people get used to this working pattern. And this is the pattern of work they come to the programming world with.
I don't mind this, but it is extremely difficult to get into programming within one working day. It would be like a drop in the bucket. There's too much to learn. No kidding, there is an insane amount of important information. And new information is appearing faster than you learn the old staff.
It's not just about theory. It's essential to put knowledge — your own and others' — into practice. Cases, products, fuck ups — these are ways that help us gain valuable experience here.
Some newcomers may say, "I don't need to learn it all, just some of it. Everything will be okay." But this is about you in particular. What's about teamwork? If it's necessary, you need learn new skills for the project your team is working on.
You will have to learn a lot, a lot of information. And in the short time. Simply put, you'll have to learn more and faster than you have ever learnt, more than at the university.
Wherever the companies take newcomers and interns, they promise to help, give a mentor, provide you with a quick start guide, etc. Some (eventually non-survivors) unfortunately think that such support will be long term and with a constant intensity. As a mentor sat by their side for half a day in the first month, so the mentor would do the same for the next six months. Alas.
A mentor is a guide and is not supposed to work like a dog. They will direct you, but you will have to walk with your own feet. Sometimes mentors will sink out of sight — they have enough work of their own. And newcomers will have to cope with tasks on their own — Some of them get discouraged at this point.
But the mentor is observing. And actually, their primary responsibility is to observe, not to help at all. If mentors have enough experience, they can form an opinion of the intern after a few days. The main idea is not that you need to know a lot or ask a lot of questions, but that you need to have a desire to learn and strive to do so every day.
During tutorials or self-studying, you code a lot. When you start to work, you continue coding a lot — you get the simplest tasks without diving into the context. It's like planting a tree under the lenses of TV cameras — it doesn't seem like a hard thing to do, you're involved in the case, and even memorized.
Then the tough stuff begins — weeks and months without a single written line of code. Because, first, you need to find the fragment where to write the code. Then you have to figure out what exactly to write. The first time it's damn hard and scary. If the mentor is not like a mommy, they will let you go through this fear. Natural selection mode will engage you into the process.
No matter how many years you work as a developer, shitcode will always surround you — including your own code that you wrote 100 years ago. "It should be done, it's part of the job".
Alas, at this stage, a lot of people burn out and run away. Their reasons range from "I can't cope with this" to "it's not programming".
This comes up from aggressive marketing of online courses that promise rapid income growth. Well, thanks God, that people don't take out loans before they enter the programming world.
At first a person in programming does not get much. If they are not new grades, they usually have a family, children, and a mortgage under the belt. The drop in income can be sharp and long-lasting — it depends on the desire to survive in the programming world. Many people simply can't stand it, in particular men in their 30s.
I don't know where the following idea comes from, but people believe that their rainy-day fund is enough for 2-3 months. What happens in 3 months is clear: "I want to try, I try, and it seems that things are working out, however I do have obligations, I can't let my family down".
Once again — I write this without irony and mockery, I have a family and obligations myself. I entered the programming world with a salary of 80$ per a month.
Therefore, dear friends and men over 30: save up a rainy-day fund for at least six months. And don't burn bridges with the previous or the new job.
Oddly enough, this is one more reason why budding programmer might not survive. I'm dead serious — some interns are turned into zealous defenders of their own vision of the route to successful developer. They criticize the values of the employer.
Nah, they'll listen — just for fun. Then, they will offer you the freedom to choose your own path. Along with the freedom to pay your own salary. Then there are two typical scenarios. You either smile, apologize, and get back to work or quit your job with head held high.
There are quite a lot of freeloaders taking the easiest route possible. The scenario is similar to the University study — they blend in, barely pass exams, learn how to solve a couple of typical tasks of some specific areas and see no evil, hear no evil.
Unfortunately, this scenario is prone to work. The world of programming is diverse that there is a place for non-programmers there. But the survival rate is not worth it.
Typically, if it was your mother — she most likely made you study at a university or college to become a programmer. If it was your wife, then the idea was something like this: "try something related to computers", because "Look at Snezhana's husband, he is raking in the money". Snezhana's husband may make boatload of money, but it's very difficult to overcome yourself in an attempt to replicate "Snezhana's husband's success" or if your mom pushed you to do so.
Such a scenario leads to both dominance hierarchy instinct and inferiority complex. Put simply, you would be just an apathetic or nervous dude who slaves away every single day and don't understand what you are doing here. This also leads to the lack of motivation.
As we know, energy attracts same type of energy. In an attempt to get rid of a forced choice or to justify it you're looking for people with the same problems, holding heart-to-heart talks, almost incite a riot or fool some not very confident newcomers and astray them.
Don't do that, please. Don't waste time of good folks, including yourself.
There is a common misbelief in programming, that you can google all the answers. Before we dispel the misbelief, I would say — it is a truth to some extent. A significant part of tasks has long been algorithmized.
But some tasks require a creative approach. You're lucky if after a few days of the probation period, you would realize that you need to think a lot, invent, screw up and sometimes comprehend the programming world blindly.
No matter how hard the developers try to invent new techniques to have the code written for them, a developer has always been and still remains to be a creative profession. Let me repeat — this is not a show-off. You need to come up with solutions. Well, it's not the difficult times as the 2000's were. I mean there is something to rely on and don't use "five-finger discount".
Unfortunately, there are those who have not survived, who have refused to think. They literally twiddle thumbs and ask, " What do I need to code?".
One of the common mistakes is the wrong starting place — the wrong company or even the wrong field. There's nothing particularly scary here, just listen carefully to the job interviewer's story about the company and not be afraid to express your desires.
And the following states how it happens. Various fields are made to teach different things — developers, technical support staff and so on. Suppose, the person desires to be a support engineer, but fears to tell HR about this — nobody wants to see HR's condescending smile (spoiler: HR is paid to close the position).
So, they suffer, then cease — "don't survive" and leave. Sometimes the opposite happens — some people dream about becoming developers, but they fear to fail, they tend to grab a tit. There seems to be a right choice and a good salary, but they never be a part of the programming world. After that, it becomes even more difficult to change the field.
The problem is generalized but is commonly widespread. The person gets hired, work for a while, a mentor supervises them and helps, however the intern gets depressed and quits at a moment with thoughts like "I am failing," "I can't do it," "others are so much better".
Moreover, the mentor might fail to dissuade the person from quitting. They are determined to quit (or even have a new job lined up). Of course, the mentor and/or the boss would get their due, since they did not notice the problem in time, did not support the newcomer, and all at once.
But we are talking about the reasons why people "don't survive". And such a reason does exist, alas. The intern faces the natural fight-or-flight response, and is not ready to freeze or fight.
You believe that if you "feel" like you are not doing well, that's the reality. Even though someone convinces you of the opposite. I suppose that "a student syndrome" is often involved here — you need to fill your CV, consider the points for the SAT and diploma's overall score. People are used to maintaining their inferiority complex, and other people only meddle them.
If you have come to be a part of the programming world, trust the assessment of only one person — your mentor. Or whatever you call them. It is better to clarify your ambiguities with your mentor then and there.
P.S.
Of course, the list is not complete — it is based on personal experience. I can prove each chapter by a bunch of real-life examples though. I seem to be biased against people who have failed and those who have succeeded — that reminds the term "survivorship bias", doesn't it? However, there are only real-life stories here that I have experienced along my way as a developer.
Looking forward you to sharing your own experience in comments.
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0