Early in your career as a developer, it can often be daunting: you face unfamiliar problems, you have a lot to learn, and you have to make difficult decisions. And in some cases, we are wrong in these decisions. This is quite natural, and you should not bite yourself about it. But what you should do is remember your experience for the future. I am a senior developer who made a lot of mistakes in my time. Below, I'll talk about the eight most serious ones that I made when I was still new to development, and explain how they could have been avoided.
I took the first one that was offered.
When learning to write code on your own or graduating from university, getting your first job in your specialty becomes one of the main goals. Kind of like a light at the end of a long tunnel.
And finding a job, meanwhile, is not easy. There are more and more people who apply for junior positions. account for , go through a whole series of interviews, and often this whole process is greatly delayed. Given all this, it is not surprising that any job offer makes you want to cling to it with both hands.
Still, it might be a bad idea. My first job was far from ideal, both in terms of professional growth and in terms of enjoyment of the process. The developers were guided by the motto "and so it will do", and it was not customary to strain especially. Everyone tried to put the blame on each other, and I often had to cut corners to meet very tight deadlines. But the worst thing is that I learned absolutely nothing.
At interviews, I ignored all the calls by the 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! Plus a good salary!
And that was a big mistake.
The first job is of great importance. She gives you a general idea of ββwhat it's like to be a real programmer, and the experience and training you get from her can lay the foundation for your entire future career. That is why it is necessary to find out everything about the vacancy and the employer before agreeing. Hard experience, bad mentors - you definitely donβt need this.
- Look up information about the company. Look around the sites with reviews, look at the official website, just surf the Internet and collect reviews. This will give you a better idea of ββwhether the company fits your needs and goals.
- Ask your friends. If anyone in your circle has worked for this employer or knows anyone in the state, talk to them personally. Find out what they liked, what they didn't like, and how they overall rate the experience.
Not asking the right questions in interviews
Interviews are the best opportunity to get to know the company better, so be sure to prepare questions about what you want to ask employees. Here are a couple of examples:
- Ask about the development process (what methodologies do they follow? is code reviewed? what branching strategies are used?)
- Ask about testing (what tests are done? are there special people who only do testing?)
- Ask about corporate culture (how informal is it? is there any support for juniors?)
Undecided on the trajectory
Undoubtedly, the path to becoming an experienced developer is very winding. There are now many languages, frameworks, and tools to choose from. My mistake at the beginning of my career was that I tried to master everything. Ironically, it only led to the fact that I didnβt make much progress in anything. First I grabbed Java, then JQuery, then moved on to C #, from it to C ++ ... Instead of choosing one language and throwing all my strength into it, I jumped from fifth to tenth, just by my mood. I can assure you, this is a highly inefficient training scheme.
I would achieve better results and move up the career ladder faster if I immediately decided on a trajectory, that is, a certain set of technologies, and focused on them. For example, if you're a front-end developer, learn JavaScript, CSS/HTML, and any framework of your choice. If you are doing back-end, again, take one language and study it properly. You don't have to be proficient in Python, Java, or C#.
So focus, decide on a direction, and make a plan that will allow you to become a professional on your chosen path (here which can help you).
Sophisticated in code
So, you are preparing a test to show the employer your skills, or have already taken on the first task at your first job. You go out of your way to impress. What is the best way to achieve results? Probably to demonstrate during the performance of that heaped technique that you have recently mastered, right?
No. This is a serious mistake that I myself made, and more often than I would like, I see in the work of other juniors. They tend to reinvent the wheel or look for complex solutions in an attempt to show off their knowledge.
The best approach to writing code is expressed . By striving for simplicity, you will end up with understandable code that will be easy to work with in the future (the developer who replaces you will appreciate it).
I forgot that there is life outside the code
Never "switching off" is a bad habit that I picked up very early on. When I got home at the end of the day, I regularly took my working laptop with me and sat at it for hours to close a task or fix a bug, although both could perfectly wait until the morning. As expected, such a regimen 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 reality, I should understand that work is a long-term process and, with rare exceptions, today's imperfections are quietly transferred to tomorrow. It is very important to periodically switch and remember that life is not limited to work - there are friends, family, hobbies, entertainment. Of course, if you like to sit until dawn on the code - for God's sake! But when it's no longer fun, stop and think about whether it's time to do something else. It's not our last day of work!
Avoided saying "I don't know"
Getting stuck in the process of solving some problem or completing a task is common, even the most senior seniors face it. When I was a junior, I said βI donβt knowβ less often than I should have, and I was wrong about that. If someone in management asked me a question and I didn't know the answer, I tried to obfuscate instead of just admitting it.
It seemed to me that if I said βI donβt know,β people would get the impression that I didnβt understand what I was doing at all. In fact, this is not so at all, there are no omniscient. So if someone asks you about something you don't know, say so. This approach has several advantages:
- It's fair - you don't 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 he does not know something
Hurry to advance
You've 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 somewhere as a junior, you just want to take the bull by the horns and immediately take on some large, complex project. Even thoughts of how to quickly earn a promotion to the next level slip through!
Ambition is, of course, good, but in reality, no one will give anything like this to a junior. At the very beginning of your career, you will most likely get simple tasks and bugs to fix. Not the most exciting activity in the world, but where to go. This will allow you to get comfortable with the codebase step by step and learn all the processes. At the same time, your superiors get a chance to see how you fit into the team and what you do best.
My mistake was that I was annoyed by these small tasks and this distracted me from work. Be patient, do everything that is asked, conscientiously, and soon you will get something more interesting.
Not included in the community and did not acquire connections
The developers have a great community: they are always ready to help, give feedback and even cheer. Programming is hard and sometimes very exhausting. For me, the period of work as a junior would have been easier if I had been actively communicating with colleagues from the very beginning.
Community contacts are also very useful for self-education. You can contribute to open source projects, study other people's code, watch how programmers lead a project together. All of these are skills that you can use in your main job and that will eventually make you a good specialist.
Pick the communities that interest you - freeCodeCamp, CodeNewbies, 100DaysOfCode are some of the options - and get involved! You can also attend local meetups in your city (look on meetup.com).
Finally, in this way you can acquire professional connections. Essentially, connections are just people in your industry that you connect with. Why is this needed? Well, let's say you ever want to change jobs. If you refer to your contacts, someone may be able to advise you on a suitable vacancy, or even recommend you to an employer. This will give you a significant advantage in the interview - you have already put in a good word for you, you are no longer βanother resume from a stackβ.
That's all, thanks for your attention!
Source: www.habr.com