The document discusses key insights for developers from startups, emphasizing the importance of understanding customer needs, managing expectations, and embracing failure as part of the development process. It highlights the value of modularity and the necessity of effective team communication, while cautioning against excessive customer collaboration. The text concludes with a reminder to focus on the bigger picture and enjoy the development journey.

1. What every developer can learn from startups

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

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

4. Why write code?

5. What drives developers? Self actualization Respect of others

6. What drives managers? ??? Profit

7. What drives customers? Value (for money)

8. Software development is like ...

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

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

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

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

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

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

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

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

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

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

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

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

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

29. Features #2 You can think through a feature without implementing it You can build a feature without rolling it out

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

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

32. Open Source Give away everything you can Promotes your business Recruiting tool Motivational aid

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

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

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

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

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

38. Thank you! @olegpodsechin github.com/olegp