Data Science Myths

Busting Myths Graphic | Code Tech Bootcamp

By Dimitri Antoniou and Maggie Giust

Data Science, Big Data, Machine Learning, NLP, Neural Networks…these buzzwords have rapidly spread into mainstream use over the last few years. Unfortunately, definitions are varied and sources of truth are limited. Data Scientists are in fact not magical unicorn wizards who can snap their fingers and turn a business around! Today, we’ll take a cue from our favorite Mythbusters to tackle some common myths and misconceptions in the field of Data Science.

via GIPHY

Myth #1: Data Science = Statistics

At first glance, this one doesn’t sound unreasonable. Statistics is defined as, “A branch of mathematics dealing with the collection, analysis, interpretation, and presentation of masses of numerical data.” That sounds a lot like our definition of Data Science: a method of drawing actionable intelligence from data.

In truth, statistics is actually one small piece of Data Science. As our Senior Data Scientist puts it, “Statistics forces us to make assumptions about the nature of the relationship between variables, the distribution of the data, etc.” In the traditional Data Science venn diagram, you’ll see that math/stats make up ⅓ of a working professional. These are tools and skills to leverage, but data science itself is about drawing intelligence from data.

BUSTED

via GIPHY

 

Myth #2: Data Scientist = Business/Data Analyst

This one is so common that we wrote a whole post about it! These are separate and different roles within the data field. While a data scientist will often do analytics, their spectrum of work is wider. A data analyst will use structured data to create dashboards and KPIs, while a Data Scientist deals with unstructured and messy data for a range of outputs. If they’re interested, business analysts will often progress to data scientists.

BUSTED

via GIPHY

 

Myth #3: Data Science = Data Science

This one’s tricky, because it’s impossible to either confirm or bust! The ‘myth’ is that one person or company using the term Data Science is not necessarily the same as another person or company using the same term. Depending on organizational capacity, individual experience, educational background, and many other variables, we might be using the same name for different animals.

Tl;dr: don’t assume a common understanding across hiring managers, recruiters, and practitioners. Look instead for specifics of tools, techniques, methodologies, and outputs. That being said, this one falls in the “plausible” category, because it may actually be true in some circumstances, while false in others.

PLAUSIBLE

via GIPHY

 

Myth #4: Data Science curricula are well-defined and consistent.

We recommend checking this one out for yourself! A quick google search for bootcamps, master’s degree programs, and online courses will reveal that different organizations teach different things. There is no commonly accepted framework for teaching data science! Some focus more on the engineering, others focus more on machine learning, some think deep learning is foundational, and some prefer to use R.

Our curriculum was built through employer interviews, practitioner interviews, market research, and company partnerships. But we’re based in San Antonio! A bootcamp in New York might follow the same process and end up with a different syllabus. Keep in mind, whatever your learning path, that there will be gaps in your learning. The most important thing is to recognize those gaps.

BUSTED

via GIPHY

 

Myth #5: If I want to be a data scientist, I just need to learn Python or R.

This one is common and dangerous! Just like statistics, programming languages like Python and R are tools. They’re just pieces of a larger puzzle! Knowing Python without understanding the data science pipeline is like knowing how to build a floor without having a floor plan. Of course, these are valuable technical skills that give you a leg up, but they’re second in importance to asking the right questions, knowing what tools to use when, and communicating your findings.

BUSTED

via GIPHY

Still have questions? Reach out to us at (210) 802-7289 or DataScience@codeup.com! Want to learn more about Data Science? Check out our recent blog posts at tribucodeup.wpengine.com/blog. And of course, if data science gets you excited, get started with us today at tribucodeup.wpengine.com/apply!

[rev_slider alias=”footer”][/rev_slider]

Don’t Be Scared of Coding

source code

 

Halloween Dancing GIF
When you’re scared to run your code, and it works the first try (Halloween style)!

When I first started as a developer I ran into some scary scenarios. My code was very error prone and I created some functions that I was expecting a string as the output but I got an object. It was very frustrating and I wasn’t even sure I would be able to understand software development let alone have to go and fix my code. My nightmare scenario was to be hired on as a developer and then have to troubleshoot, a.k.a. debug, some other developers code😱😱😱. I think most junior developers have had shared my fear at some point in their career. I was taught to heavily rely upon outputting your results to the console whether its good or bad to help troubleshoot.

In this post I will do my best to help calm the fears of my fellow junior developers with helpful debugging tools and hopefully transition away from relying upon console.log(). While my focus will be on JavaScript these tools can easily be translated to other languages.

Logging output to the console isn’t always helpful

For the longest time console.log() was my go-to when I needed to debug JavaScript code. It was my developer friend who told me what was wrong with my code and was never judgemental . I will admit that there are few scenarios where it is “OK” to output the results of a function to the console.

Except more recently, I have found using console.log() to be less useful when debugging and only making things worse by expecting a good outcome and then disappointing me. Like an expired $5 Amazon Gift Card (Thanks, grandma). Take for example, this gem:

Object doesn't support property or method 'from'

That lovely error is from IE 11 which does not support Array.from(node List) prototype without a shim/poly fill that is available here.

However, I have come to find out that logging errors to the console is either inefficient or completely irrelevant to what may actually be causing the problem in your code. I will admit that some errors are easily resolved by reading the output of the error message and fixing the typo or following the instructions of the error message to help resolve the problem.

So in the image above we are shown a node item which has so many properties that you might not be aware of, which renders console.log useless. You have to know ahead of time what value or specific attribute you are trying to output which requires some abstract thinking or referencing documentation to identify this property. Now using the console.log will output all the entire properties of the node item but its an unnecessary step to add in this line of code while you debug and then go back and remove the line of code.

“You don’t know what you don’t know” -Bill Parcel (Head Coach New England Patriots)

The error the console outputs might provide you with the location of the error, but you may not know why are you getting the error in the first place. Maybe you’re passing the incorrect value to the function or you are working with event handling and bubbling events.

Either way, chances are that you aren’t thinking about that one property that is actually passing the value your expecting because you weren’t aware of how to call it or pass it along.

I’m going to piggy back off of Mozilla’s Debug Playground as an example for why you shouldn’t use the console and instead use the Browsers built-in debugger or equally as helpful is an IDE’s built-in debugger.

cough cough Visual Studio Code cough cough

 Now, whether you prefer Chrome over FireFox is a whole different can-o-worms.

IDE Tools and Online REPLs

“Hey man, I’m a back-end developer and so I need to console.log”

-Fictional Backend Developer

So maybe you don’t have a fully fleshed out web form or you’re trying to get data from some API or JSON file. You need to see data from the function you’re writing or better yet you want to test a function that someone else wrote without having to clone the entire project. Using console.log() seems like the go to. In fact, around ¾ of Node.js developers report using it (in 2017) for finding errors in their applications.

I’m here to tell you of a few better ways to debug your code.

IDE Tools

The first tool I have come to love and trust is one made by a company called Wallaby.js

QuokkaJS (Integrated Scratchpad for JavaScript)

With this plug-in you can write your code and get immediate results. No need to throw in a bunch of console.log’s in your function and check the output. It has an integration for VSCode (💖💖💖 ), JetBrainsIDE and Atom. I personally have purchased a pro license but for the most part the community version will work just fine.

SonarLint ( Like spellcheck but for your code)

I think all developers should have some sort of code linting tool added into their IDE. This helps review your code in real-time and “should” prevent you from compiling or running code with errors in it. I’ve chosen SonarLint because its given me better results than ES6 linter or some other linting tools that i’ve tried. I’m not saying its the best or that the others don’t work but I haven’t had to configure much other than just installing the extension.

Scratchpad (Built-in Browser Javascript sandbox)

Mozilla also offers a feature in their DevTools that allows you to write, run, and view the output of JavaScript code that can interact with the current web page or not.

REPLs

I have a background in .NET development and I have fallen in love with Microsoft’s F# Language along with the fsharp community. While going through the documentation I was introduced to a new term, REPL.

REPL stands for: Read-Evaluate-Print-Loop.

“ In a REPL, the user enters one or more expressions (rather than an entire compilation unit) and the REPL evaluates them and displays the results.” -Wikipedia

So I thought, this was cool and I used my Googliness™️ to search for an online version or service and so I came upon THIS.

REPL.IT

I don’t need to console.log my output or assign the function to var result = greeting() and then console.log(greeting("Jessica")) . I just write my function, invoke it and BOOM! I get the output without the need of console.log() .

Repl.it supports many languages!

I can even create a Repl, write some code and share the link with someone that can give me feedback, Brilliant!

Coincidentally, Repl.it uses Monaco, which is the same Editor that VSCode uses.

Finally, for the developer on a budget (including myself) most popular IDEs have a built-in debugger that works the same was as the debugger in Chrome or Firefox.

I’ve kindly added links to How-Tos: For a few IDEs (don’t get mad if your IDE is not listed, I’m looking at you Atom IDE community).

Debugging in VSCode 

Debugging in JetBrains IntelliJ

Debugging in Visual Studio

Final Thoughts

So why have I gone through the long winded trouble of explaining / trying to convince you why you should wean yourself off of using the console.log and embrace debugging tools? How was this suppose to make you feel better / more confident in writing code?

The short answer is: I believe having more information and proper tools “should” make coding, and for that matter debugging, less daunting / scary.

Use of widely available, open-source debugging tools is key to be more familiar with software development and to grow as a developer.

[rev_slider alias=”footer”][/rev_slider]

Where Do Data Scientists Come From?

Data Science description and diagram | Code Tech Bootcamp

By Dimitri Antinou

Over the last few blog posts, we’ve answered a lot of questions around Data Science: What is it? What’s the difference from data analytics? Which type of program is right for me? If you’re interested in becoming a data scientist, you might be wondering how other people got into the field. Given how new the profession is, most of today’s practitioners probably didn’t study data science formally as undergraduate or graduate students. So today we’re asking: where do data scientists come from?

Let’s start broadly by defining the possible pathways into this career. If you’re a Data Scientist, you probably followed one or more of these paths:

  • Learning on the job: You ‘did it live’ and hacked your way into a data science skillset.
  • Universities: You studied Data Science, Analytics, Statistics, Programming, or Business formally in a university setting.
  • MOOCs (Massive Open Online Courses): You learned through an online resource like Udemy or Codecademy.
  • On-site or corporate training: You were trained by a learning & development department, internal academy, or contracted provider.
  • Immersive programs/bootcamps: You went to coding bootcamp  and learned Data Science through an immersive, hands-on career accelerator (like Codeup, perhaps?)

Each of these pathways has unique advantages and disadvantages across variables like cost, formal credential, length, and pace. A free online program is free and accessible, but takes a lot of dedication to follow through and is harder to change careers with. A bootcamp specializes in quick and efficient job outcomes, but is a big investment. A university offers a formal degree and dives deeper, but is more expensive and takes longer.

Each of these pathways also leaves gaps against the complete picture of a data scientist. From your training you might be missing components like: working with real data sets, understanding industry and company demands, using up-to-date technologies, or even just knowing what you don’t know! What’s important to understand here is that different pathways yield strengths and gaps. Your job is to find, acknowledge, and improve your gap areas!

Now that we have a framework for understanding potential pathways, let’s look at some data. In preparing to launch Codeup’s immersive Data Science program, we researched over 250 data scientist profiles on LinkedIn and analyzed their educational and career histories. Here’s what we found!

Education

95% have a Bachelor’s Degree, 70% have a Master’s Degree, and 27% have a PhD. Of those degrees, the most represented areas of study are: math, stats, business, engineering, and CS.

Degree's by area of study

Career History

Data Scientists come from an incredibly diverse range of professional backgrounds: psychology research, software development, business analyst, mechanical engineering, and more! We saw a few prominent patterns in our data:

Data Scientist Career History

Archetypes

A third component of our research was to interview practicing Data Scientists. We asked questions like: What was your path to the field? What did you study? Is there a need for programs like Codeup? What are the most important skills to learn? After conducting these interviews, we had three valuable lenses to understand the paths into Data Science: educational histories, career histories, and first-hand qualitative research. From these three, we compiled 5 archetypal Data Scientist personas!

 

Codeup Data Science Personas

If you see yourself in any of this research, you might be on the path to becoming a Data Scientist! Still have questions? Reach out to us at (210) 802-7289 or DataScience@codeup.com! Wondering which of Codeup’s programs is right for you? We’ve got you covered. And of course, if data science gets you excited, get started with us today at tribucodeup.wpengine.com/apply!

 

Data Science VS Data Analytics: What’s The Difference?

Data Engineer Infographic | Code Tech Bootcamp

By Dimitri Antoniou

A week ago, Codeup launched our immersive Data Science career accelerator! With our first class kicking off in February and only 25 seats available, we’ve been answering a lot of questions from prospective students. One in particular has come up so many times we decided to dedicate a blog post to it. What is the difference between data science and data analytics?

First, let’s define some of our terms! Take a look at this blog to understand what Data Science is. In short, it is a method of turning raw data into action, leading to a desired outcome. Big Data refers to data sets that are large and complex, usually exceeding the capacity of computers and normal processing power to deal with. Machine Learning is the process of ‘learning’ underlying patterns of data in order to automate the extraction of intelligence from that data.

Data Science

Now, let’s look at the data pipeline that data scientists work through to reach the actionable insights and outcomes we mentioned:

  1. We start by collecting data, which may come from social media channels, network logs, financials, employee records, or more.
  2. We then process that data into usable information stored in databases or streamed.
  3. Next, we look back on the history of that data to summarize, describe, and explain, turning the data into meaningful knowledge. Here we’re primarily using mathematics, statistics, and visualization methods.
  4. Now we convert that knowledge into intelligence, seeking to predict future events so that we can make decisions in the present. This is where practitioners will introduce mathematical/statistical modeling through machine learning to their data.
  5. Finally, we enable action by building automations, running tests, building visualizations, monitoring new data, etc.

Data professionals work at different stages of the spectrum to move data through the pipeline. On the left, Big Data Engineers specialize in collecting, storing, and processing data, getting it from Data to Information. In the middle, analysts work to understand and convert that information to knowledge. Lastly, a Machine Learning Engineer utilizes machine learning algorithms to turn intelligence into action by building automations, visualizations, recommendations, and predictions.

Data Scientists span multiple stages of this pipeline, from information to action. They will spend about 70% of their time wrangling data in the information stage. They will conduct statistical analysis to derive knowledge. Lastly, they predict future events and build automations using machine learning.

For those technical folk out there, data science is to data engineering or machine learning engineering as full-stack development is to front-end or back-end development. For the non-technical folk, data science is the umbrella term that houses data analytics, machine learning, and other data professions.

So what’s the biggest difference between a data analyst and a data scientist? Data scientists utilize computer programming and machine learning in addition to mathematics and statistics.

Still have questions? Reach out to us at (210) 802-7289 or DataScience@codeup.com! Wondering which of Codeup’s programs is right for you? We’ve got you covered. And of course, if data science gets you excited, get started with us today at tribucodeup.wpengine.com/apply!

Debugging with Codey the Rubber Duck

Cody the Duck mural

By Jennifer Walker

I first encountered rubber duck debugging while attending Codeup. Each student had a duck at their seat on the first day of our 18 ½ week advanced full stack web development boot camp. The expression of each duck varied, but they all stared quietly and blankly at us as we took in our surroundings with excitement and anticipation. At the time, I had no idea what it was for or why we needed that bath time friend. Now I do.

Part of what I love about programming is the problem-solving. However, in the attempt to figure out a software solution the developer very often can get tunnel vision – stuck on solving a problem the same wrong way or just get stumped with no real direction. This is where rubber duck debugging is the most useful. It originated from a book called “The Pragmatic Programmer” by Andrew Hunt and David Thomas.

Rubber duck debugging is simple. It includes taking the problem you are trying to solve and explaining it out loud to the rubber duck. This may seem silly because most of us have not talked to inanimate objects since we were kids. However, by doing this it forces a developer to think in a different way and to look at an issue under a microscope. Talking out loud activates a different part of the human brain, which very often helps the developer solve a problem without ever talking to another person. It keeps us from wasting our own time and the time of others when the solution is right at our fingertips.

I have experienced this phenomenon myself when I try to explain aspects of programming to people who are not programmers. It forces me to think of programming in a different way. I have to lose the acronyms, and just speak plain English to a person who isn’t such an avid techie like myself. When I do that I walk away with new knowledge and a refreshed passion for what I have been discussing.

Codey, Codeup's Mascot
Photo: Photos By Marvin Pfeiffer / Staff Photographer

I also learned later that the rubber duck is the official mascot for Codeup. His name is Codey and he has a special meaning to me beyond just rubber duck debugging. I began to sketch him on the first day of class. Over time he began to express my struggles and triumphs while learning to code. He came alive for me and became a student of Codeup alongside me during my time there. If I had a bad day, he totally understood because he was in the fire with me. If I struggled to understand a concept, he got that too and listened while I talked to him about what I was trying to do. Now, as a proud graduate of Codeup working as a software developer at a fantastic company, I keep Codey with me. He is in my car and at my desk at work. He also sits on my desk at home – waiting patiently to hear my struggles and what I am trying to solve for that day.

If you do not have a rubber duck for debugging, I suggest you go out and get one!

From the Service Industry to Software Development

By Randi Mays

Randi Mays

For many teenagers, the path to self-reliance starts in one of two places: a restaurant or retail store. Until it’s time to begin a professional career, you’re working that part-time job stocking shelves, helping irate customers with expired coupons or prepping for the dinner rush. I’d venture to say I’m one of the very few who was sad to leave that lifestyle behind.

I worked in the food service and retail industries for 10 years before I attended Codeup. I took great pride in my work every day; I couldn’t go home until everything was near perfect: my work area spotless, the shelves neatly stocked and everything ready for the next shift. When it came time to leave the service industry and move on to professional work, I was initially reluctant. I had found great personal fulfillment and success in customer service. Why would I want to leave?

I have big dreams. Of course I want to travel the world, spending my vacations in exotic destinations, trying new foods, seeing centuries-old architecture, and making lasting memories. But more importantly, I wanted to work for a company with a more widespread mission than gastronomic satisfaction. I wanted to work alongside people with a passion for their work that ran far deeper than a paycheck.

After graduating from Codeup in September 2016, I began working for USAA as a software developer and I can tell you–the company is no stranger to giving. Each employee receives company paid volunteer hours and I used some of mine to volunteer at the San Antonio Food Bank among dozens of other USAA employees. Last year when Hurricane Harvey hit, USAA was quick to organize several volunteer sessions at their home campus to prepare food and other basic necessities to be delivered to people in need. They even have a system where I can automatically deduct a specified amount from my paycheck to give to charitable causes I am passionate about. I have heard story after story about their representatives on the phone going above and beyond their duties to serve members in combat zones and at home. I can’t enumerate here all of the reasons I admire USAA for its community involvement and caring, but I’m sure I’ve made my point.

There are times I look back on my experience in food service and retail nostalgically, remembering how I excelled in those positions and enjoyed the repetitive work. Then I come back to the present and remember how big an impact my employer makes serving the military community and their families, and how many lives are changed by the work I do with my team. I find great personal satisfaction and pride in my work every day, and I am just getting started.

Codeup Student Check In: Month 2

Codeup coding school

Codeup welcomed our newest cohort, the Wrangell cohort, on July 23. With the start of this cohort, we are launching a new blog series: the Codeup Student Check In. We’ll interview a student over the course of the 4.5 months to see how things are progressing from first impressions all the way to graduation. Thus, welcome to the Codeup Student Check In: Month 2!

We took the time to sit down with our Wrangell student to see how they’ve been doing so far!

Codeup: Describe what you’re learning right now. Is it hard/fun/challenging?

Wrangell Student: In this section of the curriculum we are learning about the basics of Java and the building blocks that make up the language. This language is more verbose than previous material, and one of the hardest parts is understanding the instructions and translating them to code.

C: How has the learning process/information gathering been?

S: A wide variety of resources are available. In addition to the curriculum, I utilize the Head First Java book and the Oracle documentation. Another challenge is combining the knowledge from all these resources into one.

C: How do you feel your skill level compares to last month?

S: Comparing my skill level now with that of last month is no contest. Everyone around me is improving as well and I am excited to see my classmates skill levels growing. Our skills are improving exponentially!

C: How have the instructors and staff been helpful?

S: The instructors hold study hall before class and after to give us extra help. They’re constantly posting resources in our slack channel and encouraging us to ask questions. They have no problem going back to review material or clarify any questions we have. At the same time, they encourage our learning. They don’t give us the answer if it’s obvious or an easily searchable question.

C: Share a fun experience you had at Codeup!

Our great staff gave us some very cool thermoses. I’m a diehard sticker fan. I immediately ordered coding and anime related stickers for this thermos and they’re going straight on the thermos the moment they come in!

C: What has been the most memorable part of this month and has anything exciting happened?

S: Codeup expanded onto the 6th floor of the Vogue building, so we’re coding in a totally different environment. It’s full of natural light, which makes me very happy. I personally love heights so it’s great to look out the windows while taking a break from coding.

Something exciting that happened was that I got my first star! Instructors give us stars for asking good questions. I’m the type of person who needs to google the answer first before asking something. I wouldn’t want to ask something that is easily available on the internet. However, Java is very challenging, and I just needed to ask questions and I got a star! Super exciting!