1.
What every developer can learn from startups

2.
/me #1 <ul><li>Got hooked on startups at Riot-E </li></ul><ul><ul><li>Search for “riot on” on YouTube </li></ul></ul><ul><li>Startup cult member since </li></ul><ul><ul><li>30+ companies total </li></ul></ul><ul><ul><li>expert on failure </li></ul></ul>

3.
/me #2 <ul><li>Do technical due diligence for investors </li></ul><ul><ul><li>get paid to criticize other's work </li></ul></ul><ul><li>Keen on JavaScript </li></ul><ul><ul><li>the older I get, the more lazy I get </li></ul></ul>

4.
Why write code?

5.
What drives developers? <ul><li>Self actualization </li></ul><ul><li>Respect of others </li></ul>

6.
What drives managers? <ul><li>??? </li></ul><ul><li>Profit </li></ul>

7.
What drives customers? <ul><li>Value (for money) </li></ul>

8.
<ul><li>Software development is like ... </li></ul>

14.
… Biological Systems <ul><li>Evolving, interacting systems </li></ul><ul><li>… that nobody quite understands </li></ul><ul><li>Everything somehow still works </li></ul><ul><li>… but may end up being a monster </li></ul>

15.
How do projects get started? <ul><li>Somebody thinks they know what others want </li></ul><ul><ul><li>raise -> build -> sell </li></ul></ul><ul><li>Should validate their assumption first </li></ul><ul><ul><li>sell -> build -> raise? </li></ul></ul>

16.
Be Lazy <ul><li>The only projects that get delivered on time and according to spec are the ones that never get started at all </li></ul>

17.
Customers #1 <ul><li>You're not in the service industry </li></ul><ul><ul><li>The customer is not always right! </li></ul></ul><ul><li>Learn how to say NO , excessive customer collaboration results in bloat </li></ul><ul><ul><li>37signals vs. Salesforce </li></ul></ul>

18.
Customers #2 <ul><li>Don't build just for one customer </li></ul><ul><ul><li>Discover product market fit </li></ul></ul><ul><li>You're building a long term relationship </li></ul>

19.
The Team <ul><li>Communication overhead to be avoided at all costs, this increases exponentially with team size </li></ul><ul><li>Cross functional teams are great, but smaller teams of specialized generalists are better </li></ul>

20.
Rockstars and Ninjas <ul><li>Developer output varies by an order of magnitude, so finding the best developers (who are nice people) is key </li></ul>

21.
Expectations <ul><li>It's all about managing them </li></ul><ul><li>Very hard to do when requirements change </li></ul><ul><ul><li>Almost always means more work </li></ul></ul><ul><li>Burn-down & burn-up charts </li></ul>

24.
Milestones <ul><li>Needed to achieve sense of accomplishment and self worth </li></ul><ul><li>Needed for invoicing </li></ul><ul><li>Having something working badly is better than having nothing that works well </li></ul>

25.
Embarrassment <ul><li>“ If you are not embarrassed by the first version of your product, you’ve launched too late” </li></ul><ul><ul><li>Reid Hoffmann, LinkedIn </li></ul></ul>

26.
Prototypes #1 <ul><li>Changes are easier to make early in the development cycle, but this gets progressively more difficult </li></ul><ul><li>Functional prototypes are great for conveying the big picture and user journey </li></ul>

27.
Prototypes #2 <ul><li>Basis for a contract </li></ul><ul><ul><li>You do need those sometimes </li></ul></ul><ul><ul><li>Works even when you are your own customer </li></ul></ul><ul><li>Great for validating the customer </li></ul>

28.
Features #1 <ul><li>Features are like sex </li></ul><ul><li>Less is more </li></ul><ul><li>Not every piece of work can be described as a story or a feature </li></ul>

29.
Features #2 <ul><li>You can think through a feature without implementing it </li></ul><ul><li>You can build a feature without rolling it out </li></ul>

30.
Modularity #1 <ul><li>Monolithic systems are hard to reason about </li></ul><ul><li>The Unix philosophy is the way forward </li></ul><ul><ul><li>Write programs that do one thing and do it well. Write programs to work together. </li></ul></ul>

31.
Modularity #2 <ul><li>Creating reusable modules is the right thing to do </li></ul><ul><ul><li>Despite having no visible benefit to end users </li></ul></ul><ul><ul><li>Because you don't always want to scrap everything </li></ul></ul>

32.
Open Source <ul><li>Give away everything you can </li></ul><ul><li>Promotes your business </li></ul><ul><li>Recruiting tool </li></ul><ul><li>Motivational aid </li></ul>

33.
Technical Debt <ul><li>“ Eventual consequences of slapdash software architecture and hasty software development” </li></ul><ul><li>Do take on, as long as you know you're doing it </li></ul>

34.
Failure <ul><li>Failure is change </li></ul><ul><li>Embrace it </li></ul><ul><li>Learn from it </li></ul><ul><li>Know when to quit </li></ul><ul><ul><li>Don't throw good money after bad </li></ul></ul>

35.
Distributed Teams <ul><li>Increasing trend </li></ul><ul><li>Rockstars and Ninjas are on the road a lot </li></ul><ul><li>Meetings are evil </li></ul><ul><li>Tools can help </li></ul>

36.
Operations & Metrics <ul><li>Roll out updates quickly and often </li></ul><ul><li>Trust your developers </li></ul><ul><li>It's a numbers game </li></ul><ul><li>Track everything you can </li></ul>

37.
Summary <ul><li>This is not an exact science </li></ul><ul><li>Use whatever works for you </li></ul><ul><li>Think about the bigger picture </li></ul><ul><li>Enjoy the process, not the end goal </li></ul>

38.
Thank you! <ul><li>@olegpodsechin </li></ul><ul><li>github.com/olegp </li></ul>