Niroka

The Hustler's Manifesto

Wed, 02 Nov 2011 16:54:00 -0400

Four years ago, I began my journey of learning all about the Software Craftsmanship/Agile movements. Let me be clear about exactly what I mean when I refer to the craftsmanship/agile movement. I’m referring to the concepts of Test Driven Development, Iteration, Pivotal Tracker, Retrospectives, etc. which, at least in the Ruby community, are basically tenets. So it came as somewhat of a shock to my system to start my own company and find how royally all these tenets have failed me. Let me show you a conversation I had with my cofounder as an example:

Roshan: “Hey, so this week I think I’m going to implement the landing page for new OfficeHours instructors”

Jared: “Yeah, that sounds good. Let’s do that”

2 Days Later:

Jared: “Hey, let’s scrap OfficeHours and do this other thing. We’ll need to build a new Rails app from scratch.”

Roshan: “…ok. Let’s do it.”

The Software Craftsmanship and Agile movements have in large been driven by the consulting community, and it makes sense for them because they build in a much more controlled environment. Clients change their minds, but it’s nothing like the magnitude of code change that a startup pivot involves. Also, at the end of the day the consultant’s deliverable is code. The following doesn’t work at a startup:

Finish Pivotal Tracker Queue
???
Profit

(see here if you have no idea what I’m talking about)

Process is the nemesis of a startup and the correct dosage of chaos is its nurturing mother. With all of that in mind, I’d like to propose some principles for startup hackers who find themselves too constrained by Agile practices:

Rule #1: Don’t Test (All) Your Code

Certainly don’t ever test drive it (it’s ok, no one does anything more than pay TDD lip service anyway).

Here’s the thing: tests require maintenance just as much as production code. Here’s an example: We recently restructured our data model at Niroka to allow multiple “sessions” for a course. This involved adding an abstraction between “courses” and “enrollments”, where if I had written unit tests I would have found myself essentially rewriting all of them to respect the new abstraction layer. It probably would have taken longer than implementing the damn feature.

Here’s what you do instead: write integration tests for the critical parts of your application. For Rails, this means a high-level cucumber test for things like, in our case, “signing up”, “creating a class”, and “enrolling in a class”. It’s still maintenance, but it’s a tradeoff we like because it’s tedious to manually test those and we really, really care if they break.

The point is, code evolves. It’s never “done”, so don’t write tests that presume it will be static and your interfaces won’t change.

Rule #2: Stop Being Such a Nerd

“Do you prefer git rebase or git merge?”

“Should my spec names be declarative?”

“Is this method supposed to be private or protected?”

Ask yourself: Do the answers to these questions provide any value to myself or my customers, or am I just dorking out hardcore? I don’t mean to be derisive, this is the rule I break most often and so I am guilty of dorking out hardcore.

I don’t know why this over-analyzation happens, There’s something about the programmer’s brain that wants to make everything more efficient, and then that brain gets tunnel vision and finds more and more minute ways to be efficient and loses the forest for the trees. We also work in an industry that is obsessed with methodologies and best practices, so it’s easy to get caught up in trivialities. Just build things, motherfucka.

Rule #3: Take Ownership of Your Features

Don’t worship the codebase. I had the tendency to treat code like a sacred scroll that should never be tarnished, and it gets in the way of me creating value to our users. A related effect is that coders tend to push off non-programming work in favor of the next feature to implement. We’re good at coding, so we try to find reasons to always have something to code. I think a lot of developers do this, but remember:

Finish Pivotal Tracker Queue
???
Profit

doesn’t work.

Here’s how to get around this gotta-code-the-next-feature mentality: take ownership of the features you implement. Instead of spending time developing Feature B, figure out a way to track and quantify the success metrics for Feature A. Use A/B tests, funnels, or solicit user feedback and actually figure out what value Feature A brought to your app. You may be surprised how much work it is to answer a question as simple as “Did this feature bring any value?” The upside is: you own your feature, it’s like a little feature-baby that is all your own and all you want is to see your feature’s metrics go up and to the right. Through this process, you’ll become a more valuable developer by understanding your business and also gain an appreciation for the idea that “software is just a tool”.

Noteworthy: Facebook has a really interesting system for allowing developers to take ownership of their features even with as many devs as they have. From my understanding, it involves letting dev teams take ownership and implement whatever they want as long as they roll it out slowly and have the metrics to validate the feature.

Two notes to end on:

A healthy dosage of chaos can go far for your team. It may not optimize your productivity, but we’re not machines — we need some disruption in our environment to stay creative and excited.

Finally, software is a means to an end. Try not to lose sight of that end, or you’ll end up just treading water and never moving forward.

EDIT: HackerNews comments here

— roshan

People Paid Us $10,000 Last Week To Learn How To Program. Lessons Learned...

Mon, 31 Oct 2011 16:48:00 -0400

We had a few key experiences with Niroka so far. In order to jumpstart our growth, we approached AppSumo and worked out a deal to have them promote our first class. Within 24 hours, we signed up 202 people and sold $10,000 of digital classroom time. So was it as easy as we made it sound? You’re reading a blog post about how we miraculously just created this web site, and instantly made thousands of dollars! We’d be fooling you if we made it seem so easy.

Mistake #1: changing URLs just before the class starts.

We believe the release of Flash Player 11 coincided with the instructors’ particular operating system—an unreleased developer version—causing some unforeseen problems with the course software. As a last-minute resort, we purchased a 1-seat $100/month Adobe Connect account and realized 20 minutes before the presentation would start that it had a 100 user limit. So we paid the $350 fee to get LiveStream to work, and e-mailed everyone the new address. Some people got frustrated about that. The fix to this problem is have somewhere the user can always go, even if there’s a failure somewhere. 307 Redirect them, or grab live updates to display both in the web site and e-mail. Changing URLs should never happen.

Mistake #2: understating the challenges of learning a topic like how to program.

We noticed some people were very vocal about the course being more difficult than they anticipated. At times we weren’t sure whether to interpret the feedback as valid criticism or as someone who is too impatient to commit to learning the material—Objective-C is not a walk in the park for newcomers when you compare it to languages like Ruby or Python that don’t deal with things like memory management.

Mistake #3: treating our online classes like our college classes.

Live videos are nice because you have interactivity: when you watch a YouTube tutorial, you really can’t ask questions if you get stuck on something. In this course, with over 100 people in attendance, we also couldn’t stop to answer every question that came up. That’s a real problem since it defeats the purpose of doing live courses. Why were we putting everyone together in the same class at the same time and expecting it to be any different from a large lecture hall?

We got around these problems by making some important changes:

Talk to your customers when something goes wrong and make it right. We had 10 unhappy e-mails from people requesting refunds, and we turned all of them into happy customers because we paid attention to them and made it right. Only 1 person out of the 10 insisted on the refund after we tried everything here. We could have just shrugged it off, but we would have heard about it on Hacker News or someone would have wrote a blog post criticizing us on some of these mistakes. We also do this stuff because we’re excited by it; when people complain then we also feel their pain because we’ve been in their shoes and feel frustrated when technology doesn’t work or we felt misled.

We will always guarantee small classrooms. Roshan and I didn’t like large lectures in college; we usually didn’t even show up to class because there was no point in sitting with 200 other students when you could sleep in and watch the recording later. We don’t believe you have to sacrifice quality in order to accomodate larger crowds who want to learn something. What this means is that if we sell 200 seats next time, we’ll break the class into 10 sections so that there won’t be more than 20 students per class.

Give users the mental preparation and encouragement they need. A lot of people say “those who can’t do, teach”, but I realize now that teaching requires a different skill set that might make the inverse true: “those who can do, can’t teach.” I wasn’t instructing the class, but I had the urge to put people’s mind at ease before jumping right into the course material, as I had flashbacks of my younger self taking CS 125. I distinctly remember Professor Angrave telling us all at the beginning:

You are about to embark on a magnificent journey. You may see some people, especially in the engineering department, walking around with their heads held high. They may think they’re better than some of you younger guys because they’ve gone through what you’re about to go through. You are all at the very bottom of Mount Everest, and we’re going to climb it together. This course and CS more broadly speaking is not easy, and you will struggle at times. Some people will decide it’s not for them and drop out entirely. Just remember that things won’t make sense the first time you see them, and that’s perfectly normal. Keep practicing and you’ll get there.

I was lucky to hear this and mentally prepare myself. I could see how it could intimidate newcomers, and I hope to pass along the sentiment to them when it comes to topics like programming. When you’ve been programming since you were a kid, you forget how intidimating it is to look at all of these semicolons, and dear god, the endless brackets in Objective-C! What do they all mean!

Send out all class materials. We did this on the first course and sent out the entire collection of Dive Into iOS materials. People loved us because of it, and I think they got a great deal from it ($130 value). We provided recorded videos afterwards in case people showed up late, got lost in the middle, or needed to play back certain parts. On this one, since it was our first course, we offered each person enrolled in that class a coupon for a free class the next time around to give us another shot if they were disappointed with anything.

Don’t give away any free answers in the first 5 minutes. My girlfriend taught Java tutoring in high school and she said this was one of the key rules to tutoring successfully. I noticed something felt weird when we started our first course, and looking back it would have been much more engaging if I were forced to think about the topic first. My computer architecture professor used to say, “We’ll stay in class and do nothing else for the next hour if nobody answers this question, so someone please help us move things along.” I never really understood why that was important and I sometimes found that tactic annoying, but for the sake of teaching, it’s important.

Be human, be encouraging. I remember watching the Stanford CS 101 class and noticed that Mehran was not only incredibly entertaining to watch, but he handed out candy every single time someone raised their hand; regardless of whether they answered correctly or not, they are rewarded for trying to answer. You don’t want to be judgmental or shame anyone for being wrong, you just want to encourage participation by providing rewards. Admittedly, we received some e-mails that the first live course was a little dry and felt robotic at certain points, so we want to make sure that people are engaged and happy whenever possible.

With all of that, hopefully the negative feedback doesn’t overshadow the positive feedback. Our instructor was flexible enough to get up early on Singapore time and work around our schedule, he’s offering Q&A sessions, he sent out all of his course materials, and he executed.

Thanks for being our first instructor and helping shine a light on the world of programming, Sidwyn. We taught people—many who had zero experience programming before—how to get their start programming in Objective-C, and we made it happen. We’ll keep making it better.

—jared