Click “CSDN” at the top and select “Top public account”

Critical moment, the first time to arrive!

By Greg Sabo

Finishing by Su Mi

As a developer, taking the first step to ask for help can be difficult, but it’s a good time to practice collaborative problem solving with your colleagues.

I still remember the last time when Xiao Zhang, an employee of a large software enterprise in Nanjing, was controlled by a pyramid scheme organization and was almost desperate, he took the opportunity to communicate with his colleagues about the code and sent an SOS message by using the code path name. His fellow programmers unexpectedly “understood in seconds” and went to Tianjin to assist the police to solve him successfully.

The so-called “one minute on the stage, ten years of work off the stage”, collaboration is not a day, only after a long period of collaboration running-in, to achieve a certain tacit understanding, and this article to share an excellent development engineer to seek daily collaboration help skills, I hope to be helpful to you.

Today, it’s a new day. You go back to work and start the server, but again, the icy message err_node_unsafe appears on the screen. The same bugs that existed yesterday remain unchanged today.

It’s 9:48 a.m., and the rest of the team has barely arrived. This is your fifth week at the company, and the features you need to work on should have been completed two days ago.

When you’re stuck in a Bug and can’t take the first step to ask for help, first you raise your seat and imagine looking up at the screen again. After restarting the computer again, the stack trace slides into the terminal and again: err_node_unsafe. Refreshing the database: err_node_unsafe.

On the verge of collapse, look around. The technical lead of another team is sitting in his office chair, wearing headphones and indulging in his own world. So you think to yourself: Can he solve this problem? What would he say? Does he know what’s going on? Will he help me?

After thinking about it, you continue to look at the screen silently and decide to restart the computer again, praying that maybe this time, the mistake will disappear.

In fact, this is the daily routine for many of us developers, especially newcomers. Asking for help is the first hard step, and procrastination protects us. This is the main reason why you, as a developer, have to perfect your ability to ask for help. To be a good engineer, productivity is the key. Here are some collaborative tips for asking for help.

1. Clarify your expectations

Don’t start work with vague expectations, or the result will be ambiguous and fallible. Here’s an example:

  • Get out of the house and go to work.

  • Leave the house and go to the gym.

Which of the two things is easier to do? Going to work in the morning isn’t the easiest thing in the world, but it should be a lot easier than going to the gym. Because I know if I don’t show up for work, my co-workers or supervisors will find out THAT I’m not showing up. But usually, no one cares if I go to the gym. Lack of anticipation means lack of motivation.

When your expectations are unclear, you procrastinate, make excuses, change your mind a lot, and finish your work late.

So the same goes for asking for help at work. If you feel that no one expects you to go to them for help, it will take you a while to convince yourself to do it.

When you’re stuck, ask your supervisor, what do they expect you to do

This approach will change the way you get help at work. Ask your supervisor for advice when you’re stumped about what to do. After the conversation, start thinking about unlocking new work instead of staying rooted in the undoable.

Discuss solutions to work and face challenges head-on.

Do you worry about what your manager is thinking when you broach the subject? Be sure to start a conversation and state your position. Reiterate that your main goal is to be an autonomous and productive contributor to the team. Then discuss what engineers do when they encounter difficulties.

Make a list of personal experiences and ask for help

Describe the steps you took when you were stuck, including anything you might not have been able to do without help. In your experience, the last step is to ask for help.

Then when you need help, don’t hesitate. Ask for help as clearly and objectively as possible. The more you can take judgment out of a decision, the better.

Based on the case described at the beginning of the article, the following list can be made:

  • Did I restart my development environment?

  • Did you write down the question?

  • Did you use Google for help?

  • Have the BUILD and CLEAN commands been run?

  • Are internal documents searched?

  • I read some relevant source code for 20 minutes?

  • If so, ask your colleagues for help immediately.

Don’t forget to share this list with your manager and colleagues. This is a powerful way to set clear expectations for yourself. Remember to revise and update this list as you learn more about how to work in your team.

2. When asking for help, accept full responsibility

Many engineers believe that asking for help is the cause of job failure. For them, asking for help means giving up. When they ask for help, they just want to fix the problem so they can get on with the real work. That’s why they might ask the question:

“My Git branch screwed up. Can you fix it?”

Then they might sit to the side while another engineer picks up the keyboard and solves the problem for them. Their eyes glaze over as they look at other people’s work and they don’t care about the problem.

Make it clear that you’re not giving up

Avoid phrases like “I need your help” or “I can’t solve this problem.” Both mean you’ve done the work and are now trying to shift responsibility to someone else. Instead, describe what you’re working on, for example: “I’m working on this weird bug on my development server.”

Next, remind yourself of some of the work you’ve done. “I have checked the error, searched the source code and so far have not been able to find the root cause of the problem.”

Finally, describe how they can be involved in your next step. “I want to see this file to understand what happened. If you have time, you can take a look with me, that would be very helpful. “

Focus on the conversation and help everyone have a better experience. If your colleagues see that you are not checking for problems, they will be more enthusiastic about helping you.

Actively participate in the assistance process

Once you start working with someone, don’t turn your back on them and let them work for you. To build your own mental model, ask “why?” questions such as “Why might a node be insecure?” “And” Why are you reading this file?

Take short notes along the way. These may be of great help to you later. Active learning is much more effective than passive learning, so participate verbally and in writing whenever possible.

Collaborative programming takes a lot of effort. If you feel like you’re slipping back, then don’t be afraid to say you need to deal with it on your own. Be clear about how to explore the problem so they can leave with confidence in you.

3. After you get your answer, follow up

After being stuck for a few hours, the problem is finally solved and the project feels like a big step forward. Now get ready and follow up. After all, productivity is the key, right?

Getting help requires a significant investment of time from all parties, just make sure that investment is not wasted. Make a conscious effort to get help.

Consolidate what you’ve learned

This is crucial: whenever you work with someone, write down what you learn. Writing is an oven that hardens your thoughts like bricks in your brain.

Keep records forever. I found even selecting a filename a cumbersome task, so I used Quiver to keep track of my notes. This way, my notes are still useful to me, even though they are not organized.

If you post a problem on the company channel, follow up with a solution. This creates a knowledge base that is useful to you and others. It also creates a greater sense of accomplishment, which encourages you to seek help again in the future.

Spaced repetition is one of the most effective ways to remember information. Anki is a powerful tool for managing interval repeats, and sending yourself a looped email or delaying Asana tasks is an easier way to refresh your knowledge base.

To show appreciation is more than just gratitude

If you make people feel good about helping you, then they’ll do more. You may have already said “thank you” after someone has helped you, which shows gratitude. But appreciation is different from gratitude. When you appreciate someone, they feel special and unique.

Here are some ways to do this:

  • In your team work group, say, “Alice helped me figure out that weird mistake!”

  • “I was bothered for a while yesterday, but Alice helped me out because she knows a lot about how our controllers work.”

  • Write an email: “Thanks again for taking the time to help me today. I’m making great progress now. “

Appreciating others after difficulties have been solved makes collaboration feel less commercial. Conversely, it feels like you’re building a strong professional relationship. Appreciating is harder than it looks, so remember that doing so will make you stand out.

Make a note of any problems you have solved

Software engineers exploring the uncharted territory of logic and data can encounter unexpected things. There is much to discover on your own, however, in collaboration with your fellow explorers, there is much more to learn. Embrace it, master it.

Your ability to solve difficulties is one of the key skills of being a professional software engineer, so when you run into a problem, what can you bring to it? Solve it and master it, and you’re invincible.

As a developer, do you remember the first time you asked for help? Do you usually seek help immediately?

Note: all the pictures in this article are paid for download by Visual China.

——– Hot news review ——–

A major security breach in Wi-Fi has made all wireless devices — Android, iOS, Windows — insecure

How can IT professionals get rid of the curse of low EQ from the Death of programmers

Vue.js 2.5 was released, and the playable team had already developed their own framework for developing applets using Vue