The best thing to do is to plan your day in advance

[joxet11299]

and go to standups prepared. It is better to take three minutes before starting work or before going to bed to put everything you have managed to do on the shelves, determine what you have to do and what may prevent you from solving the task at hand.

If you come to a standup meeting fully prepared, you not only make a good impression on your team leader, but you also show yourself to be a very professional and reliable employee, even if you still get stuck and fail to complete the work that was planned for the day.

Don't be afraid to ask for help

It's important for a new developer to understand how and when to ask for help. You might spend five hours as a junior trying to figure something out, while more experienced developers might only spend five minutes (or even a few seconds) helping you.

It's entirely in your best interest (and it's in the company's best interest, too) to ask for help when you need it.

On the other hand, constantly rushing for help without even trying to solve the problem on your own is also not the best option. Therefore, before asking someone to help you, try to solve the problem yourself, and if this does not work, you can still search for a solution in Google (just paste the necessary location from the logs or the error message into the search bar). And if this does not lead to anything, then it is worth asking for help. In this case, you need to ask for help in an appropriate way.

Personal request for help

It is important to pay attention to the body language of the person you are planning to ask for help. If you get the feeling that this person is irritated or stressed, then it may make sense to first "ping" him and ask if it is possible to approach him with a question.

Also keep in mind that some people actually use the George Costanza trick (i.e., they may pretend to be busy).

Request for help via messenger

If you decide to ask one of your fellow developers for help by sending him a message via messenger, there are a couple of ways to increase the likelihood of a positive and fairly quick response.

Here's a bad example of a help request to start with: "Hey, can you help me? I can't install node.js on my PC, it doesn't work."

This is not a good idea. This message can be improved in a few simple ways. First, introduce yourself as if you have never spoken to this person before. Be sure to mention in the message that you have already tried to figure it out on your own. Tell where there are definitely no problems so that the person can quickly understand where there might be problems.

Here is a good option for addressing:

"Hi Sergey, this is Dmitry, I'm a new developer. Nice to meet you. I heard you might be able to help me with a problem I'm trying to solve. I'm trying to install Node.js on my PC. I've already tried this link (insert link here) and followed the instructions, but after I ran this command (insert command here), I got an error message (insert message text). I'm using one of the new MacBooks at work. Can you tell me what the problem might be?"

This message sounds much better. It gives the person a lot of information about what you have already tried to do on your own, and this way he will be able to understand more quickly what the problem is. When you do not provide this information, he has to ask you a lot of leading questions himself. The time that is spent on these questions, your colleague could have spent more usefully on his own affairs, which this person was doing before you bothered him.

In general, try to help the other person save more of his time. And to do this, you just need to give him more information about the problem you have to deal with.

How to behave when you have received assistance

First of all, forget about your ego.

If someone takes the time to help you with a problem, don't cambodia whatsapp number database pretend that you knew how to solve it. After the problem is solved, don't say, "That's exactly what I was going to do." Simply thanking your colleague is enough.

It's also best to refrain from making accusatory comments about someone. Don't say, "The backend team messed up, that's why it didn't work as expected." Instead, say, "I think it has something to do with the recent changes to the backend."

If you ask a question and later find a solution on your own, be sure to let the person you asked know. They may still be deciding how to help you, and since you solved it on your own, they can move on to the next task.



Manual code testing is a must

Code needs to be tested. Test happy paths (we are talking about typical paths of code execution) and, especially, do not forget to test non-happy paths. Try to break your code yourself. Remember - if you have bugs in your code, then users will definitely find them sooner or later. So it is better to try to find them yourself. And even if your company has a QA team, your goal is to make sure that this team does not find anything in your code. Also, learn to create testable code and tests for this code. Preparing testable code is usually outside the scope of the university program, but in fact, you learn this using the SOLID principles.

You can also ask your senior developers how to make tests for your code. They will probably appreciate that you are interested in this. They may even show you a trick or two. If they do not have this opportunity, or if you notice that the code base is not very rich in tests, the next thing to do is to test your own code manually.