开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《翻译 chitchat-on-translation》
今日推荐英文原文:《The Biggest Sign of a Senior Engineer》
开源日报第530期:《翻译 chitchat-on-translation》
今日推荐开源项目:《翻译 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/