开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《冲击力 obnoxious.css》
今日推荐英文原文:《Don’t be too Proud to Ask For Help》

今日推荐开源项目:《冲击力 obnoxious.css》传送门:项目链接
推荐理由:这个项目包含了一些极具冲击力的 CSS 动画——字面意义上的冲击力,配合自己页面上的主题元素一起使用能够给来访者留下足够深刻的印象,包括但不限于为元素们附加强烈的闪烁与震动等等(有时冲击力和惊吓意外的只有一线之差呢……)。
今日推荐英文原文:《Don’t be too Proud to Ask For Help》作者:Rose Day
原文链接:https://towardsdatascience.com/dont-be-too-proud-to-ask-for-help-76f21d16f318
推荐理由:建议和提问的艺术一起食用来确保在你知道你应该向别人求助时能够正确提出问题

Don’t be too Proud to Ask For Help

If you are stuck on a bug or feel overwhelmed, you can ask for the help you need.

One of the hardest lessons to learn when working on a problem is when to step back and ask for help. Don’t be too proud to ask for help. Whether it be an issue with a coworker, a bug in your code giving you grief, or a personal problem you have going on, you can always ask for help when you need it.

Noticing Your Problem

Recently I took on a project to develop a new set of functionalities in our codebase. Looking at this problem, it appeared to be relatively easy work as it just extended off existing code to cater to a new use-case. I spent a few days developing the code and creating unit tests to test the new functionality. As the sprint was coming to a close, I noticed two small issues that appeared in my output, (1) I had duplicate timestamp columns, and (2) my generator was returning an empty list though it should have had one element in it.

Working on data science and software projects, you can often face problems at work where you end up looking at code on a computer screen for hours on end and can’t seem to find the issue. For me, these two bugs were one of those cases. The first bug surfaced as a duplication of columns in my output dataset. I was receiving two timestamp columns with the same value but each in a different format. As I looked closer at this data, it was clear something was wrong, but I did not understand where the problem was coming from.

As I read through the code, I traced the timestamp column through the creation of the output but was not seeing the issue. The data looked fine throughout the process up until the final result was printed. My second bug was my generator function producing an empty list instead of creating a list of objects. So what was happening? At this point, I had identified that I had two problems and spent too much time debugging them alone; it was time to ask for help.

Accepting You Need Help

When you find yourself spending too much time trying to solve a problem yourself, step back from the problem for a few minutes. Accept that this problem may be something larger than yourself or maybe something you are just overlooking. As you step back, recognize that you can ask for help. And no matter what stage you are in your career, you can ask.

You shouldn’t feel as though you are too far along to need the assistance of others. If you are working on a coding project or an analysis and are now facing a bug, you may have made an assumption somewhere in your code that you overlooked. Maybe you missed something in the data that was unclear to you before. Could you have spelled something wrong or used a different function, which is altering your output? There are so many things that can cause problems, but you don’t need to solve them alone.

Asking For Help

After spending a day on my duplicate columns bug and empty generator output, I stepped back and set up a meeting with two other developers. I explained my issue in the email and asked if they could review my code for anything that I could have missed.

Heading into the meeting, I read through my code one more time and spotted the line creating the initial empty data frame. That line of code was creating the data frame with a timestamp column and a timestamp index. Thinking to myself, “that can’t be my problem!” I removed the timestamp column and left the timestamp index. I reran my code and looked at the output just as the meeting started. It was, in fact, my issue with the duplicate timestamp columns. With bug 1 concurred, it was clear I needed to step back from the original code for a while to bring a fresh perspective on the issue.

So what was wrong with my generator function producing an empty list of objects? As the meeting started, I explained my duplicate column bug and the solution. It was helpful for one of the developers who would be working on similar work in the upcoming sprint. As for the generator bug, I brought up my code and shared my screen. The function was operating without producing any error statement, but the output was wrong. It came down to a simple data type issue. I was trying to cast the data going into the generator as the wrong type. Therefore, it was not finding anything of that type in my folder. Since nothing in my folder was the correct type, nothing was added to the list, in turn, producing an empty list. Once I updated the class to the correct type, my generator created a list with the folder’s data. My problem as simple as a find and replace of one word that I overlooked.

Summary

So what did I learn here?
  • You can ask for help, and you should. Please don’t feel that you have to go it alone with your problem.
  • Don’t let what seems like a trivial bug put you off schedule because you are too proud to say, “Hey, can you look at this with me quickly?”
  • Sometimes you need to step back from what you are working on to recognize where the problem is. Code can blindside you, walk away and come back for a fresh look later.
  • Don’t feel that you are alone. Every developer will ask for help at different times and for various reasons.

下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/