开源日报 每天推荐一个 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/