Mentoring in Gaza's first hackathon

Last month, I spent eight days in the Gaza strip in Palestine. There, I mentored Gazan entrepreneurs, taught workshops, and got to judge in Gaza’s first ever hackathon. I was invited by Gaza Sky Geeks, a startup incubator that is part of a humanitarian organization called Mercy Corps. The trip was self-funded.

What follows is a collection of notes and observations from my trip.

Setup

I’ve always wanted to go to Gaza. Like many places in the world, I knew what it looked like on cable television news. I wanted to see what it was like with my own eyes. I wanted to see what the Gazan thinking, spirit, and culture was like. So when a friend told me about an opportunity to mentor entrepreneurs in Gaza, I jumped. Not only could I go to Gaza but I could also bring along two passions of mine—technology and education—to be part of it.

I applied and was interviewed over Skype. I was asked about general problem solving skills and my comfort level with following ground rules (more on that later). Once I passed the interview, I bought a plane ticket and applied to the Israeli military for a permit to cross into Gaza via the Erez crossing.

I flew from San Francisco to Tel-Aviv. From there, I went to the southern Israeli city of Ashkelon where I was picked up by a staff member and driven down to Erez to make the crossing into Gaza.

Notes

  1. There is a one-mile no-mans-land walkway between Israel and Gaza. This is the Erez crossing. There are drivable roads but they are reserved for the UN and Red Cross.

  2. There were seven mentors in total—three from the US and four from Europe. Some came from big companies, some worked at small startups. Some were engineers, some were data scientists. Everyone had different motivations for coming. Some were of Palestinian descent and wanted to see the other half of home. Others were curious about Gaza like me.

  3. There are ground rules every mentor had to agree to before going. We could not go anywhere unaccompanied. We had to stay inside the incubator or our hotel. On the one tour we did go on, we stayed along a UN sanctioned path. These precautions were taken out of safety.

  4. Due to geopolitical differences, shortage of funds, and lasting effects from previous wars, there are only six hours of electricity in Gaza per day. There’s no fixed schedule either; some days it’s available from midnight to 6 in the morning, other days it’s available noon to 6 in the evening. Many organizations, including Gaza Sky Geeks and the UN, have backup generators that run off petrol.

    You get used to it. At the incubator, the lights would go out every so often for a minute before the generators turned on. No one flinched; you just carry on in the dark. For those without access to generators, UPSes and battery packs are a must.

  5. Hamas is the ruling political party in Gaza and they enforce parts of Sharia law. One example of this came out in the hackathon. On the first day of the 48 hour hackathon, all female participants had to leave by 6:30 PM. This is because, under Sharia law, women cannot hang out with men they are not related or married to late into the evening.

  6. The gulf (UAE, Saudi, Qatar, etc) is the closest regional tech hub accessible to Gaza. I met many Gazan programmers who either freelanced or worked for companies based out of the gulf. I believe the reasons for this are three fold: same language, lower costs, and an economic way for them to support the Palestinian cause.

  7. I’ve been asked a lot about the programming competency of Gazan developers. I saw a lot of competency with PHP (CodeIgniter and Laravel on the framework side), C# .NET, and certain gaming frameworks such as Unity. I did not see a lot of expertise with some of the more “bleeding edge” technologies such as React, Angular, Node, Go, or Rust. I do live in Silicon Valley startup land so my view might be skewed.

    As far as work ethic, I came away really impressed. I saw a lot of drive and grit. I hosted two workshops at the incubator - an introduction to prototyping and an introduction to python. In both cases, turnout was spectacular, questions were well-informed and meaningful, and attendees always wanted to stay longer and keep working. This was one of my most happiest moments from the trip.

  8. I made it a point to learn some Arabic everyday. Here are my favorite words and phrases:

    • haz muafa = good luck
    • nana = mint
    • ya hamkoum allah = bless you (after a sneeze)
    • enduk ai sou-elle = any questions?

    Fun fact - there are several crossover words between Hindi and Arabic. I tried to drop them in conversation as much as I could. Here’s a list.

  9. For the longest time, I was jealous of medical students and doctors. They had a very clear way to apply their skills, do social good, and travel abroad. Engineers have similar outlets but they mostly revolve around civil engineering projects such as building wells or setting up computer labs. As a software engineer, it just hasn’t been obvious what I could personally do to hit that triple bottom line.

    I think that’s now changing for two reasons:

    • Software programming has become a tool for economic development. [Why this happened just recently is something I’ll explore in a future post]. In a place such as Gaza that is bounded by hard borders, software breaks through. The challenge then becomes to (1) educate/train talent to become software programmers that are aware of the latest technologies and software development methodologies and (2) connect those programmers with employment opportunities. Internationally trained engineers can make a difference with (1).
    • Technology entrepreneurship has gone mainstream (whether this is a good thing I’ll save for another day). There’s a common methodology everyone has adopted or is atleast aware of: Lean. Even people outside the startup scene know what an MVP is. The word “hackathon” has entered the lexicon. These events create a venue for socially engaged entrepreneurial engineers (SEEE what I did there?) to bring their experience building businesses in their countries to places such as Gaza. Though businesses can’t be cloned wholesale to underdeveloped markets, there is value to bringing in people who might have attempted to build or have even used a developed competitor.
  10. I met a Gaza Sky Geeks staff member who told me about his story. His parents had to flee their ancestral home from Jaffa in 1948. He lost his childhood home in the war of 2014. He also lost friends and neighbors in the war.

    Despite all of this, you would never be able to guess of any of his past after talking to him. In fact, the only reason I knew to talk to him is because I overhead someone else mention his past. He’s the most upbeat, jovial guy at the space who was on his way to the U.K. in a couple days with an eye on a seed round for a startup he’s working on. One might expect atleast some chip on the shoulder, some bitterness, maybe even a little anger. I haven’t seen that from him or any of other Gazans I’ve met and that—more than anything else—has been the biggest surprise for me on this trip.

Parting thoughts

I had a wonderful time in Gaza in no small part to the hospitality Gazans gave me when I was there. I want to give a huge shout out to the staff at Gaza Sky Geeks. Thank you for hosting this program and inviting us from abroad. I do want to return again some day.

If you’re interested in participating in such a program or have questions about it, reach out to me and I’ll pass you on to the right person.

edit 06/24 - I talked more about my experience in the comments section in this HackerNews thread.

More pictures

Written on June 7, 2016

Scanning with the Brother HL-2280DW on Linux

When scanning on Linux using the Brother HL-2280DW, I've relied on reformedmusing's invaluable guide many times. In the guide, you must know the IP of the Brother machine in order to setup the scanner. If you're in a shared office setting like me where you don't have access to the router, this can be difficult. Here's a quick tip:

  1. Find the subnet you're on by finding your internal IP:

    ip route get 8.8.8.8 | awk '{print $NF; exit}'

    Say you get 192.168.1.8. Probably a safe assumption the printer is on 192.168.1.*

  2. Use nmap to find all the hosts on your subnet. nmap will also spit out nodenames. Per Brother's documentation:

The node name appears in the current BRAdmin Light window. The default node name of the print server in the printer is “BRNxxxxxxxxxxxx” or “BRWxxxxxxxxxxxx”. (“xxxxxxxxxxxx” is based on your printer’s MAC Address / Ethernet Address.)

      So run:

      nmap -sP 192.168.1.0-255 | grep "BR\(W\|N\)" | awk '{print $NF; exit}' | tr -d '()'

      That will return the IP that you can feed into the brsaneconfig4 command.

Happy scanning.

Written on September 11, 2015

Cuba

In July of 2014, my girlfriend and I went to Cuba for two weeks. I knew US-Cuba relations would normalize soon and from that moment onward, Cuba would become a very different place. I wanted to see Cuba before it changed.

This post is a collection of my observations from that trip.

Prep

Because it is illegal to visit Cuba as a US citizen, there are no direct flights between the two countries. So we wired money to a friend in Mexico who bought us tickets from Mexico City to Havana. We then bought tickets to Mexico City.

Because we couldn't access the US banking network in Cuba, we each packed a grand in cash which we exchanged to pesos in Mexico and then to CUCs in Havana.

Observations

  1. There is no such thing as an advertisement in Cuba. No billboards plastered with phone numbers to call. No annoying slogans on the radio that are impossible to get out of your head. No commercial "breaks" on television.

    And you know what? It's a beautiful, beautiful thing.

    Coming from a country and city where every square inch is monetized by ads, I no longer had to be distracted by companies trying to sell me their product. I could focus all of my senses to things that actually mattered like nature and people and music. Arriving back in Mexico City after leaving Havana was a little bit like turning off AdBlock: you freak out at first and then wonder how everyone else has been living this way.

  2. While the Cuban economy isn't capitalistic, the people are. We stayed with locals in their homes through the Casa Particular system (state sanctioned AirBnB). And everytime we needed something, we got the "I know a guy" response. Need a taxi driver to take you around town? The host knows a guy. Need a private tour of the city on bike? Don't bother with the tour companies - the host knows a guy with some spare bikes. I'm sure there was a revenue share behind the scenes. One of our hosts even tried to upsell on the included meals.

    Every single human has an innate desire to ascend above their peers. That cannot be surpressed even under the most promising of ideologies (communism) or powerful of personalities (Fidel / Che / Raul). I remember walking in Havana and meeting a guy in his mid 20s who quit medical school to sell boat tours because the money was better. Think about that: quitting a profession that makes Cuban lives better so that you can show people you'll never see again your homeland by boat. That's a very sad reality for a country full of so many talented individuals. Examples such as these show how misguided economic principles can destroy people by preventing them from reaching their highest potential in life.

  3. No one is poor because everyone is poor. You won't see homeless people. You won't see beggars. Everyone's needs (not desires) are met either through their profession or through the government. As a Cuban citizen, you are at economic and social parity with your neighbor. Because there are no means to differentiate yourself along these lines, there's no notion of class.

  4. Compared to the US, there is less segregation in Cuba. I saw light skinned and dark skinned Cubans mix, work, and interact much more casually than I see it here in the US. I believe historical and economic factors (including (3) above) have resulted in this positive outcome.

  5. In the US, people use their smartphone to stave off boredom, loneliness, and the perception of loneliness. Walk into a bar and arrive before your friends? Open up the phone to check something---anything. Waiting for the bus outside? Consume more content (any content) before the bus arrives. Indeed it's actually awkward to sit in a public space without being occupied.

    In Cuba, most people cannot afford smartphones so this dynamic doesn't exist. Cubans sit on a bench and people watch. Or they talk with strangers while they wait. Or they ponder about the day. There is value to being fully present in the moment. Banning smartphones is not the solution but changing our behavior and its perception when we're alone might be.

  6. Cuba is a beautiful place. The beaches, countryside, and people are gorgeous. Cuba should change and it will soon enough. But I hope these three things stay the same.

Closing

My prediction about Cuba came true. In December of 2014, President Obama started the process that will lead to the normalization of relations between the US and Cuba. This makes me excited for the future of Cuba and its people. I hope to visit it one day and see how it has changed.

Here's a picture of me playing a pickup game of soccer with some kids in Old Havana:

image

Written on May 26, 2015

Ground rules

I've become comfortable enough with writing to lay down some self-imposed rules:

  1. I write for myself, not you. I'm not doing this to get clicks. I'm not doing this to build my "online brand". I'm doing this to bring clarity to my own thoughts. To that end, I have and intend to keep analytics off this blog. I will never know how many people read this.

  2. I'm not going to repost content from elsewhere. I'm going to assume you've already solved your online content discovery problem.

  3. Quality over quantity. I know there's a movement out there to "commit often"---it's not for me. I'm only going to write when I have something to say.

  4. The majority of my posts will be about engineering (hardware & software), entrepreneurship, and teaching. There will be infrequent posts about music, travel, media, and psychology.

  5. I will not write about politics, religion, or any other topic deemed "controversial". This is unfortunate and sad.

Written on March 31, 2015

Teaching code

Since September 2013, I've been volunteering twice a week for an hour and a half at a high school in downtown Brooklyn where I, along with three other developers, teach the basics of HTML, CSS, and JavaScript to about fifteen students. This post is a collection of some of the observations I've made during that time.

Background

When I quit my job two years ago to pursue a startup, I had a new, more flexible work schedule. I wanted to use this as an opportunity to do things I had neglected in the past such as exercising regularly, cooking regularly, and keeping in better contact with friends. I also wanted to give back to my community on a more frequent basis. For reasons that deserve another post, I had realized that my mental happiness was connected to, among other things, helping those around me. It was difficult to feel inner satisfaction without volunteering some amount of my time to bettering the social conditions of others.

I had a casual interest in teaching and I absolutely loved coding so I thought I'd try to marry the two and teach people how to code. After some googling, I came across a non-profit that puts developers in high school classrooms across NYC. And so I signed up.

Knowing versus teaching

I didn't bother preparing for the first couple of classes. Writing "hello world" in HTML, making the background of a page red, changing font sizes? Please. I could do that in my sleep. And so, with supreme confidence, I walked into class and starting teaching.

And failed pretty quickly.

Only later did I realize that there's a big difference between practicing knowledge and being able to reproduce it. The latter requires one to present said knowledge in a form of narrative so that someone with little command of the context can understand. Most of my students had never programmed in the past so they couldn't rely upon the same contextual clue base I could. This meant I needed to prepare a narrative in advance of class (otherwise known as lesson prep). It also meant coming up with real world analogies. A vending machine is like a function: it takes inputs (in the form of money and code selection) and outputs a single item (the drink or snack).

Teaching also forced me to better understand the "why" behind certain things. I couldn't teach a fact, wave a magic wand, and have everyone commit it to memory. It had to make sense and the only way I could do that was by explaining the rationale behind the fact. Variable names cannot have spaces in them because the computer cannot tell if you are trying to make one variable or many.

Vocabulary

I teach at an international school. My students came to the United States in the past four years. For most, English is their second language. Being able to explain a highly technical domain (programming) using high school level vocabulary is hard. I'll constantly catch myself using a word like "functional" or "user" and self correct. If I don't self correct, the three other co-teachers usually will.

Over time however, I will introduce these words to my students and ask them to memorize it. I firmly believe one must talk like a programmer before one can be one.

Precision

Last year, my students and I would recite the following mantra: humans are smart, computers are dumb. While a generalization, I used it to communicate an important point: we must be precise with computers and tell them exactly what we want. Computers cannot make the same assumptions we humans can.

Syntax errors, misnamed function calls, and plain typos can kill the morale of a beginner programmer. Connecting these errors to the inability (or "stupidity") of the computer blunts this frustration by shifting the blame off the programmer. It also provides a brief source of levity. Repeat the mantra with a class of high school students and you'll know what I mean.

Authority

Perhaps the most difficult challenge I had when I started out teaching was with keeping control of the classroom. The biggest mistake a teacher can make when interacting with students is by treating them like adults. Students look to the teacher as a source of authority. The moment they don't see that is the moment they lose focus and drive.

This means being "mean" sometimes. This means cutting students off, passive-aggressively waiting for them to be quiet, and metting out a stern reprimand if no one does their homework. Tactics deemed unimaginable when dealing with adults are sometimes required in a high school classroom. And while students may disagree at first, deep down I think they appreciate a classroom that is in control and has high expectations.

Fun

High school students and teachers have different priorities. High school students want to have fun and teachers want to communicate knowledge. I've found the best teachers occupy a middle ground. Much like how Jon Stewart uses comedy as a vehicle to deliver facts and opinions about the news, a good teacher will leverage humor to communicate facts on a certain subject.

The first lesson of the school year involves role play. One teacher is designated as a robot and is stationed at one end of the classroom. Their task is to pick up a piece of paper on the other end of the classroom and throw it in the garbage. The students are responsible for guiding the robot to perform this task. Instructions such as "go to the chair" will elicit a shrug from the robot (the computer only understands a predefined set of simple commands). A request to turn 30 degrees to the right and go straight will send the robot tumbling into whatever and whoever is in the way until it is told to stop (computers are dumb and need to be told exactly what to do at every point).

Students (and teachers) break out laughing everytime we do this exercise. And that will help them remember the underlying point---that machines need to be spoken to precisely---even better.

Growth

Some of my past students have gone on to do programming internships at organizations like Ghostery and Teach for America. Others have gone on to pursue computer science in college. Remembering where they were on day one and how far they have triumphed since then leaves me speechless.

When I was a student, our teachers asked us to keep in touch with them. I now understand why. They want to see what imprint, if any, they left on their students as they went on to pursue their careers. I hope I leave something positive behind---programming related or not---with my students. I'm genuinely curious to see where they end up.

Parting thoughts

Coding is rewarding and teaching is rewarding. Being able to do both at the same time is pretty much the dream. If you're a developer in NYC and want to get involved, hit me up. I'm happy to talk more.

Here's a picture of the crew from a hackathon last year:

image

Written on March 7, 2015

Consulting

I get asked a lot about what software consulting (aka freelancing) is like. Full-time salaried software developers tend to be the most curious. This post is a collection of observations I've made from my brief time as a consultant.

One important caveat worth mentioning is that I never pursued consulting as a means to recreate a full-time income. This is something I do on the side and the content below reflects that.

Background

After my startup failed, I decided not to pursue another one right after. I wanted time to internalize the mistakes I made on the first go around. After more 14 hour days than I'd like to remember, I also wanted a more relaxed pace of life. Tired of seeing my bank account take a beating for nearly a year straight, income was welcome too. Keeping my brain active and in exercise was another priority. For these reasons and with no prior experience consulting, I dove in.

Physical presence

When I quit my job to pursue my startup, I moved into a co-working space in Brooklyn and sat across a real estate broker. One day, he told me he wanted to have a website that his clients could log into and view available properties to rent over a map based layout. He talked to some development shops and got quoted for $X. $X turned out to be significantly greater than his budget and twice as much as what I would do it for. I took him out for coffee and told him just as much.

And I got my first deal.

In the age of phone calls, email, and remote working, I can't stress enough how much my clients value a personal presence. Being in the same office and sitting across the same desk considerably increased my first client's comfortability in working with me. Meetings with pencil and paper and white boards are very powerful. If something went wrong for any of my clients, they knew exactly where they could find me. This made a risky calculation---paying thousands of dollars to someone they had never worked with for something they couldn't directly control---much less riskier.

Human problems

Nearly all of my clients are non-technical. I don't know if this happened by coincidence but I love it because I get to put my business analyst hat on and solve human problems rather than machine problems. Not to knock those who solve the latter. I've done it and still do.

First, I sit down with them and identify their values and priorities. Then come requirements. More often than not, they don't know what they want which is OK. We discuss, debate, and draw to figure that out. Distilling "what I want" statements into hard technical requirements comes next and I've noticed, oddly enough, clients enjoy this part of the phase the most. I'm not sure why but I think it has to do with bringing in harsh clarity to something that was vague a couple minutes ago. I get a lot of "that's exactly what I mean" moments. There are therapeutic elements at play here.

The entire process of taking something that was not-known to desired-but-vague to technically-defined to finally-implemented is the closest thing there is to the circle of life in this field.

Immediate rewards

Having previously worked at a big company and before that, at a small one, I really missed days at the latter. At the former, I never got to see my users interact with my product. This made it difficult to feel rewarded---on an inner level---for my work.

Consulting is the opposite. I see my work used, commented on---and sometimes criticized---right in front of me. The feedback loop is quick and it is tight. Seeing a client improve their productivity or generate more revenue because of code that I wrote is one of the most rewarding feelings I've ever had.

Independence

Being a consultant means I am my own boss. I get to decide my schedule. If working on the weekend means more time to work on side projects and research startup ideas during the week, I can. If I absolutely have to push back a deadline, I can. If I need to visit my family on the west coast and work remotely for long stretches, I can.

The downside to the independence is the lack of structure and routine. Workload can swing wildly from one week to another. Goals that require a recurring commitment such as exercise or cooking sometimes take a backseat.

Value of time

Having been a salaried employee in my past jobs, I was guaranteed to make a fixed sum per time period whether I completed y tasks per day or y+1 tasks per day. Furthermore, the completion of a task resulted in the "award" of another one. This was OK because the more tasks I accomplished, the more productive I was. The more productive I was, the more impact I had on the company, more recognition was received, etc.

Consulting (especially under fixed contract) changes this around. The one and only goal I have is to minimize the time it takes for me to deliver a working product to specification. The quicker I deliver, the more money I get rewarded. Time is literally money. This has pushed me to optimize my tool chain and processes so that my analysis->execute->test->deploy cycles are as tight as possible. I realize that there are such things as bonuses under the salaried practice. I would argue getting frequent "micro-bonuses" as opposed to one big yearly bonus still has an impact on how differently time is valued under each practice.

I want to be clear that I don't think one practice is better than another. But it is interesting to experience both.

Friendships

There's an interesting nature to colleague based relationships. In some ways, you know your work colleagues better than you know your normal friends. You spend many hours a day with them. You get to see how they react under pressure and adversity. You get to see their character up close and transparently. There's also a sense of spirit and shared purpose because you're on the same team. A special bond is built.

I've made life long friends with some of my clients. That, more than anything else on this list, has made consulting special to me.

edit 06/24 - additional commentary in HackerNews thread

Written on February 27, 2015

Startup mistakes

Two years ago to this day I quit my job.

I quit for a lot of reasons but mostly to strike it out on my own and build a business. That part didn't work out as planned; I ended up closing shop about a year later. This post is about some of the mistakes I made along the way.

Background

I set out to build a peer-to-peer marketplace called Qhojo (pronounced ko-jo; I know, bad sign already). On Qhojo, videographers, photographers and creators could lend and borrow equipment from and to each other. Think AirBnB for camera and video gear. It took three months to build the first iteration and another three to build the second iteration. By the time we shut it down, it had about 250 signed up users and had facilitated a handful of transactions.

Mistakes

  1. No customer development: Customer surveying? Nah. Talking to the creative community? Nah. All that Steve Blank nonsense? Psh. That was for the b-school kids who didn't know how to program. We didn't follow any of that "boring" advice. Why? Because I'm an engineer and I wanted to build build build. And that mentality is exactly how you end up with (1) solutions to problems that don't exist or (2) poor solutions to actual problems (which Qhojo was). We should have stepped away from the keyboard and talked to people.

  2. Bad name: I can't tell you how many times people asked us "is that with a 'c' or 'k'"? It was a name that was incredibly difficult to spell and more critically, impossible to reproduce after hearing. This made it tough for the casual meetup attendee or passer-by to look us up at home. For those curious, the name was inspired by the hindi word "Khojo" which means "find it". While we lost points on spelling, we scored pretty well on meaning.

  3. High risk-to-reward ratio: The average item price on Qhojo was around $2000. Typically, rental rates for A/V equipment are about 1% of their total price so ~$20 a day in our case. Suppose an average rental span of 3 days and a commission of 10%.

    The equipment owner has to post an item, accept a request for someone to borrow that item, establish meetup logistics for the exchange, establish meetup logistics again for the return, meet the person for the return, and then verify that the equipment still works.

    Is it worth the owner's time to perform all these tasks for ($20*3)-($20*3*.1) = $54? More importantly, is that $54 a sufficient reward for the risk of damage, internal or otherwise, of their possession?

  4. Over engineered: We focused on making the cleanest, meanest, and leanest machine out there. We automated where we could and made a moderate effort at producing maintainable code through periodic refactoring.

    This was a waste of time.

    We should have built the absolute minimum and then manually maintained transactions through the backend if need be. To hell with formality. We were in the business of proving a hypothesis yet we acted as if it had already been proven.

    There's a broader point to be made here. Briefly, this has to do with the formal training engineers go through during schooling and professional work. In the former, engineers are taught to build efficient and elegant solutions. In the latter, code reviews check for each. Although I eventually became comfortable with a do-it-quick-and-dirty approach, I found it very difficult initially. Interestingly, I don't see non-formally taught developers make this mistake in their startups.

  5. Lack of lender protection: We couldn't figure out a way to subsidize the risk on behalf of the lender. We reached out to insurance brokers and insurance companies; no dice. We also talked about charging a monthly fee to members. Ultimately, we ended up putting temporary holds on the borrower's credit card. These holds represented the entire amount of the item. This did not work because many couldn't sustain that kind of load, albeit temporary, on their credit card.

  6. No team: I went into building Qhojo alone. One day, I posted about it on Facebook. An old friend saw it and we subsequently reconnected over beers. I asked him if he was interested in joining and he was. But he said he couldn't commit fulltime. No problem, I thought. Any help is better than none and all the more if it's from someone I know and trust.

    Only towards the later stages of Qhojo did I realize this arrangement wasn't going to work out. Building a business (startup or otherwise) requires a massive amount of work and 1.5 people is not enough for it. Furthermore, when the going gets tough (and it will), you need someone there in the trenches with you. I can't understate how important that is for one's mental will. Knowing you're not in it alone is a huge source of comfort on the bad days and awesome energy on the good days.

  7. Misleading encouragement: If I got a nickel everytime someone told me how great of an idea Qhojo was, I would have wised up and made my business just talking about Qhojo. Almost every creative we met burst with support when we pitched them the idea. And that was great except when we realized that while the idea is great for them, it needs to be great to us, the business, too. The analogy I'd draw here is of the person who decides to make a business out of giving money away for free. That person is going to make a lot of friends but their business isn't going to last very long. It must be mutually beneficial.

    Looking back, I wish we listened harder to the critical viewpoints. Instead, we let the praise drown them out.

Parting thoughts

There's a couple businesses trying to do what Qhojo couldn't. Kitsplit, Cameralends, and ShareGrid come to mind. I really hope they succeed, but deep down, I think (3) above will prevent any from doing so.

While Qhojo didn't work out, I'd like to think I got a very cheap MBA along the way. I've drawn lessons from the mistakes I've made above. I am a smarter person and entrepreneur for it.

edit 06/24 - additional commentary in HackerNews thread

Written on February 19, 2015