You guys, LoveItOrLeavitt has been super neglected of late.  That’s cuz my tumblr energy goes into our blog over at Hopscotch!  Check it out. 

Cdixon once said that having a blog is kind of like having a pet—you can’t get one started because you like the idea of it, feed it for a while and then just abandon it.  I figure this little pet of mine is gonna have to be a hibernating bear cub.  A sleeper for now.  See ya over at Hopscotch! 

gethopscotch:

Terrific interview with Maria Klawe, the president of Harvey Mudd College, about why more women don’t become computer engineers and why it matters that girls are interested in the sciences. Her main points:

• Careers in these fields pay well and are flexible.  They’re a great way to combine career with family, and it is a shame that more women don’t get to access them.  
• What gets created in technology depends on who’s doing the creation.  Eliminating the feminine perspective alters the realm of products that gets made—not just, say, videogames, but also all the other things that use computing: medical devices, art, educational technology.  
• Media needs to portray careers of engineers and scientists the way they started depicting the lives and loves of doctors and lawyers in the 70s, which resulted in skyrocketing numbers of women finally entering those fields.   
• The US strongly lags other countries in graduates of STEM-related fields; we need to encourage young people to enter these careers or we will lose our competitiveness as a country.

We recommend listening to the whole thing or checking out the transcript of the interview.   

(via gethopscotch)

Hi there.  I took a break from posting (and social media in general—if you check my twitter, it’s been pretty thin lately) for a while due to some major life events both expected and not.  Nothin’ like a little life to put the world of consumer software startups into perspective.  But while I may not have been so chatty in the last four months, we’ve been hard at work at Hopscotch.

What’s Hopscotch, you ask?  Short version: educational software to teach kids to program.

Yeah, yeah, we know programming education has been a hot topic lately.  Learning to code is sexy because of startup sweepstakes stories like Instagram, and roaring demand for software engineers at a time of sustained high unemployment.  A lot of people —especially in the world of tech startups—like the idea of learning to program.

But Sam and I were talking about doing something like this quite a while ago—back when we were figuring out how to overcome marketplace dynamics for Kangaroost.  ”I wish there was a toy to get girls into learning how to program,” we thought.  We were focused on something else though, so after idly chatting about how great the equivalent of female Legos for programming would be, I added it to my list of startups I wished someone would build.      

But this past fall, when Sam, Evan and I were feeling a little lukewarm about applying to YC with NerdNearby, we dredged this idea back up again and all instantly realized we were all much more excited about this than a mobile location-based app.  

Our general take on teaching kids to code is that you only want to learn to code in order to make stuff.  Programming a computer is a means to an end: you don’t just code for the sake of learning coding, you code to make a product that has its own value.  And so to get kids interested in it, you need to give them specific things to make.  

Following the “launch early and often” philosophy, we put out a couple of experimental products:

1) Daisy the Dinosaur - an iPad app with a drag and drop programming language to animate a dinosaur.

2) Hopscotch Kits - CoffeeScript coding tutorials to make specific projects using the Raphael drawing library.

We’ve been surprised by the positive response these products have received, considering their lack of polish and our lack of promotion.  To us, it only underlines the strong demand for a good product that gives people exposure to programming. 

We’ve also learned a lot about kids learning programming.  We’re hard at work on a new product now, and we’re back to the iPad.  We’re really excited about all of this.  And I’m excited to (try!) to be a little more consistent about posting here.  Stay tuned, folks.  

I just finished Eric Ries’s excellent book The Lean Startup.  

“The big question of our time is not Can it be built? but Should it be built?”  To a skeptic and an empiricist, and not withstanding all the Lean Startup-type ideas that have been circling for the past few years, this book felt like a revelation. 

Ries’ core assertion is that a startup isn’t a baby company, but rather a learning organization, a lab where you are constantly running experiments to see whether your guesses about what your audience wants are correct.  The methods outlined here are useful not just to entrepreneurs but to anyone responsible for innovation: within big companies, non-profits or governments.  He explains the best way he has found to methodically turn a new idea into a sustainable business product.   

In one passage, Ries relates the experiences of a Lean Startup workshop participant upon returning to his large company.  Even though this workshop attendee was a junior employee at the firm, in meetings he would ask a few probing Lean Startup-based questions to senior executives to help them realize their projects were based on testable hypotheses.  He could lay out plans to help them scientifically validate their ideas and they consistently responded with ‘Wow, you’re brilliant.  We’ve never thought to apply that level of rigor to our thinking about new products before.’ ”  While this was flattering to the employee, it was also frustrating because he wanted them to embrace the overall framework of thinking about innovation, rather than coming to him for one-hit insights.  

If you have some familiarity with the world of tech startups, no doubt you’ve encountered a lot of Lean Startup-type theory already:  Your first idea is probably wrong.  Release a Minimum Viable Product—if you aren’t embarrassed by your first release, you’re waiting too long.  Iterate and pivot.  Get out of the building and ship, ship, ship!  You may think you don’t actually need to read the book because through osmosis you have absorbed so many of these ideas.  

I thought that too, which is why I waited a couple of months to read it.  The above ideas encompass some of the language of Lean Startup but don’t fully communicate the scientific rigor of the Lean Startup practice, which was inspired by the lean manufacturing movement and has an explicit process.  The idea of software development having inventory that is WIP based on learning cycles.  That build-measure-learn must be planned in the reverse order and pulled from hypotheses about customers.  Testing your riskiest hypotheses first (this can be an uncomfortable one).  The power of small batches.  Cohort-analysis vs. vanity metrics.  I could probably write blog posts about each of these, but I don’t have to, because Eric wrote a whole book about them.

So, I’m a fan.  Now we need to see whether we can apply the principles here to Hopscotch.  

Here’s the landing page for Hopscotch.  We’re on version 0.1.  What Sam and Evan have built over the last couple of nights/weekends of coding is even cooler, but we can’t show it off just yet.  Until we can, leave your email.  Also, we got an interview for Y Combinator!  Woohoo!  

THE EXPERIENCE:

So, it’s been a few action-filled weeks since the Tech Crunch Disrupt Hackathon.  It was my first ever hackathon, and it was pretty great, considering our hack got covered by TechCrunch.  Violating the “one meme per post” rule I’ve stuck to since it was first posited by cdixon, I’m going to go ahead and give a long and meandering account of whole experience.  Skip directly to the bottom for THE TAKEAWAYS.

Initially, my partner Sam and I were deciding whether or not we should participate in the hackathon at all, given that we had just launched Kangaroost three days prior, and it needed a lot of work.  We didn’t even have a good idea for a project to work on, but we thought the exposure would be good.  Sam’s friends Evan and Sean joined our team at the last minute.

Our team spent the first three hours generating and debating different hackathon project ideas.  These ranged from Wikipedia Mad Libs, to a mashup of Instapaper and ShelbyTV for your twitter feed, to some jokey hack about the startup bubble, to a service that would automatically claim your username at new startups—thus insuring you wouldn’t ever miss out on, say, grabbing @PaulGraham as a handle for a nascent service called Twitter.  We had nine different index cards with ideas written on them, which we successively ripped up after nixing each idea.  The index cards are a part of the Pivotal Labs agile process, fully internalized by my three Pivot teammates even into their recreational time…I’ve found this process fascinating and will write another post on that in the future.

Ultimately we settled on a version of a locational services aggregator, a startup idea that Sam had mentioned to me privately weeks earlier.  She said that her friends sometimes complained that they weren’t sure which service to pull up or check into: Foursquare, Instagram, Facebook Places, Color, Gowalla, etc.  Riffing on that idea, we decided to do a mashup of a few different simple APIs for geotagged content.  

At Pivotal, engineers pair program (again, more on this later) and my teammates fell into their familiar rhythms.  Sam and Sean began pulling out data from the APIs, and Evan generously offered to pair with me, which meant I “drove” (typed) while he painstakingly dictated commands.  I can’t tell you how thrilling this was for a non-engineer that spends a lot of time with software startups.  Look, you type in a command and stuff happens!!  Amazing.  We did a little combinatorial hack to come up with a domain name:  Nerd Nearby (rejected options included: “Dork Spy”  “Nerddar” “Geek Voyeur” “Local Nosy”).  Friends drifted in and out throughout the evening.  Pam stopped by our table and whipped up our logo in ten minutes, and then Sonali sat with Evan for a couple hours designing the feed layout.  

By about 4am, we were tired enough to cut the remaining features and head home, promising to be back at 10am for the demos.  

Unsurprisingly, we all slept in and were late.  But lo and behold, after a relatively unremarkable 60 second presentation amid over a hundred others, TechCrunch gave our hack a writeup!

We were giddy.  Sam and Sean raced to increase the site’s capacity as it got slammed.  We were bombarded with tweets and congrats and general nerdnearby love from people.  We went to a late lunch together and plotted improvements to our hack.  In the weeks since the hackathon, we’ve met up on a regular basis after work to make a bunch of improvements and build an iphone app.

THE TAKEAWAYS :  

Amid over a hundred TechCrunch Disrupt Hackthon projects, TechCrunch only gave writeups to ours (Nerd Nearby) and another project that went on to win the hackathon before eventually providing obligatory coverage of the winners.  Why?  My thoughts:

1)  Live on a production site with a URL.  This was probably the most important thing for getting a writeup.  When demo-ing, we could tell the audience to visit our site on their browser, and it worked.  Many of the other hacks were cool, but were deployed from their creators’ local machines, or if public, had the haiku-esque Heroku addresses, like stark-dusk.heroku.com or cold-stream-78.heroku.com —imagine getting the audience to try an address like that. 

2)  Fully populated with usable content.  One of the benefits of building an aggregation service is that you can piggyback on someone else’s content, rather than needing your users to generate your content (oh, Marketplaces).

3) Easily graspable idea.  Pretty basic design and concept here: Share your location and get a stream of geotagged content.  The reporter didn’t have to worry about explaining it incorrectly. 

4)  Did not require login.  This is another basic logistics-y thing that makes a huge difference.  People hate logging into stuff.  Nerd Nearby is great for completely passive consumption, no thinking required. 

5)  Zeitgeist-y.  A mobile app that enables local photosharing…how many more hot buzzwords can you cram in to a description?  Maybe we could fit “Social” in there somehow.  It’s almost as good as this gag deck that went around when the funding for Color was announced. 

Based on this one admittedly overwhelmingly positive experience, I highly recommend participation in hackathons.  But it would have been totally fun and worth it even if we hadn’t been covered in TC.  Great things about it:

-Very social.  We met countless new people all around, and cigarette breaks proved an ideal spot to strike up conversation with random participants.  If you are a non-tech person, you’ll meet a lot of engineers at these events, and you probably won’t be the only non-tech person there. 

-Good way to test group dynamics in a low risk environment.  Thinking of starting a big project with some people?  How well do you work well together?  Do you have fun together?  Can you make project decisions that everyone’s happy about?  Can you get work done?

-Free stuff.  We were feted with countless cheap plastic knicknacks and promo items, tshirts, the Mashery was giving away 1G flashdrive bottleopeners, plus free tickets to the TC Disrupt conference for all participants.

I also admit I would have been pretty shy to attend it if I weren’t going with a crew.  But when I got there, I realized I knew many more attendees than I had expected to.  And even though I didn’t know how to do anything but some basic HTML/CSS, I still could have worked on something completely on my own, without a team.  I went to a hackathon presentation once where a kid had just used the time to teach himself jQuery and presented a messy little project he hacked while learning it the night before.  So if you don’t already know how to code, you can use the nice substantial block of time and studyhall-like environment afforded by these hackathons to teach yourself something new (you’ll be surrounded by potential tutors).  Again, highly recommended. 

UPDATE:  Check out this post by Sam about staying productive and avoiding procrastination at the hackathon and every day. 

Ok, so I know it’s been a while since I last posted—it’s because we’ve been busy baking up the latest incarnation of Kangaroost!  Plenty more on that soon. 

For now, I’m brainstorming ideas for the Techcrunch Disrupt Hackathon tomorrow (registration is closed, but if you wanna come hack, they’re giving away 100 more entries at the door that morning). 

Any ideas, folks?  It needs to be relatively easy and simple—something that can be built in a day and would provide some marginal utility.  What little software tool do you wish existed?