A Fortnight Has Finished: Initial Insights and Impressions

Week two has officially ended for the Galvanize data science cohort in Denver, and there is no better time to discuss takeaways from the week – as well as first impressions of the program.  There was a flood of information and experiences thrown at us, so I write this in order to speak on the week’s events as well as organize the new “data” that has been entered into my brain.

---

General Schedule

Due to the length of the immersive program at Galvanize being only three months, the daily workload is quite demanding.  A typical day begins at 9am with a mini quiz – a short challenge that is meant to test everyone on the previous day’s material.  At 9:30, the students submit their solutions and a morning lecture is given (typically an hour to an hour and a half).  After this lecture, the class breaks for the individual assignment/lunch, a span of typically three hours.

The individual assignments are constructed so that if one has a relatively solid understanding of the material, they should be capable of finishing the assignment with about an hour to spare for lunch.  That being said, we are constantly reminded that it is not required of anyone to finish the assignment.  In contrast to an assignment completed sloppily, the instructors would rather a portion of the assignment be completed with quality work.

After lunch, there is another lecture, often ranging from one and a half to two and a half hours.  This often happens due to the concepts being increasingly difficult compared to the first half of the day, and more time must be devoted to their explanation.

Read my discussion on pair programming here

The longest portion of each day – typically three to four hours – is the pair programming assignment.  Here we are encouraged to cooperate with one of our fellow students (a new person each day) in order to solve complex problems related to that day’s topics.  The instructors often stress the importance of these exercises, as they prepare us for working in a team setting.  If you’re interested, you can find a focus on pair programming in my previous post.

The Actual Material

The influx of material each day is large, and there is no doubt the curriculum is meant to push the limits of our mental capacity.  The first day of class, we learned everything about SQL that we would ever have to use in a practical sense – joins, temporary tables, pivoting data, and data wrangling.

Never say no to pandas

Two days later, the day was dedicated to working in NumPy , pandas, and SciPy, followed by matplotlib and Seaborn the next.  These are all packages that can be used with the Python programming language for data analysis and visualiztion.  It was clear to see why the required pre-course work was so extensive, as one would undoubtedly be lost without some familiarity.

The second week, focus was shifted to probability and statistics.  The pre-course work had contained a few examples of coding and statistics merging together, but this week served as an introduction to the sheer magnitude of things you can do.  I’ve barely started, but I’m gradually becoming more aware of the capabilities of data science’s multidisciplinary nature.

Though the flood of information is intense, I have been able to keep up quite well.  While that does require a significant amount of personal study, I also believe a large part is thanks to the structure of course.  The concepts are explained concisely, and about 5-6 hours everyday is dedicated to putting those concepts into practice.  This has been fundamental in solidifying concepts for the students, and I am grateful for the amount of time that can be focused on implementing what is taught.  Moreover, if there is any confusion, the instructors are constantly in the same room (sometimes the same table), and can explain concepts individually if need be.

Extra Endeavors

I’ve also individually started a nanodegree program on Udacity for machine learning.  Machine learning is built on the foundation of coding and statistics that fills the first few weeks of curriculum.  The nanodegree program was co-created by Google and Kaggle (a platform where companies post their data and people compete to produce the best model).  Given that one works for 10 hours a week, Udacity expects the program to take 42 weeks to complete.  My goal is to complete the material in two months, so the intensity has definitely been increased.  But, if I’m going to be drowning in data science for the next three months anyways, I might as well dive in!

A Machine “Learning”

My main motivation for taking the course was to get a head start on machine learning concepts, as well as get a nice qualification under my belt.  The program consists of five projects and one capstone project.  Since Galvanize has a capstone project as well, I plan to finish the nanodegree material and create an amazing capstone project, which I will use for both Galvanize and Udacity.

I have seen some capstone projects from previous cohorts, and I can’t help but think to myself “Am I really going to be able to do those things at the end of the program?”  As time continues, my excitement for the future exponentially grows.  I anticipate the day where I will have a project of my own to present.

---

In this past week, I have worked on assignments with a former drumming instructor/performer and an ex-entrepreneur who had attempted to innovate LED technology.  I am honored to be surrounded by fellow students and instructors from whom I can learn so much, and appreciate the opportunity to be a part of such a community.

Thus far, Galvanize has been an eye-opening introduction to the world of data.  I have become more aware of the labor and skill behind initiatives that utilize data science to better humanity.  I look forward to what next week will bring and will continue learning so that I may one day be capable of the same feats.

A Meditation on Pair Programming

 

When my partner and I can pair program efficiently

Four hours each day at Galvanize’s Data Science program is dedicated to pair programming.  Initially, I expected each cooperative experience to be smooth and efficient.  With some people, efficiency doubled; however, with others, efficiency exponentially decayed.  Therefore, I began my endeavor to understand this phenomenon.

What is Pair Programming?

The structure of pair programming consists of a “driver” and “navigator”, who alternate roles periodically.  The driver types the code, while the navigator focuses more on the overall direction of the code.

This approach to coding is common, as it can improve accuracy and quality of work.  Though it may require longer man-hours, the decreased volume of mistakes can save a company time and money in the long run.

That being said, my experiences thus far have shown me that this isn’t always true in practice.  In fact, it is quite common for there to be frustration among pair programming partners, for reasons such as differences in personality or even coding methodologies.  In this article,  John Kim, a software engineer at CDK Global, briefly discusses some pitfalls he’s experienced with pair programming.

How I feel pair programming w/ some people

Why am I Writing This?

From the beginning, I genuinely appreciated pair programming for all it had to offer.  My first partner and I worked well together, effectively solving problems and progressing farther than many other teams; I was amazed at our efficiency.  However, different partners brought different levels of productivity.  I became aware that pair programming can decrease efficiency as well.  Though most of my experience has been positive, there have been times I left the exercises dissatisfied with the progress made.  In these scenarios, disagreements stop the gears of progress rather than facilitate it.  I often leave these experiences exasperated and fatigued.

This starkly contrasts with positive experiences where interaction seems to flow naturally.  Both conversation and debate are smooth and constructive, leading to a better solution than either partner could discover on their own.  Assignments are completed effectively and submitted early.  These experiences always leave me feeling fulfilled and energetic.

I set out with the goal of finding a solution to this disparity; I wanted every partnership to be as fulfilling as the last.  Therefore, I hoped to find advice about what I could do differently to make every assignment enjoyable for me and my partner.

Is it Simply Compatibility?

During my endeavor, I stumbled upon an article by the New York Times.  The article explained insights Google gained through Project Aristotle – an initiative enacted by the company in order to understand why teams fail or succeed.  The article is a fascinating read, and I recommend it to anyone who has some free time.

The insights gained from Project Aristotle challenge many current team building practices.  For years, employers and recruiters have been forming teams based on member personalities and skill sets.

For example, the Chief Data Scientist of Sailthru, Jeremy Stanley, suggests companies implement a “Data Day” for potential data science hires to partake in.  During this stage of the application process, an applicant works with the team on an open-ended challenge.  This gives them a chance to assess their skill and compatibility with the team.

Despite current team building conventions, the research conducted on Google employees for Project Aristotle suggests that the group norms of a team are the only consistent indicator for success.

Among the varying group norms Project Aristotle discovered for each successful team, there were two traits common among them all:

1. All members of the team spoke in roughly the same proportion
2. There was a collectively high “social sensitivity” – the ability to discern how other members feel based on a variety of non-verbal cues.

Subjectively speaking, this makes logical sense.  During my positive pair programming experiences, each person felt comfortable voicing their thoughts, resulting in better communication.  I was also better able to discern my partner’s thoughts and feelings through their body language in these situations.  The reason for this may be that I often considered my partners in these scenarios as friends rather than colleagues.

However, not every successful team in the study was composed of coworkers who were friends.  In fact, one team’s members were complete strangers outside of work.  If this is the case, how come both of these teams still exhibited the same common traits?

I believe the teams that attained success did so because they practiced good communication habits.  The successful teams created environments where everyone was given equal opportunity to speak, and each member knew what they had to contribute to the team.

A more detailed explanation of Project Aristotle’s findings can be found here.

What I’ve Learned

Though I do attempt to speak objectively, the above analysis was spurred from my own experiences.  There are bound to be differences between the program and a company when it comes to pair programming, the most obvious being that we are asked to pair with a new person every day.  This may be a major factor, as there is no consistency.

Nevertheless, I’m positive there will be moments when I will be required to work with someone I don’t know well.  It is also clear that these frustrations do exist in real life situations.  Because of this, I’m glad to have researched and reflected on this topic.  I’ve recognized the effort and awareness that is required for smooth cooperation, and I plan to make a more conscious effort in putting these lessons into practice.

By discussing with my partner beforehand and specifying guidelines for working together, I hope to avoid frustration and instead encourage constructive dialogue and consistent communication.

I’ve learned a lot from these past two weeks at Galvanize.  However, the most important lessons are the ones being taught to me by my peers.  By working with others, I am able to develop abilities just as necessary and beneficial as anything I’ll learn in the classroom.

The Journey Begins

A front view of the Galvanize Denver – Platte location

I write this post one week after I have officially started my path in data science.  The building pictured to the left will serve as my launchpad into this field.

There are many reasons I find myself in Galvanize today – many of which I plan to elaborate on during the duration of my time in the program through this blog.

The program takes place at one of Galvanize’s seven campuses around the country.  Founded in 2012, Galvanize offers programs in web development, data science, and data engineering; moreover, their locations serve as hubs for entrepreneurship and business, being populated by innovative companies and startups.  For the next three months, I will be attending their Data Science Immersive program.  One week has already made it clear that I will have a multitude of opportunities to expand the scope of my knowledge.

In a cohort that consists of former entrepreneurs, middle school math teachers, chemical and petroleum engineers, and even ex-retirees, the range of experiences are vast.  My fellow students all have interesting backgrounds and stories, each with their own motivations for attending this program.  Furthermore, the program grants me opportunity to interact closely with instructors who have years of experience in the field.  I believe the lessons I learn from my fellow students and mentors will be invaluable in the future.

---

Galvanize (v.) – to excite about something so that action is taken

I stated earlier that I had many reasons for choosing this path, and I would decisively cite the diversity of data science and it’s ability to change the world as my major motivations.  I have been convinced that through the study and utilization of data, I can truly impact the world in a positive way.

It is as of this moment that I officially find myself Galvanized Into Data Science.