By Neal Sales-Griffin
on April 22, 2014
When we launched The Starter League (then called Code Academy) we were the first of our kind. There was no DevBootcamp, there was no Flatiron, General Assembly existed but hadn’t taken the “immersive” approach yet.
We thought we were special because we were first. But now there’s more than a hundred software schools that have started in the past three years. Some of our alumni (we’ve reached nearly 1000!) have even started their own schools all over the globe.
We’re proud to have played a meaningful part in the movement as subject zero. But that doesn’t mean it was easy for us to deal with such a hyper competitive landscape.
At The Starter League, we strive to be the purple cow. We offer a completely different experience for our students than any other software school.
Our goal isn’t to place you into a job, it’s to help you solve a meaningful problem with software that you care about.
We don’t only teach you how to design, or how to code. We weave the two together with product managemet and entrepreneurship. It’s the alchemy of those pieces that lead to innovative solutions for people through software. We don’t get commissions for placement. But our students are happily employed and applying their newfound skills in meaningful ways.
It was both a gift and a curse to find little to no examples of a software school like ours. On one hand, we had no competition so our novelty would allow us to garner a lot of attention. On the other hand, there was no evidence of demand which put us at risk with no proof that our model would work.
Thankfully it worked out for us. Though we’ve been navigating the bloody, competitive waters in search for our new blue ocean ever since. I’m happy to report that we’ve built our castle and moat with Starter School.
With these experiences, I’ve learned a lot about dealing with competitors. I’ve also learned how to deal with my own feelings and fears because of them.
When you come up with an idea for a business, it’s important to research the other companies who are solving a similar problem. If you find comparable companies, you’ll discover what works and what doesn’t with their solutions.
But, this process has a dark side.
When you’re analyzing the alternatives, it’s easy to get intimidated about your ability to compete. Most ideas won’t last a day before something like it shows up in your search results.
A natural reaction is to feel a sense of urgency. You’re not moving fast enough. You’re not working hard enough. You don’t want these other guys to build your idea first.
Instead of freaking out, turn the energy you’re wasting on envy into fuel to push forward with your idea.
Competition forces improvement. You owe it to the other companies to challenge them with a competitive product. You should be happy there are potential solutions out there. They are proof of demand for the problem you’re trying to solve.
You’ve got too much work to do and too much to learn to feel salty about their success. All those emotions point to is your own insecurity with your capability to execute.
Embrace the first-movers. Don’t let your hope balloons pop just because you found an example of someone else doing it already. Who cares? They need you. They need someone who’s willing to give them a run for their money and force them to become better. Just like we need the other software schools to push us to become better every day.
“No idea’s original, there’s nothing new under the sun.
It’s never what you do, but how it’s done.
What you base your happiness around? Material women and large paper?
That means you inferior, not major.”
Don’t be jealous of your competitors. When you come up with an idea, do some quick research. Find out what’s out there, what’s missing, what’s unnecessary, how it could be better etc. Then build it, regardless of whether something comparable is out there or not.
By Arvin Dang
on April 18, 2014
Our Starter School students are impressive individuals. Their stories are inspiring and as we've watched them grown over the past six months, we couldn't resist to feature them on our site. Here's how we did it.
We began looking for inspiration from features we loved across the web and pieced together simple layouts. We liked Pitchfork's Cover Stories, but we didn't want to distract from our students' stories — so we asked ourselves, what would best bring them to life?
Our next step was making sketches of potential layouts, then an HTML/CSS prototype. We reworked the grid to see how it felt and used Web Inspector heavily to design in the browser as quickly as possible, taking screenshots as we ideated and shared them with the team in Basecamp for feedback.
It's important to note just how useful Web Inspector was in this phase. This isn't where we wanted to worry about code, but instead where we wanted to discover the right feeling for our page. Using Web Inspector gets you out of the mindset of clean code, and instead focused on just getting it to work. And if something isn't right— just refresh.
We bootstrapped a photo studio using white boards, backdrops, and umbrella lights. We had students bring in props, dumped confetti on them, threw rubber ducks in the air— anything we could think of to get the most entertaining shot.
We processed hundreds of photos using Adobe Lightroom. Our favorite photos were flagged and added to Dropbox for review. Once we had a quality photo sequence picked out, we went back to the HTML/CSS and began coding static versions of what we envisioned.
During the prototype phase, we decided that a sequence of photos would alternate on scroll alongside each student's story as you read them. This would allow a visitor to read a student's profile while sharing a visual moment with them.
Once we finished our prototype, we asked for feedback from the entire Starter League team. After some more iteration, we split up into sub teams to finalize the development, image processing and student profile copy.
We had to build around the notion that content could be any size. A student's profile could be 200px or 1700px long, and our images had to adjust both in size and scroll rate accordingly. You have to stop and think through what your ambiguities are as early as possible. From the sketching phase, we knew we would need a flexible approach to alternating between photos as a user scrolled.
To better understand where we needed to be flexible in our approach, we'd create small test examples in JSBin of each component. We wrote a small script showing how we can capture scroll in jQuery, then another script to show how on scroll how we could change a CSS property like background color, etc. Once we had each of these pieces built, we put them together in the final app.
We realized the constraint became our photos. On some screen sizes they were too big, others too small, sometimes too far to the left, or right of the content. Plus we needed to find a way to have the images stay fixed when you scrolled, but not permanently since we didn't want them to overlap with other elements like the footer.
It took a lot of experimenting, trial-and-error, and time to just sit and think through the problems we would run into. Fixing one issue often created another one. But eventually we chipped away and relied heavily on the resources around us to really understand what was happening at a fundamental level.
With the layout finished, and the content loaded, we began adding and editing each student's photo assets. We went profile by profile ensuring we had optimized all the images correctly, and more importantly chose the right sequence of images to represent the personalities of our students.
We love what we've created for our students as our Stories section is a fun and engaging way to meet our inaugural Starter School class. We hope you read them all, share them and find value on what they've built.
By Neal Sales-Griffin
on April 18, 2014
The best way to start a company is to convert a problem you have into an opportunity. Think about something that pisses you off, and consider what you can do to change it into something that makes you happy.
This is how most great ideas are born. The sustainable ones stem from problems shared by many others. And if you build a solution for it, there might be people willing to pay you to share it with them.
Discover what that intolerable problem is for you, and it will give you the conviction needed to move forward:
We needed something to help us communicate ideas, organize the work to be done, and present work to stakeholders. Simple as that.
We tried a few tools, but they were complicated and too hard to use. So we slowly slipped back to using our old standby — email. Our problems continued.
Frustrated, we decided to build our own simple project management app. A few months later we had something ready. We started using this tool with our existing clients.
Immediately projects ran better! We regained the sense of order and calmness we’d been craving. And clients noticed — they really appreciated the improved communication and organization.
Jason Fried, Founder & CEO of Basecamp.
If it’s hard for you to work on something for yourself, it’s also effective to solve a problem for someone you have empathy for. But, if you aren’t experiencing the pain yourself, it’s harder to connect to the issue and design a proper solution.
Thankfully, it’s doable with help.
Think of someone you care about. It could be a relative, a friend, or someone who was born with a profound lack of freedom or choice in their lives. These are the types of people that the best of us live to do work for:
One weekend my in-laws were visiting, and my wife wanted to make restaurant reservations. She ended up spending three and a half hours calling restaurant after restaurant. I thought it would be great to build a website that could hook up to back-end restaurant reservation terminals.
Chuck Templeton, Founder of OpenTable
To solve a problem for someone else, you have to talk to them about it, a lot. Get to know it from their perspective and seek their help along the way as you design the solution. You should work with them closely. And you should definitely make them your first customers.
Once you’ve completed your research, it’s time to commit to getting it done. Develop a business model for a company that could make the solution. Learn what you need to create the product. If it does the job, great. If not, adapt your solution until it does.
By Mike McGee
on April 7, 2014
Stelios Constantinides is an alumnus of our inaugural Starter School class. He just launched a new product called Notably. I talked to Stelios to learn more about his journey from Starter School to Notably.
What problem are you solving with Notably?
I have a pretty "dynamic network." My friends move, switch jobs, and fall in (and out of) love often. Besides a handful of close friends that I talk to on a regular basis, there was no easy way for me to keep track of what was going on. Notably does just that. It's news about your friends from Facebook.
How did you come up with the name?
The idea was always to focus on important news about your friends. Not another album of vacation photos, but the fact that someone called their engagement off. That's news! Since it's all about "notable" news, "Notably" seemed appropriate!
How has the reception for Notably been so far?
It's been great. There were already success stories just a week after launch. Users finding that a old friend moved back into town, the girl they had a crush on had "hid" her relationship status, and other things that you can easily miss or just can't see on Facebook.
In September 2013, you were one of our inaugural Starter School students. What made you decide to go to the program?
Like a lot of fellow students, I was tired of being an "idea guy" who didn't know how to take a concept and turn it into a product people use and enjoy. Starter School shows you how turn an elevator pitch into a shippable product.
What did you learn at Starter School?
Confidence! Coding isn't easy but it's not as hard as it seems to a complete beginner. It's not that there aren't good resources available, it's that you're intimidated because you don't know where to start. Jeff, Vince, Arvin, Arjun, and Raghu did an awesome job of showing just enough to get us started so that many aha moments were on our own time. The concepts you learn outside of class are the ones that stick with you and give you the confidence to keep going.
Did you build any other apps before Notably?
Nothing as full-featured (yet) but I've made a couple simple apps for fun: Shit To Do and The Fuck Should I Wear.
Sound like fun apps! What was the reception?
"The Fuck Should I Wear?" was featured on the Tosh.0 blog. It was pretty cool to get 5,000 hits in 2 days!
What's the next milestone for Notably?
Growth. People who try it love it, but it's never easy to get new users. We're looking for a partner that can help with distribution and benefit from our API. Any leads? Let us know.
If you want to give your Facebook news feed a makeover, sign up for Notably today!
By Daniel Lopes
on April 4, 2014
One of our students ( @cbgriffin ) shared a blog post from Scott Adams, Dilbert's cartoonist. It has one of the best pieces of career advice I’ve ever heard:
"Become very good (top 25%) at two or more things."
He even uses himself as an example:
"In my case, I can draw better than most people, but I’m hardly an artist. And I’m not any funnier than the average standup comedian who never makes it big, but I’m funnier than most people. The magic is that few people can draw well and write jokes. It’s the combination of the two that makes what I do so rare."
I think this is great advice for anyone at any stage of their career. Read the entire blog post here http://dilbertblog.typepad.com/thedilbertblog/2007/07/career-advice.html
By Daniel Lopes
on April 3, 2014
I've always been intrigued by leadership and self management in teams. Some people need rules and recipes to make progress while others become less productive with more structure and oversight. The way leadership and hierarchy is defined determines what kind of people you can attract to, and keep on, your team.
I've noticed that a lot of people who've never experienced being part of a team without much management are the ones that advocate the idea that you always need someone to give you a path to follow. But an environment that's more directive is often less collaborative, with people asking for permission more often than assuming the responsibility. It's a major reason why so many people complain about their jobs and bosses.
On the other hand, in a self managed team you don't have pre-defined roles, but it happens naturally anyway. It isn't a person that has all the answers, or just a formal designation of one person in charge of each area, but there's usually someone that steps on the shoulders of the others to improve the result of the work based on his own special skills. For example, somebody with interface design skills improving the first version of a prototype after an engineer makes it work; or a more experienced engineer that improves the performance of an existing feature.
When the benefits are tangible and everybody is at the same level of hierarchy discussions and decisions can produce much better results than just one person giving instructions. Another good side effect for self-managed teams is that the person who stands for an idea will naturally assume responsibility for that and care about the implementation.
In self-managed teams the focus is usually more on the product and less on selfish goals like showing off one's skills to get recognition or to find out who's best. A self managed team is a much better environment for innovation and creative solutions, but it also requires a lot of maturity and it's extremely hard to achieve. It's a structure we strive to keep in our software projects.