The three rules of awesome mobile hackers

One of the reasons why I’ve been mostly absent from this blog is that, together with a couple of very interesting people, I started a new company and we’ve been busy closing our Series A and getting things off the ground. More on this in another post.

This post is about mobile developers or, most precisely, about talent development in the mobile ecosystem. In the past few weeks I’ve been recruiting, I’ve learned a few things about the current state of the iPhone/Android developer ecosystem that I’d like to get your thoughts on.

My new startup is at the intersection of mobile, local, retail and advertising. We are taking a contrarian approach in this bubbly space born out of deep customer relationships. Because of this customer connection, contrary to many others in the space, we have a pretty good idea of what needs building. It’s one of those “they asked us to build it and are waiting with their checkbooks open” types of situations. This doesn’t say much but it sets up the problem.

For us, user experience matters a lot but distribution matters even more. Distribution is why we are not going to build the 113th mobile-local-retail-advertising app. There are plenty of apps that touch the lives of shoppers. Rather than competing with them, we want to help them create a better user experience and make more money, in that order.

No, we are not an ad network. The above two goals are impossibly at odds with one another when an ad network is involved. Giving the bottom portion of an app’s precious screen real estate may make the app developer some money but certainly doesn’t improve user experience. We are doing something that’s never been done before on the client side that, if we solve some very challenging problems in an elegant manner, can both generate substantial revenues for app developers and lead to a stickier and more engaging user experience.

Technically speaking, we’ll integrate with apps both through existing services they use as well as our own SDK. We need to do some serious jiu-jitsu in order to make app developers’ lives easy. There is low-level device/framework work. There is also fancy GUI work. It’s stuff that’s never been done before on a smartphone. It’s the kind of thing that can improve the user experience of tens of millions of people. It’s the kind of thing I need awesome mobile hackers for, starting with the iPhone and Android platforms.

Here are the three core rules that, for me, define awesome mobile hackers:

  • They have done low-level mobile development. They don’t have to have worked on a mobile OS but they know and have rearranged the innards of mobile frameworks (or their desktop counterparts) such as Cocoa (Touch) on the iPhone and understand what it takes to do fast, efficient and reliable communication with servers. They have a thorough system-level understanding of how the device, the mobile OS, the high-level framework and the app coexist. This allows them, with hardly a thought, to power through the types of problems others post of Stack Overflow.
  • They deeply understand end-to-end mobile app development and lifecycle and have built a number of mobile applications. This allows them to relate to and empathize with the experience of other mobile app developers. That’s why awesome mobile hackers build tech other developers find sexy.
  • They are active in the ecosystem. They have lots of friends doing cool work. They know people on the iOS and Android teams at Apple and Google who will more often than not enjoy going out to lunch with them at a conference. They pay it forward. They contribute to open-source projects and mentor up-and-comers. This builds good karma, which invariably helps them out with life on the bleeding edge.

In the past few weeks I’ve come to believe that the iPhone and Android ecosystems are evolving in a way that fundamentally works against the development of awesome mobile hackers. This very much reminds me of the mid 90s when, as the chief architect of the first Web application server, I watched the explosion of the Web developer community. For a more recent reference, what I’m seeing in mobile from a talent standpoint is worse than the bubble in Ruby-on-Rails development. Here is why:

  • There is too much money to be made in consulting. Apps are churned out on a conveyor belt. The focus is on speed and reuse so why bother learning hard things such as low-level mobile development? Non-visible features pay less because clients don’t appreciate them as much. On top of this, mobile devices are locked down to an extent, which limits the practical value of low-level mobile work. Few try it and why even fewer become great at it.
  • On the flip side, many low-level mobile developers come from mobile OS backgrounds and, unfortunately, don’t like to build apps. Even when they do GUI work they tend to find it “below them.” This makes them blind to the perspective of app developers. Those are the guys that build wonderfully-architected frameworks that nobody wants to use.
  • In this crazy environment of excess demand, developers get very, very busy and spend much less time connecting with their peers, contributing to open-source projects, etc. Skill development becomes almost entirely job-driven as opposed to personal interest-driven. Foundation skill development doesn’t pay and is therefore deemphasized.
  • Conveyor-belt consultants, as opposed to long-term independent contractors or outsourcers, tend to lack appreciation of the ongoing lifecycle of an application post ship. Enough said.
  • The awesome mobile hackers employed by larger shops are used as fire-fighters across many projects. They gain breadth and exposure but lose depth. They also lose the motivation and satisfaction of owning the building and shipping of products. This numbs the soul of a developer and is a topic many top geeks at consulting companies have discussed with me over the years.

Don’t get me wrong. Consulting shops are not the problem. The market has set up a certain incentive structure and people operate within it to the best of their knowledge and abilities.

What I’m noticing, however, is that many don’t understand the opportunity cost of dumbing down the work they do from the standpoint of their market worth, personal happiness and long-term career. With the benefit of experience across many companies, bubbles and crashes, I’d argue that:

  • An awesome mobile hacker can make more money in an early-stage product company than in a consulting company but, more importantly, they’ll do this while having more fun and positioning their career better.
  • Great mobile developers don’t understand how much their career is suffering by them not investing in becoming awesome mobile hackers.

If you don’t trust me, talk to a top recruiter or some of the top geeks at the companies you wish you worked at.

The fine print: if you’re an awesome iPhone or Android mobile hacker who likes to solve hard problems that have never been solved before and doesn’t get nightmares from the thought that tens of millions of people will use your code daily then, hell, yeah, I want you on my team.

[Update] I’d like to highlight a point from the comments below in response to some private questions. I am dead serious about giving $10K to the first person who introduces me to someone I hire and I mean that not just for these positions but for any position I am also using recruiters for. It’s only fair to acknowledge the huge value that the right referral can bring to a company.

Posted in iPhone, Mobile, startups | Tagged , , , | 7 Comments

The rising power of the Google platform

If anyone ever doubted that Google is a platform company, check out the “Google SDK.” I’m putting this in quotes because what you find there is really an aggregation of a bunch of separate projects than a well-thought-out integrated SDK–that wouldn’t fit Google’s chaos by design operating principles.

That said, it’s hard to ignore the breadth and depth of what’s on offer. Or think about how, regardless of any theoretical openness, using many of these APIs in your applications would tie you and your data inseparably to Google.

I predict than within 2-3 years many projects that depend on third party APIs will start including a data and API portability review just as they have security reviews today. This will come as a result of more and more data living behind SaaS apps and online services, making cloud integration as common as enterprise integration is today.

 

Google API and SDK

Posted in Google, Uncategorized | Tagged , , , | 3 Comments

Eric Ries interview about lean startups

Lean startup meme inventor Eric Ries is in town. He will be at the Lean Startup Circle event on Thursday night. If you are lucky-enough to have gotten a ticket for this, either hold it tight or sell it on eBay.

For the rest, there is another chance. The good people at CSN Stores, an awesome and fast-growing e-commerce company in Boston, have organized a Thursday morning event with Eric. Hurry up and get a spot while there are any left.

I have the honor of interviewing Eric for a second time in a few months–we was at the customer development event I put together in the fall with Future M, General Catalyst and Microsoft. What questions shall I ask him? Leave a comment here or @reply @simeons.

Posted in Uncategorized | Tagged , , , , | 1 Comment

Twilio forwarding and CallerID hack

I like Twilio. They’ve made programming voice fun, something it certainly wasn’t when Dialogic boards were the platform of choice. I’m using Twilio for a new service I’m working on. More on this in another post.

When you start playing with Twilio, a few common needs arise. For me, the first two were:

  • Forward a Twilio phone number to another phone number. In testing, I have to switch between lots of different numbers. Twilio uses Web hooks, i.e., maps phone and SMS events to HTTP requests. I found myself tweaking scripts a few times per day.
  • Registering a Twilio phone number for CallerID. Twilio wants to validate that you control the number you want to register for CallerID. Therefore, they give you a call and ask you to enter a random PIN. That’s not easy to do when the verification call to the Twilio number will result in an HTTP request to some app.

It was the problem of registering a CallerID for a Twilio number that led me to a simple hack that solved both problems. My idea was to forward the Twilio number to my cell phone and enter the PIN validation when I got the verification call. To make things a little easier, I made the forwarding endpoint accept the forwarding number as a parameter.

You use it like this:

http://simeonov.com/twilio/forward.php?to=12345678900

The link is live so feel free to point your Twilio numbers to it. Remember to enter the phone number with the country code.

The code is trivial:

<?php
    header("content-type: text/xml");
    echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
    if(!$to = $_REQUEST['to'])
        $to = "18005551212";
?>
<Response>
    <Dial>+<?php echo $to ?></Dial>
    <Say>The call failed or the remote party hung up. Goodbye.</Say>
</Response>

One of the Twilio numbers I set up for CallerID is going to be used for outbound calls only. What was going to happen when someone called it directly? That led to another quick Twilio hack–email me instead–which will greet callers and tell them to email you at a given address.

http://simeonov.com/twilio/email-me-instead.php?name=Twilio+Hacks+Incorporated&email=info,+at,+twilio+hacks+ink,+dot+com

Side note: when doing speech to text, you have to write the text in a way that helps the speech engine pronounce it correctly. Note the commas I added to insert short pauses and the mis-spelling of Inc as ink, which I found made the “k” sound a little stronger.

Go ahead, try this by calling (917) 300-0268.

Another “twivial” code snippet:

<?php
    header("content-type: text/xml");
    echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
    if(!$name = $_REQUEST['name'])
        $name = "";
    if(!$email = $_REQUEST['email'])
        $email = "the feedback address on our site";
?>
<Response>
    <Say voice="woman">Thank you for calling <?php echo $name ?>.</Say>
    <Pause length="1"/>
    <Say voice="woman">Please, email us at <?php echo $email ?>.</Say>
    <Pause length="2"/>
    <Say voice="woman">Goodbye.</Say>
</Response>

I wish Twilio did three things:

  1. Allow for static TwiML to be associated with a phone number. I’d love to just be able to enter some markup in a text box to handle simple cases like the ones above without having to deploy any server-side code.
  2. Automatically allowed us to set up CallerID on Twilio numbers we own. That’s just common sense.
  3. Allowed localhost targets using some type of automatic gateway software (in-page applet or browser plugin or Adobe AIR app). This will make testing so much easier.

Other than that, thanks, guys!

Posted in Web 2.0 | Tagged , , , | 13 Comments

Finally

After more than four years, I finally updated the theme of this blog and added better linking to FastIgnite and FastStartup.

The new theme is Twenty Ten, which sets me up for planned obsolescence in less than three months. Know any great WordPress designers?

Kidding aside, I’ve made extensive tweaks to the theme using only CSS and widgets, because I keep the blog hosted on WordPress.com. I’m at about 300 lines of custom CSS and seven custom widgets. I plan on sharing the code soon so that others can take advantage of the tweaks.

I’d appreciate your thoughts on what you do and don’t like about the blog’s design in the comments.

Posted in Posts | Tagged , | 1 Comment

The Zen of fundraising

When investing in companies through FastIgnite, I usually sell my super-secret value-add as opposed to just cash. See, cash is not that hard to get if you know how to ask for it and there aren’t any obvious reasons for investors to say “no.”

Much of the fundraising advice entrepreneurs get is extremely tactical, e.g., say the following thing on this slide or don’t say “platform”, etc. This may make a first meeting with investors go better but usually leads to disillusionment and a pass later on in the process. It’s a lose-lose proposition. Both sides spend precious time and go nowhere.

I prefer a more fundamental approach, one that attempts to help build a business with fundraising simply an artifact of that broader goal. A founding team must discover its core strength and the reason why they, as opposed to the other dozen smart teams going after similar ideas, are going to win. This requires intellectual honesty and emotional maturity. It’s hard work. It may point out significant holes in a team’s capabilities or issues with the company’s business model. Then the work gets harder. Companies that face these challenges come out stronger and much better prepared to raise money and grow.

Here are a few of my posts I tend to refer founders to over and over. I hope you find them helpful.

Posted in FastIgnite, startups, VC, Venture Capital | Tagged , , , , , , | Leave a comment

FastStartup

Through FastIgnite I work closely with entrepreneurs as a co-founder, investor and mentor. Today, FastIgnite gets a partner - FastStartup. While FastIgnite is primarily about my work, FastStartup will be more community-oriented.

FastStartup will do some events, like the sold out Customer Development: The Second Decade. Let me know if you want invites to future events.

FastStartup is about to take part in something BIG. More on that tomorrow at the event.

Posted in FastIgnite | Tagged , , | Leave a comment