Eight mistakes I made when I was a junior
At the beginning of a developer’s career, it is often scary: unfamiliar problems arise before you, you need to learn a lot, and you have to make difficult decisions. And in some cases we are mistaken in these decisions. It is quite natural, and you shouldn’t bite yourself about it. But what you have to do is memorize your experience for the future. I am a senior developer who made a lot of mistakes in his time. Below I will talk about eight of the most serious of them, which I did when I was still a newcomer to development, and explain how they could have been avoided.
When you learn to write code on your own or graduate from university, getting a first job in a specialty becomes one of the main goals. Something like light at the end of a long tunnel.
And finding a job, meanwhile, is not easy. There are more and more people who are applying for junior jobs. We have to make a cool resume , go through a series of interviews, and often the whole process is dragged out. Given all this, it is not surprising that any job offer causes a desire to cling to it with both hands.
')
And yet this may be a bad idea. My first job was far from ideal, both in terms of professional growth, and in terms of pleasure from the process. The developers were guided by the motto "and so it will come down," and it was not particularly stressed. Everyone tried to put the blame on each other, and I often had to cut corners to meet the deadlines. But the worst - I absolutely did not learn anything.
At the interviews, I missed all the bells past my ears, so I was fascinated by the prospect of getting a job. If any doubts arose, they all flew out of my head as soon as I heard that they were taking me! Yes, for a good salary!
And that was a big mistake.
The first job is of great importance. It gives a general idea of what it is like to be a real programmer, and the experience and training that you get from it can lay the foundation for an entire future career. That is why it is necessary to properly find out everything about the vacancy and the employer, before agreeing. Difficult experience, bad mentors - you definitely do not need this.
The interview is the best opportunity to get to know the company closer, so be sure to gather questions about what you want to learn from the staff. Here are a couple of examples:
Undoubtedly, the path to becoming an experienced developer winds up a lot. Now there is an opportunity to choose from a variety of languages, frameworks and tools. My mistake at the beginning of my career was that I tried to master everything. No matter how ridiculous, it only led to the fact that I was not particularly advanced. First I grabbed Java, then jQuery, then moved to C #, from it to C ++ ... Instead of choosing one language and throwing all my strength at it, I jumped from fifth to tenth, just in the mood. I can assure you, this is a very inefficient training scheme.
I would have achieved better results and would have moved faster through the career ladder if I had immediately decided on the trajectory, that is, a certain set of technologies, and focused on them. For example, if you are a front-end vendor, learn JavaScript, CSS / HTML and any framework of your choice. If you are engaged in a backend, again, take one language and study it properly. It is not necessary to own both Python, and Java, and C #.
So focus, decide on the direction and make a plan that will allow you to become a professional on the chosen path (here's a road map that can help you with this).
So, you are preparing a test to show your skills to the employer, or have already taken up the first task at your first job. You are trying to make an impression. How to most accurately achieve the result? Probably, to demonstrate in the course of performing that clever technique that you have recently mastered, right?
Not. This is a serious mistake that I myself made, and more often than I would like, I see in the work of other juniors. It is very common for them to reinvent the wheel or search for complex solutions in an attempt to show off knowledge.
The best approach to writing code is expressed in KISS principle . Striving for simplicity, you will get a clear code at the output that you can easily work with in the future (the developer who will replace you will appreciate it).
Never “disconnecting” is a bad habit, which I acquired very early. When I was going home at the end of the day, I regularly took the working laptop with me and sat for hours to close the task or fix the bug, although both could well wait until morning. As expected, such a regime caused stress and I quickly burned out.
The reason for this behavior was partly in my desire to do everything as quickly as possible. But in fact I should have understood that work is a long-term process and, with rare exceptions, today's shortcomings are calmly postponed until tomorrow. It is very important to switch from time to time and remember that life is not limited to work - there are friends, family, hobbies, and entertainment. Needless to say, if you like to sit until the dawn over the code - for God's sake! But when it is no longer a joy, stop and think about whether it’s time to do something else. We are not the last day working!
To get stuck in the process of solving a problem or performing a task is common, even the most senior seniors encounter this. When I was a junior, I said: “I don't know” less often than it should, and this was wrong. If someone from the management asked me a question, and I did not know the answer, I tried to let the fog go instead of just admitting it.
It seemed to me, if I said: “I don’t know,” people will get the impression that I don’t understand what I’m doing at all. In fact, this is not at all the case, omniscient does not happen. Therefore, if you are asked about something that you do not know, say so. This approach has several advantages:
You have probably heard the saying: “Before you run, learn to walk.” It is nowhere more relevant than in the field of web programming. When you first get a job as a junior, you just want to take the bull by the horns and immediately take on some large, complex project. Even thoughts about how to quickly make a raise to the next level slip!
Ambition is, of course, good, but in fact no one will give anything like this to the junior from the doorway. At the very beginning of your career, you will most likely get simple tasks and correction bugs. Not the most exciting activity in the world, but where to go. This will allow you step by step to get comfortable in the code base and explore all the processes. At the same time, your boss gets the opportunity to see how you fit into the team and what you do best.
My mistake was that I was annoyed at these minor tasks and it distracted me from work. Have patience, do whatever they ask, conscientiously, and soon you will get something more interesting.
Developers have a great community: they are always ready to help, give feedback and even cheer. Programming is a complicated thing and sometimes very exhausting. For me, the period of work as a junior would be easier if I started to actively communicate with my colleagues from the very beginning.
Community contacts are also very useful for self-education. You can make contributions to open source projects, study someone else's code, watch how programmers lead a project with joint forces. All of these are skills that you can use in your main job and that will eventually make you a good specialist.
Choose the communities that are of interest to you - among the options I can call freeCodeCamp, CodeNewbies, 100DaysOfCode - and join! You can also visit local meetings in your city (look at meetup.com).
Finally, in this way you will be able to acquire professional connections. In fact, communication is simply the people from your industry with whom you communicate. Why do you need it? Well, let's say you ever want to change jobs. If you contact your contacts, someone might advise you on a suitable vacancy, or even recommend you to an employer. This will give you a significant advantage in the interview - for you have already put in a word, you are no longer "just another resume from the stack."
That's all, thank you for your attention!
Took the first thing offered
When you learn to write code on your own or graduate from university, getting a first job in a specialty becomes one of the main goals. Something like light at the end of a long tunnel.
And finding a job, meanwhile, is not easy. There are more and more people who are applying for junior jobs. We have to make a cool resume , go through a series of interviews, and often the whole process is dragged out. Given all this, it is not surprising that any job offer causes a desire to cling to it with both hands.
')
And yet this may be a bad idea. My first job was far from ideal, both in terms of professional growth, and in terms of pleasure from the process. The developers were guided by the motto "and so it will come down," and it was not particularly stressed. Everyone tried to put the blame on each other, and I often had to cut corners to meet the deadlines. But the worst - I absolutely did not learn anything.
At the interviews, I missed all the bells past my ears, so I was fascinated by the prospect of getting a job. If any doubts arose, they all flew out of my head as soon as I heard that they were taking me! Yes, for a good salary!
And that was a big mistake.
The first job is of great importance. It gives a general idea of what it is like to be a real programmer, and the experience and training that you get from it can lay the foundation for an entire future career. That is why it is necessary to properly find out everything about the vacancy and the employer, before agreeing. Difficult experience, bad mentors - you definitely do not need this.
- Look for information about the company. Browse review sites, check out the official website, just browse the Internet and get feedback. So you better understand if the company meets your needs and goals.
- Ask friends. If someone in your circle worked for this employer or knows someone in the state, talk to them in person. Find out what they liked, what they didn’t like and how they generally rate the experience.
Did not ask the right questions at the interviews
The interview is the best opportunity to get to know the company closer, so be sure to gather questions about what you want to learn from the staff. Here are a couple of examples:
- Ask about the development process (what methodologies do they follow? Is the code inspected? What are the branching strategies?)
- Ask about testing (what tests are conducted? Are there any special people who are involved only in testing?)
- Ask about corporate culture (how informal is it? Is there any support for juniors?)
I did not decide on the trajectory of movement
Undoubtedly, the path to becoming an experienced developer winds up a lot. Now there is an opportunity to choose from a variety of languages, frameworks and tools. My mistake at the beginning of my career was that I tried to master everything. No matter how ridiculous, it only led to the fact that I was not particularly advanced. First I grabbed Java, then jQuery, then moved to C #, from it to C ++ ... Instead of choosing one language and throwing all my strength at it, I jumped from fifth to tenth, just in the mood. I can assure you, this is a very inefficient training scheme.
I would have achieved better results and would have moved faster through the career ladder if I had immediately decided on the trajectory, that is, a certain set of technologies, and focused on them. For example, if you are a front-end vendor, learn JavaScript, CSS / HTML and any framework of your choice. If you are engaged in a backend, again, take one language and study it properly. It is not necessary to own both Python, and Java, and C #.
So focus, decide on the direction and make a plan that will allow you to become a professional on the chosen path (here's a road map that can help you with this).
Refined in the code
So, you are preparing a test to show your skills to the employer, or have already taken up the first task at your first job. You are trying to make an impression. How to most accurately achieve the result? Probably, to demonstrate in the course of performing that clever technique that you have recently mastered, right?
Not. This is a serious mistake that I myself made, and more often than I would like, I see in the work of other juniors. It is very common for them to reinvent the wheel or search for complex solutions in an attempt to show off knowledge.
The best approach to writing code is expressed in KISS principle . Striving for simplicity, you will get a clear code at the output that you can easily work with in the future (the developer who will replace you will appreciate it).
I forgot that there is life outside the code
Never “disconnecting” is a bad habit, which I acquired very early. When I was going home at the end of the day, I regularly took the working laptop with me and sat for hours to close the task or fix the bug, although both could well wait until morning. As expected, such a regime caused stress and I quickly burned out.
The reason for this behavior was partly in my desire to do everything as quickly as possible. But in fact I should have understood that work is a long-term process and, with rare exceptions, today's shortcomings are calmly postponed until tomorrow. It is very important to switch from time to time and remember that life is not limited to work - there are friends, family, hobbies, and entertainment. Needless to say, if you like to sit until the dawn over the code - for God's sake! But when it is no longer a joy, stop and think about whether it’s time to do something else. We are not the last day working!
Avoid saying: "I do not know"
To get stuck in the process of solving a problem or performing a task is common, even the most senior seniors encounter this. When I was a junior, I said: “I don't know” less often than it should, and this was wrong. If someone from the management asked me a question, and I did not know the answer, I tried to let the fog go instead of just admitting it.
It seemed to me, if I said: “I don’t know,” people will get the impression that I don’t understand what I’m doing at all. In fact, this is not at all the case, omniscient does not happen. Therefore, if you are asked about something that you do not know, say so. This approach has several advantages:
- It is fair - you do not mislead the questioner
- There is a chance that they will explain to you and then you will learn something new.
- This causes respect - not everyone is able to admit that something is unknown to him.
Hurry to move
You have probably heard the saying: “Before you run, learn to walk.” It is nowhere more relevant than in the field of web programming. When you first get a job as a junior, you just want to take the bull by the horns and immediately take on some large, complex project. Even thoughts about how to quickly make a raise to the next level slip!
Ambition is, of course, good, but in fact no one will give anything like this to the junior from the doorway. At the very beginning of your career, you will most likely get simple tasks and correction bugs. Not the most exciting activity in the world, but where to go. This will allow you step by step to get comfortable in the code base and explore all the processes. At the same time, your boss gets the opportunity to see how you fit into the team and what you do best.
My mistake was that I was annoyed at these minor tasks and it distracted me from work. Have patience, do whatever they ask, conscientiously, and soon you will get something more interesting.
Did not join the community and did not acquire connections
Developers have a great community: they are always ready to help, give feedback and even cheer. Programming is a complicated thing and sometimes very exhausting. For me, the period of work as a junior would be easier if I started to actively communicate with my colleagues from the very beginning.
Community contacts are also very useful for self-education. You can make contributions to open source projects, study someone else's code, watch how programmers lead a project with joint forces. All of these are skills that you can use in your main job and that will eventually make you a good specialist.
Choose the communities that are of interest to you - among the options I can call freeCodeCamp, CodeNewbies, 100DaysOfCode - and join! You can also visit local meetings in your city (look at meetup.com).
Finally, in this way you will be able to acquire professional connections. In fact, communication is simply the people from your industry with whom you communicate. Why do you need it? Well, let's say you ever want to change jobs. If you contact your contacts, someone might advise you on a suitable vacancy, or even recommend you to an employer. This will give you a significant advantage in the interview - for you have already put in a word, you are no longer "just another resume from the stack."
That's all, thank you for your attention!
Source: https://habr.com/ru/post/447854/
All Articles