When I participated in a Data Science Meetup for the first time last month I was expecting to be the odd one out as a Ph.D. candidate among industry people. However, to my surprise, I could have meaningful conversations with people about data science. Regardless of our specialization, we, quantitative PhDs, apply principles that would make us very good data scientists. Here are the top 5 lessons that I learned that are helpful for data science.

• Never make visualizations or analyses without knowing the purpose just because someone is demanding them. Sometimes a graph or analysis is requested from you as a researcher. It is important to investigate the question behind why such analysis is needed in the first place. This has a multitude of benefits. It gives you the flexibility of utilizing different methods than suggested if you think the suggested method is not the best to answer the question posed.
• Never forget the story. As researchers, we are excited at the sight of numbers and sophisticated models. But this is usually not the case for stakeholders to whom you are communicating your results. It is important to not forget that numbers and modeling are just tools to answer a question.
• Keep the visuals as simple as possible. Yes, it feels nice to have complex visuals that show your level of programming and effort. However, an unnecessarily complex visual with too much going on will usually not help anyone if not confuse them. Simple visualizations are the way to go to make your point in a strong way and identify any problems in the data or analysis.
• Iterations over trying to have a perfect prototype. This is a lesson I learned by reading The Lean Startup by Eric Ries and I wish I had known this sooner. I would perfect a visualization or modeling but later we would decide to ditch these as they are not the best option for the question that we want to answer. To avoid this what I do is to build a working prototype that does the job but I leave fussing over small details for later if we decide to keep it.
• Always code as if you lose your memory about the project the next day. Somebody told me this before but I thought it did not apply to me as I have a good memory. Well, I was wrong. There is nothing as bad as going back to your own code and not having a clue about what’s going on. Now, what I do is explain my code as if I am writing for someone else, step-by-step.