今日推荐开源项目：《自动流程图 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/
