开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《强制传送 python-goto》
今日推荐英文原文:《Stop Apologizing for Asking Questions》

今日推荐开源项目:《强制传送 python-goto》传送门:项目链接
推荐理由:相信在初学编程时接触过 C 语言的朋友一定对 goto 这个魔法般的命令有些印象——这个命令可以强行令代码从你指定的位置执行,如果用的多了就会让代码结构变得一团糟,除了跳出多重循环之外几乎没有地方可以合情合理的使用它。这个项目使用 Python 实现了 goto 指令,从而可以……如果你能保证不随意使用 goto 来折磨下一个读你代码的人的话,它的确会派上用场的。
今日推荐英文原文:《Stop Apologizing for Asking Questions》作者:Jeremy Aw
原文链接:https://medium.com/better-programming/stop-apologizing-for-asking-questions-88944858d0c1
推荐理由:没有人是全知全能的,所以不需要仅仅为了向他人提问这件事而感到抱歉(不过别忘了学习正确的提问技巧)

Stop Apologizing for Asking Questions

I hid behind “sorry” to mask my doubts and fears

No criminal would admit to their wrongdoing, but I was at an impasse. I did not possess the know-how to get the job done, and the information I sought was a question away. All I had to do was ask.

“Sorry” — this was how I started most of my questions.

I apologized excessively when asking questions, even for things I was not expected to know. It felt like a crime to not know everything, and asking questions was the equivalent of a signed confession.

As a software engineering intern, I felt that I had huge shoes to fill. To make things worse, I set absurd expectations for myself. Whenever I ran into something unknown, I was under the impression that I was supposed to know this sort of basic stuff (even when it was anything but basic).

It wasn’t the first time, and it wouldn’t be my last, but I asked anyway. It felt shameful. I hid behind “sorry” to mask my doubts and fears.

But the thing is, the software engineer who has mastered all existing technologies does not exist. It’s a myth born from our unrealistic dreams to become the omnipotent, all-knowing software engineer.

Enlightenment

I don’t remember when this started; it was probably an unconscious defense mechanism, and it became a habit over time. This only came to light from a fellow engineer’s feedback.
“I guess one feedback I have is to stop apologizing for asking questions. I don’t think anyone is expected to know every little detail about the stuff we are working on, especially not an intern.”
That was when I realized this seemingly innocuous behavior of over-apologizing comes with hidden consequences. “Sorry” does not only give you a false sense of relief over your insecurities, it also invites trouble.

Detrimental Side Effects of Over-Apologizing

In retrospect, I over-apologized as a defensive measure to avoid any unexpected response or repercussion from voicing my doubts.

No one is expected to know everything, especially not a new hire. There are bound to be knowledge gaps. Asking questions serves to bridge that gap and get you up to speed. It is OK to not know everything. Also, there are no stupid questions, period. Fire away.

A software engineer must be able to communicate clearly to be effective. Your messages should be clear and concise. Appending “sorry” before each question is at best an unnecessary filler. At worst, it diminishes your credibility, shifts the blame onto you, and desensitizes people to your apologies. That compromises your ability to be an effective communicator.

Self-confidence

Adding “sorry” in front each time you ask a question erodes your self-confidence, and the lack of self-confidence hurts your credibility.

You may have doubts about the work you’re doing or even question your ability as a software engineer (looking at you, Impostor Syndrome), but redundant apologies only make it worse. They place the spotlight on your insecurities and doubts and invite people to question your abilities.

Blame game

Bugs are part and parcel of programming, but critical bugs and vulnerabilities that go undetected are a serious cause for concern. During the process of your work, you may come across critical issues that were not detected or addressed appropriately during implementation.

Bringing these issues up is the right thing to do. However, when you apologize for asking such questions, you provide an opportunity for others to turn you into a target board. The software engineers who carelessly overlooked the issues in the first place will not be too happy about it.

In an ideal world, the team will come together to fix the problems immediately and conduct a postmortem to prevent such incidents from repeating. But the reality isn’t ideal, and in some cases, your unnecessary apology becomes an attack vector for toxic, defensive software engineers to pin the blame on you.

Your apologies lose value

Over-apologizing can desensitize the people around you and reduce the impact of your apologies when they are truly called for. There is less value in your apologies if you use them superfluously. They become background noise.

When you made an actual mistake that warrants an apology, your “sorry” may come off as insincere.

No Apologies, Questions Only

Unwarranted apologies dilute your message and obfuscate your intention, hindering effective communication. On the contrary, admitting that you do not know the solution to the problem at hand shows self-awareness and humility.

Furthermore, taking the initiative to do your due diligence, seek additional information, and comprehend and evaluate available options showcases your capabilities. It establishes your credibility as a reliable, competent software engineer.

Apologies have their uses but not here. Skip the “sorry” and go straight to the question.
下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/