開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，堅持閱讀《開源日報》，保持每日學習的好習慣。
今日推薦開源項目：《翻譯 chitchat-on-translation》
今日推薦英文原文：《The Biggest Sign of a Senior Engineer》
今日推薦開源項目：《翻譯 chitchat-on-translation》傳送門：GitHub鏈接
推薦理由：現在這年頭看英文文檔已經是家常便飯了——畢竟中文文檔暫時還是少數，而與其等著不知道啥時候才出中文文檔，不如直接讀英文的來的更快。而熟能生巧，讀得多了自然就會掌握一些翻譯的方法，這個項目就是用來提升翻譯技能的，通過實例來指出新手譯者容易犯的錯誤。既然獲得了經驗，利用起來多練個新技能也不壞不是嗎？
今日推薦英文原文：《The Biggest Sign of a Senior Engineer》作者：Jason Cromer
原文鏈接：https://medium.com/@JasonCromer/the-biggest-sign-of-a-senior-developer-547598987e02
推薦理由：有經驗的人從來不會疏忽戰前準備

The Biggest Sign of a Senior Engineer

I am always surprised when I overhear a conversation about what makes an engineer senior, and the most important virtue is completely left out.

It』s not that people forget, or that it』s an unknown trait.

In fact, I think it』s the opposite: it』s something so well known, that we often take it for granted.

It becomes an overlooked part of software engineering, and because it』s overlooked, it makes the truly great engineers stand out.

What is that virtue? It』s patience.

Your work may take twice as long, but it will cost those working with it ten times less in the future

I remember at my first internship, each project assigned to me would cause a sense of urgency. Always get your work done on time or early, right?

Sure, you should always aim to get your work done before the deadline, or push back if you think the deadline isn』t reasonable. I』m not advocating for late work.

What I am advocating for, however, is patience. Instead of hopping on your laptop and creating a new file/project, take a deep breath, a short walk, or a pause for a glass of water or snack.

While you』re taking a short pause, take your time to think about the project. Approximately how long will each piece of the project take? How common are mistakes in the platform you』re going to be working on, and how long can those take?

Walk yourself through the flow of the design or spec. See if you can play devil』s advocate for edge cases or something the project manager and/or designer may have missed.

Once you』ve spent some time asking yourself these questions, start writing out a rough plan for you or with your colleagues. How will the project be broken up? Who will complete each set of tasks? How can you minimize overstepping and potential merge conflicts?

If the task at hand is simple, now might be a good time to start digging into existing code and seeing how your new project will fit in. Otherwise, it may be beneficial to create an RFC (Request for Comments) or an architectural plan on how to execute the project.

Have your colleagues look over and critique your RFC. Welcome the criticism, and use it to make your code cleaner, and life easier. Create a map of the project, using the questions you』ve asked yourself as directions along the road.

At this point, you may have spent a few hours, or up to a few days, thinking about and designing the project you will be working on. While you can』t foresee every bump in the road, you』ve got a basic direction of how to execute the project, who will take which tasks, and pain points that could arise. You』ve taken these points in account for your deadline, and even added a few hours or days on top to give yourself padding for unforeseen incidents.

Now you can start writing some code. Since you』ve created a well thought out plan, the task at hand will become a lot easier, and you』ll be able to push out well-architected code at a quick pace.

Meanwhile, the engineer who started coding after the project meeting is rewriting their implementation for the third time after running into some problems. Problems you thought about after the first half hour of planning. Don』t be that engineer.

After working with a diverse set of engineers, across multiple companies, in a wide age range, there』s one trait amongst the best that stood out to me:
Patience
It can be hard to push the urgency to start coding immediately back, but doing so will propel your progress and quality of work leaps and bounds ahead of other engineers.

You』ll produce cleaner code, easier code for others to work with, and code that requires less maintenance. You』ll not only become more responsible, but your external perception will be that of a more responsible and reasonable person.

Think. Debate. Plan. Take your time, and create a map and direction of your project before taking a dead-end road.

Happy coding.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/