開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《高質量文檔 The-Documentation-Compendium》
今日推薦英文原文:《Get Comfortable Not Knowing》

今日推薦開源項目:《高質量文檔 The-Documentation-Compendium》傳送門:GitHub鏈接
推薦理由:編寫文檔的小技巧。大部分人看到一個項目時最開始看到的就是它的 README 和文檔了,而這個項目就提供了一些 README 的模板以及關於編寫程序文檔的技巧。寫文檔不光是給別人看的,也是讓以後你重新回來時看的,一些小玩意可以快速的掃一遍代碼來弄懂你幹了啥還沒幹啥,但是一旦這玩意的規模大起來,光是這一步就會浪費你很多時間,而一個簡單的文檔就能解決這個問題。
今日推薦英文原文:《Get Comfortable Not Knowing》作者:Sean Watters Sean Watters
原文鏈接:https://medium.com/better-programming/get-comfortable-not-knowing-745aa7c6d4c5
推薦理由:不需要為未知感到擔心,最起碼還有學習和求助的機會

Get Comfortable Not Knowing

I wrote an article a couple of weeks ago about prioritization and understanding goals in a broader context. A big part of remaining goal-oriented, while still navigating a complex problem or project, is being able to learn quickly and becoming comfortable with not knowing.

Get Comfortable Not Knowing

At the start of any project, anticipating there will be problems you don』t yet know how to solve is incredibly helpful. This anticipation allows you to approach all tasks — even the ones you』re familiar with — flexibly and with less discouragement as you progress.

Often, relearning a familiar task reveals quicker or more efficient solutions to problems you didn』t anticipate. Better implementation of a familiar component will often compensate for deficiencies elsewhere.

There are often situations where partners and team members come from different backgrounds with diversity of skill and experience. I recently worked on a prototype for a mobile app with a team member. We both had some shared experience working with rails, but the majority of his experience had more to do with front end development. Given that I was more familiar with relational database structure and back end, clear communication about our respective understanding was important. We had a short time frame to build out something workable. As we worked on building the MVP, obviously, all or most components of the project required enough understanding of the other』s work to progress and create something usable.

When workload is distributed to larger groups, good communication between team members and teams is super important. Willingness to admit when certain implementation wasn』t immediately understood was vital for us to move quickly through roadblocks. Without honest communication, much time would have been spent spinning in place, preventing progress toward the overall goal. Asking questions allows you to avoid needlessly wasted energy.

The faster you are willing to say, 「I don』t know」, the faster your team can start on a path toward a solution. Being willing to say, 「I don』t know」 quickly is crucial to project success, especially in a tight window.

Be Patient with Yourself and Your Team Members

When you hit a roadblock, the 「right」 place to start often feels unknowable until long after you understand what you were fixing in the first place. Setting a growth target is important. However, allow for the possibility that you will spend time distracted by something that appears to be necessary and later is found not to have been. Plenty of things learned will be found later to have been irrelevant to solving the initial problem.

A helpful guardrail for navigating a new landscape and avoiding the 「will learning this matter, later?」 questions, is seeking out mentors and peers who have struggled through similar problems before — prioritize working with those assets.

Be patient with yourself as you navigate through new material but more importantly, foster a culture that is patient for all team members. It is especially important to be patient as team members navigate unfamiliar territory or material you already have an established understanding of. Be the asset to your teammates that you would look for in a mentor. Avoid interjecting 「well actually』s.」 Instead, set out to be someone who makes it safe to ask questions. 「Well actually」 sets the wrong precedent and makes it unsafe to ask questions, even if your intent is to be helpful.

The Difference Between Knowing Enough and the Bare Minimum

As you』re tackling a new concept, it』s important to emphasize understating enough. Enough and the bare minimum are not the same.

The bare minimum is about foregoing necessary understanding of a topic to implement short-term solutions with the false appearance of completion. Enough is about building a solid base of understanding with the intent of furthering growth in the future. It』s important to spend a non-trivial amount of time when solving the immediate problem, but without exceeding reasonable bounds.

Full understanding is often unattainable or unnecessary. Understanding enough becomes more important when the path to deeper understanding later is dependent on 『just getting in the door.』

In many cases, just getting the job or getting accepted to an academic program allows you much greater opportunities for learning. There are many cases where it doesn』t make sense to ignore current priorities and go learn it all before applying. Prioritize enough in contexts where you will spend otherwise useful energy on something that can be learned trivially in a more productive context with better guidance.
Calvin and Hobbes by Bill Watterson

Don』t Stop Learning

Get comfortable saying, 「I don』t know」 quickly. It allows for flexibility as you navigate complex problems. The belief that you can 『arrive』 or attain complete understanding is often discouraging and limiting — rarely is full understanding attainable. As you work through things unfamiliar, allow yourself the freedom to embrace what you don』t know and pursue resources and individuals who will help you grow.
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/