Engineering vs Entrepreneuin’

As a software engineer, your comfort zone is generally in front of your computer working on the solution to a well defined problem. You want to write code. You want to build something. You want to produce. But in the early stages of a startup, sometimes the idea or business isn’t quite ready for an all out assault on code.

As a technically focused founder, this can be a challenging time to determine how exactly you should focus yourself in order to contribute maximally to your business. You could hone your technical skills, preparing the tools, languages, platforms and materials such that when the vision is fully in place you’re able to quickly execute. Or you could spend your time brainstorming, defining product, learning about the market, talking to potential customers, and validating your hypotheses. In short, you can engineer, or your can entrepreneur. But how to split the time? It would seem there are three options:

Only engineer
Only entrepreneu (yes, this is the verb that I’ve been using casually pronouncing in my head as entreprenewwwww to engage in the activities that an entrepreneur might undertake)
Engage in a mix of engineering and entrepreneuin’

Surprisingly, I believe that you can succeed with any of the above routes depending on the makeup of your team, the market you are entering into, and your personal strengths and weaknesses.

On one extreme, you may decide that you should spend all of your time engineering. If you are deeply technically focused, have full trust of your partners, and are comfortable that the company direction is set firm enough such that you won’t be disappointed with any product or business decisions that come down from above, then you can get some great momentum and a great head start on the technology. You can set up data systems and engineering practices, you can prototype initial versions of the ideas being tossed around, and you can get familiar and tinker on the platforms that will be inevitably crucial such as iOS, AWS, or HTML5. All of these activities will pay tremendous benefits and allow you to come out hot when it comes to finally producing product. But know the tradeoff is that you may not be involved in much of the early learning, feedback, and brainstorming that will shape the direction of the company.

On the opposite end of the spectrum, you could spend all of your time entrepreneuin’ until you are confident that the vision for the company and product is clear enough to build with confidence that things won’t change out from under you at a moment’s notice. You’ll spend your time meeting with every person you respect who’s done something smart in your space. You’ll run through your thinking in front of everybody who will listen, you’ll absorb their feedback, and you’ll spend time thinking hard about how all of this external stimulus should shape the direction that you take the company and product. You’ll think about strategy related to team building, fundraising, product design, distribution, user acquisition, and more. But you won’t build – and this may be frustrating. As a software engineer, you’re trained to default your free cycles to your editor, but in this stage you’ll default your free cycles to thought. The tricky part with this approach will be identifying when the right time is to cross the gap from thinking to building, because when you begin to build you’ll want to go all in. In a startup you may never know exactly what you’re running at, but when you have defined clear goals of what you need to prove in order to reach the next stage of your business, this can generally be a good point to get to work on building to reach your goal.

Naturally, between the two extremes lies a compromise of doing a bit of engineering and a bit of entrepreneuin’. This is the approach that enables you to stay technically relevant, ready, and optimize for the first sprint when it comes time to get building, while also participating in the all important shaping of the business from the get-go. It is also the approach that I’m currently taking as I get started on building my next company. The key with this approach is discipline, as you risk losing out on both sides of the equation. You could easily spend an entire day tinkering with iOS performance, while spending absolutely zero time on solving key early business strategy, and you could likewise spend an entire day in meetings getting feedback, without getting any closer to that prototype which you’ll have to show off in a few weeks to recruit that great product person to come join the team. If you’re disciplined, and allot certain time for building, and certain time for thinking and meeting, then you’ll be able to find a healthy balance that lets you productively work towards engineering readiness while also steering the ship and making the tough early calls that will guide the business.

With any approach, you know that eventually you’re going to transition into a technical lead responsible for the company’s engineering team, engineering culture, and technical decision making. Depending on your founding team, the market you are entering, and your personal strengths and weaknesses, you can determine the best path to take to get you to that point.

One Day With Android

The Android vs iPhone battles have raged for a few years now, and it’s likely that they won’t subside anytime soon. While both sides seem to battle back and forth claiming that they have a larger percentage of the mobile market, the general consensus is that at the current moment Apple offers developers a larger opportunity to monetize through the app store and their integrated payments platform (though their lead may be shrinking), but the Android install base seems to be growing at a faster clip. It’s hard to ignore the Android trend.

Though it may be hard to decide which platform to bet on for the long term, it is clear that right now, if you want to conceptualize and develop products that reach the majority of the mobile market, you need to understand both environments well. There are inherent differences in the interactions, design constraints, and underlying behaviors of the OS. Android can’t be this great unknown that you read about occasionally and pretend to understand. For me it was an unknown, so I decided that it was time to pick up an Android device and live within it for awhile.

Yesterday I went to AT&T and purchased an HTC One X+ and added it to my existing plan on a second number. I shared the number with a few people who I interact with frequently and asked them to use it as my primary number for the time being so that I can get the experience of using it naturally as a first resort. Twenty four hours later, I want to share some of my initial impressions around being an Android user for the first time after years of using an iPhone.

Immediately I was humbled by being uncomfortable in a new experience. I took for granted the fact that over the last four years I’ve used an iPhone every day as an intricate part of my daily interaction with the world around me. I knew every setting on that thing, every customization, and had followed the announcements of every new feature the week that they were announced and made available. That level of time commitment and use created a high level of comfort. In a new Android environment, it was very clearly apparent, that 4+ years of innovation, new features, customization options, had rolled on without the slightest bit of attention paid, and as such, jumping in at this point left me with quite a bit of uncertainty about what to do.

That being said, initial discomfort or uncertainty does not mean that my experience has been negative. On the contrary, I’m enjoying many things about the device, and am getting used to things very quickly. The large screen, the informational widgets, the nice Google service integrations, and the Play store have all been major positives. I’ll share some of my initial thoughts in bulleted form, with the disclaimer that I’ll likely discover solutions to some of the negative issues (if they are not in fact real weaknesses of Android) as I get more familiar with the ecosystem – in the meantime this only serves to notify people of some things they’ll notice early on transitioning from iOS to Android.

No visual voicemail – back to dialing your voicemail number and listening to terrible prompts.
Informational widgets (weather, sports, stocks, foursquare, etc) give you zero click access to valuable information that you’d otherwise have to launch an app for in iOS.
Google Now has done a nice job of anticipating what information I’m interested in. For example I learned that The OKC Thunder are playing in town tomorrow against the Warriors and I’d consider buying tickets.
Notification overload – I am the guy who can’t have a single outstanding badged icon on iOS indicating an unread message, must be at inbox-zero at all times, and hates thinking that there’s information out there that he has missed. Well, Android seems to bombard you with notifications in the header that you need to swipe to clear, and for me that’s just another chore that I don’t need. I should probably figure out how to tune these via settings.
The back button is a completely different nav paradigm than exists in iOS. It frees up in-app real estate for the developer, but creates a more clunky hardware interface for the user than iOS’ one home button. I’ll have to weigh in later on whether I appreciate the tradeoff.
Users have the option to choose which service/app they’d like to use to accomplish a specific function. This was very annoying to me when I was just trying to listen to an audio note and had to select whether I wanted to use “Music” or “Google Play Music” to play the sound. I don’t know – just play the darned 20 second sound clip. I assume this may come in handy in other circumstances though.
It feels like I don’t have to type in my password nearly as often as I do in iOS. The Play store seems to trust you that you actually want to install what you say you want to install.
Push notifications temporarily turning on the screen in iOS is nice so you can quickly glance at your phone to see if you’re interested. On the Android you hear a buzz, but don’t know what’s up unless you unlock the phone. This may be a setting, but if so I haven’t found how to override it.
No badges on icons mean you have to dig into your notifications screen to find out what’s up.
Web and email don’t seem to quite snap to your screen size the same way they do on iOS. I’m constantly scrolling around horizontally to read all the content, and there doesn’t seem to be a pinch gesture to resize what you’re looking at. Or am I just missing it?
Nice job of setting up your contacts from Google + Facebook + other services when you first set up your phone.
It’s completely unclear to me how I go about putting music or media onto the massive 64GB of storage that come with the phone by default. It’s probably not hard, but there’s no seamless iTunes integration like with iOS.
Phone didn’t even come with headphones, and at first impression it doesn’t seem like the iPhone headphones+microphone work incredibly well with the device.
In just playing with and testing the phone, it didn’t ring when I called it half the time, going to voicemail after a couple rings when it displayed full service on AT&T 4G LTE. One call was garbled and the recipient couldn’t hear me. This may be an AT&T issue and not an Android or phone specific issue, but it’s not a good sign when you’re only about 50% success rate on a limited sample.
Tethering is huge! In fact, it was not that much more expensive to add an Android to my plan than it would be to get a MiFi or another mobile hotspot. Instead of shelling out $40+ a month for said base station, just add an Android and tether. A base station with functionality!

That’s all for now. I’m looking forward to begin hacking on Android development a bit, and learning what it’s like to really build for one of these things.

The Technical Lead

I’ve spent the better part of the past three years learning on the fly and thinking about how to be an effective technical lead at an early stage startup. Whether the role is called a VP Engineering, a CTO, an Engineering Lead, or something else, its aim remains the same: to build both product and team. Responsibilities can include defining and executing on product, recruiting a talented engineering team, building a strong technical brand, evangelizing the company’s platform, creating a fun and intelligent engineering culture and environment, forecasting for the company’s technical needs in the future, and establishing metrics and criteria for ensuring the the company’s technology is delivering and progressing according to business needs.

While all of these things, and many more, are very important, I believe that there are really three overarching themes that the technical lead of a business needs to be thinking about all the time above all else:

The technical vision of the company
Enabling the engineering team
The engineering culture

The technical vision of the company

It is the technical lead’s job to set, communicate, and lead the technical vision of the company by example. This includes but is not limited to:

clearly defining what is going to be built and when it will be delivered
justifying and communicating why this is important to the business
determining what technologies will be used and why
determining workflows for development including iterations, release cycles, testing practices, deployment practices, code reviews, etc

Is the team going to rush to the quickest possible minimum viable product and then iterate, or is it going to build quietly for months until it emerges with a hardened solution that’s ready to go to market? What tech stack will it use? It’s always recommended to use the best tool for the job at hand, but a company that is building using .NET and Oracle from day one is likely going to follow different technical dogma than one using Python and MongoDB. A company doing waterfall development will feel a lot different to an engineering hire than one continuously integrating and deploying.

The technical lead will make these decisions early on in the company’s path, and the practices that they lay down by example amongst the early employees will dictate the future technical direction of the company. And with quite a bit of momentum it may be hard to change course later.

Enabling the engineering team

After the initial team is established, and all of the roles are filled that are required to get the product to market, I believe that enabling the engineering team is the most important role of the technical lead. They must identify any blockers to progress for the team, and remove said blockers as quickly as possible.

Blockers are tricky because they can come in many forms – an unnecessary midday meeting which interrupts the flow every Tuesday and Thursday, ill-defined requirements from the product side of the house, inefficient processes and lack of automation for requesting and setting up servers, unavailability of healthy snacks around the office, lack of data to validate whether the feature in question is effective or not, etc.

Team is everything, and when the right bunch is fully enabled with the right equipment, environment, vision, and resources to do their best work, the results are magical. When they are blocked by any of the above, productivity can grind to a halt. As technical lead of the company, you have more power than anybody else to empower your team to be the best and happiest that they can be. Make it your highest priority to do so.

The engineering culture

I believe that a clearly apparent culture within a company is critical. From observing and living within the culture you can tell who the company is, what’s important to it, who will fit in and enjoy working there, and what it might look like when it grows. If a company is devoid of culture, it has no clear identity to those looking to join or work with it, and this obviously can have negative consequences.

From an engineering perspective, the culture begins with the technical lead. Is this an engineering team that diligently works together from 9-5 and then checks out? Is it one that grinds through the night and wanders back in to work in the afternoon hours? Is techno blasting from the office speakers or do people quietly work with headphones? Does the team sit together on an open floor or sequestered within their own offices? Do you hold weekly tech talks, brown bags, hack days? Is there 20% time for personal projects? Is it an academic environment that encourages research and publishing? Do you eat lunch together and go to happy hour? Do you break for high intensity table tennis matches or do you reward engineering milestones with prizes and bonuses?

You can build a successful engineering team by answering any of the above questions in any way, as long as the culture is consistent amongst the majority (or preferably all) of your team members. When you’re working as one team, the culture that you define, prioritize, and maintain will go farther than anything else in attracting a strong team that works together efficiently, productively, and most importantly has fun doing what they do.

At Hyperpublic I was very lucky to work with a team of some of the finest engineers I’ve ever known, within a culture that was a ton of fun to be a part of and help create. I have no doubt that as a company grows beyond ten people, and branches into multiple teams, the challenges for an engineering lead grow and become more complex. I look forward to learning and adapting to them on the next go round.

Prologue Profiles

My friend Dan Feld, who I've known since I was about 6 years old, is working on a really interesting project called Prologue Profiles. It's tagline is "Twenty-somethings onto something" and its current form is a weekly podcast in which he interviews someone who has given up the normal route through life in favor of trying to create something meaningful of their own. He's interviewed writers, musicians, designers, entrepreneurs, and this week he released an episode in which he interviewed me.

In the 14 minute interview I talk about the path through the world of entrepreneurship over the last four years, and address such topics as finding the right business, and the thin line between struggle and success.

Give it a listen, and be sure to send Dan any followup questions or feedback.

What Happened To JumpPost?

I frequently get emails from people looking to use the JumpPost product that we launched a year ago to help find a new apartment. This post explains what happened to JumpPost and why we aren’t running it anymore. In case you weren’t familiar with JP, the model was that we would pay vacating tenants $500 to list their apartment with us, if we found someone to sign a new lease on the apartment. Apartment hunters could search in advance, not compete with the craigslist crowd, and not pay a full broker’s fee, and vacating tenants could make $500 for doing very little work.

When Jordan and I were starting a company we wanted to build a large “local” product. At that time our ideas weren’t fully formed yet, but the vague way to describe it would be a Craigslist 2.0. We had studied marketplaces and attempts at better craigslist-type products, and we knew that you needed a unique model to create liquidity within one channel before you could just launch a craigslist with a better UI. So we looked at real estate as the most valuable vertical within craigslist, and came up with the JumpPost model as our “in”. We also knew that we would need a significant amount of capital to go after a huge marketplace, and to attract the capital we’d have to prove our team, product, and revenue generation abilities before we could raise financing.

JumpPost was quite successful for an early stage company in that it was generating revenue right away. And the whole time we were working on it, we were constantly trying to figure out how to expand it beyond just the unique real estate value prop that we were offering. Unfortunately its blessing was its curse in that the model was so specific, that if you added any more categories or even other types of real estate, people would be really confused about what to do when they landed on your site. They wouldn’t know why they could earn $500 for listing and showing an apartment, but nothing for listing and selling an old ipod or furniture.

So if we just continued on with JumpPost under the $500 incentive model, it would have likely been very successful if you measure success as owning a real estate brokerage which generates $1000+ profit on almost every apartment that you transact through the site. You have to also be excited about being “on the ground”, handholding every deal from start to finish, dealing with multiple parties on every deal, and losing out on a lot of deals you put work into. This can scale into an NYC only multi-million dollar business if you work long and hard at it.

But as Justin Timberlake let us all know: A million dollars isn’t cool…You know what’s cool….?

We’re internet entrepreneurs, developers, hackers, product designers. We want to change the world. We’re not real-estate agents. After we proved that we could execute on a local marketplace, build product, etc, we were able to pitch the big vision which was now much more fully formed. Outside investment was raised, and the seeds for Hyperpublic, a local data platform, were planted. The decision wasn’t made overnight to just shut JumpPost down. We certainly debated about modifying it, letting someone else run it, rolling the new product under the JumpPost brand, but in the end with the help of our advisors and network, we decided it best to focus on the enormous long-term opportunity.

At JumpPost we were focussed on making money in the first month, and at Hyperpublic we won’t be focused on it within the first year. But if we succeed, we’ll change the world, and that’s what gets us really fired up to work the long hard hours that it takes to run a startup.

Hyperpublic Developer Challenge Stats and Recap

Last Thursday over at Hyperpublic we launched The Hyperpublic Developer Challenge. It consisted of two programming problems, one of easy/medium difficulty, and one which was slightly harder. We built it for fun, because we’re developers, and we love when there’s a fun problem around to work on if we get bored or need a distraction. The response to the challenge was phenomenal. We had thousands of developers from around the world working on the problems, and hundreds submit correct solutions. Here’s a summary of the response, the problems, the winners, and some observations.

The Response

To our amazement, 5,759 people landed on our challenge start page. From there 2/3rds of them, or 3,856, were feeling brave enough to at least look at the first problem. I’m sure it didn’t hurt that we were giving away free Dropbox and Github accounts, so even the non-programmers who landed on the page at least wanted to take a look at the first problem. The response peaked out with 400+ people viewing/working on the challenge concurrently.

The first problem, summarized below, proved to be a strong filter. Only 446 people, or 11.57% of people who looked at the problem, submitted a correct response. 4,860 incorrect answers were submitted, meaning that the successful submission rate was under 10%.

Problem 2, the more challenging problem, received 231 correct submissions. This means that of the 446 people who made it through question 1, only 51.79% of people made it through problem 2. There were 753 incorrect submission attempts.

All in all, 4.01% of people who viewed the challenge made it through to completing both problems.

The Problems

Problem 1 asked developers to calculate the influence of fictitious users in Hyperpublic based upon the influence of the users which they have added to the system. The data was given as a text file, but it could easily be converted into a 2-D array representing which users added which other users to the system.

The most common approach was to use the input as a matrix representation of a directed graph. For each user in the input, traverse the graph recursively to sum up the number of users that the initial user was responsible for. Then find the three users with the highest scores, and use them to compute your answer to problem 1.

While we won’t be posting code examples here because we’ll leave the contest up for others to try, there are various solutions available around the internet and github, which can be found quite easily be googling/searching github.

Problem 2 assigned point values to various tasks around Hyperpublic and gave 4 users point totals. It asked the developer to compute the minimum number of tasks required in order to reach their exact point totals. This proved a bit trickier, in that many people’s first instinct was the use a greedy algorithm in which they always executed the task with the largest point total before moving on to tasks with smaller point totals. This would lead to an incorrect submission and developers to rethink their solutions.

The best way to write this program for inputs and point values of any size is using dynamic programming. This is analogous to the optimal solution coin changing problem which asks what the optimal way to make change for a given amount of money is using coins of various values. It uses a technique called memoization, where you compute the optimal ways to make change for values 1, 2, 3…up to your highest amount, and you use the previously computed values to compute the next unknown values in k attempts, where k is the number of distinct values of coins.

The other way common way in which people solved this problem efficiently was by solving 4 different linear equations. There were some one line solutions using Mathematica and Matlab linear solvers.

Fortunately, the problem size was limited enough in that a brute force solution would run quite quickly if people really got stuck as well.

The Winners

From the 231 correct submissions, we randomly selected winners of the following prizes:

Github “Medium” account free for one year – Norbert Fekete. Norbert hails from Mosonmagyarovar, Hungary, and submitted his solutions in C++. He’s new to github, so follow him over there and suggest some repos for him to fork.

Dropbox “Pro 100” account free for one year – Brian Barthel. Brian is from Memphis, Tennessee, submitted a C# solution, and runs an independent software company called Zoasoft.

Free desk for a month for two hackers to work on their own project at Hyperpublic HQ – Martin Czygan. Martin is from Leipzig, Germany, submitted a python solution, and since he can’t take advantage of a free desk in NYC anytime soon he has graciously donated the prize to an NYC based hacker who can use it. You can find him on github and twitter.

Other Observations

The most common language that we saw in submissions was Python. We haven’t run exact numbers, but eyeballing it, Ruby, PHP, Java, and C++ were the next most common. There were submissions in a wide range of languages though including Groovy, Scala, Clojure, L, Ocaml, C, Javascript, Haskell, Matlab, Mathematica, and others. Haskell in particular was popular among people who self identified as students or researchers.

Many people who submitted commented that the problems were too easy, and they would have preferred a harder challenge. We think that judging by the number of people who made it through, the number of people who emailed for help, and the number of people who submitted incorrectly, that the difficulty was about right. The majority of responses were very positive in that they said “this was a fun way to kill an hour or two.” We wanted the problems to take only an hour or two, and as such I think we got the difficulty right. People got to brush up on their dynamic programming or linear solving, they got to construct a graph, or they got to get their hands dirty with a new language. We think people had fun.

The last thought, is that we did this for fun, and we’re glad people enjoyed it. We also wanted to meet more developers and make them aware of Hyperpublic. We’re working on structuring data around every “local object” in the world, which is a big technical problem. If you’re interested in working on this with us, or hearing more about it. Don’t hesitate to contact me.

Looking forward to the next programming challenge.

The Hyperpublic Developer Challenge

Over the past couple of days the team at Hyperpublic has been working on the Hyperpublic Developer Challenge. It's a simple programming contest consisting of two problems: an easy problem, and a slightly harder one. It should take a programmer with a CS background 1-2 hours to complete.

We love hacking, we love building, and we love puzzles, so we made this for fun. But we're also hoping that it will spark developer interest in our product and our platform. Anyone who completes the challenge successfully will be entered into a raffle to win a free year's account at Dropbox or Github. We also have open desks in our new office and we'll be giving some of them away to developers looking for a home for a month or two.

Have fun, and let us know if you have any questions or feedback.

What is Hyperpublic?

As an entrepreneur you frequently get asked what you do, what you're working on, and what your big idea is. Even your closest friends don't always know, since over the years they've observed all of the "pivots", "iterations", and "experiments" that you've conducted in the name of finding that elusive product market fit. I'd like to explain what Hyperpublic, the product we launched two weeks ago, is all about, since there is more to the company than appears on the newly minted Hyperpublic.com.

Hyperpublic is a company focused on capturing and structuring local data.

What does that mean? Well, we look at local data as being any object in the world with a location attached to it. These objects can be people, they can be places (like restaurants, shops, and parks), or they can be things (like the West Elm bookcase in your apartment you're trying to sell). After we know what the object is and where it is, we'd like to structure and attach as much data to it as we can. This data may be photos, it may be tags that describe it, it may be pricing data if the item is for sale, it may be contact information. The list goes on.

After you collect and structure all of this data, there are a lot of things you can do with it. You can browse photos of local restaurants, you can find and hire a babysitter in your neighborhood, you can list all of the great comic books for sale in your city. We'd like to make it available to developers in order to find uses that we haven't even dreamed about. As such, the Hyperpublic platform will have an open API where developers can not only pull our data to create and enhance local applications, but they can also push objects, tags, and photos back into the system to distribute through the Hyperpublic ecosystem.

Hyperpublic.com is the first application built on top of the Hyperpublic platform. It exposes some of the data in the system as a local search, discovery, and curation tool for several big cities in the United States. Add yourself to the site if you'd like to be discovered. Tag yourself with "web designer", "freelance", "writer", or "looking for love". Browse your local neighborhood and save your favorite places and items into lists to organize your local world. Share your favorite spots with your friends. Post items you want to sell to the things category. You can join by simply emailing a picture of yourself, a thing, or a place to add@hyperpublic.com from your camera phone. No signup required.

Structuring data and location around every single person, place, and thing in the world and becoming a data provider is certainly a large goal, but it's a goal that our team is incredibly excited about pursuing. We'll have to solve hard problems involving big data, search, mobile product design, API and platform design, and more. If you're interested in working with us on these challenges, I'm hiring. Email me at doug@hyperpublic.com, or hit me up @petkanics.

Heroku Support Saved My Launch Day

The last 72 hours have been a wild ride leading up to the launch of my new site, Hyperpublic.com. I'd say that I got about 3 hours of sleep last night, 0 hours on Sunday, and maybe I was lucky to get 4 hours on Saturday. Pushing the site live this morning gave me all the adrenaline I needed to carry through the day however, as watching the users, tweets, and data pour into our hyperlocal object database kept me from falling asleep on my keyboard. A great writeup from Techcrunch and The Observer provided an extra boost of momentum.

We got quite a bit of traffic, and thanks to Heroku, the instant deployment and scalability Ruby application hosting service, we were able to handle all of the activity without a problem. The last thing you want to worry about on launch day is keeping the site up, and instead you want to be supporting your users and getting their feedback. After a few months of building and a momentous sprint at the end to get launched, I was very excited as we were nearing COB here on the east coast and traffic was starting to level off indicating that I would be okay to finally get some rest.

But that was not to be, as anyone who's ever launched a web product before knows, anything that can go wrong, will go wrong (ATCGWWGW). The site went down around 5pm with a few hundred active users on it.

There was no evidence, no error, no log message to indicate what the problem was. I tried everything I could think of to get it back up with no success. That's when we reached out to the aforementioned Heroku to see if they could help diagnose the issue.

I filed a ticket with support hoping to hear back. Sure enough a few minutes later I got an email response. After a quick exchange we were on IM. A few minutes later my contact had the database team looking into the issue while he worked with me to help diagnose it at the application level. After about half an hour we found out that the database drive failed and needed to be switched out. They made the change, and within minutes Hyperpublic was back online.

Anyone reading this may first react that this was Heroku's fault in the first place. Sure it was horrible that my app was down for an hour on launch day, and I would have preferred that there was no problem with our database. But as mentioned before, ATCGWWGW, and I'm damn glad that I had Heroku at my back helping to diagnose and fix the issue, as opposed to having to go it alone with my own server or unsupported hosting.

Instant, personal, realtime, friendly, and free support more than makes up for the occasional glitch in service, even if it occurs on a launch day. Once again, thank you Heroku.

Advice for college computer science students interested in entrepreneurship

This past Friday I took part in a panel at Penn’s computer science department designed to help students figure out what options are available to them career-wise post graduation. The panel was excellent and included representatives from big tech companies, big finance companies, graduate research programs, startups who had already grown and had a successful exit, and early stage founders such as myself. A lot of great advice was handed down through the Q&A session in particular, and I figured it would be good to summarize some of the best advice for college computer science students who are interested in entrepreneurship.

Build a web presence

This was echoed over and over again. One of the best parts about college is that you aren’t burdened by a nine to five job, and you actually have time to work on projects. In many cases, you can actually receive credit for such projects. Use your senior design project, your independent research projects, and even project based homework assignments to enhance your web presence. Spend a little extra time putting up a simple web site to collect and show off your work. If appropriate, open source your work on github and contribute to active open source projects. Start a blog to document your entrepreneurial endeavors and instincts.

Whether you’re looking for a job at a startup, or elsewhere, simply pointing to your web-based project repo or your github account will be 10x more effective than emailing over another one-page resume.

Learn systems – take the hard, project based classes

Operating Systems, Databases, and Networking should all be required for anyone looking to build applications. Why they are sometimes electives are beyond me. Take these classes, work through the projects, and what you gain in experience will pay off for your entire career.

Get comfortable with a scripting language

Many good CS programs eschew practicality in favor of teaching the fundamentals and core concepts. This is a good thing as the current popular languages will go out of style at some point, but the core concepts never will. But just because the CS departments may teach you Java or C++ doesn’t mean that you are stuck programming in them forever.

Many startups use scripting languages like Python, Ruby, and PHP, as well as the accompanying popular web frameworks that go with them. These languages, although not the most performant, contain great high level standard libraries allowing you to accomplish many useful tasks in just one or two lines of code that would otherwise take 30 in C++. You can easily and quickly write scripts to solve many of your problems, and you won’t have to worry about complicated compilation or deployment setups. Spend time learning and using one of these languages for your senior design or independent research projects if your program doesn’t use them in any of your classes.

Graduate

If you start a company during college, it might fail. Most startups do. What you learn at college, in and out of the classroom, will benefit you your entire life. Most people don’t look back on college and regret staying the full four years.

Sub-matriculation can save years off of the immigration process for international students, which can be especially helpful in working towards entrepreneurship

This was a great practical piece of advice that apparently many undergrads aren’t aware of until after the fact. I’m not familiar with all of the immigration laws and processes, but the gist of the advice was as follows:

With a bachelor’s degree you need to be sponsored by an employee to remain in the US, and you likely have to stay with that employee or find another big company sponsor for a period of 7+ years while you work to earn your green card. It’s hard to make an entrepreneurial move in the US during this process. However if you sub-matriculate into a 1 year master’s program, then you cut the process from 7+ years to about 1.5 years. If you have the flexibility to spend one more year on campus, it can be worth it just in the immigration benefits alone.

Getting funding for your college startup can be difficult if you go the traditional VC route, but there are options

Programs like YCombinator, Techstars, and Dreamit are perfect for recent college grads. You have a smart and scrappy team, no overbearing life commitments or costs, and the ability to relocate to the best possible environment to launch your company. Big-time investors will look for proven leadership teams, past experience, and market intelligence and connections when making million dollar investment decisions, and this likely doesn’t describe the team comprised of your dormmates. But the accelerators mentioned above are looking for smart teams working on hard problems. This is right up your alley, and they’ll lead you to the connections you need later.

The above is just some of the great advice that was given. If you are a college student and you have questions about working at a startup or entrepreneurship, email me anytime at petkanics@gmail.com, or hit me up on twitter @petkanics.

The DOB

Insights by Doug Petkanics

Author Archives: petkanics