Eight mistakes that I made when I was a junior

Original author: Chris Blakely
  • Transfer
At the beginning of a developer’s career, it’s often scary: you face unfamiliar problems, you have to learn a lot and have to make difficult decisions. And in some cases we are mistaken in these decisions. This is quite natural, and you should not bite yourself about this. But what is worth doing is to remember your experience for the future. I am a senior developer who made a lot of mistakes at one time. Below I will talk about the eight most serious of them that I committed when I was still a beginner in development, and I will explain how they could be avoided.

Took the first thing that was offered

When you learn to write code on your own or you finish your studies at the university, getting your first job in a specialty becomes one of the main goals. Something like the 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 vacancies. One has to compose an awesome resume , go through a series of interviews, and often this whole process is greatly delayed. 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 turn out to be a bad idea. My first work was far from ideal, both in terms of professional growth, and in terms of the pleasure of the process. The developers were guided by the motto “and so it will do”, and it was not customary to particularly strain. Everyone tried to blame each other, and I often had to cut corners to meet a very tight deadline. But the worst part is that I have not learned anything at all.

At the interviews, I missed all the calls 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 work is of great importance. It gives a general idea of ​​what it feels like to be a real programmer, and the experience and training that you get from it can lay the foundation for your entire future career. That is why it is necessary to properly find out everything about the vacancy and the employer before agreeing. Hard experience, bad mentors - you definitely don't need this.

  • Look for company information. Go to the sites with reviews, look at the official site, just surf the Internet and collect reviews. This way, you’ll better understand whether the company meets your needs and goals.
  • Ask your friends. If someone in your circle has 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 value the experience.

I did not ask the right questions at the interviews.

Interviewing is the best opportunity to get to know the company more closely, so be sure to collect questions about what you want to know from employees. Here are a couple of examples:

  • Ask about the development process (what methodologies do they follow? Is there code inspection? What branching strategies are applied?)
  • Ask about testing (what tests are carried out? Are there any special people who are engaged only in testing?)
  • Ask about corporate culture (how informal is everything? Is there any support for juniors?)

Undecided on the trajectory of movement

Undoubtedly, the path to becoming an experienced developer is very winding. Now it is possible to choose from many languages, frameworks and tools. My mistake at the beginning of my career was that I tried to master everything. Funny as it may seem, this only led to the fact that I didn’t make much progress. 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 at it, I jumped from fifth to tenth, just by mood. I can assure you, this is an extremely inefficient training scheme.

I would have achieved better results and would have moved up 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 user, learn JavaScript, CSS / HTML, and some kind of framework of your choice. If you are doing a backend, again, take one language and study it properly. You don't have to own Python, Java, or C #.

So focus, decide on the direction and make a plan that will allow you to become a professional on the chosen path (here is a road map that can help you with this).

Sophisticated in code

So, you are preparing a test to show your employer your skills, or have already taken up the first task at your first job. You go out of your way to impress. What is the best way to achieve a result? Probably, to demonstrate during the execution of that tricked out technique that you recently mastered, right?

Not. This is a serious mistake that I myself made, and more often than I would like to see in the work of other juniors. It is very common for them to reinvent the wheel or look for complex solutions in an attempt to show off knowledge.

The best approach to writing code is expressed in the KISS principle . Striving for simplicity, you get an understandable code that will be easy to work with in the future (the developer who comes to replace you will appreciate it).

Forgetting that there is life outside of code

Never “disconnect” is a bad habit, which I acquired very early. When I was going home at the end of the day, I regularly took a working laptop with me and spent hours behind it to close the task or fix the bug, although both of them could perfectly wait until the morning. As expected, such a regimen caused stress and I quickly burned out.

Part of the reason for this behavior was my desire to do everything as quickly as possible. But in fact, I should understand that work is a long-term process and, with rare exceptions, today's imperfections are calmly carried forward 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 before dawn over the code - for God's sake! But when it’s not a joy, stop and think about whether it’s time to do something else. We are not working the last day!

Avoid saying: “I don't know”

Getting stuck in the process of solving a problem or completing a task is common, even the most senior seniors are faced with this. When I was a junior, I said: “I do not know” less often than it should, and this was wrong. If someone from the management asked me a question, but I did not know the answer, I tried to let the fog in, 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 true, there are no omniscient ones. Therefore, if you are asked about something that you do not know, say so. This approach has several advantages at once:

  • This is honest - you do not mislead the questioner
  • There is a chance that they will explain to you and then you will learn something new
  • This is respected - not everyone is able to admit that he does not know something

Hastened to advance

You 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 yourself somewhere as a junior, you just want to take the bull by the horns and immediately start some large, complex project. Even thoughts slip up on how to quickly earn a raise to the next level!

Ambition is, of course, good, but in reality no one will give anything like this to a junior from the doorway. At the very beginning of your career, you will most likely get unpretentious tasks and fix bugs. Not the most exciting activity in the world, but where to go. This will allow you to get used to the code base step by step and learn all the processes. At the same time, your superiors get 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. Be patient, do whatever you ask for conscience, and soon something more interesting will come to you.

Not included in the community and not made connections

The developers have a great community: they are always ready to help, give feedback and even cheer. Programming is a complicated thing and at times very exhausting. For me, the period of working as a junior would be easier if I began to actively communicate with colleagues from the very beginning.

Communicating with the community is also very useful for self-education. You can make a contribution to open source projects, study someone else's code, observe how programmers lead the project together. All these are skills that you can use in your main job and which over time will make you a good specialist.

Choose the communities that interest you - I can name freeCodeCamp, CodeNewbies, 100DaysOfCode among the options - and get involved! You can also visit local rallies in your city (search meetup.com).

Finally, in this way you can grow professional connections. In fact, communications are simply those people from your industry with whom you communicate. Why is this needed? Well, let's say you someday want to change jobs. If you turn to your contacts, someone may advise you on a suitable vacancy, or even recommend you to your employer. This will give you a significant advantage in the interview - the word has already been put up for you, you are no longer “another resume from the pile”.

That's all, thanks for watching!

Also popular now: