10 tips for juniors ... No, 10 tips for every developers

10 tips for juniors ... No, 10 tips for every developers

I managed to collect 10 things that we often forget about. Each of them is extremely important both during the first job in IT and at later stages of the career. Of course, you can agree with me or not, that's your business. Are we starting?

Code Review is there to learn

During Code Review, most of us get a lot of feedback, no matter if we are juniors or seniors. Very often these are specific suggestions that allow us to improve the code that we have already written. Most of the comments that will be included in code review should be discussed later to make sure that we really understand what we are changing in our code, rather than just pasting it mindlessly and believing that it will make it better. We should never do that, because it leads to various idiocy.

Be sure to participate in team discussions

You may find yourself participating in a variety of design interviews. Sometimes they will be talks about the methodology of work or about technical solutions or architectural discussions. Don't be afraid to ask questions here if something is incomprehensible or share your ideas. Even if the solution is created by a tech lead, it may turn out to be extremely complicated or he / she cannot explain why it should be done one way or another. And if other programmers can explain a given solution in a simple way, it means that it is well thought out and a lot can be learned.

Use pair programming

Pair programming is a great solution if you need to find bugs in the code you are writing and want to write better code. This is how it works, and it works very, very well. If you can't explain to your partner why something was written one way or another, then this piece of code is definitely something to be thrown away. Another way is the rubber duck method. Every day, for eight hours of work, another person is a rubber duck to which we translate our code.

Get to know your team

I just like to know the people I work with. Then I feel much more comfortable asking all kinds of questions. It doesn't mean you have to do everything with your band, because maybe you don't drink and you don't want to go out for a beer. Or maybe you like to eat alone. But for example, I used to come to play board games a lot.

Consider whether you are responsible for the stress of delivering functionality for too long

All the estimates we make at work are speculative. You should know what the estimates are based on, because maybe they are just a fingerprint, or maybe someone can actually do what you are doing faster and more efficiently. Sometimes you can finish something faster, but don't worry if something was only supposed to take 3 days and it took the entire sprint. This is actually normal. Remember that if you have a real problem, someone will step in to help.

Ask if you can work on a side project in the product domain after hours

Each of the codebases I launched in my work seemed to me to be a huge creature at first that I thought I would never understand. But I often did side projects, such as a login system, that touched so many places in the code that I immediately had to learn certain parts. This knowledge helped me understand what I was actually writing in the sprint and why I was doing it. Additionally, with a little support from the company, I was able to get through the various release and testing processes. Additionally, I was able to pinpoint many parts of the application or process that I thought needed improvement. Studying on a side project has always been very important to me.

Writing code is really only part of the job

There is much more to being a developer, including writing good tests; cleanup and refactoring of old code; technical design and architecture decisions; understanding the product domain; user support; DevOps basics; deployment streams; and how to use the assistive technologies your team uses like Kubernetes, AWS, and Git, to name a few.

Don't compare yourself to anyone else on the team - that is, dealing with the cheating syndrome

This is what the industry talks about very often. If you want to code as fast as anyone else, you need practice. You need to understand your project. Sometimes you don't know as much as the other developers on your team. And it's not a bad thing. It just means that you are just getting into the project and you still need to learn and learn a lot about it. More important to you should be whether you know how to use Google and search for information. Additionally, it often takes just a bit of extra work on your part to become as good as the rest of the programmers on the team.

When it comes to technology, there is so much to learn that you can give yourself time

Each of us begins to learn something new. And wherever we look, there are as many as 10-20 things that should also be looked at and that may not be known. This is normal. If you come across one thing that you don't know and want to learn more about, set aside a few hours a week for it. If your boss is smart, he'll let you do things after working hours.

People can develop quickly or slowly, and there is nothing strange about it

Some of us spend a lot of time on our side projects and they grow rapidly. Others take a while to develop. And this is really normal and there is nothing to be ashamed of. I myself have recently been neglecting the transition from Java to Scala and learning Akk. But what should be remembered that each of us has his own private life, apart from what he does professionally. And again, this is absolutely normal.

Share this Post