By Caity Moran
on April 7, 2015
We recently had our second workshop for people who have never written a line of code. The goal was to demystify web development and get people excited about building web apps. To do this, students built a landing page using HTML, CSS, a text editor and a browser. That night, every student was invigorated with the prospect of learning something new. And the energy was contagious.
As our teaching assistants were buzzing around helping students, I noticed that there were a lot of women in the room. Then I counted, there were two women for every man taking the workshop. That’s huge!
At The Starter League we value diversity*. It creates a unique environment where learning goes beyond the classroom or curriculum and students also learn from their peers’ experiences. We’re always looking for ways to draw a diverse student body. And we’re doing pretty well, 40-55% of our applicants for our classes are women. When it comes to converting applicants into enrolled students, those numbers drop.
So why do less women convert to students? And how do we get more women to convert?
Let’s start with why less women convert to students. I often hear women say they’re intimidated by coding or apprehensive of jumping into the tech scene or start a coding course. I get that. I can’t speak for all women, but I can speak for myself. In both my educational and professional career, I’ve encountered people who made me feel incapable.
I minored in computer science and my classes were predominantly male. In programming classes, we were often paired up for assignments to work through the problem with a partner. On several occasions, I would reach out to my partner about our shared assignment and get a response akin to, “Oh don’t worry about it, I already did our assignment with another group. I figured you were busy, and I wanted to make sure it got done.”
Which left me with two options: don’t do the assignment and fall behind in class. Or take what was supposed to be a group assignment and figure it out on my own. It was frustrating and insulting. I had to work twice as hard just to prove I wanted to be there and could do the work.
Here are a few examples of assumptions people have made about me over the years:
- When I offered to help troubleshoot the AV issues for an event renting space at 1871. I was told, “I’d feel more comfortable with the AV guy, he will really know what he’s doing.” I was the AV guy.
- While having a conversation with an older gentleman and one of my college interns, the older gentleman looked at me and said, “Oh I guess I shouldn’t swear in front of you.” If you really feel that way, then please don’t swear in front of my 18 year-old intern either. Otherwise, don’t apologize to me.
- Can you have you web guy update our logo on your website? I was the web guy.
- “I guess not all blondes are dumb” then he laughed and said he was joking. Enough said.
I could give you a dozen other examples. Instead, let me share that I've had the honor of knowing and working with so many amazing individuals, both women and men, who have imparted knowledge and believed in me. I focus on those people.
Now, how do we get more women to convert? I think these workshops and events like them are a great start. They provide a lot of value for just three hours of instruction. It's also a much smaller commitment compared to an 11 week class. But just having a workshop isn’t going to convert more women.
We need to use these opportunities to show everyone intimidated by coding that its not a bro’s club. It’s imperative to create and foster a culture that is welcoming and inclusive. You can actively make an effort to be part of the solution, not the problem. We all make assumptions about the people around us. Making statements with these assumptions can alienate and set people up for failure. Not to mention, we’re often wrong. Instead of making assumptions about why people want to learn, what brought them here and what their goals are… ASK them. Get to know them and let them tell you their story. Assumptions don’t bring us any closer, conversations do. Challenge yourself and those around you to be a part of the solution.
*Diversity is about more than gender: age, race, work experience, marital status, education, country of origin, etc. but for the purpose of this post I focused on gender diversity.
By Mike McGee
on March 10, 2015
This is the second in a series of posts highlighting Starter League representation at MATTER, a new health-tech incubator located at the Merchandise Mart.
I first learned about HappiLabs when Tom Ruginis was a student in our Spring 2013 HTML & CSS class. So I was happy (sorry, I had to) to hear that his startup is in MATTER's inaugural class! I caught up with him to see what was new.
What problem are you focused on solving at HappiLabs?
The big problem is a lack of transparency for information about lab supplies and equipment. This has a 2-fold effect on the industry and consumers (scientific and medical researchers):
1) Scientists are constantly overpaying because they don't know what a fair price is. They don't have a central site/resource to visit and find pricing data, and therefore suppliers have the advantage. This costs researchers around $50-$100 million dollars (per our estimates).
2) Scientists waste time searching the internet and interacting with customer service and sales reps to obtain pricing. They use Google and the very few other resources available. We estimate that scientists spend around 10 million hours per year searching for this information. Those are hours that could be spent doing research and advancing the health of our planet.
The other problem we're solving is creating a new job market (Virtual Lab Managers) for scientists where they don't have to work in a lab but can still utilize the knowledge and skills they have.
How did you identify this problem?
I worked in a cancer research lab as a Ph.D. student, so I understood the use of the products. Then I quit the Ph.D. and became a sales rep where I identified the problem as I was consistently charging very high prices for supplies, and my competitors were charging even higher prices! I'm a scientist at heart, so I was not cool with this.
I kept thinking, "Well if there was a Yelp or Kayak for lab supplies, scientists would spend their money much more efficiently and wouldn't have to spend hours per week shopping around." I quit the sales job and started developing HappiLabs.
I remember watching you present HappiLabs at our Starter League Demo Day. What has changed with HappiLabs since then?
Back then, we were working on the "Yelp for lab supplies." In fact, a few Starter Leaguers in the Spring class of 2013 built a decent MVP where you could review some basic lab supplies (pipette tips, PCR tubes, nitrile gloves, etc.). It's still accessible in the footer of our site, but not in use. It was very difficult to get scientists to write reviews, and we didn't have enough resources to make the UI excellent.
What changed? Like any smart startup, we pivoted. Instead of focusing on sharing pricing data and reviews on a website, which would save money, we realized that customers were also spending too much time on other tasks associated with the purchasing process. Too many hours were spent calling customer service and sales reps to get pricing info, product details, and shipping updates. Scientists shouldn't spend time doing this work.
We decided to create the Virtual Lab Manager to solve this problem. Today we offer a service that allows scientists to hire us hourly to do the purchasing in their lab (and other admin tasks like bookkeeping). Think of a personal assistant with a Ph.D. and who specializes in shopping for lab supplies and finance management.
Our tagline is: Focus on your science, let us manage your lab shopping and finances.
There are 59 other startups at MATTER, have you been able to create any partnerships since joining?
Not yet. I've been traveling a lot to San Francisco--land of biotech--and haven't been at Matter for more than two days/week. The rest of our team focuses on operations, not business development.
What's your vision for HappiLabs?
Every research lab in the world (academic and private) will hire a Virtual Lab Manager to do their shopping and purchasing (OK, realistically, I'll be happy with 15-25% of the market). We'll spend their money better than they could, and the researchers in the lab need to be doing more important things... like solving health problems!
Think about it, there are highly educated Ph.D. researchers, of which there are relatively few in the world, should they spend time searching Google for info about lab supplies or focus on their experiments? It's a no-brainer decision. The world will be healthier and happier if they are more productive with their experiments.
Smaller question, what's next for HappiLabs?
We'll continue to serve our current customers. And we look forward to finding new ones because, for every few customers, we create one new Virtual Lab Manager job for unhappy or unemployed scientists who want out of the lab.
We're also working on raising money and finding a strategic partner to build software to automate this process. These will help lower the cost to our customer (which is an hourly rate), and create an awesome virtual lab manager UX.
Beyond that, we continue to live our mission: to improve the happiness of scientists and the quality of their research.
If you want to learn more about HappiLabs impact on science research, check out this profile below.
Welcome to HappiLabs from HappiLabs.org on Vimeo.
By Mike McGee
on March 5, 2015
This is the first in a series of posts highlighting Starter League representation at MATTER, a new health-tech incubator located at the Merchandise Mart.
Coeus Health was one of the first 10 companies accepted into MATTER and was co-founded by Kate Wolin, a 2014 Starter School graduate. I caught up with her to check-in on their progress!
What problem are you solving?
Obesity is one of the biggest, and most costly, problems facing our country. It extends beyond the health care system to schools and workplaces. Despite this, there are few clinically proven solutions out there. The few that exist are often expensive, or only serve a small segment of the population.
How did you identify this problem?
We’ve been working on health promotion, disease prevention, and disease management for over 15 years. We found that, over time, more and more organizations were asking us to help them identify a solution that they could easily implement, but that worked. When we couldn’t find one, we decided to build it!
Looking at the bios of your team members, it looks like the "Justice League for health." How was your team formed?
Since that analogy clearly makes me Wonder Woman, I’ll take it! I’ve been extremely fortunate to work with a lot of amazing scientists in my career. Gary had the (mis)fortune of being one of the ones who laughed at my jokes, so I kept finding ways to work with him. We shared a similar view on where our academic research should be leading and as we had more and more of those conversations realized we both wanted to do something in this space.
I have had some great mentors in my past life so the opportunity to work in space where mentorship and training are integral to the experience resonated with me. I’m a life-long learner and MATTER provides the opportunity to do that with people also working in healthcare.
How has the experience been so far?
Phenomenal. I’ve been able to attend workshops and meet with mentors. Each time those sessions end, I leave realizing every second of my time was well spent. MATTER was built with a focus on the start-ups and what we need to succeed. The MATTER team has taken the time to chat with the companies and learn what we need and have built everything (the space, the programming) around that.
What has been the main challenge in getting this startup off the ground?
Time and money. There never seems to be enough of either :)
A Starter School hoodie sighting at MATTER!
You've had the opportunity to work in the academic and startup environment. What are the main differences?
The approach to failure. I had never had a conversation about the benefits of failure before I entered the startup world. In academia, there is never a positive slant to failure. Related to that is the approach to when you plan and build. In academia, you have to design your whole study/program/platform before you begin and the result is typically a plan that requires lots of money. The lean approach is starting to make tiny breakthroughs in a few spaces, but it is still really rare.
You've gone through a great period of transition in the past two years, from professor to Starter School student, and now co-founder of a startup. What's the most important lesson you've learned in this time?
I have been blown away by the support I’ve received. I knew I had some phenomenal friends and great colleagues, but I didn’t anticipate how willing people would be to lend a hand, offer an introduction or drop everything for moral support cocktails. Practicing gratitude has been easy because I’ve been so fortunate.
What's the next step for Coeus?
Get out of the building!
To learn more about Coeus Health, visit their website at http://coeusapis.com and follow them on Twitter @coeushealth.
By Mike McGee
on February 25, 2015
This is the second guest post by Starter League alumnus Roneesh Vashisht. He's a professional web developer at Sears and a mentor for our Web Development program. He wrote this message for our current class of web development students, but I thought it was too good to keep in-house.
I've now been coding for over two years (prior to that I was an engineer). I've helped a lot of newbs (aka a beginner) and I've worked with a lot of veterans. In my experience (and this just my experience, so take it only as that!) there's only one thing that determines if you'll be a successful coder:
Can you be zen about errors?
Everyone handles adversity differently, for sure, but the only commonality is if when confronted with a coding problem, can you just step back, breathe and work on it calmly.
It doesn't matter if you're old or young, man or woman, black, white, brown or green. To code, you don't have be smart, you don't have to be clever, you don't have be bold, hell you don't even have to be particularly passionate (though that helps).
You just have to be able to be zen. When you encounter an error that won't go away, you can't start letting a part of you die. You can't let your pulse rise. You can't take it personally. You can't get embarrassed or feel dumb (I mean, you will I suppose, but fight it!). I see it happen to people all the time, and this why "getting zen" is the #1 piece of advice I give to young coders and those looking to get into the field.
Errors, they happen man. Honestly, just today I spent twenty minutes on a misnamed variable. I swear to God I checked everything but the most obvious thing, and I've been doing this two years. You just started, so you'll spend even more time. It's part of the fun!
It also helps remember one important thing: a computer is one of the most fundamentally different things than you that exists on Earth.
Let's look at just one example.
If I tell you to go make me a peanut butter and jelly sandwich, you can do it. Most of you will go make it from your cupboard. A few of you will be clever and call a restaurant. One or two of you will try and convince me a tortilla is a PB&J. No matter the method, you'll do it, with minimal instruction and tons of improvisation.
If I tell a computer "Go make me a peanut butter and jelly sandwich", well, it will sit there and stare at me blankly like a dog. It will wag its tail, it won't even sit! However, if I give it detailed instructions, more detailed than you've ever imagined (like including coordinates of bread locations and stuff), it will eventually do it. And when there are finally the necessary pages and pages and pages of instructions required, it will make the sandwich perfectly.
If I give you 20 single-spaced pages of instructions to make this sandwich, you too will make it, but imperfectly. You'll miss a step or two inevitably. Humans just aren't meant to process 20 single-spaced pages of instructions perfectly, we're meant to improvise.
So don't feel bad, you're doing a hard thing that humans really aren't meant to do. You're meeting an alien life form half way. You're meticulously typing out the instructions and then letting the computer do them perfectly (bugs are when you got the instructions wrong).
This is an illustration of what is actually the only true error that exists in programming: You weren't clear enough on what the computer should do.
Errors are a computers way of saying "Hey man, this list of instructions isn't complete!" and when the errors aren't as helpful as the ones in Rails, well that's kinda like the computer saying "Hey man, I know something is off in this big list of instructions, but I'm not sure what."
So don't get mad, don't get defeated, you gotta get zen. You also gotta get your butt up and go ask for help ;-)
P.S. And don't feel bad about feeling bad! It's all one journey!
Missed Roneesh's first post? No worries, just click on this link - "What is a Web Application?"
By Vince Cabansag
on February 24, 2015
Bootcamps. There’s plenty of buzz around them these days. And for good reason. Who wouldn’t want the promise of a programming job after 3 months of immersive learning? It’s a honeypot that bootcamps use to attract anyone who’s looking for a career change. It’s also a path that’s become dogmatic — immersive learning has become more about sheer hours instead of a culture that promotes learning with a work-life balance.
Spending 80+ hours a week on anything will be disruptive to the rest of your life. If you’re considering a program that teaches you how to build web applications, and you’re devoid of any responsibilities or relationships, then a bootcamp is right up your alley. But there’s better ways to immerse yourself without sacrificing the other parts of your life. If you have a beloved pet, significant other, kids, spouse, or responsibilities that can’t be put on hold, then you owe it to yourself and to them to find a culture that fits your life, not the other way around.
A question that I’ll get when I interview students is, “Why does The Starter League have less class time than XXX bootcamp?”. My response is somewhere along the lines of this: “While we could increase the class hours and teach you everything about web development, there’s only so much knowledge that you can consume at a given time”. A study at UCLA found that cramming can be harmful to a student’s learning outcomes. They concluded that students perform better when they space their study sessions. We plan our classes so that our students have the proper time to implement the concepts we introduce. That’s important for long-term learning outcomes.
We also don’t set expectations where our students should stay up late at night or even sleep in the space because they’re exhausted from coding all night. Working longer, late at night or when you're exhausted doesn't teach you more or produce better work. We intentionally schedule non-class days where students can come in for office hours, review sessions and get help from instructors on their projects. We do this so that they can absorb the concepts from class, work through any issues on their projects, and make themselves better developers through good work flow practice. Our students’ schedule is more consistent with a 9 to 5 business day.
Alex Payne wrote a candid blog post to anyone who is considering a career as a programmer in a startup. After reading that post, I didn’t realize how many mom’s have taken our classes. For example, one of our Starter School students commutes from Libertyville five days a week. Her schedule is like clockwork — she’s in by 8am and out by 4:30pm. She’s also a mother and wife. If we scheduled classes later in the day or asked our students to stay late, then we wouldn’t have students like Amy.
Learning how to code is fun and as addictive as your latest Netflix season binge. If you’re looking at programs that teach you how to build web applications, consider the sacrifices that you’ll be asked to make. You don’t have to give everything up to make an impact on your life.
By Mike McGee
on February 13, 2015
This is a guest post by Starter League alumnus Roneesh Vashisht. He's a professional web developer at Sears and is a mentor for our Web Development program. Our current class has just started to type out their first lines of code, and Roneesh sent this message to remind them of what they're building.
Web Applications are in the running for world's simplest computer programs.
You've learned how to communicate with a computer program.
It's also interesting to realize how little we've come.
From about 1970-1990, a computer program was a thing you bought, probably in a Micro Center or hobbyist store, that displayed and manipulated text. You only communicated with it via text.
From 1990-2005, a computer program became a thing you bought, probably in a Best Buy, but it lived in a graphical world, where pretty soon your typing only became about the content. All other manipulations were graphical, and there was no database. When, how, why or in what way data was accessed was completely obscured. Programming them was hard (believe me I tried). They didn't share data, or play with other people, or do anything other than sit on your computer.
Then from 2005 or so onward, we started entering the world of web applications, and data started to live on the web, and it played nicely with other people, since the data was in the same pool, and now it was in a database, and even a lay person with an analytical mind could guess how that data was structured (hint: it was all forms).
What's interesting is that we've sort of returned to the world of 1970-1990, we only communicate with these programs via text. That text is your params hash and routes tables.
And so when I say that Web Applications are the world's smallest computer programs, I really mean it.
A web application is a computer program designed to respond to one input, a URL.
And since all URL's are just HTTP requests, we get this:
A web application is a computer program that just does one thing: respond to an HTTP request.
I'm not being dramatic or histrionic when I say that the above statement contains all the truth of a web application. It's kind of your North star. When I transitioned from student to full-time developer, I routinely found myself in meetings where I had to discuss technologies I had no clue about. What kept me sane was realizing that I was working on a web application, and it had just one job to do. From there I could riff.
It doesn't matter what your stack is, what language you use or what framework. A web application running Java, with no Ruby whatsoever still needs to be able to parse a URL, run some code, and return a response (a web page). A web application has just one job, and best of all, we can do it with just one thing, an address bar.
So go on, party like it's 1990. It still is.