开源日报 - Page 181 of 262

2019年1月23日：开源日报第321期

23 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：：《3，2，1，音乐开始 nuclear》
今日推荐英文原文：《Machine Learning — Should you be a first mover or fast follower?》

今日推荐开源项目：《3，2，1，音乐开始 nuclear》传送门：GitHub链接
推荐理由：一个搜索互联网上免费资源的免费音乐播放器。基本上普通音乐播放器有的播放队列这些功能它都能实现，除此之外它还能从 Youtube 和 bandcamp 这些地方搜寻音乐，兴许你喜欢的歌手的新专辑就能在这些地方先一步找到。它现在还处在发展当中，在之后的版本中可以支持本地音乐和推荐音乐这些功能，有兴趣的话可以关注一下。
今日推荐英文原文：《Machine Learning — Should you be a first mover or fast follower?》作者：Tejas Mahajan
原文链接：https://medium.com/datadriveninvestor/machine-learning-should-you-be-a-first-mover-or-fast-follower-8b1b2660e686
推荐理由：你是选择做一个勇敢的开拓者呢，还是一个敏锐的跟随者呢？
Machine Learning — Should you be a first mover or fast follower?

“Innovation distinguishes between a Leader and a Follower” — Steve Jobs
Machine learning is not just glorified statistics. It’s a story which is being modelled using incremental learning algorithms with data being the core driving fuel to it. This blog post is one which will drive you through, what one shall expect from machine learning and how does being a first mover or fast follower in this domain have its positive consequences and drawbacks.

Building machine learning powered products is an art developed by having persistence to do uncountable experiments involving a thorough study of understanding how to curate datasets, doing extensive exploratory data analysis to understand which questions can be answered by your data, building features using that data, use these features to solve the business problem using learning algorithms. It’s an iterative process where results obtained at every stage go through phases of analysis to determine the efficacy of the algorithm. Machine learning is no rocket science or magic, in simple terms it’s how a person uses the data, understands it, and has the knowledge of how to leverage it to build generalizable systems.

So why does every organisation whether it be in retail, fintech or any vertical are investing their resources in data science? The answer is simple — DATA. The exponential rise in data generation has given these data-hungry algorithms something to feast upon. Another reason is the availability of affordable cheap compute resources helping research labs, startups and companies iteratively progress experiment after experiment.

So these two major reasons gave rise to a plethora of problems to solve in every vertical across various industries be it retail, supply chain, fintech, health, IT, telecommunications, automotive and many more. With this rise in problems, has given birth to many companies across various countries to solve local and global issues, which leads to two class of problem solvers who are the first movers and the fast followers.

A first mover in machine learning ecosystem is one who is first to use an untapped data source, idealise the proper use of this data, craft solutions and ultimately build scalable products answerable by that data. A first mover has the upper edge by being first to market, in some cases having patents filed on products they have built, understanding the very minute intricacies in the data they gather from day one. Shazam, a simple music recognition app, a first mover, built the most accurate music recognition engine to eliminate noise and recognize the song with incredibly low latency and till date doesn’t have any strong competition to supersede it or even match it. Snapchat is also one such app that was first to develop the destructible messages idea, live face filters, stories which are powered by the best low latency face landmark detection machine learning algorithms.

The technological leadership using the state of the art algorithm with appropriate fine-tuning helps the first movers get a firm footing in their domain. Being first to customers can be very helpful as it helps create loyalty towards your product, at the same time a feedback loop gets sets in place which helps you to incrementally upgrade your product based on user suggestions.

While being a first mover in machine learning industry also comes with its share of disadvantages. Since your product has never been conceptualized before, you are very susceptible to tap the wrong or rather invaluable data sources, leading to waste in time, resources and most importantly meaningless insights. A naive implementation of data management infrastructure can cause serious problems once your product needs to scale to millions of people with least infrastructure costs, contrary to this, setting up an infrastructure to serve millions on immediate basis can incur high bills when you don’t have the customers yet. Webvan, a failed online grocery platform, is the perfect example of a company who wasted a huge amount of their funds on infrastructure costs even when they didn’t have sizeable customers then, a perfect example of failing because of very fast growth. How will the market react to your product? is one of the very big risks first movers take and with machine learning products, there have been cases that people have built smarter products but if they are doing only as good as rule-based systems with lesser costs; people will find no motivation to use your product.

Sometimes being a first mover can also prove fatal because it is very much possible that the product is very ahead of its time. One famous example of such product is Google Glass, as sexy it was and the endless possibilities of applications that can be built around it, it failed for the current time because people don’t see it as a need yet. This now lets us think who will be that fast follower who is going to tap, as in this case, the market of google glass with the many limitless applications around it powered by machine learning algorithms.

So, fast follower huh? The very first thing that arises in your mind now is can I really build stuff that someone has spent years on? has the most brilliant minds and resources to build them? will it be worth my time to enter that market or cost-effective say if its an in-house solution than a 3rd party?. While all these are valid concerns, history suggests that fast followers have at the majority of the times come up top. Speaking strictly based to machine learning, this has been a very common phenomenon primarily because of two factors; one being the ability to use existing data points, to create new features which help in building products to solve new use cases; the other being old handcrafted feature-based statistical machine learning model being replaced by automated feature engineered deep learning models where the amount of data is sufficiently available. Fast followers can even be successful in reverse engineering a product, which some years ago felt a technological challenge, but due to the enormous amount of data, research papers and implementations being open-sourced, and compute resources being easily available it is possible. Fast followers can eventually event turn out to be market leaders even though they do not have the best fit model, but have the technical expertise to produce their nearly good model, scale it as per demand and periodically improve it. There have been cases where certain problems once solved by first mover startups are not periodically upgraded, where fast followers see an advantage and capitalize on it. Whether you are the first innovator or late entrant to the market, every startup needs a differentiator which is seen as an important requirement by your customers, that’s your USP (unique selling point). Fast followers understand the pain points of customers through their study on the first movers and capitalize on these points; in machine learning space it helps by creating cost-effective new architectures with existing data or even helps realize different by-products answerable by data which help solve critical customer issues. Apart from having AI assistants to help you with daily news and managing your IoT devices, Woebot is a different type of chatbot developed by Stanford researchers to combat the problem of depression through interactive cognitive therapy. Slack, an enterprise team collaboration tool, another fast follower, has gained lots of success by developing smart chatbots and third-party app integrations to help streamline processes like recruiting new employees, managing project deadlines, and many more.

Fast followers have their share of problems too. Considering a first mover has gained success, entering the market you must have a clear differentiator and no room for failures. Many times projects have been scrapped while reverse engineering because the increasing amount of time invested in a particular problem is not translating to a profitable product. Sometimes the problem itself is pretty difficult to decipher like the case of Shazam. Having the right dataset isn’t enough to build the next upcoming ML solution, you need to at times understand the domain to create relevant features; have the skill to craft algorithms which can update itself based on new variations in its data.

It’s not about having the largest dataset, but having a dataset capturing every variation during test time.
With all said fast followers will always be there, with the ever-increasing set of solutions that can be devised, by procuring the right data, building a scalable data infrastructure pipeline and ultimately producing intelligent learning systems. Fast followers (like cruise, drive.ai, aurora, pony.ai etc.) to google’s self driving car project turned company called waymo, are procuring investments amounting to millions of dollars, is a clear indicator of the potential and impact of machine learning technologies in the coming years.

In our current age of technology, we see machine learning algorithms to do very good in task pertaining to supervised learning but that’s just the icing on the cake, unsupervised learning, the real cake, has only scratched the surface and I personally feel it will be the one the most active area of research for the coming years. On a closing note, it doesn’t matter if your first mover, second, third or very late in the race but what counts is whose horse is running the long race and becomes the unicorn in their domain.
It always seems impossible until it’s done. — Nelson Mandela

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月22日：开源日报第320期

22 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《对于专业编程我还是稍稍有点自信的 professional-programming》
今日推荐英文原文：《Machine Learning: Diagnosing bots save lives》

今日推荐开源项目：《对于专业编程我还是稍稍有点自信的 professional-programming》传送门：GitHub链接
推荐理由：这个项目是给程序员的全栈资源集合，你可能会在里面看到些非常有用的新资源，或者是你已经看过的那些经典的老资源。这个项目中不仅仅有各种技术方面的资源，还有一些虽然不常被提起但是一样重要的方面——心态习惯，职业道德和工作生活之间的平衡之类的，兴许在学习技术之前看一下它们会有所收获。
今日推荐英文原文：《Machine Learning: Diagnosing bots save lives》作者：Hely Herranen
原文链接：https://medium.com/@helyherranen/machine-learning-diagnosing-bots-save-lives-6d90f8afdabe
推荐理由：AI 能够帮人类在很多领域减轻压力，医学方面就是其中之一
Machine Learning: Diagnosing bots save lives
While the wait for the doctor’s office lengthen, medical data doubling every third year and healthcare costs growing, there is a shortage of medical professionals. Machine Learning provides an answer to many challenges in present-day medicine. Machine Learning Systems are fast and accurate at diagnosing.

This article discusses the problems Machine Learning can solve in the medical field. The requirements for Machine Learning Systems are addressed. The requirements are gathered from the referred article, Machine Learning for Medical Diagnosis: History, State of the Art and Perspective (Artificial Intelligence in Medicine), written by Igor Kononenko. In addition, this report introduces the supercomputer, IBM Watson, it’s history and arrival in the healthcare. In the last part, the report presents the diagnosing chatbots, Machine Learning Applications that focus on speed, accessibility, and accuracy. The goal of this article is to elaborate how diagnosing bots can save human lives. A couple of examples, Babylon Health and Woebot and studies on them, are introduced. The studies include: Delivering Cognitive Behavior Therapy to Young Adults With Symptoms of Depression and Anxiety Using a Fully Automated Conversational Agent (Woebot): A Randomized Controlled Trial carried out by the University of Stanford, and another study: A comparative study of artificial intelligence and human doctors for the purpose of triage and diagnosis written by Fitzpatrick KK, Darcy A, Vierhile M.
Machine Learning
The term Artificial Intelligence (AI) refers to intelligent computers, and a basic requirement to be intelligent is the ability to learn. Consequently, Machine Learning, a subfield of AI, is a very significant element in the project of making computers intelligent.[1] Machine Learning uses statistical techniques to give computer systems the ability to learn from data, without being explicitly programmed.[6] It evolved from pattern recognition and computational learning theory. Pattern recognition is automated recognition of patterns and regularities in data. Computational learning theory is the design and analysis of machine learning algorithms.[6] In this part, the challenges Machine Learning can facilitate and the requirements for Machine Learning Systems are explained.
Why we need diagnosing systems?
The world will be short of 12.9 million health-care workers by 2035.[8] The shortage of doctors and other medical professionals is a threat, computer systems can assist in by speeding up the diagnosis and treatment processes. The patients would be able to describe their symptoms to a bot before seeing the doctor, who would then have all the information already needed to make good decisions.

According to IBM the amount of medical data doubles every third year.[2] It makes the physicians unable to keep up with the latest research. Computers can manage massive amounts of data to help with the task of maintaining the latest information. Also, there is a challenge to expertise in medical fields. Patients are treated by general practitioners to all kinds of diseases. A Maschine Learning System can provide the expertise for the practitioners.

One challenge that matters is the speed of diagnosis and treatment. When deadly tumors are growing rapidly, it is a matter of life and death, or when a suicidal teenager goes into a waiting line to see a psychiatrist, the time is of the essence.

The patients will be able to get a ”second opinion” from the system, either encouragement that the doctor’s diagnosis is correct, or it may find the rare diseases, the physician was not able to diagnose.
Requirements for Machine Learning systems in healthcare
To be effective and reliable in medical diagnosis, there are requirements a Machine Learning System must meet. The following requirements include good performance, the ability to appropriately deal with missing data and with error in data, the transparency of data [1] and the recovery from biased data.

Good performance is the accuracy in which the system is able to produce the correct answers. The accuracy must be as high as possible.[1] In some cases, the system performs better than human doctors do.[10]

Dealing with missing data refers to the fact that for example, some relevant patient information may be missing. The algorithms must be able to appropriately deal with such incomplete descriptions of patients. Also, errors in the data can produce a problem. All data includes errors and uncertainty.[1]

The conclusions the system comes to should be transparent, in a way, that it can be shown, how it ended up with the answers. All the decisions should be explained and backed up with research and data that was used. The physicians have to able to analyze and understand the knowledge generated by the system.[1]

Another requirement is the recovery from biased data. Since humans train Machine Learning systems, the systems sometimes inherit unfortunate features like racism. The system is only as good as the data, it is trained on, the quality matters.
IBM Watson Healthcare
IBM Watson Healthcare has developed into an intelligent system that helps doctors make informed decisions in cancer treatment.[2] From winning a television quiz show to assisting doctors in diagnosing, the supercomputer developed by IBM has come a long way. In this part, we will discuss the development of the supercomputer and how it is used in medical diagnosis.
Supercomputer history and development
To many, IBM’s Watson is famous for winning the 2011 Jeopardy! quiz show against the best players in the history of the show.[2] Succeeding in Jeopardy! requires an understanding of language, even humor, which is difficult for computers. However, Natural Language Processing (NLP), stored information and statistical analysis helped Watson to create the winning answers. Watson is not simply smart but growing more intelligent continuously by learning from success, failure and user feedback.

During the time of the Jeopardy! competition, Watson needed a separate room. Three years later, Watson had shrunk to the size of three pizza boxes and increased its processing speed by 240%.[2] This can be explained by Moore’s Law, which means that the number of transistors placed in an integrated circuit doubles approximately every two years.[5] Ergo, computers decrease in size and become more effective exponentially. There has been some speculations whether there will be an end to Moore’s Law. Still, we are moving towards an artificially intelligent future in a rapid speed.
Watson in Healthcare
Healthcare professionals need to use vast amounts of data, such as patient history and the latest research, to diagnose their patients. Watson assists in the task by analyzing all the possible data. When a new patient comes to an assessment to the clinic, the doctor inputs all the critical medical information into Watson. Next, the supercomputer analyzes all the data, collects a list of hypothesis and recommends a treatment based on the patients’ medical information, best practices guidelines, latest worldwide research, and historical cases.[2] All the data that Watson uses can be seen in detail, for example citations from researches. That is an endless source of information from where to conclude, much more than a human doctor can keep in working memory at once. The volume of medical research available doubles every three years which makes human doctors job to keep up with the latest very difficult.[2] In addition, there are various side-effects of different drugs taken together, that is difficult to keep in working memory all of this information to come to a diagnosis or a treatment decision. Diagnosing is pattern recognition, which is what Machine Learning Systems do best and were made for.

In 2012, IBM partnered with Memorial Sloan Kettering Cancer Center to bring Watson into healthcare focusing on breast and lung cancer. The same year, the treatments Watson has suggested, went under a test by Texas MD Anderson Cancer Center, and they were compared to the suggested treatments of human physicians. The results overall accuracy were 82.6 %.[2]
Applications for Machine Learning in diagnosing
There is an increased demand for services in healthcare. In addition, patients wish to gain control of their health decisions.[7] A solution for these problems comes from the field of Machine Learning applications as diagnosing chatbots. Diagnosing bots are easily accessible to anyone and may provide a relief to a person in desperate need of advice. They reduce unnecessary visits to the hospital when the symptoms can be fixed at home, and they encourage when it is really the time to go to the hospital. The systems in practice are chatbot applications used via mobile or browser, easy to download or navigate to by anyone who has access to a computer. Entering the symptoms and answering the bots questions gives the patient a list of hypothesis and recommended action. The diagnosing bots are reliable, fast and accurate, and above all, they have the ability to save lives with their advice and encouragement. Next, a couple of examples and studies are introduced.
Babylon Health
Babylon’s mission is to put an accessible and affordable health service in the hands of every person on earth.[10]

A study was made comparing Babylon Health to human doctors and the results suggest that the accuracy is comparable. The results also suggest that the treatment recommendations made by Babylon Health were in comparison even safer than human doctors recommendations.[10] This proves that even not so high-end solutions like chatbots, can do the same tasks as doctors can.
Woebot
Woebot is a free, therapy app, that focuses on mental issues. Woebot prompts the patient every day asking questions about their mood and how they are doing. A study was made to research if the application has any effect on depression.

In an unblinded trial, 70 individuals suffering from depression symptoms were recruited online from a university community social media site and put into two different groups. The other group had access to Woebot and the other one did not. The results of the study proved that the group that had access to Woebot reduced their depression symptoms significantly.[9] A depressive person with suicidal thoughts can benefit enormously from talking to a chatbot. The bot knows to ask the right questions and gives good recommendations on what the person could do to improve their mood.
Use of AI necessary to survive
The use of Artificial Intelligence in medical diagnosis is not only growing but necessary due to medical data doubling every third year, doctor shortage, healthcare costs rising and when the time is critical for treatment. Diagnosing is pattern matching which is what Machine Learning algorithms can do very precisely and effectively, better and faster than human doctors can. The systems are reliable and accessible. They increase the speed for treatment and can make a huge difference in helping patients find the right solutions for them.

There is no doubt, that the systems can do much good and while operating at the level of human doctors, it is enough to start their utilization. In the future, there will be many more tools to help medical professionals and patients to understand their symptoms better and conclude to the right diagnosis. The right diagnosis is crucial for saving a persons life.

References
1. Igor Kononenko, Machine Learning for Medical Diagnosis: History, State of the Art and Perspective (Artificial Intelligence in Medicine, 2001), p. 89–109.
2. Susan Doyle-Lindrud, Watson Will See You Now: A Supercomputer to Help Clinicians Make Informed Treatment Decisions (Clinical Journal of Oncology Nursing, 2015), p.31–32
3. Qeethara Al-Shayea, Ghaleb El-Refae and Saad Yaseen, Artificial Neural Networks in Medical Diagnosis (International Journal of Behavioural and Healthcare Research, 2013), p. 45–63
4. Brijesh Verma and John Zakos, A computer-aided diagnosis system for digital mammograms based on fuzzy-neural and feature extraction techniques (IEEE Transactions on Information Technology in Biomedicine, 2001), p. 46–54
5. R. R. Schaller, “Moore’s law: past, present and future,” in IEEE Spectrum, vol. 34, no. 6, pp. 52–59, 1997
6. Understanding Machine Learning: From Theory to Algorithms, Shai Shalev-Shwartz and Shai Ben-David, Cambridge University Press, 2014
7. Digital Healthcare EcoSystem, Uday Kiran Kotla & Ginni Jain, Whitepaper by Infosys, 2018
8. A Universal Truth: No Health Without a Workforce, Third Global Forum on Human Resources for Health Report, Global Health Workforce Alliance and World Health Organization, 2013
9. Fitzpatrick KK, Darcy A, Vierhile M, Delivering Cognitive Behavior Therapy to Young Adults With Symptoms of Depression and Anxiety Using a Fully Automated Conversational Agent (Woebot): A Randomized Controlled Trial, JMIR Ment Health 2017;4(2):e19
10. A comparative study of artificial intelligence and human doctors for the purpose of triage and diagnosis, Razzaki et al. Babylon Health, School of Public Health, Faculty of Medicine, Imperial College London, Northeast Medical Group, Yale New Haven Health, Division of Primary Care and Population Health, School of Medicine, Stanford University
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月21日：开源日报第319期

21 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《大家 howmanypeoplearearound》
今日推荐英文原文：《What I Learned in My First Two Years as a Software Engineer》

今日推荐开源项目：《大家 howmanypeoplearearound》传送门：GitHub链接
推荐理由：现如今大家几乎人人都有智能机了，所以项目的作者就想到了这样一个方法来计算自己周围的人数——通过监控 wifi 的请求来确定周围有多少台手机靠近你的电脑。这玩意已经在 Linux (Raspbian 和 Ubuntu) 和 Mac OS X 上经过了测试，当然了，如果你也想要试一试的话，你不仅需要一个支持监控模式的 wifi 适配器，而且最好确保自己没有违法……
今日推荐英文原文：《What I Learned in My First Two Years as a Software Engineer》作者：Mitchell Irvin
原文链接：https://medium.com/@mitchell.k.irvin/what-i-learned-in-my-first-two-years-as-a-software-engineer-4e374fdcf0fd
推荐理由：作者刚开始作为软件工程师的两年的经验教训
What I Learned in My First Two Years as a Software Engineer
What follows are two stories, some lessons learned, my regrets, and my goals after my first two years working as a software engineer.
University and the Workplace
It was 2015 and I was a student at the University of Florida. During that time, I studied under a professor who, for what was probably the hardest class in the department, would assign multiple team based projects throughout the semester. At the end of each project, the professor would evaluate each student individually. When the next project came around, this professor grouped the best students from previous assignments together, and the worst students on their own teams. By the end of the semester, each student either fought their way into a strong team and succeeded, or ended up failing on a team full of low performers. It was beautiful. The strong were not forced to carry the weak, and the weak could either get strong or die. This environment could be aptly described by the word meritocracy. This system rewards the most talented students and allowed the students who didn’t work hard to sink with their own ship. I loved it.

A year later, I graduated. I was energized, idealistic, and ready to make my mark on the field I had spent the last four years studying. After an internship, I received an offer for a position as a software engineer at a large company with a great reputation. I walked in on my first day, eager to become a great software engineer.

I started on a project with a crippling lack of resources. We were building a web application that did what most web applications do: expose some data and allow users to manipulate it. I was working with two other engineers on development, and one Quality Engineer on the testing side. It only took a few months before I thought I was the keystone holding everything up. The users needed a new feature built? I can handle it. We need somebody to facilitate a retrospective? Sure thing. I quickly found myself in a place where very little moved without my efforts. At 22, I was playing the role of lead engineer at a Fortune 25 company.

But wait a second… despite carrying the vast majority of the weight for nearly a year, I was still paid a fraction of what my more experienced team members were taking home. I wasn’t getting an “A”, and they weren’t getting an “F”. I didn’t have stock options. I had less vacation time. What gives? It didn’t take me long to notice these things, and it took me even less time to wear the frustration on my sleeve. I struggled to be a patient and helpful teammate when pairing with engineers less familiar with the software. My apathy grew and my productivity plummeted. If I pair with another engineer and move at their pace (even if it’s 5% of mine), I’m still doing my job, right?

I spent the final three months like this, and the project landed in its final resting place with a bit of a crunch. Team morale was low. Nobody was really celebrating the culmination of this 14-month endeavor. More importantly, I knew a few of my teammates wouldn’t be excited at the prospect of working with me again in the future. I started to realize how much my attitude toward the work environment had adversely affected myself and the people around me.

A couple of weeks later, I sent out a survey seeking feedback on how I could improve as a teammate. The results of the survey made one thing really clear. Performance isn’t everything. Coming into my career, I assumed the golden standard of meritocracy I had so appreciated in school would be the same standard upheld in the workplace. There would be appropriate reward for the strong and swift justice for the weak. This perception poisoned my ability to work well with others, to be grateful for their contributions, to be humble in learning, and patient in teaching. People’s perception (of me) had become, “He’s too focused on performance”.

Lesson 1: Your relationships with your coworkers (interpersonal/leadership skills) and your technical prowess (hard skills) are equally important

To be a great software engineer, you need to hone your craft over the course of many years. Over time, you’ll travel up, down, and back up again the plot of the Dunning-Kruger chart. As you go you’ll make mistakes, learn from others, and share your knowledge. You must have strength in your technical discipline. However, if this is the only strength you have, you’re going to find yourself in an unhappy place. If your goal is to become the best software engineer possible, that journey must include a pursuit of becoming the best teammate (and perhaps leader) possible. This begins with making the people around you as much of a priority as you’ve made yourself.
The Best Engineer I’ve Ever Worked With
One September morning, two new contractors joined our team. Our team pursues pair programming as a discipline, so I ended up sitting next to one of the two contractors on a “pairing station” to begin the day’s work. Over the course of the next seven or so hours, this engineer (let’s call him Bob) asked questions. When we were working on a new feature, Bob asked questions about the language and framework we were using. When we were ironing out details of business rules, Bob asked questions about the product and the problem we were solving. Bob didn’t write much code that day. At the end of the day, I was a little disappointed in Bob. I had high hopes for his skill as an engineer, and had hoped he was somebody I could learn from.

The next day, Bob and I worked on writing another feature. As I wrote out the initial test case for that feature, ran it, and grinned when all the green check marks showed up on the screen. Bob looked on, pensive. After the tests came back green, he went into the method being tested and changed a line or two. I started to object “Wait! That behavior is incorrect.” He nodded, and then proceeded to run our test cases again. All tests passed. Yikes.

Weeks went by as Bob and I continued to pair. He continued to ask questions as we went about our work. He started making suggestions as I was driving (actively on the keyboard/mouse) and would step in to drive himself when he saw fit. He answered a few of my own questions about our framework and language’s inner workings, and introduced an OO Design Pattern that I wasn’t familiar with. His questions about the domain and our business problem started poking holes in our software. He revealed bugs and flaws in our code that I could’ve promised you didn’t exist. Yet there I saw them, clear as day. As time went on, Bob and I resolved the bugs he discovered, bullet-proofed the software design, and vastly improved the relationship between the business problem and our code (see Domain Driven Design’s idea of ubiquitous language for more on this).

In our team’s conversations, Bob didn’t steamroll anybody when he thought they were wrong. He asked questions. As they answered those questions, they often found themselves where (I suspect) Bob had been the whole time. At the heart of nearly every software-related decision the team made I found Bob’s questions. Bob didn’t make assertions about his contributions to the team. He never referred to his skill as an engineer. He didn’t seem to care how much time he actually spent on the keyboard when he was pairing. Bob is the best engineer I’ve ever worked with.

Lesson 2: Your ability to influence others is most prominently determined by your ability to help them reach the same conclusion you did, on their own

Bob rarely stated, “this is what we should do and why”. He asked questions about the other ideas that were on the table. At the end of most conversations, his questions would have led the others to remove pretty much any other idea from the table. Now, Bob didn’t have all the perfect ideas. Very often he would get an answer to one of his questions that would cause him to say something to the effect of, “Good point. Let’s go with that.” However, he had by far the most positive influence on the quality of our software because he possessed a powerful ability to influence our team’s reasoning. Yet, he spent much more time asking questions than he did sharing his own thoughts.

Lesson 3: It is the mark of a great problem solver to ask many questions before beginning to think about a solution

As software engineers we are, at our cores, problem solvers. Learning something new is a problem to solve. Coding is a problem to solve. Communicating is a problem to solve. Great software engineers are great problem solvers, and great problem solving starts with understanding the problem by asking questions. Asking questions demonstrates respect for others’ ideas. Asking questions helps you gain understanding you wouldn’t otherwise garner. Asking questions improves the odds that when you do share an answer, that answer will be appropriate. The people who most often come up with a great solution are the same people who took the time to understand the problem.

A final note about Bob. He was easily technically talented enough to be an anchor and lead teams. I’m sure he could be an architect if he had the desire. He doesn’t. Bob likes writing code. He likes doing domain analysis. He likes designing business objects and writing robust test suites. He likes delivering quality software.
Looking Back
My first two years were an adventure. I built software, broke software, and fixed software. I sat in meetings where people quite literally fell asleep at the table. I had my hand smacked a couple of times (often by my future self). I threw myself into the work, with all of the joys and pains bundled in.

Looking back, here are some regrets:
- The times I let the work take priority over the people. The work (product) always sorts itself out. The relationships, however, can be much more difficult to repair and maintain.
- The time I spent looking around instead of looking up and looking in. You don’t become a better teammate by being focused on what others could improve on. You get better by recognizing your weaknesses and strengths.
- The time I spent talking when I could’ve been listening. Nobody gets smarter or gains more empathy when they’re speaking.
- The times I was frustrated about something and didn’t communicate it openly and honestly to my leader(s). They can’t help if they don’t know what the problem is.
- The time I spent learning AngularJS. RIP.
If you try hard and care about the work you do, you’ll step on somebody’s toes. You’ll probably offend somebody. You’ll fail, constantly. When you do, keep the people first. Take responsibility, apologize sincerely, and move forward. The ability to do this is the difference between the individuals that plateau at “Software Engineer” and the individuals that end up leaders in the industry. An aside: you’re probably the former if you could offer me multiple criticisms about everyone you work with, but don’t think there’s that much wrong with you or your performance.

As I move forward, here is what is top of mind:
- Goal: become the best software engineer possible. It’s a journey of a thousand miles and it happens one step at a time.
- Goal: become the best teammate possible. Being the best engineer means very little if I’m not a positive relational force. Team cohesion beats individual talent.
- Goal: maintaining priorities. Software is not more important than my relationship with God, my marriage, my friendships, or my health. Think about what your top priorities are. I’m not planning on sacrificing any of those things to be more “productive”.
Two years ago, I set out on this journey to become the best software engineer I can be. I’m much closer now than I was then, and now am much more aware of how far I am (is there a destination, really?). These stories and thoughts represent some of that journey. With any luck, they’ll be able to help you in some way on yours.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月20日：开源日报第318期

20 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《M I T mit-deep-learning》
今日推荐英文原文：《Encouraging the Wrong State of Mind for Creating Good Code》

今日推荐开源项目：《M I T mit-deep-learning》传送门：GitHub链接
推荐理由：来自麻省理工大学的深度学习课程资料，现在包括深度学习基础，驾驶场景分割两个课程和一个深度学习驾驶竞赛——创建一个神经网络让你的模拟车辆跑得更快。如果对深度学习有兴趣的话建议从基础开始看起，它介绍了一些基础概念，并提供了关于它们的其他教程的指引，可以作为一个好的开始。
今日推荐英文原文：《Encouraging the Wrong State of Mind for Creating Good Code》作者：George Hosu
原文链接：https://medium.com/@george3d6/encouraging-the-wrong-state-of-mind-for-creating-good-code-531031517881
推荐理由：兴许一些压力能够更好的激发我们的创造力
Encouraging the Wrong State of Mind for Creating Good Code
Over the last year I’ve started noticing this strange pattern of how innovative ideas come to me when working on a project. Innovative — as in solving a problem in a creative way that makes the solution much easier to implement, much less fragile, or both.

It seem to me that innovative ideas emerge in two states of mind: bored and stressed.

I’m going to focus on how this applies to people’s professional work, rather than their hobby projects, because that’s where employees and manages shun these two states of mind most.

Boredom and stress are both, to some extent, external stressors for your conscious thinking. The simplest way to see this is to think about how you feel if you are overworked, anxious, or bored for a long time: you feel bad.

But external stressors aren’t all bad. The dose makes the poison. In recent years, medical researchers have become more and more interested in the idea of hormesis, the long-term positive adaptation of our bodies triggered by short-term, non-deadly stressors.

The best example of the hormetic effect is exercise causing a short-term raise in cortisol, but actually lowering cortisol levels overall during that day. Similarly, exercise induces oxidative stress (a factor in a host of problems ranging from dementia, to cancer to arthritis), but your body reacts to said stress by producing enzymatic antioxidant(mostly superoxide dismutase, catalase and glutathione peroxidase) , it actually leads to lower overall oxidative stress.

Other less proven examples of hormesis are short-term exposure to extremely hot or cold temperatures, fasting and even low dosages of ionizing radiation and alcohol (ethanol).

But this “what doesn’t kill you makes you stronger” principle also applies, I would argue, to your thinking. When you are in a bad state of mind, you are forced to think about getting into a good state of mind and your brain starts getting creative.

On Boredom
The benefits of boredom for creativity are probably obvious for most of you. If you have nothing to do for extended periods of time other than reading or procrastinating, ideas will start flowing through your mind.

In this context, boredom also implies that there’s no state of urgency in regards to whatever you are working on — everything is going smoothly; sure, there might be a small issue here and there, but your 8h/day job really only takes about 10 minutes a day to do.

Much like sleep, boredom allows your subconscious to take over for you, to do the heavy lifting in terms of ideas. It also allows your brain to restructure information.

Boredom is also nice in terms of allowing you time to detach yourself, it allows you to see the bigger picture. If you are focusing on a single tiny bug, your whole life becomes the parts of the code where you are tracing the bug. If you are thinking about predicting where the next tiny bug will emerge, your mind will switch to a wider perspective of the code and data you are operating on.

Furthermore, boredom provides you with a hunger to spend all that free time on something. If you are constantly bombarded with tasks, you don’t necessarily feel the need to plan a 40 hours refactoring adventure, but if you are extremely bored, finding something difficult to do might seem like a great idea.

The number of times I went from bored to “I have an amazing idea” are countless.

On Stress
One more controversial claim I will make is that stress is also a great helper in regards to creativity.

Let’s say that the project you are working on is burning, you’ve been fixing issues or adding critical features for 10 to 14 hours a day for the last 5 days.

You won’t necessarily have a “detached” view of the project, but you will be so familiar with every line and every snippet of code that you won’t need to detach yourself, because your mind can already navigate the project at any level it desires. You won’t have the energy to involve your subconscious while awake, but I guarantee you that you will be thinking about the project in your sleep.

Most importantly, you are in a situation where you are forced to think creatively, because you either find a way to make your job easier by being innovative, or you soon won’t be able to handle it. This is an uncomfortable position to be in, for sure, but your brain is made for these high-stakes type scenarios.

Many of us become creative and motivated only when we have skin in the game, when our head is on the chopping block. You might not want to do that 40 hours long refactoring, but if it’s the only way to get things running decently again and stop issues from pilling up, it will seem like the best way forward.

Of course, boredom can become apathy and stress can become burnout. As with almost any high efficiency bargain, there’s a narrow line between hitting a sweet spot and falling off the cliff.

But used in moderation, boredom and stress are amazing tools for creativity.

A State of Perpetual Busyness
The problem that most developer and most companies have is that they prefer and encourage a state of “busyness”. That is to say, nothing is on fire, but there are always a few things to do.

Fixing a non-critical bug here, adding a small feature with a far-away deadline there, chatting with Fred about reducing technical debt, creating a report on the state of automation in regards to testing, helping Charlie learn that library you kept talking about, etc.

It’s understandable that most people like being somewhat busy, that way they feel like they are doing “something”, but they don’t feel overwhelmed. They feel useful yet comfortable.

As is true the case for most “balanced” states of mind, busyness feels good. But feeling good is a reason to stagnate, not to innovate. We need adversity in order to be creative, we need to feel that something’s not right in order to progress.

It’s also understandable why most companies like busyness: it gives managers a sense that all is moving forward “as planned”. The employees aren’t being “lazy” and the bosses have everything under control. The worst thing for a manager to see would be people hanging around the office doing nothing all day or people constantly putting off everything because the production servers are one step away from burning down.

This busy-yet-complacent state leads to crisis further down the line. People don’t have the time to think in advance, like they do when they are bored, and they don’t have the need to learn how to deal with and improve from extreme stress.

Humans don’t form strong bounds and good teamwork practices when they are busy. Collaboration and innovation occurs people have to collectively face a huge challenge or when they are trying to fill in dead time.

A state of perpetual busyness is harmful because it doesn’t leave you time to think of good ideas and it doesn’t force you to think of good ideas.

I’m not saying that work on a project should always oscillate between highly boring and highly stressful. But we need to start taking into account how useful these states of mind are and welcome them rather than try to avoid them at all cost.

How I Trigger Mental Hormesis
The way I try to introduce these states of boredom and stress in my work life is by getting rid of huge swaths of work in as little time as possible. Pull hard for 2 days, relax (and get bored) for the other 3.

It’s good to note that I don’t do this every week or even every month, but I do it often enough so that I don’t get complacent and I do it more often if I feel like something is “flawed” with the code but can’t quite figure out what or why.

Another good way of introducing external stressors is to work on other projects, be it inside the company, for another company, or on an open source project. This way, you are slightly overloading your work capacity for a few days or weeks and you start thinking of innovative ways to improve development on your main project, to keep stress coming from that to a minimum.

Still, especially in large companies, there needs to be a change in culture for this kind of work style to be acceptable and improved upon. In corporations, both managers and colleagues seem to prefer everyone to be in a constant state of busyness. Not doing anything “productive” for a few days is seen as lazy and overworking yourself is seen as being a try-hard, wasteful and short-sighted.

But it’s the combination of these two things that makes for the best engineers out there.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

2019年1月23日：开源日报第321期

Machine Learning — Should you be a first mover or fast follower?

“Innovation distinguishes between a Leader and a Follower” — Steve Jobs

It’s not about having the largest dataset, but having a dataset capturing every variation during test time.

It always seems impossible until it’s done. — Nelson Mandela

2019年1月22日：开源日报第320期

Machine Learning: Diagnosing bots save lives

Machine Learning

Why we need diagnosing systems?

Requirements for Machine Learning systems in healthcare

IBM Watson Healthcare

Supercomputer history and development

Watson in Healthcare

Applications for Machine Learning in diagnosing

Babylon Health

Woebot

Use of AI necessary to survive

References

2019年1月21日：开源日报第319期

What I Learned in My First Two Years as a Software Engineer

University and the Workplace

The Best Engineer I’ve Ever Worked With

Looking Back

2019年1月20日：开源日报第318期

Encouraging the Wrong State of Mind for Creating Good Code

On Boredom

On Stress

A State of Perpetual Busyness

How I Trigger Mental Hormesis