Hi!
The last couple of years I have been working a lot with people who are just starting their careers in IT. Since the questions themselves and the way many people ask them are similar, I decided to collect my experience and recommendations in one place.
Long time ago I read 2004 by Eric Raymond, and has always followed it strictly in his career. It is quite large, and is geared more towards system administrators. I have to help people, often with no development experience at all, become juniors and start their careers.
For those who have already become, or still only dream of becoming a novice developer, I can give the following recommendations:
- Study the problem yourself
- State the goal first, then state the problem
- Write well and to the point
- Ask questions at the address and share the solution
- Respect other people's time
- Look wider
And now more.
Study the problem yourself
You are learning a programming language from a book or course. We took a sample code, ran it, but it crashed with an error you didn't understand. According to the book, it should work. But you believe your eyes - it does not work. What are the options?
- Decide that you will never become a developer because the whole world is against you, and even working examples do not work. Quit learning;
- Decide that you will never become a developer because you are too stupid or you are not given. Quit learning;
- Start asking all your friends who are somehow connected with IT, demand that they figure out why it doesn’t work for you. Learn a lot about yourself, take offense. Quit learning;
Which option is correct? Here he is:
To understand that you are not unique (no matter what your mother and grandmother say), and the IT world is not as simple as they trumpet when they invite you to courses and webinars.
Understanding that you are not unique leads to the realization that your problem has probably already been encountered by tens, hundreds, thousands of people. If you are a novice developer, then you could easily not notice something, not install or configure it. Here is a checklist that I suggest you go through before you realize that you cannot solve the problem yourself and you need help:
- Make sure that the question is unique and there is no answer on the Internet
- Carefully study the cause of the problem, not the consequence
- Evaluate possible solutions to the problem, their pros and cons
- Consider alternative ways to reach your goal
- Think about what you might be asked and prepare your answers ahead of time
С first everything is trivial with the point: if the text of the error is completely incomprehensible to you, copy it to Google, and carefully read the text on the links.
Second: for example, if your code crashes with the error “I can’t connect a third-party library”, then the problem is not in your code. The point is that you haven't installed some library you want to use. So, you need to look for how to install it, and not how to fix your code.
The third и fourth very similar: What if the problem is in this library, and I just need to look for another one? What if I do not use a third-party library at all, but write my own code using standard tools?
Fifth point brings us to the next part: think about what the person you're talking to might ask you, and have the answers ready.
State the goal first, then state the problem
The goal is what you wanted to do. For example, write a code that goes to the Internet and saves 10 pictures with funny cats. The problem is why you see an error in the console, but you don't see 10 funny cats. Don't start your question with a problem. Start with a goal, end with a problem. If the person you are asking for help is an experienced developer and knows a lot, then they will surely be able to offer you a simpler and more elegant solution to the problem. If you have already chosen the simplest and most elegant, he will clearly understand what and why you want to do, and this will speed up the response.
Good question:
I want to save 10 funny cats every day to laugh and prolong my life. To do this, I wrote the following code: […]. I expect it to connect to an FTP server and download new pictures from there. However, when I launched it, I saw this error: [...] Although I can access this server through the browser.
Quick response:
You took this library in vain, no one has supported or developed it for a long time. Better take this one - I myself download pictures with cats for her!
Bad question:
Hello, my code gave the following error […], do you know what could be wrong?
The obvious answer is:
Hello. No, I do not know.
Write well and to the point
No need to pour a stream of thoughts on a person. The person to whom you turned to solve the problem is busy with his own affairs. Make sure that he quickly understands what your problem is and what you want from him. If you have problems with literacy, use online spelling and punctuation services. You can remove garbage from the message without online services. Do not pour water, do not start from afar. Write briefly, concisely, and to the point. Provide examples.
Badly:
- hello, how did the exhaust pass))) I’m trying to assemble the project in a shorter time, but for some reason it doesn’t work for me O_o although it seems like I did everything right, come please))))) here, in general, something incomprehensible I have in the console (((it’s already straight I tried everything, nothing works, aaaa (
Good:
Hello, I'm trying to run a project, but there's a problem. It crashes immediately after the docker-compose up command, here is the launch log and the error: […] Can you tell me how to solve it?
Ask questions at the address and share the solution
You should not write a question in a personal message to a specific person, unless you have been told that you should ask that person. It is better to write to a group of people because:
- Everyone is busy solving their own problems. The chance that someone in the general chat or on the forum can give you time is higher.
- The chance that someone in the general chat knows how to help you is higher.
- You leave it up to others to find the same question and answer later.
Take a look at the last paragraph. Have you already learned that you should try to solve problems on your own? Already searched the chat/forum/group but didn't find any mention of your problem? Okay, then ask.
On the other hand, don't bother people for nothing. If possible, exclude from the mailing list anyone who cannot help you. The more messages a person receives, the less likely they are to read them all. Don't get people into the habit of turning off alerts or simply ignoring messages.
Surely, your experience can be useful to someone else. Save time for yourself and others by posting an answer or solution. The next newbie, if he already knows what we are talking about here, will not bother anyone at all - he will find your solution by searching. Why do I say that you can save time for yourself? Because you can face this problem in a year and don't remember how you solved it. The search will save again.
Respect other people's time
Make life as easy as possible for the people you ask for help.
Make sure the links you send are working. Try opening it in incognito mode. If the link requires authorization, you will see an access error. For example, if you uploaded code to a private repository, or sent a link to a Google drive that only you have access to, a person will see an error, and he will have to spend time informing you about it, and then wait for you to set up access. Make sure that the person immediately sees what you are talking about.
Don't expect anyone to want to remember what you asked two days ago. Send the information again, remind the context. No one wants to look in correspondence for what you have at hand. If you are too lazy to duplicate information so that people do not waste their time searching, then you do not need help.
Don't take it out of context. If you send a log with an error, it is obvious that you need to include not only the error itself, but also the code that caused it, with an example of what it broke on.
If there is an established process for solving your problem, follow it. Don't reinvent the wheel if there's already an article with a step-by-step HowTo.
You should not seek an answer from one person through different channels (write to Slack, Skype, Telegram) at the same time - it will be unpleasant for a person.
No need to write the same message to several people at once, in the hope that at least someone will answer you. All these people can give you an answer (most likely, it will be the same), but they will all be distracted from their affairs for a while. Use group chats.
Look wider
Everything we've talked about here applies outside of the IT realm as well. Follow these rules in the supermarket, car service, on vacation in another country, when communicating with friends and relatives. Show people that you value their time and don't want to strain them over trifles. Show that you spent time and energy trying to solve the problem yourself, but you did not succeed, and you really need help. In gratitude, people will treat your problems with understanding and help with their solution.
Source: habr.com