mehdi's notes

Dev Bootcamp* is not the gate to a high paying job in startup world

Thu, 24 Apr 2014 11:02:45 -0700

s/Dev Bootcamp/{any intense software training programs}/g

PunchTab is hiring, and I manage the whole process for the product development recs.

I see different profiles who apply for the junior positions. It usually falls in one of these buckets:
* CS grad or undergrad
* Self taught
* Intense software training programs hustler.

I have interviewed, made offer, and hired candidates from all these buckets. With each experience, I improve my filtering skills. I do interview folks who come out of intense software training program. But, I pay special attention to two specific aptitudes: passion and fundamentals.

* Do you have a real passion for building software? How do you show you are not just opportunistic and trying to get a high income and surf the tech wave. The easiest proxy I have found for this is to look for a genuine side project *outside of the program*. This usually prove me passion. I look at the details of the product that you have shipped. How much effort did you put into building something nice? Are real people using it? How much time did you spend on side projects.

* The fundamentals are also important while building product. I do believe in the “10,000 hours to mastery” theory. I don’t assume junior developers have achieved mastery, but you have to show me how you are getting there. The easiest proof is Open Source project contribution. How do you get your code reviewed, trashed, mocked by other people, and get better.

There are no shortcuts to make a difference in a startup. Find something you like, become good at it.

Back Pain, and attempt treatment.

Sun, 16 Jun 2013 17:15:01 -0700

I have been hurting for back pain for now more than 12 months.

My symptoms are pretty common: * Lower back pain (mostly on the right side) * tingling on throughout the legs (that doesn’t happen all the time) * Not extra painful (may be a 6 out of 10 at worst, 3 out of 10 on average), but pretty annoying

The pain came on an off for the past 12 months. Mostly feeling better when I don’t spend too much time standing, or when I swim a lot. And feeling bad after the kind of exercise that requires bending forward or on the sides (Squash).

I know I have a bulging disc (did an MRI). It’s not too bad, but I don’t want that to impact my life. I’m 30.

My guess is that if I have strong core, and flexible hamstrings I’ll be fine. So here is my plan:

Swim 2 times a week.
Core work everyday.
Yoga once a week.
Standup desk as much as I can (depending on riding).
Ride 100 miles/week

I’m going to track workouts and results on a daily basis in a spreadsheet that I might share or not. will see.

What are the cons and pros of using a hosted MongoDB hosting and running it on Your own VM?

Mon, 28 Jan 2013 16:28:18 -0800

Answer by Mehdi Ait Oufkir:

Your job is to quickly build a product that people use, so you can measure and learn if you should pivot or persevere.

Here is what my guts tells me: you need to focus your brain power on bringing value to your customer. You need to focus on building software, not on Dev/Ops or SysAdmin stuff.

Here is a more objective take on it:
2 scenarii:
1. Your product is not taking off. You don’t have a lot of traction.
    * If you use a DB-as-a-service:
        * The price of hosting will be low (<$40/month)
        * You will have an extra 2-4h/week to focus on iterating on your product to make it successful (and you will probably need it)
        * You will have the piece of mind of knowing experts are watching your DB.
    * If you do it yourself
        * The price of hosting will probably be at least $10/month. (I’m just guessing here, I haven’t done the math)
        * You will have to do SysAdmin, Dev/Ops and DBA tasks (setting up the VM, installing everything, updating the software when it needs to be updated, restarting the box when it needs to be bounced)

2. Your product is taking off. You have traction.
    * If you use a DB-as-a-service:
        * The price of hosting will be proportional to your traction.
        * You can focus on : (1) making your product even better, (2) find a way to cover your cost if you want to stay independent, (3) spend time trying to raise money if you have bigger plan.
    * If you do it yourself
        * You will have to invest ahead of your traction, on VM/hardware.
        * You won’t have time to do the SysAdmin, Dev/Ops and DBA tasks yourself, so you will have to hire someone at typically ($150/hour). This person will not help you build a better product. It will just be an ongoing maintenance cost.

View Answer on Quora

The Reactive Company

Sun, 20 Jan 2013 16:24:02 -0800

The concept of reactive company is something that I expressed while brainstorming after a pretty embarassing bug we found in our platform in the early days at PunchTab. It is a pretty trivial, but really important concept.

To be honest, I’m not even sure what was the bug we ran into. I remember it was pretty embarassing. I remember it affected our customers for a noticeable amount of time. While discussing how we could avoid this kind of issue in the future, I concluded that there was no way to make sure these kind of bugs would not happen if we wanted to stay nimble. The only variable that could be optimized without hurting the company’s agility was the amount of time it took us to identify and fix the issue. That’s when I explicitly declared we needed to be more reactive. Here was our plan:

All trackable business metrics would be shown real-time in a dashboard (We use geckoboard for this) on a giant screen in the office. By using the “in-your-face” method, you make sure that there is always someone in the company that is briefly glancing at the dashboard. And I trained everyone to mention something if a trend looks out of the ordonary.
A good portion of our key metrics have paging setup (SMS, phone calls and emails). We use PagerDuty for this. We set it up for business metrics as well. It does not only track uptime. It tracks activity and engagement of our users. PagerDuty is setup to go off if it reaches certain treshold, which is usually calculated based on the standard deviation of the average.
Obviously our uptime and response time is also setup with tracking, and paging. This is done simply with newrelic.com and allows us to have a objective view of the performance of our system.
If one end-user complains about something, we automatically assume it means that thousands are running into that issue (This works better if you are running at scale). This is probably the hardest to turn into actions in real life, but your answer cannot be “I can’t reproduce the issue”, if someone is running into it, then a lot more are, and you need to act on it.

The goal with this setup is to make sure that when something goes wrong with the system (which happens really often), we are able to detect the malfunction really quickly, and respond to it in no time. There is no waiting 24hours, until enough people complain to start looking into it. I’m actually extremely surprise how little false positive occured in the past 2 years.

This simple rule got us in a place where we have been able to react to crisis before they even existed. And it grew into the culture of the company which allowed us to apply these same tactics for other stacks than product development. I believe this is now stored in the DNA of company, and this how company with a small team can execute so well on so many levels.

Software engineering at startup is not craft

Mon, 07 Jan 2013 23:29:11 -0800

Unlike a lot of the technical co-founder of startups, I did not grow up “hacking” for pleasure. I discovered software engineering much later when I had to pick a major in college. I was lucky enough to pick something I ended up liking, I picked software engineering, which allowed me to learn how to build stuff that people used; that’s how I like to call it. The emphasis on the “people used” part is actually important. I did not necerarly like building software for the sake of building software. I actually enjoyed the vision of the software being used by people. I think that’s why I was so lucky to end up in the startup world, even though I was train for a broader “Software engineering” industry.

I could only see my way in this industry if I could build stuff that would be used, by a lot of people. It did not need the sofltware I built to change people’s life, or the world, I just needed it to be used.

After college, I ended up being lucky enough to intern for YouSendIt.com, which was a typical fast growing startup in the Silicon Valley. I knew almost nothing, but as soon as I got my buggy software into people’s hand, something happened to me, and I really strived getting better at building software. Not getting better, for the sake of crafting beautifully engineered software, but getting better at delivering web applications that would be used by millions of people.

When a startup launches, the only focus that the product development team should have is how to get as many people as possible to use the application.

The type of engineers that makes a product development team succesful in the early days of a startup, is not an engineer who builds software as a craft. It is not an engineer who focuses on creating the most elegant software architecture. It is not an engineer who wants to use the latest technology, nor the best-most-obscure algorithm. The type of engineers that makes a product development team succesful is the type that strives to ship software to get people to use it. His self-proclaimed success should correlate with the number of people who use the product he builds, and its growth.

Comes a time engineers need to use their craftmanship to build software, but it comes way later in the life of the company, when shipping codes involves enough engineers that non-crafted code could affect how the product is being used. As engineers we all have to keep in mind the reason why we are building software: for customers.

"A number of the responses brought up Firefox. As in, Chrome seems to be heading down the same path..."

Fri, 28 Sep 2012 18:15:38 -0700

“A number of the responses brought up Firefox. As in, Chrome seems to be heading down the same path that Mozilla’s web browser went down a few years ago. What started as a fresh, fast answer to Microsoft’s Internet Explorer at the height of its dominance, eventually became a slow, buggy, bloated turd.”

- Dear Chrome, Slow Your Roll | massive greatness by MG Siegler

That’s why Safari is till the best browser around. period.

whitneymcn: Just a reminder. Yep. I’m buying one today

Fri, 14 Sep 2012 09:01:47 -0700

whitneymcn:

Just a reminder.

Yep. I’m buying one today

Biz Dev for engineers

Thu, 13 Sep 2012 15:28:00 -0700

Biz Dev for engineers

There is no shortage of explanations on why Business Development is a distribution channel that should not be under valued. But Business Development can sound a bit obscure when you listen to BD veterans. From my experience at PunchTab I’ve found that successful business development ventures must have the right combination of the following:

A good network, in order to find the right complementary partner.
A compelling and flexible product to integrate.
A great story to tell, or at least the potential to tell a good story.

#1 is not going to be the sweet spot for most first time entrepreneurs but connected investors help. For #2, a bit of product sense and a good engineering mindset should get you in the right place. #3 is usually the toughest part, especially for entrepreneurs with an engineering background.

So how do you help yourself with #3

This might sound obvious but there is a simple solution to facilitate business development opportunities when you’re a first time entrepreneur with an engineering background: API.

Provisioning: You can install a loyalty program on your website without going on punchtab.com by using CloudFlare. We made this happen by providing access to our provisioning API. A few HTTP calls later, we were up and running.
Integration: In the early days of PunchTab, we had our single largest growth day thanks to our integration with Wibiya. Our JS SDK made the integration extremely simple. (Hide the reward tab + instrument an element from the wibiya bar= BOOM)
Functionality: The founder of OpenDining.net stopped by on our customer chat. He wanted to build a loyatly program for restaurants. It was as simple as pasting the link to our documentation to get the integration started. 2 weeks later, he came back with a fully functional version of a loyalty program for restaurants… powered by PunchTab.

Without jumping through hoops, or sitting in countless meetings to discuss possible integrations. We solved major pain points, in large markets, through the combined use of 2 different products from 2 different companies. Business Development partnerships can be kickstarted thanks to an open API. I have personally experienced it. It will not be a long term substitute to more traditional business development practices, but in a (startup) world where every resource is counted and you need to get answers to your questions quicker than ever, it definitely simplifies the process.

"Following a day-long Domain Name Service server outage, web hosting provider GoDaddy is letting its..."

Tue, 11 Sep 2012 07:24:47 -0700

“Following a day-long Domain Name Service server outage, web hosting provider GoDaddy is letting its competitor, VeriSign, host its DNS servers.”

- Amid Outage, GoDaddy Moves DNS to Competitor VeriSign | Wired Enterprise | Wired.com

This is actually pretty interesting that GoDaddy admit losing the battle on this one. I’m not sure how many companies would do something like this…

How to translate your app to 15 languages in 4 month

Sun, 29 Jul 2012 17:21:00 -0700

Translating web applications to other languages is pretty common these days but I’m really proud of the team for getting this done so quickly, especially if you consider headlines like “Company X raises $100,000,000 to expand product internationally”. Even if you can argue that going international is more than translating your platform (marketing + business dev. is probably what costs the most), often the product development part of initiative is usually over-engineered. Here are three key points that helped us do this right at PunchTab.

Reactive company

Really early on, Ranjith (my co-founder) and I discussed the fact that the company we were building had to be reactive. I have seen too many instances of projects/companies/initiatives failing because they were trying to be too pro-active too early, and lost agility in reacting to market demands; they were locked into a direction early and couldn’t react fast enough. So it’s no surprise that my answer to the question “what about internationalization of the platform?” was “Assume it’s there, we will make it happen whenever needed”. I knew the team was set up to react quickly whenever the customer opportunity would arise.

Platform

I don’t consider myself as a great software engineer (we hired the bestest as soon as we could) and that’s why I always constrain myself into standards. This has worked very well for picking a few different pieces of the architecture for PunchTab. All those standards helped integrate features required for i18n with no difficulties.

Crowdsourcing

I have always been fascinated by crowd-sourcing solutions to problems. One of the my stillborn week-end projects was a crowd-funding service. Two of our angel investors (Venky and Anand) co-authored the first paper on mechanical turk. Regarding PunchTab, we used some of Transifex to crowd-source the translation of the platform. Out of the 10,000 loyalty program we power, a couple dozen dedicated site-owners are participating to translate the platform. The incentives are aligned for everyone and that’s why the process is actually pretty smooth. We even have an Icelandic version of PunchTab running (which was translated by an enthusiastic PunchTab publisher in less than a weekend).

In my previous experience i18n projects are constantly pushed down the list of the priorities because it’s deemed a big undertaking. The ecosystem around tech companies is becoming so powerful that things like providing your service to the international becomes trivial as long as you have the right company culture. Set yourself up for success by re-thinking how to tackle the problem and you’ll be amazed how fast it can get done.