DataWrangl

Most Important Data Science Skill? (Re)learning to Learn, Perhaps

Mon, 19 Dec 2016 17:34:00 +0000

“What, in your opinion, is the most important skill for data scientists to have?”

Fortunately, I had a minute to think. I was one of four data scientist panelists, talking to a meetup group of mostly aspiring data scientists, about how to get into the profession and how to be successful. I was on the opposite end from the microphone, so I had a few minutes to gather my thoughts while the other panelists answered.

My mind raced: so many things a data scientist needs to know. What is the most important? Do you need to know R? Or Python? Data wrangling and analysis? Machine learning? Visualization? Hadoop or Spark?

Ok yeah, you need to know all of those things. Those are fundamentals (maybe not Hadoop any more). But how do I choose just one thing?

The microphone came my way. Still a little unsure about what to say, I gathered myself and said, confidently (or so I hope it sounded): “The most important skill for a data scientist is to know how to learn, and how and where to acquire new skills.”

On the surface, it sounds a little like a cop-out answer. But the more I think about it, the more I believe it. That skill is fundamental to having success as a data scientist. The field is rapidly changing. How do you keep up?

Learn the Fundamentals

It’s like when I take my kids to ski school. The instructors don’t start the little rippers on the lift to the top of the mountain. I’m glad too, because then my own epic day would be ruined. No, the instructors stay at the bottom, on a small hill with maybe 20 feet vertical rise. The kids learn how to turn, learn how to stop, learn mountain safety. Only after they have mastered these skills with repetition are they allowed to the top of the mountain.

But after they’ve mastered the fundamentals, do they stop learning? I think if my 5-year-old stopped continuing to learn more about skiing, he would be a bore to ski with by the time he’s 8. If he keeps learning, he’ll enjoy it more, and skiing with him will continue to be more and more enjoyable (at least until his skill far surpasses mine).

Skiing with the 5-Year-Old

Likewise, you absolutely cannot stop learning data science once you have the fundamentals down. The fundamentals: R and/or Python, machine learning, data exploration and analysis, visualization. Learning those fundamentals is a huge hill to climb (and the peak may be receding as you’re climbing!). Once you have a few basics down, you might want to take a break, to rest. Binge on Netflix in your new-found free time. That might be ok for a little while, but if you keep it up, the market will soon pass you by, and your value will quickly diminish. To be successful long-term, you will need to continuously refine your skills. Learn how to learn, and continuously practice this skill.

Chasing the Latest Fad

Scroll through your LinkedIn feed, and if you’re well-connected to other data scientists you will see that a lot of them get excited about new data science or engineering technology. Your feed might currently be dominated by articles about deep learning, Apache Spark, or Internet of Things (IoT). Those are all great emerging technologies. Yes, you should probably learn a bit about them. Maybe a lot. But don’t think that if you learn about them and become an expert, you are “done.”

Even if you become the expert in a certain niche of data science, you are likely still at risk. The field is changing too fast. Becoming the expert and then relaxing: that’s not a good way to success. The hype cycle is real. It will hurt you, badly, if you don’t continually work on obtaining new skills and getting better.

That’s why the current “fad” that excites me the most isn’t necessarily data science: it is how easy it is to learn and pick up new skills in an on-demand fashion. And I don’t think this is a fad either. Education is changing, and quickly. We can all be the beneficiaries.

Learning Options

So how can you go about this continuous learning? If you are working in the data science field, you might be somewhat constrained by the products you are working on and the tech you are using for your job. You don’t have the time to spread your wings while also working against a product deadline. That’s fine – if you’re getting paid to work you should probably focus on doing your job, not building your skill set to impress a future recruiter! Rather, I suggest you spend some of your away-from-work time continuing to build your skills. A few hours a week will go a long ways.

Here are some options for continuing to build your skill set. Depending on where you’re at in your career, some of these options may make more sense for you than others.

MOOCs

If you look at my LinkedIn profile, down in the certifications section, you will notice I am a big fan of the Massive Open Online Courses, or MOOCs. They are largely how I was able to pivot from working as a long-time data analyst into a role in modern data science and machine learning. MOOCs, at least for me, are one of the easiest ways to pick up new skills. That doesn’t mean I become an expert after taking a class. Just because I finished the Coursera Data Science specialization doesn’t mean I deserve to be a data scientist in industry. But the classes give me enough of a background in the fundamentals that I can go off and learn/practice more on my own and turn those beginner skills into real expertise.

The MOOCs I’ve taken are mostly from Udacity, Coursera, and edX. I think by and large Udacity has the best quality courses of the “big three,” but since the introduction of their very successful nanodegree programs it has been impossible to do courses á la carte and receive a certificate of completion (certificates aren’t necessary, of course, but I’m a sucker for their motivational value). I’ve also enjoyed most of my edX and Coursera courses, and have appreciated what I’ve learned from them.

Graduate or Professional Certificates

For those people who might come from an educational background in a field other than data science, a graduate or professional certificate from a university may be a good, relatively inexpensive solution for building your skill set and your network. In 2015 I completed the University of Washington’s Professional and Continuing Education certificate in Data Science. I thought it was a very good program, overall (see my review on my blog), but data science novices are the most likely beneficiaries of this method of learning. Unlike MOOCs, it’s not the sort of thing where you can quickly pick up a single skill and move on with your life.

Graduate Programs

Graduate programs in data science are popping up all over the country. Buyer beware: the quality of such programs varies widely! I’m currently working on a M.S in D.S from Regis University here in Denver. While I don’t think a master’s degree is necessarily needed to be a successful data scientist, I’m a believer that in many ways it opens up more options later down the road. I may expand upon this idea in a future post.

Obviously, a graduate degree is a much more expensive option than either of the previous two options. And data science is changing so fast that by the time a curriculum for data science is designed, it is out of date! But I still believe that completing such a degree can be valuable to your career for many reasons.

Open Source Data Science Masters

The Open Source Data Science Masters site is amazing. I won’t talk about it in any depth. But if you’re looking for inspiration about what to do or what to read, just go to this site and check it out. You’ll have plenty of reading and studying options to keep you busy for a long time!

Read, Read Read!

Often by the end of the day, the last thing I want to do is open my computer and do more coding. I’ve been doing that all day at work. So, instead, many nights I’ll read about data science. It’s amazing how much this reading has helped me when I talk about data science among peers, co-workers, and in interviews.

When you read, you get the wisdom and experience of those who have taken the time to write down their thoughts. Like the writer James Altucher says: “That’s why reading is great. It’s like I’ve lived 100s of lives as well as just my own.”

What do I read? I usually just scroll through my LinkedIn feed and see what the amazing people in my network have posted. How did I build this network? First, I joined data science related groups. Then, I saw who was posting interesting stuff. I followed them. Saw what these people were commenting on and liking, and I followed those people. Made my own comments, and people started connecting with me. The power of the network is truly amazing to me, still. I eventually got on Twitter, and get many valuable articles from there too, as long as I’m willing to put up with the low signal-to-noise ratio present in the firehose.

Keep Refining

If it sounds like a lot of work, well, it is! Data science isn’t for the lazy. Not for the get-rich-quick folks. Despite what Glassdoor and Harvard Business Review say, it’s hard work, and it’s really not as sexy as it sounds. I like it, and I contribute to my business, but it can be grueling and exhausting. And I constantly feel inadequate: there are questions that come up all the time where I answer: “give me a month to study that in depth, and I’ll get back to you.” But the thrill of discovery keeps me going. That and the thrill of continually needing to push myself to get better. I know that if I don’t keep my skills active, and improving, I will soon be passed by the many ambitious people who are willing to work harder.

So get out there, get your hands dirty, and have fun learning. And then learn some more.

Thank you for reading my post. What about you? Do you have any other favorite learning resources for new data science techniques and technologies? Would you be willing to share them in the comments?

Storytelling: The Power to Influence in Data Science

Wed, 22 Jun 2016 02:50:00 +0000

Note: This is a lightly edited excerpt from my recent interview with Kaggle.
Humans are story-telling animals. We love a good story. Stories, whether in the form of movies, epics, songs, or myths: they capture us, they move us, they bind together generations, get us in touch with deeper messages. Everyone knows how to tell stories, at least a little bit. But, certainly some of us seem to have more storytelling talent than others. That group of five or six friends you hung out with in college: there was probably one person in that group that everyone loved to listen to. They could tell stories for hours on end – funny stories, stories that made you think, stories that made you cry, stories that changed your life. This person, they didn’t necessarily know more about the world than you. But they knew how to craft their message in an interesting manner, and likely had an outsized influence on you and your circle of friends.

As Data Scientists, we need to be able to influence. We have data and insights that can shape the direction of a business. But all our insights are for naught if we can’t convince the leaders in our business to act on our insights. Our Data Science peers might be interested in the details of our heroic data wrangling, or seeing how many models we ensembled, or how many features we engineered. Leaders of our business? Unless our work can save or generate dollars, they see nothing more than perhaps a grown-up version of a science fair project. That’s right, I’m comparing your sophisticated models that took you three months to build to a fifth-grader’s papier mâché volcano. Interesting and fun, but eventually just clutter in your bedroom that you throw out with the garbage. Hopefully you had fun and learned something, even if you didn’t win that ribbon!

Not my volcano, but I made one like it in fifth grade.

So, as Data Scientists, how can we influence? How can we convince our company leadership to act our insights? I struggled with this when I began my current job. The five-minute morning standup meeting and occasional ggplot visualizations dropped into Slack chat weren’t enough. I was doing (what I thought was) cool work, but it wasn’t affecting the direction of our product. So I found my voice. I began telling my data’s stories, and writing the stories down. Working hard on visualizations. Thinking about my audience’s needs. Asking lots of questions – finding out what my business needs were, not just what I found interesting in the data. I began focusing on how I was communicating my insights. And things began to change. It’s still (and always will be) a work in progress, but I am having increasing influence as my communication and storytelling improve.

How I Communicate my Results

It starts with the blog. Last September, I spent several days figuring out how to start a Jekyll-driven blog on our company’s GitHub Enterprise install (of note, my personal blog is Jekyll as well). At first I was worried that my time setting up the blog would be wasted – these were a few days when I wasn’t doing data work, after all. But this has been one of my best decisions I have made. I blog about two to three times a month, at various “stopping points” in whatever project I’m working on. I love the blog because the words are mine, and I don’t have to worry about sounding too formal. I can easily cross-reference previous blog posts. Writing helps me organize my thoughts, helps me record additional questions, and provides a repository of ready visualizations if I need to have a presentation ready quickly. I forget what I worked on just two months ago. I forget what ideas I had two months ago. If I go to my blog, I get that refresher much better than I would had I left the results in an R Markdown file in a random directory on GitHub. And I can easily share my blog links with company leadership. In fact, I’ve been shocked how many times I’ve been asked a question by company leadership, and I can say “oh yeah, I think I did a project on that 4 months ago…yep, here’s the link!”

It won't win any style points, but my work blog is my best gift to my future self.

On a short-term basis, I still share day-to-day findings with my team in the morning standup meeting, but I try to limit what I share to just a couple sentences, unless someone asks me to elaborate. I might still drop a ggplot visualization or two in our Slack chat every couple weeks. These are nice to keep a conversation going, or to maybe get a question answered, but are easily forgotten and not very influential.

Finally, I’ll occasionally give presentations to customers or potential customers, usually with leaders from my business in attendance. These can be high-stress, because business and dollars rely on the outcomes! But, since I frequently write on my blog, I find delivering the content of the presentations to be rather easy. I know the material, have done my best to explain it in my blog, and rarely do I get very technical questions that I can’t answer. The presentations are more about showing pretty pictures and telling how our way is an improvement on the old way (and it’s not very hard showing that Machine Learning is an improvement compared to analysis from Excel spreadsheets!).

Adding Value to my Work, Beyond the Numbers

Effective reporting, detailed analysis, and visualization is what gives my “core” work any value at all. My core work is developing machine learning software. So it’s similar to a Kaggle competition, where I develop a model, test it against a metric, and iterate to improve the model. Once I get to a good “stopping point” with my model, I’ll write production-level code to integrate with the rest of our application.

But, as any good Kaggler knows, in the course of creating my model, I’ve created a beast! In particular, I’ve come up with several new features that must be engineered. But I don’t do the engineering for the production systems! I write code in R! My team writes code in Ruby! Their engineering pipelines feed my models. How do we get on the same page?

I’ve just spent two months creating this new, better model. Now comes the arguably more difficult work. The work of influence. The work of convincing my team lead that it’s worth his effort to write new Pivotal stories, point them up, and assign them to team members. Maybe push our product deadline back by a few weeks to accommodate the new work I’ve created. Why and how is my new model better? Why should they care?

Fortunately, I’ve been blogging about my new model all along. Creating visualizations showing the improvements against the test metric. Admitting in my blog when a new feature that I thought would improve the model actually made it worse. Ordering my changes in terms of priority, should we not be able to implement all of my recommendations.

My analysis must be extremely detailed. I need to anticipate questions. I need to have had conversations with my team lead all along, to try to figure out what changes might be feasible, and which ones I should leave until the next version of our app.

I’ve found that visualizations are even more effective than my words. I can write for five pages trying to explain my argument. But a good visualization or two captures the mind, captures the imagination, and I’ve found can ultimately be the influencing factor in convincing my team to take my suggestions.

Source: Forbes.com: Data Storytelling

Six Ways to Improve Your Storytelling Skills

Every person has the ability to tell a story. Clearly, some people seem to have more talent than others, but storytelling is ultimately a skill, and skills can be improved with intentional practice. Technical people in particular can really struggle telling a story. I don’t know if it’s the whole left-brain versus right-brain thing, but clearly crafting a story is a creative process. People with technical skills often tend to bogged down in the details. Effective storytelling is more about keeping an eye on the big picture – where you want to start, the waypoints you need to hit, and where you want to end – while giving enough details to fill in the gaps in the big picture. Here are some of my tips for becoming a better storyteller:

Read as much as possible. Fiction, non-fiction, technical books, blog posts, magazines, newspapers. If you’re only reading material in Data Science, or in technology, most people will find you boring. You won’t be able to connect with many people. Human connection is critical to effective storytelling. Writers who get paid to write are essentially paid storytellers. Learn from them! I love reading National Geographic magazine in particular. The photographs are the story, and the essays surrounding the photographs add in the color and context. If you must read data-related stories (and you should!), I think FiveThirtyEight sets the standard. Take inspiration!

“You have to read widely, constantly refining (and redefining) your own work as you do so. It’s hard for me to believe that people who read very little (or not at all in some cases) should presume to write and expect people to like what they have written, but I know it’s true.” - Stephen King
Write as much as possible. Writing provides clarity to your thoughts. You will ask better questions. You will be able to provide better answers when asked about your work. A well-written blog post or report can give you significantly more influence than you may think! But you must practice. Do the Work.
Find your voice. You won’t be influential if your reports are boring or overly academic. Leave the academic work for academia. That’s its place, and it works there. You are in business now! Find your voice. Don’t be afraid of saying “I” in your blog posts. Make people want to read your work. Make people want to act on what you say. This may be especially hard for people with PhDs, who have written academically for years. But once you get past this, it is extremely freeing.
Visualizations First: When writing or giving a presentation in Data Science, before you write a word, add in your visualizations. Your visualizations should be your story. The words you write or say should be meant to add context to your visualizations.
Listen to Stand-up Comedy. Comedians have a special gift for noticing absurdities in the world around us. But listen to the best stand-up comedians. Are they standing up there telling one-liners? Knock-knock jokes? No! They are communicating the absurd via stories, often very elaborate stories. Listen to how they craft these stories. You don’t want to necessarily emulate a stand-up comedian when you are giving a Data Science presentation (I highly recommend against it), but you can learn a lot through their use of story as a communication tool, and can take cues from their cadence and inflection.

Know your Audience: This is key to connecting, and thus influencing. If your audience is the decision-makers of a potential client, they aren’t going to care about the details of your five-model ensemble, or what features you had to create. They have business pain; how is your model solving it? Who do you expect to read your reports? Target their needs. Sure, you might need to write up a technical document for your future self or future teammates (or your replacement when you leave). But then write another version of that report that your third-line manager can understand and act on. If you don’t know your audience’s needs, you won’t connect with them; if you don’t connect, you won’t influence; if you can’t influence, then hopefully your work has been interesting to you, because it’s likely useless to your business.

Thank you for reading my post. Do you have any examples of how storytelling has helped you in your career, in data science or otherwise? Any additional tips for how to improve as a storyteller?

Data Science: Beyond the Kaggle

Sun, 15 May 2016 14:07:00 +0000

A few weekends ago, on a snowy Saturday in April (not uncommon in Denver), I signed into Kaggle for the first time in several months, looking to play around with some competition data in order to while away the chilly day. My kids’ endless chatter and my wife’s disapproving looks faded into the background, and I blissfully wrangled data from the Expedia Hotel Recommendation competition for several hours. I submitted a few entries, slowly climbing the leaderboard, and then finally I got up to help with my family duties.

That night in bed, my mind whirled with possibilities for what I could do with the data to improve my score – different variables I could use, several time-related features I could engineer, and thoughts about how to ensemble a couple dissimilar models together.

I woke up early Sunday and fired up my project in RStudio. Between breakfast and reading a few news articles, I submitted a few more entries. None were improvements on my previous entries. By noon, I lost interest. I quit. I shut my computer, said sorry to my wife, I got on the floor, and started playing with my kids. My mind slowly spun down, and I focused on the moment. And I became happy again.

I have a love-hate relationship with Kaggle, the self-proclaimed “Home for Data Science.” There are a lot of reasons to love Kaggle. The competitions can be interesting, the forum participation fascinating and educating, it’s instructive to see the sorts of ways that companies are using predictive analytics, and the whole process is a fun way to learn about Machine Learning techniques in a hands-on manner.

But it’s not Data Science. Kaggle’s bread-and-butter is its Machine Learning competitions, or Predictive Analytics competitions. The processes used in Machine Learning competitions only encompass a very small fraction of the Data Science process. I suppose “Your Home for Data Science” sounds better from a marketing standpoint than “Your Home for Machine Learning Competitions” or “Your Home for Cross-Validation, XGBoost, and Overfitting Techniques.” But I think people, especially those new to the craft and/or those companies looking to hire Data Scientists, should be aware that the Kaggle competitions only encompass a small part of the Data Science process.

As I have made my own transition from long-time data analyst to modern Data Scientist, I have read several articles about “How to be a Data Scientist.” Many, perhaps most, of the current articles suggest participating in Kaggle, or building a Kaggle resume/portfolio and getting a good ranking as a ticket to a job. Some authors stress this more than others. One person suggested that participating in Kaggle competitions could be the equivalent of a Master’s degree. Another comment for a different article said “all you need to do is Kaggle.”

Really? That’s all you need to do? Sure, the skills learned and practiced in Kaggle competitions are important to Data Science. But, based on my experience and the range of articles I have read on the subject, the skills to be good at Kaggle are maybe only 5-10% of the skills that you need to be a useful Data Scientist. Here are some of the reasons why Data Science > Kaggle:

Defining the Question: When working Data Science for a company, one of the first steps, and perhaps the most important step is defining the question(s). What is the problem you are trying to solve? How will it help your business? What data do you currently have to support your analysis? What data do you need to find or create? If, as a Data Scientist, you can’t ask good questions, you are sunk before your ship even sails. In Kaggle competitions, you are just given the question – it is served up to you on a silver platter. Get the data and go!
Data Acquisition: Working Data Science for a company, one of your challenges will likely be just finding the data. Where do you get it? Maybe you scrape a web page. Or you hit a public API, which might be an ugly municipal government SOAP API. Perhaps you use SQL to pull from a company relational database. Or you go harass your friend in engineering to deliver you a data set. For a Kaggle competition, you are given a data set or data sets, likely in CSV format. Many competitions forbid finding and using external data for your solution.
Data Cleaning and Data Set Creation: In the real world, after you’ve found a data set, or several data sets that you have to figure out how to merge, there should be a significant amount of data janitor work. This is a big hurdle, and arguably takes the most amount of effort from any Data Scientist. With the Kaggle competition data sets, sure, there might be some cleaning you have to do, but for the most part the data are fairly clean already and you just have to figure out what to do with NA values or outliers.
Anonymized Data: Companies that work with Kaggle to create competitions are understandably conscious about competitors using their data to gain a competitive advantage. To prevent this, Kaggle competitions usually use anonymized data. While understandable, I think this gets in the way of really understanding the data. If all I have is some arbitrary feature names, like V1, V2, V3, etc, and some integer values for those features, it is hard to use intuition to help solve the problems. Sure, we can do feature engineering to “combine” features in creative ways, but it’s not the same as intuiting that you can multiply V1 and V2 and divide by V3 to get a reasonable engineered feature.
Evaluation Metrics: Another difficult part about real-world Data Science is coming up with an evaluation metric to evaluate the effectiveness of your machine learning model. Kaggle competitions, in order to be a fair competition, must hand you the evaluation metrics. The flip-side of this is that I’ve learned about several metrics that I otherwise might not have.
Scoring Against the Evaluation Metric: In the real world, accuracy and having a good algorithm are important. You want your machine learning model to be accurate. However, more important than having the most accurate algorithm is that your model is useful. Ensembling a dozen or more different machine learning models to win a Kaggle competition is cool, and it displays a fair amount of computer science chops (running and combining that many models isn’t trivial!), but it’s not very useful in the real world (the winning Netflix Prize algorithm is a famous example, though that wasn’t a Kaggle competition). In real-world Data Science, it’s more important to have a useful model that you can explain, and that can run in a short enough amount of time to be usable in a production setting. In my own job, I’ve suggested to higher-up managers that I could use ensembling to improve our models, maybe achieving an accuracy 5-10% improved compared to our current accuracy. They said effectively “that’s cool, but will our customers notice an incremental improvement?” I said probably not. “So let’s focus on answering some other questions first.” Fair enough!
Scripts and Scoring: Kaggle scripts are an ingenious way for competitors to share their work, and for newcomers especially to learn about coding techniques that the experts are using. Unfortunately, the scripts can lead to inflated user rankings for unscrupulous and lazy users who don’t want to do the work themselves. I believe it is too easy to fork a nice script that someone has written, click a button to run the script, and submit the results (you could do it all from your iPhone!). This takes a few seconds to minutes at most, and doesn’t require you to download data, import it into R or Python, and really figure out how the algorithm works. And yet, you can get full points for the leaderboard position your copied script takes! I found one such script-button-pusher, completely evident from a few of his results (2 or 3 submissions for each of about half a dozen competitions, with the “script” icon next to his results, finishing in a knot of others with the exact same score using the exact same script) that had gotten enough points to be in the top 0.75% of Kaggle user rankings! His LinkedIn profile headline says “Machine Learning Enthusiast.” Apparently not enthusiastic enough to do his own work. So I say: Recruiters beware of a person’s Kaggle ranking! That’s only one data point that could be easily fudged to say “I’m top 1%!” For more good bullet points on the pros/cons of Kaggle scripts, see this Quora discussion.
Substantive Expertise: One of the coolest parts about Kaggle is that you get to learn about how different companies are using Data Science in their operations. As a budding Data Scientist, it helps you realize that Data Science is becoming more important in virtually every industry and scientific endeavor. That’s exciting! But in a 2- to 3-month competition, unless you have virtually no family or work commitments, it seems as if it would be almost impossible to become a substantive expert in your competition of choice. And, of course, the famous Venn Diagram of Data Science shows that substantive expertise is just as important as Hacking Skills (programming) and Math/Stats knowledge. No doubt competition winners, maybe top five percenters, get a fair amount of substantive expertise during the course of the competition (or already had it coming in), but for the rest of the field you are likely more in the Machine Learning slice than the Data Science slice.
Telling the Story: According to an HBR article from 2013, a Data Scientist’s real job is storytelling. You need to tell the story of your data, from beginning to end, what it means, and how it affects the business. When telling the story, effective visualizations are paramount! For the overwhelming majority of Kaggle participants, this step is completely skipped. Sure, winners might be obligated to write up results as part of the condition of accepting prizes, and many winners and others blog about their results, but those blogs are more about the machine learning process, what features they engineered, and how they ensembled their models. Interesting from a technical perspective? Yes! Useful from a business perspective? Not so much. With anonymous features and a lack of substantive expertise, it becomes extremely hard to present a compelling story about the data, which is what you would be required to do in a business setting. So, for me, more admirable than being a consistent top-percentage finisher in Kaggle competitions would be to have a Data Science blog where you compile and display your own projects and your own stories (one such excellent example is Julia Silge’s data science ish blog).

My point here isn’t to complain that Kaggle is a bad company, or has a bad service. I still think Kaggle is, overall, an awesome company with a great vision about crowd-sourcing machine learning. I am excited about Kaggle Datasets, and seeing what people can do with that new service. They have an amazing jobs listing service, which is another great place to learn what companies are hiring Data Scientists. Their forum is full of amazing contributions from brilliant machine learning experts from across the world. It’s a fun place to while away a weekend or a few evenings if you have the time to do so, and a great place to learn about new machine learning techniques. My main point is to warn aspiring Data Scientists that there is a lot more to Data Science than just Kaggle competitions, or your Kaggle scripts profile. Take courses (MOOCs or formal education); find your own data sets; do full-stack analytics, including exploratory analysis, machine learning, and visualization; engage on social media; start a blog. Show you know how to ask questions, source your own data, build your own project from scratch, and write up the results. Kaggle can be an enormous time-suck, so don’t allot it more time than its “weight” if you want to be a well-rounded Data Scientist (maybe 5-10%). And then use your skills to make the world a better place.

What do you think? I’d love to hear your opinions, whether supporting or antagonizing. I’m ready for the “sour grapes” comments because my Kaggle ranking isn’t all that high (5195 out of 545,284 as I publish – see my Kaggle profile), so I’d prefer those that disagree to use a more thought-out argument (my counter-point to the sour grapes argument is that I usually lose interest in the competitions after a few hours due to some of the reasons bulleted above). Otherwise, interested to hear what others in the Data Science profession think.

My Post on the Comverge Blog

Tue, 15 Mar 2016 13:02:00 +0000

Just a quick plug here. I work as a Data Scientist doing energy and demand response forecasting for Comverge in Denver, Colorado. The marketing team asked me to put together a high-level overview of how we are using Machine Learning at the company. If you are interested in learning more about how we use Data Science and Machine Learning techniques at Comverge, please click through to see the blog post. I used R to do all my modeling and make the “Model 1” and “Model 2” charts. My engineering team created the nice user interface using D3.

Exploring 2014 Denver B-cycle Ridership

Sun, 21 Feb 2016 21:02:00 +0000

Denver, Colorado is considered to be one of the most bikeable cities in America. In addition to the fine bike lanes, bike trails, and mostly favorable weather (300 days of sunshine, says the possibly dubious but sunny claim), Denver is also a B-cycle city, with bicycle rental kiosks dotting the sidewalks near the city center. For this short study, I obtained Denver’s 2014 B-cycle trip data, and used it along with some other data sources to see if I could model hourly ridership across the Denver B-cycle network. My study indicated that most calendar and clock variables are highly significant when predicting ridership, and weather variables such as temperature and amount of cloud cover appear to be as well. This post details how I obtained the data, how I merged data from different sources, shows some explorations of the data, and finally shows how I created a regression model of system ridership.

About B-cycle

B-cycle is a public bicycle sharing company that operates in several cites, including Denver, Colorado. The premise is that users may “checkout” a bike from a kiosk, which is usually along a city sidewalk, under various short- to long-term access passes, depending on the user’s preference and anticipated usage. In Denver, most of the kiosks appear to have 10-20 “docks” where the bikes are stored until a user checks out the bike. After a user checks out a bike, they ride it for as long as they wish, and then check it back in any B-cycle kiosk. In 2014, Denver B-cycle operated 84 different kiosks, which are mostly clustered around the city center. At the end of the year, B-cycle posts their yearly trip data as an Excel spreadsheet on their company webpage. I used these data, along with data from a few other sources, to conduct this study. For more information, please see the Denver B-cycle homepage.

Data Acquisition and Merging

For this report, I obtained data from several sources and combined the data together, taking the following steps. Most of the initial data download and munging steps can be replicated by looking at the exploring_bcycle_data.Rmd file; most of these steps were too time-intensive to be carried out in a production-level script.

Downloaded B-cycle 2014 Trip Data from the B-Cycle company information webpage. I did some date munging and changed variable names to ones that are more R-friendly.
Obtained B-cycle kiosk data (kiosk name and address) by hand from the Denver B-cycle homepage.
Created a list of the 6800 combinations of checkout kiosk/return kiosk. For each combination, I used the mapdist function from R’s ggmap package to find the approximate bicycling distance and time between each kiosk. Because of the large number of one-way streets in the Denver downtown area, where the kiosks are highly clustered, I chose to find each checkout-return pair’s distance separately, rather than finding a single distance for each pair regardless of direction of travel. This process took three days, because the Google Distance Matrix API (which the mapdist function uses) only allows 2500 calls a day.
Found the latitude and longitude for each station using the geocode function in the ggmap package.
Obtained an API key from forecast.io. Within R, in my exploratory Rmd file, I wrote a function to download the weather data from forecast.io. Each day’s hourly data comes in a separate JSON file; I saved each JSON file to a directory.
Within the production script, I merged different parts of the above data in different ways, depending on the specific task goals. The final merging was to merge aggregated hourly checkout data with the hourly weather data.

A Note about Holidays

For my study, I factored in City of Denver observed holidays. Denver city celebrates all the same holidays as the federal holidays, with the following exception: Columbus Day is not a city holiday, and is replaced by Cesar Chavez Day, usually in late March. I only factored in the major federal holidays that result in government and bank closures (with the exception above), and not the lesser holidays.

Basic Ridership Statistics

Number of Rides

The B-cycle data, as downloaded, contains 377,229 rows of “trip data.” Nominally, this means that 377,229 B-cycle trips were taken in 2014. Indeed, the 2014 Denver B-cycle annual report claims this to be the number of rides for the year.

However, over 1% of the rides (4279 rides) have the same checkout station as return station with a trip duration of only 1 minute (see Figure 1 below). I believe these should be filtered out because I believe the majority of these “rides” are likely people checking out a bike, and then deciding after a very short time that this particular bike doesn’t work for them. I believe that most of the same-kiosk rides under 5 minutes or so likely shouldn’t count, but only culled the ones that were one minute long.

Figure 1: Trip Duration when Checkout Kiosk and Return Kiosk are the same

I also filtered out 258 rides with an “invalid return” station. This could be any number of things, but since finding nominal distance for these rides is very difficult, I filtered these out as well.

With the above, I arrived at an estimate of 372,684 B-cycle rides in 2014.

Distance Traveled

As mentioned in bullet #3 in the Data Acquisition section, I used a Google Maps API in the ggmap package to derive the between-station distance for each station pair and then for each ride. Because a large number of rides were returning to the same kiosk, meaning the minimum distance ridden cannot be estimated by Google Maps, I estimated the distance ridden by calculating the average speed of all the other rides (nominal distance ridden divided by the duration), and then applying this average speed to the same-kiosk trip durations, capping the trips at an arbitrary 5 miles. While it’s likely I am underestimating the total distance ridden by a fair amount (perhaps 25%), since many riders will not take the straight-line distance between two stations (especially tourists/non-commuters), I estimate riders rode at least 616,960 miles on B-cycle in 2014, with a more likely number 25% higher at 771,200 miles.

Most Popular and Least Popular Kiosks

Most Popular

The following ten kiosks are the most popular kiosks by number of total bike checkouts in 2014. The return kiosk popularity is very similar.

REI                     9898
14th & Stout            8903
22nd & Market           8896 
18th & California       8363
1350 Larimer            8273
13th & Speer            8128
Market Street Station   8116
1550 Glenarm            7940
16th & Platte           7714
Denver Public Library   7401

Least Popular

The following ten kiosks are the least popular kiosks by number of total bike checkouts in 2014.

29th & Zuni                      780
Florida & S. Pearl               987
Louisiana / Pearl Light Rail    1407 
Ellsworth & Madison             1523
Pepsi Center                    1610
Denver Zoo                      1704
33rd & Arapahoe                 1851
32nd & Juliann                  1926
Colfax & Garfield               1989
32nd & Clay                     1997

Map of Station Popularity

I used the ggmap package to create the following map showing the popularity of the various checkout kiosks (Figure 2). The size of the circle is proportional to the number of checkouts from that kiosk in 2014.

Figure 2: Kiosk locations and number of checkouts in 2014

Checkouts Per Membership Type

B-cycle has a number of different membership passes. The following were the top 5 by number of checkouts in 2014.

Annual (Denver Bike Sharing)               232180                                  
24-hour Kiosk Only (Denver Bike Sharing)   119489                    
30-day (Denver Bike Sharing)                 6025
Not Applicable                               4490
7-day (Denver Bike Sharing)                  3853

Ridership by Calendar and Clock Variables

Ridership by Hour

To dive a little deeper into the data, I aggregated the data by taking the total number of bike checkouts for each hour of the year. All checkouts in a given hour were assigned to that specific hour (i.e. a checkout at 6:02 AM and a checkout at 6:56 AM both count as a checkout in the 6 AM hour).

I then totaled the number of checkouts in a given hour of the day – summing up over the entire year (so the 10 AM sum is the total number of riders checking out a bike in the 10 AM hour for the 365 days in 2014). Figure 3 below shows the total number of bike checkouts for each hour of the day, and Figure 4 shows the estimated distance ridden given the hour of checkout.

Figure 3: Number of checkouts by hour, all 2014

Figure 4: Estimated average miles ridden by hour of checkout

These figures show that most bike checkouts occur during the 4 PM and 5 PM hours, likely for the evening commute; however, people are more likely to ride a longer distance during the middle of the day – this may have more to do with the “tourist factor.”

Ridership by Hour and Weekday

I also looked to see if the above patterns held true each day of the week, or if the patterns were perhaps different on the weekend. Indeed, as Figure 5 below shows, the weekday patterns (days 2-6) are all fairly similar; the weekend patterns show a significantly different shape, with usage peaks occuring between 1 PM and 3 PM.

Figure 5: Checkouts by Hour of Day per Weekday

Ridership by Month

Another calendar factor I explored was the number of checkouts by month. Unsurprisingly, as Figure 6 shows, most bike checkouts occur during the summer months of June through August, and the fewest checkouts occur during the winter.

Figure 6: Total Checkouts by Month

Merging with Weather

After looking at ridership as it relates to calendar and clock variables, I merged the data with hourly historical weather data. My hypothesis, based on observations of bicycle riding around Denver, is that in addition to ridership being affected by the time of day, ridership is also affected by the weather. We would likely expect more riders on warmer days (the monthly ridership statistics may be a proxy for this).

Checkouts vs. Temperature

One variable I plotted is the number of bike checkouts versus the temperature (Figure 7 below). I noted that the relationship between numbers of riders and temperature appeared to follow curve, rather than just a straight line. I fit a loess curve in ggplot to visualize the curve; based on this, in my linear regression in the next section, I used temperature and temperature squared for my linear model fit.

Figure 7: Checkouts vs. Temperature with Fitted LOESS

In my linear model, I also considered humidity levels and cloud cover levels.

Days with Highest/Lowest Ridership

I also found the 10 days with the highest total number of rides, as well as the 10 days with the fewest number of rides. See tables below. Unsurprisingly, the days with highest ridership were mostly warm (but not overly hot) weekend days, and the days with the least ridership were cold weekend days. One reason for this effect may be that people who commute to/from work via B-cycle may be less affected by the weather in their decision to ride, while the “weekend warriors” who rent the B-cycles for pleasure are highly affected by the weather in their decision to ride.

Highest Ridership Days

[1] "Top 5 Days by Total Number of Checkouts:"
Source: local data frame [10 x 5]

         date total_checkouts max_temp min_temp   weekday
1  2014-07-19            2181    91.96    61.79  Saturday
2  2014-08-01            2085    78.98    56.26    Friday
3  2014-07-05            2082    90.78    61.51  Saturday
4  2014-06-25            2064    84.34    56.20 Wednesday
5  2014-08-02            2027    81.67    54.46  Saturday
6  2014-07-03            1950    89.01    57.01  Thursday
7  2014-07-18            1917    85.38    59.38    Friday
8  2014-07-25            1914    90.50    67.80    Friday
9  2014-07-10            1892    91.93    62.38  Thursday
10 2014-10-04            1892    71.55    39.93  Saturday

Lowest Ridership Days

[1] "Top 5 Days by Fewest Number of Checkouts:"
Source: local data frame [10 x 5]

         date total_checkouts max_temp min_temp  weekday
1  2014-01-05              25     9.21    -2.79   Sunday
2  2014-01-04              30    39.38     9.79 Saturday
3  2014-02-01              40    24.57    11.21 Saturday
4  2014-12-26              42    19.33     9.12   Friday
5  2014-12-30              44     1.49   -10.55  Tuesday
6  2014-05-11              60    46.47    32.10   Sunday
7  2014-11-15              64    23.64     6.78 Saturday
8  2014-12-27              67    27.17     4.78 Saturday
9  2014-12-29              69    18.00     1.94   Monday
10 2014-04-13              75    46.68    20.79   Sunday

Linear Model

My final task in this short study was to attempt to create a linear regression model using a number of calendar variables and weather variables.

Setting Up Input Variables

To create this model, I forced the calendar variables to be “factor” variables. For example, it makes little sense to treat the months as actual integers – the integers denoting the months are stand-ins for the months’ names. Similarly, because peoples’ schedules do not follow a linear trajectory throughout the day, despite the increasing hours (the activity levels are more sinusoidal), it makes more sense to treat hour variables as individual factors. Likewise for weekday factors. I also have holiday factors – either 1 for holiday or 0 for not a holiday.

For the weather variables, I have temperature and temperature squared, since the ridership vs. temperature is not a straight linear relationship. I also used humidity (values between 0 and 1.0), and cloud cover (values between 0 and 1.0).

Model Output

Using the above inputs, I created a linear model. A summary of the linear fit shows the following output. An interpretation follows in the next section.

fol <- formula(num_checkouts ~ temperature + temp_sq + humidity + month + wday + hour + is_holiday + cloud_cover)
                        
Call:
lm(formula = fol, data = merged_data)

Residuals:
   Min     1Q Median     3Q    Max 
-83.76 -14.02  -1.27  12.56 148.12 

Coefficients:
              Estimate Std. Error t value Pr(>|t|)    
(Intercept) -2.833e+01  2.561e+00 -11.060  < 2e-16 ***
temperature -4.677e-01  5.315e-02  -8.800  < 2e-16 ***
temp_sq      1.789e-02  6.025e-04  29.698  < 2e-16 ***
humidity    -4.332e-01  1.919e+00  -0.226  0.82141    
month2       1.115e+00  1.278e+00   0.872  0.38303    
month3       8.045e+00  1.257e+00   6.399 1.64e-10 ***
month4       1.036e+01  1.346e+00   7.698 1.53e-14 ***
month5       6.819e+00  1.545e+00   4.415 1.02e-05 ***
month6       3.727e+00  1.778e+00   2.096  0.03612 *  
month7      -4.154e+00  2.014e+00  -2.062  0.03921 *  
month8       1.857e+00  1.892e+00   0.981  0.32639    
month9       1.061e+00  1.752e+00   0.606  0.54460    
month10      1.167e+01  1.441e+00   8.101 6.21e-16 ***
month11      2.439e+00  1.259e+00   1.937  0.05274 .  
month12      3.514e+00  1.251e+00   2.809  0.00499 ** 
wday2        4.448e+00  9.715e-01   4.578 4.75e-06 ***
wday3        4.379e+00  9.582e-01   4.570 4.95e-06 ***
wday4        4.718e+00  9.500e-01   4.966 6.95e-07 ***
wday5        6.542e+00  9.556e-01   6.846 8.10e-12 ***
wday6        9.304e+00  9.545e-01   9.747  < 2e-16 ***
wday7        8.487e+00  9.532e-01   8.904  < 2e-16 ***
hour1        3.736e-01  1.766e+00   0.212  0.83249    
hour2        1.406e+00  1.763e+00   0.797  0.42523    
hour3        2.405e+00  1.761e+00   1.366  0.17212    
hour4        2.846e+00  1.770e+00   1.608  0.10784    
hour5        9.176e+00  1.764e+00   5.203 2.00e-07 ***
hour6        2.611e+01  1.763e+00  14.812  < 2e-16 ***
hour7        6.521e+01  1.766e+00  36.916  < 2e-16 ***
hour8        6.601e+01  1.761e+00  37.491  < 2e-16 ***
hour9        3.927e+01  1.766e+00  22.240  < 2e-16 ***
hour10       3.693e+01  1.777e+00  20.783  < 2e-16 ***
hour11       4.943e+01  1.790e+00  27.623  < 2e-16 ***
hour12       5.910e+01  1.805e+00  32.739  < 2e-16 ***
hour13       5.335e+01  1.815e+00  29.388  < 2e-16 ***
hour14       4.746e+01  1.822e+00  26.044  < 2e-16 ***
hour15       5.116e+01  1.827e+00  28.009  < 2e-16 ***
hour16       6.745e+01  1.817e+00  37.126  < 2e-16 ***
hour17       8.211e+01  1.804e+00  45.514  < 2e-16 ***
hour18       5.358e+01  1.795e+00  29.849  < 2e-16 ***
hour19       3.255e+01  1.781e+00  18.272  < 2e-16 ***
hour20       2.549e+01  1.768e+00  14.412  < 2e-16 ***
hour21       2.122e+01  1.767e+00  12.012  < 2e-16 ***
hour22       1.628e+01  1.766e+00   9.218  < 2e-16 ***
hour23       1.077e+01  1.761e+00   6.112 1.02e-09 ***
is_holiday  -2.896e+00  1.536e+00  -1.885  0.05944 .  
cloud_cover -4.018e+00  1.230e+00  -3.267  0.00109 ** 
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 23.78 on 8714 degrees of freedom
Multiple R-squared:  0.7382,	Adjusted R-squared:  0.7368 
F-statistic:   546 on 45 and 8714 DF,  p-value: < 2.2e-16

Model Findings

I have a few intepretations of the above model:

The R-squared statistic of 0.7382 means that approximately 73.8% of the variation in the hourly ridership can be explained by the chosen variables and model.
The residual standard error of 23.78 means that, for each hour, about 2/3 of the time the model will predict total system ridership within plus or minus 23.78 riders.
Most of the calendar variables are highly significant predictors:
- All of the hours of the day from 5 AM onward are significant.
- All days of the week are significant predictors.
- Roughly half of the months are significant predictors.
- Holidays are weakly significant predictors. This isn’t surprising, since holidays aren’t one typical unit. For instance, there may be lower ridership on “family holidays” such as Christmas and Thanksgiving than there are for holidays where people are more out-and-about, such as July 4th and Memorial Day, no matter the weather conditions.
Some weather variables are significant, others are not:
- Temperature and temperature squared are both highly significant predictors.
- Humidity is not a significant predictor of ridership.
- Proportion of cloud cover appears to be a signifant predictor, with a negative slope. That is, a fully cloudy day will have, on average, 4 few riders per hour than an otherwise identical day that is fully sunny.

Summary

Based on my short study of 2014 Denver B-cycle trip data, I found that we can create a linear model of trip ridership based on several calendar and clock variables merged with basic weather data. My study focused on total system ridership, on an hourly basis, rather than modeling specific checkout or return kiosks. Most calendar variables are highly significant when predicting ridership, and weather variables such as temperature and amount of cloud cover appear to be as well. Based on R-squared, approximately 73.8% of the variation in hourly ridership can be explained by the simple model.

Additional Areas of Study

I have many more ideas of ways that we could study this data, which I did not have time for in this particular project. The following are some of these ideas:

Graph analysis – Which checkout/return kiosk routes most heavily used
Kiosk predictive analytics – How to optimize the distribution of bikes at kiosks to make sure there are enough?
Find a better method of predicting distances ridden.
Trend analysis of ridership over more years than just 2014 – how is the program growing, and can we predict its growth in the near future?
Break down hourly data into 15-minute increments for finer-grain resolution of ridership data – do we see a spike just before or just after the top of the hour during commuting times?
Use autoregressive weather variables (like “lagged” temperature variables). Perhaps people may be less likely to use a B-cycle today if yesterday was very cold (even if today’s a bit warmer – but perhaps the opposite is true!).
Model “interactions” between variables in the linear model. As it is, the variables are being modeled individually; however, there are likely significant interactions between variables that we should model (for instance, 75 degrees at 10 AM is different than 75 degrees at 9 PM with respect to ridership).
Actually use some machine learning techniques to see if we can produce better predictions than the linear model, and test with training/validation/testing sets. I believe that if we tested some decision-tree methods (such as random forests or gbms), that we could likely get much higher predictive power than the linear model can give us.

About this Project, Source Code

I originally completed this project in August 2015 as my final project for University of Washington’s Methods for Data Analysis class, course #2 of 3 in the Data Science Certificate program. This blog post has only been slightly modified from my assignment submission. Source code for the analysis, in addition to other project files and data, can be found in my denver_bcycle repo on GitHub.

Reviewing the UW Data Science Certificate Program

Tue, 19 Jan 2016 11:26:00 +0000

In December, I completed the third of three courses in the University of Washington’s Professional & Continuing Education’s (PCE) Certificate in Data Science program. All courses in this program were 10 weeks long, with 3-hour lectures held once a week. Since I live in Denver, I could not physically attend the meetings, held at the UW campus in Seattle, so I was part of the online cohort. This is my review of the program, and hopefully may be useful for others that are considering the program.

Why Did I Enter the Certificate Program?

Time for a Change

In early 2014 I decided I had had enough. I had been doing data-related work for the federal government for a little over 8 years, but I was ready for a new challenge. The work was good, but I was tired of the crushing bureaucracy, and feeling like my career was no longer progressing in the direction I desired (someone unfortunately decided that I had a little bit of aptitude for management, and I could feel myself getting pulled in), and was tired of using a 2006 release of MATLAB to do much of my “fun” data work.

Taking MOOCs

So in 2014 I began taking Massive Open Online Courses (MOOCs) in earnest. I knew I loved, and was fairly good at, data analysis and programming, so I began taking courses in the Data Science track at Udacity (this was before their popular Nanodegree programs were developed). By May, I had discovered Coursera, and in June I began the JHU Data Science Specialization (I finished that specialization in December 2014). I plan to review some aspects of these MOOCs at a later date, but for now I’ll just mention that these courses were life-changing.

UW Certificate and Application

In summer 2014, I found out about the UW PCE Data Science certificate. Even though I was taking many MOOCs, I was still unsure if they would actually help me qualify for a job. I wasn’t getting many hits from recruiters on LinkedIn, and a few applications I chucked over companies’ walls didn’t get any bites. I wasn’t ready for the time and expense of a master’s program in Data Science, so I thought a university professional certificate would be the next-best thing, and maybe help me find some additional contacts to make a job connection.

So I applied for the program. Since it’s been about a year and a half since I applied, I don’t remember many specifics about the application process, but I believe there was a 25-question test on Data Science knowledge (some SQL and stats are what I remember), I had to submit a resume, a short statement of interest, and about $50 as an application fee. It wasn’t too stressful.

Accepted, but New Job!

I was accepted into the program. However, there was a waitlist, so I couldn’t start until April 2015.

By the time April rolled around, I was in talks with a recruiter and had an interview with the company that I now work for. They wanted me to come and do Machine Learning for them! I was 4 weeks into the first class in the certificate program when I accepted my new job. So, I had a dilemma: I had reached my goal (new job in the private sector), but I had just begun this program that I had waited 7 months to start (and paid a non-refundable $1100+ to attend). Should I continue? After some deliberations, I gave in, and decided that the money was a sunk cost, so I might as well learn something.

Course #1 was good enough that I continued to pay for and take each subsequent course, despite massive internal debate each time (do I need this? should I spend my time/money elsewhere?). Overall, I mostly enjoyed the remainder of the program and feel accomplished for finishing; however, I’m not sure it was the best investment of my time and money. I learn more, and more quickly, taking most MOOCs, than I did from this program (James Altucher’s Don’t Send Your Kids to College post comes to mind). But, I also made several valuable connections with my fellow classmates, far more connections than I made from any MOOC.

Is This Program for You?

Ok, enough about my motivations for taking the certificate program. Here are some of my positives and negatives for the program, which, if you are a budding Data Scientist and wondering if you should try for the certificate, might help you to make a decision.

What I Liked About the Program

Certificate from a trusted institution that is a leader in Data Science and Machine Learning.
Attend courses online or in person (if you live in the Seattle area). Nice that they give you the choice, and that even as an online student you can attend “live.”
Personal feedback from the instructors on all assignments (for me it was usually 2-3 lines of feedback). Not sure if this is better or worse than auto-graded or peer-graded assignments on many MOOCs.
Courses taught by Data Scientists in industry. My courses were taught by Data Scientists at Prediction Software, Zillow, and Microsoft.
Opportunity to talk to and ask questions of the instructors. Even online, there is a chat function, and the teaching assistant relays questions to the instructor. It’s nice to get real-time feedback from the instructors.
The cost: I spent around $3400 for the three courses. Much more expensive than a MOOC, but much cheaper than a master’s degree.
Extra learning and reading materials. The instructors all did a great job of finding interesting things to read as part of the weekly assignments.
Making contacts, and a continuous cohort. In the first course, there were about 45 students; approximately half were in-class and half online. The instructors set up a LinkedIn group, and most of us connected (the group is closed, so don’t try to find and join it!). Maybe 20% of the students washed out by the third course, but those students that were most active in the group stayed in and contributed. It’s been fun watching my classmates get new jobs in analytics over the past few months, and making the connections with them has been valuable.
Fairly easy assignments. This one can cut both ways – if the assignments weren’t hard, then I didn’t learn much; but, it means I can supplement my learning with other experiences. On average, I spent 3 hours in class a week, and 2-3 hours on homework.

What I Didn’t Like about the Program

Mandatory class attendance at least 8 of 10 lectures per course. Attendance is taken. The class meets at 6PM Pacific Time and runs for 3 hours. So, since I’m an hour ahead, for me that was 7PM-10PM. For the first two months, I had to wake up at 5AM for work, so attending these lectures while they were being held could make for a sleepy next day. Obviously, the further away from Seattle you are, the more difficult it will be to attend the lectures online.
Watching lectures in real-time. When I take MOOCs, I usually speed the videos up to 1.5x to 2.0x the real speed, depending on how fast the speaker talks. This helps me focus better. With MOOCs, you can also rewind if you miss something. With the live course, obviously you can’t do that until the lecture is posted (usually the next day), and then finding your key moment isn’t trivial.
Cannot see the instructor in lectures. Other online courses I’ve taken have a camera trained on the instructor, so you can see them while also looking at slides. UW’s technology, for some reason, doesn’t show the instructor, so you just hear their voice and look at the slides. This makes it much harder to focus if you are an online student, and dilutes the learning a bit, since you can’t see the non-verbal communication.
Continuity between classes less than ideal. In courses #2 and #3, there were several times when the instructors asked, “Did you learn this last course?” It would be good if a more focused curriculum could be nailed down and the instructors passed information to each other better.
Weka for Machine Learning? In the second course, we did statistics using R. And then, instead of continuing with R in the third course, the instructor taught Machine Learning using Weka. The good people at the University of Waikato did a good job with the Weka software, but is anyone in industry using Weka any more? I don’t see it for many job advertisements. Fortunately, the instructor knew R well, and accepted assignments in R if we wanted, so that’s how I completed my assignments. But, he taught much of the course using Weka, which I think is a major missed opportunity and a mistake.
Not enough depth. Okay, so Data Science is a very broad subject, growing all the time. UW apparently decided for this program that they would go for breadth rather than depth. This is probably a good decision, because there’s only so much you can fit into 90 hours of lecture time, then you send students off to learn on their own, having been at least exposed to new concepts. But I kept wanting to go deeper and learn more about various subjects we talked about; instead we’d move to the next concept for a slide or two.

Quick Review of Individual Courses

Course 1: Introduction to Data Science

The first course was a basic survey of the land of Data Science. It truly is an introduction, and assumes almost no previous knowledge of Data Science. We learned about basic data flow through a project, and went through some primers on tools of Data Science (R, Python, SQL, MATLAB/Octave, as well as a little intro to Hadoop). We had a few homeworks in R, and learned about sparse matrices, and had a SQL homework or two. The course isn’t very challenging, especially if you’ve had any previous exposure to Data Science, but the lectures were good and the extra readings were helpful. I give this course a B- – good content and good instructor, but the speed and depth were not what I hoped I paid for. I almost dropped out of the program after this course, but when it came time to register and hand over my credit card information for Course 2, I went ahead and did it.

Course 2: Methods for Data Analysis

Despite the name of this course, this was primarily a statistics and data wrangling course. I thought this was the best course of the three, and I learned quite a bit about some stats methods I did not know. My running of the course was taught by a Senior Data Scientist at Zillow, an Applied Math PhD who was also a talented teacher. Unfortunately it looks like future runnings of the course may have a new instructor – TBD as I write this – so hopefully they can find a good replacement.

All of the homeworks used R. We had some exposure to doing web scraping with R (yes, you can saw “Ew!” here – Python is far superior for web scraping!), running Monty Hall simulations, doing basic network graph analysis, regression, and creating autoregressive variables, among other statistics concepts. We finished the course with a course project, where we had to find our own data, analyze it, and write a report. My final project was exploring Denver B-Cycle 2014 Ridership.

I give this course an A. I found it to be fairly challenging at times, and the homeworks made me think and took a few hours each. I felt this course was worth my money and my time.

Course 3: Deriving Knowledge from Data at Scale

After a good experience with Course 2, I had no problem signing up for the third course.

This course was kind of, sort of, the Machine Learning course.

This course was taught by a long-time Boeing statistician who is currently working as a Principal Data Scientist for Microsoft. He seemed like a very personable guy, making jokes and telling folksy stories for the class. I wish I could have been at the lectures in person, instead of listening in online, because I could tell he was really interacting with the class and sharing his enthusiasm (he also had a nasty habit of wandering away from the microphone for half a minute at a time).

However, I was rather disappointed in this course as a follow-up to the second course. By now, we had spent probably 3 months doing work in R, for the first and second course combined, so it would have made sense to teach machine learning concepts and assign homeworks in R. Instead, as I mentioned in my gripe list, we used Weka. Sure, Weka has a nice-looking GUI, but I didn’t want to learn a new software that I guarantee I will not use in the future (sorry, but R, Python, and Spark Machine Learning packages will be much more useful). Fortunately, the instructor allowed us to turn in our homeworks in R. But I became so frustrated with the course that I tuned in to the lectures, in order to get my attendance, and then left my computer running while I went to do something else.

The final project for this course was to participate in a Kaggle competition. The focus was only a little bit on the competition – it was more about documenting our process, from understanding exploring the data, to modeling, to writing up our results. The instructor asked us to pair up. This is another very difficult thing to do as an online student. I initially found a couple guys to form a team; however, we were all in different time zones, and given family responsibilities it was difficult to meet up at night, so I eventually said “sorry guys, I’m going it alone.” Each team in the class chose a current Kaggle competition that looked interesting to them, so we collectively worked on about 8 different projects, instead of competing against each other, like in the edX Analytics Edge course. I settled on the How Much Did It Rain? II competition; if interested you can see my project writeup in my GitHub repo.

I give this course a C-. There was good information, and the instructor was interesting, but the choice of Weka boggled my mind, and the course organization was a bit poor (students were often confused by due dates).

Summary

Overall, I give this certificate program a grade of B-.

I would recommend it for people who can attend in person, for those with good tech/math/stats skills who have not been exposed to Data Science, but are really curious and want to learn, and for those who like a very well-structured learning environment. I also would recommend it if you are interested in growing your professional network of like-minded individuals (especially those in the Seattle area). I’ve heard that people in the courses network and have helped each other find jobs. Maybe that happened in my cohort(?), but it’s hard to tell as an online student.

I don’t recommend it if you’ve taken, or are comfortable taking, MOOCs in Data Science and/or Machine Learning (Coursera, Udacity, edX, etc), or perhaps are willing to slog through the Open Source Data Science Masters list, or have been working in a Data Science capacity for any length of time. For my money and my time, courses on the MOOC sites were much more valuable. Don’t expect to finish these three courses and come out a Data Scientist on the other side – this barely scratches the surface (although it could be a good place to start!).

If you have any additional questions, please ask them in the comments below! Also, if any of my fellow students care to share their experiences in the comments, that would also be appreciated! I am but one voice; anyone else trying to decide for themselves whether this is a good program for them would be wise to listen to more than just me!

Hello World!

Fri, 15 Jan 2016 03:53:00 +0000

Just as the Hello World program is meant to introduce programmers to the basics of a new-to-the-noob programming language, this post is a break-the-ice post for me on my new blog. I’ve thought about doing a blog for a long time. But, there’s a lot of inertia to overcome when starting almost anything, and writing a blog is no different. I’m not usually described as lazy, but there was always a different MOOC to take, or LinkedIn post to read, or Denver Broncos game to watch, or one of my kids to chase. And sleep is important too – I am not one of those people who functions well when I’m low on sleep!

But, I keep feeling like I should make the effort, even if it’s only occasionally. Hadley Wickham, who has done so much to make R a bona-fide practical, useful, and (dare I say) beautiful language for Data Science, said something in his Reddit discussion that I haven’t forgotten:

If you want to give back, I think writing a blog is a great way. Many of the things that you struggle with will be common problems. Think about how to solve them well and describe your solution to others.

When it came time for me to start a blog at work, I found it was fairly simple to set up a Jekyll-powered blog on our Enterprise GitHub account (sorry, due to the proprietary nature of the work on that blog I will not be sharing it with the world). So I’ve taken some of that learning and set up this blog. But I owe many thanks to others who came before me and explained how they set up their Jekyll blogs, or created the templates:

Joshua Lande: http://joshualande.com/jekyll-github-pages-poole/. A great resource for learning how to set up a blog like this.
Ragu Papa: http://ragupappu.com/2015/04/22/setup-website-using-github-pages-and-jekyll/ . Has several links for improvements made to the theme.
Mark Otto for developing the Poole/Lanyon theme: http://lanyon.getpoole.com/

Back to Hadley’s comment, this blog will by my attempt to “give back” when I have time and when inspiration strikes. I hope I can be even a little bit helpful to someone out there.

Thanks for reading!