今日推薦開源項目：《自動流程圖 js-code-to-svg-flowchart》
今日推薦英文原文：《4 Ways to Ask Better Questions as a Software Engineer》
今日推薦開源項目：《自動流程圖 js-code-to-svg-flowchart》傳送門：項目鏈接
推薦理由：回憶一下開始學程序時老師（如果有的話）給你的任務吧，你得寫個程序，再為它專門畫個流程圖……但是現在已經有了新的解決方案。這個項目根據你提供的 JS 代碼可以自動生成一個 SVG 代碼流程圖，用於教育新人讀懂倉庫里那一大堆代碼這樣急切需要代碼可讀性的場合自然再好不過，至於拿去交作業嘛，如果你確定你不會被老師教育的話可以試試看。
今日推薦英文原文：《4 Ways to Ask Better Questions as a Software Engineer》作者：Devin Soni
原文鏈接：https://medium.com/better-programming/4-ways-to-ask-better-questions-as-a-software-engineer-a342ffc251a1
推薦理由：在向別人求助之前，先把自己能做的都做好可是基本常識
4 Ways to Ask Better Questions as a Software Engineer
How to stop asking bad questions
No matter how experienced you are, everyone eventually has to ask someone else a question at work.However, not all questions are made equal.
The thing that separates people is how they ask their questions.
By following the tips below, you can ensure that you are being respectful of others』 time and maximizing your chance of getting the answer you need.
1. Research Beforehand
Before asking for help, try to find a solution yourself. While you should not feel afraid to ask questions, you should also be respectful of others』 time and first try to see if you can do it on your own.The key here is to timebox your investigation to a set amount of time. Exactly how long you should wait is up to you and your company』s culture, but typically this should be between 30 minutes and a few hours.
If you repeatedly ask questions that can be answered with a few minutes of research, you will probably end up being overly reliant on others and deprive yourself of the opportunity to develop your searching skills. Conversely, if you often waste hours or days searching for answers that others could have told you within a few minutes, your productivity and your team』s productivity will suffer.
Finding this balance is an important component of developing your own skills while still remaining productive.
2. Give Context
Once you have determined that you should be asking your question, it helps to provide as much context as possible to the person who will answer your question.Consider these two ways of asking the same question:
- 「My deploy failed. Can you help?」
- 「My deploy on service X failed with Y error message in the logs. The most recent change I made was Z. Can you help take a look? You can view the logs at [link] and you can view the pull request for my change at [link].」
With the second approach, the person you are asking hopefully has enough context to understand the problem and can begin helping you out.
In order to save everyone』s time and increase the chances of getting an answer, it is always helpful to provide as much context as possible. The person you are asking is not all-knowing and will probably need to spend some time of their own investigating, so giving them a head start makes a big difference.
3. List What You』ve Tried So Far
In addition to providing context, it also helps to tell the person you are asking what you have already tried. If you followed Step 1 and did your own research before asking the question, you should have some solutions you have already tried or at the very least a list of things you searched for.In a similar vein to providing context, by telling them what you have done already, this removes some of the back-and-forth while they are helping you. If they know certain approaches did not work, they can more easily identify methods that would work. They might also realize that you have already tried every approach that they know of, so they know that they need to redirect you to someone else who has more expertise.
4. Write Down the Answer
Finally, once you』ve asked your question and hopefully gotten an answer, make sure that you write down the answer somewhere. It』s perfectly fine not to know everything, but if you have to ask the same question more than once because you didn』t write down the answer, you aren』t being respectful of others』 time.In addition, consider adding the answer to public documentation or some other knowledge-sharing platform like Stack Overflow. It』s unlikely that you will be the only person to ever ask this question or run into this issue, so by making the solution public knowledge, you can save others time in the future.
Cultivating a company culture of knowledge sharing and public documentation is important, as it helps people onboard quickly and reduces interruptions throughout the day.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
