Week 7 of Startup School 2018 we get technical with a panel of CTO/COOs Geoff introduces funding.
A recurring question from startup school participants is how to handle engineering best practices. I think it keeps coming up because it's so hard to reconcile good engineering with the YC culture that applies extreme pressure to launch and iterate fast. Inexperienced devs have to ask because "best practices" are received wisdom. They are rules to follow and they don't really understand the problems they solve. Just using the term "best practices" is a strong indication that someone is trying to impose external standards instead of responding to what is needed.
To summarise the answers: it's a balance which changes as you scale up and have users depending on you. You will grow into the practices like continuous integration and deployment.
The question is where that balance starts. If you learned a practice by experiencing a problem and solving it, you can now anticipate the problem and pull in the practice at the right time. Does this mean everyone needs to hit these problems themselves? Probably. It's very difficult to obtain this type of judgement by study instead of experience. Studying means taking on behaviours by faith alone. There was a lot of faith in the 90s where developers were buried under heavy-weight processes that could not be questioned. The problem is that an engineering environment and problem is so unique that generalised advice is bad advice.
The counter argument to learning empirically is that you don't live long enough to make all the mistakes yourself! This is why I look forward to the lessons learned part of a talk the most. However not all experience creates a teachable lesson, for example, Ralph Gootee said:
I don't think I would choose to write four different platforms. If I was gonna write again I'd probably would've picked one of the cross platform development libraries. I don't know which is best, you'd have to tell me.
The problem here is that devs who took the other path and gone all in on a cross-plaftorm toolkit e.g. Cordova, Xamarin or React Native often say "never again" and long for platform native tooling. For example, the top two most dreaded technologies in 2018 Stack Overflow Survey are Cordova and Xamarin! React Native is still in a honeymoon phase. There have been some notable reversals e.g. AirBnb and Udacity but it hasn't developed enough hatred to join Cordorva... yet!
When you have only travelled one path, it's not a lesson yet, it's just a grass-is-greener reaction to a hard problem. The only people who can teach a lesson are those who have climbed both mountains because the valuable information is specific and nuanced. The teacher is able to advise when cross-platform toolkits help and when they hinder. In PlanGrid's case, their product was a performance play to handle large pdfs that broke the default apps. That would be the type of application I would be quite pessimistic about about handling in a cross-platform toolkit where memory management is often a big problem.
In the spirit of learning lessons, I had high hopes for this discussion. Both Adora and Eric had high profile start-ups which rapidly imploded. Both Adora and Eric presented their success stories at YC events when their start-ups were in the ascendency so this was a chance to reveal the other side of the story. It would be a difficult but important discussion.
I was quite shocked that Pebble's failure wasn't even mentioned. It felt close to deception because if you knew nothing about Pebble going in, you will be left believing Pebble is a thriving hardware company. I don't blame Eric and Adora because I'm sure they were both wounded by their experiences but I think it's an example that the valley is not really as ok with failure as it claims.
Not really my type of talk but a couple of tidbits:
Some people have raised as much as $30 million investment on a SAFE
AngelCalc is a tool Geoff made for calculating the conversion of safes and convertible notes