Solo: Building Successful Web Apps By Your Lonesome

Whether by choice or by circumstance, you may find yourself developing a web application alone. Congratulations! You've got the house to yourself and no one telling you what to do. But at the same time, there's no one to share the burden or make up for your shortcomings. How do you build well and ensure project success? We'll look at the pros and cons of working alone, what kinds of projects are well-suited to solo development, strategies for professional growth, and development and operational processes that will save you time and help you sleep better at night.

Transcript

1. Solo
   Building (& Running)
   Successful Web Apps
   By Your Lonesome
   

   View Slide

2. ! Why Solo?
   

   View Slide

3. 1. Broad Competence
   Over Narrow Excellence
   

   View Slide

4. View Slide

5. 2. Optimizing
   for Autonomy
   

   View Slide

6. View Slide

7. 3. The Pleasure of
   Accumulated Sophistication
   

   View Slide

8. View Slide

9. " Finding Projects
   

   View Slide

10. Early-Stage Projects
    Small, Indie Products
    Internal or Ancillary Apps
    Throttled Projects
    

    View Slide

11. # Three Keys
    

    View Slide

12. 1. Be Good
    2. Be Fast
    3. Don’t Die
    

    View Slide

13. $ On Being Good
    

    View Slide

14. No one telling you you’re doing it wrong
    No one to question your architectural
    decisions or technology choices
    No one holding back your growth
    

    View Slide

15. No one to point out your weak areas, push back
    on your decisions, and help you improve
    No one to talk through problems with,
    or review your code
    No one to show off to or celebrate with
    

    View Slide

16. Making Yourself Better
    

    View Slide

17. Find a Community of Practice
    

    View Slide

18. View Slide

19. Scan for Gaps
    

    View Slide

20. View Slide

21. Shift Between
    Creator and Editor Modes
    

    View Slide

22. Wear All the Hats
    

    View Slide

23. DAMMIT JIM, I’M A DOCTOR, NOT A…
    

    View Slide

24. Making Your System Better
    

    View Slide

25. Clarify What You’re
    Optimizing For
    

    View Slide

26. We can live with the occasional maintenance window,
    but we must keep infrastructure costs below $X.
    

    View Slide

27. We can tolerate missing a delivery deadline,
    but we can’t afford to ship a poor user experience.
    

    View Slide

28. Intent, Content,
    Form, Function
    

    View Slide

29. Learn from Failure
    

    View Slide

30. A customer didn’t receive an important daily summary email.
    1. Why?
    The nightly job that sends the summary emails failed halfway through.
    2. Why?
    That job iterates over the customers to send each email, and there was a
    timeout on one email delivery, causing the job to crash.
    3. Why?
    I hadn’t anticipated or tested failure states.
    

    View Slide

31. A customer didn’t receive an important daily summary email.
    1. Why?
    Add alerting on job failure or the absence of successful delivery.
    2. Why?
    Switch to a fan-out approach with a separate background job for each
    customer email delivery, which will retry on failure.
    3. Why?
    Set aside some personal research and learning time.
    

    View Slide

32. Ratchet Up
    

    View Slide

33. % On Being Fast
    

    View Slide

34. No time spent on building consensus
    No time wasted fighting
    over tools or approaches
    No time needed to coordinate the work
    

    View Slide

35. No parallelizing work
    No momentum from others
    No one to get you unstuck
    

    View Slide

36. Making Yourself Faster
    

    View Slide

37. Tackle Biggest Unknowns First
    

    View Slide

38. View Slide

39. Steal as Much as Possible
    

    View Slide

40. View Slide

41. Reduce Work in Progress
    

    View Slide

42. Shift Gears Based on Terrain
    

    View Slide

43. Minimize risk through:
    Extra research
    Incremental changes
    Plans and checklists
    Predetermined rollback strategies
    

    View Slide

44. Making Your System Faster
    

    View Slide

45. Choose Simple,
    Boring Technology
    

    View Slide

46. View Slide

47. Use Technical Debt Carefully
    

    View Slide

48. Yes: Speculative projects, high tolerance for failure, or
    “default dead”
    Maybe: One-offs for near-term speed (with
    acknowledgement)
    No: Constant pressure for speed
    

    View Slide

49. Build Feedback Loops
    

    View Slide

50. Level One: Automated tests
    Level Two: Production observability
    Level Three: Customer support
    

    View Slide

51. Prefer Less Code
    

    View Slide

52. ☠ On Not Dying
    

    View Slide

53. Satisfaction of knowing
    you built this yourself
    Complete ownership and responsibility
    

    View Slide

54. Can’t easily leave
    Project is in danger of failing without you
    

    View Slide

55. Making Yourself
    More Sustainable
    

    View Slide

56. Be Your Own Best Manager
    

    View Slide

57. Communicate Your Value
    

    View Slide

58. Move to Successively Higher
    Levels of Consideration
    

    View Slide

59. View Slide

60. Work on Multiple Projects
    

    View Slide

61. Making Your System
    More Sustainable
    

    View Slide

62. Stay in the Big Boat
    

    View Slide

63. View Slide

64. Foster Trust
    

    View Slide

65. Surprise or anger because expectations weren’t met
    Decisions or actions being hidden from others
    Hesitancy to change code, infrastructure, or process
    because of previous bad experiences
    Excessive verification or micromanagement
    Long-running debates without resolution
    Lack of collaboration
    

    View Slide

66. Spend more time together
    Apologize or make repair attempts, when appropriate
    Increase transparency or the level of detail
    Change the communication medium
    Propose solutions that better align interests
    Clarify expectations and commit to follow-through
    

    View Slide

67. Build “As If…”
    

    View Slide

68. Keep all credentials in a password manager
    Keep your README up-to-date
    Write automated tests
    Use a project management tool
    Document architectural decisions
    Create runbooks and process docs
    

    View Slide

69. Have a Succession Plan
    

    View Slide

70. Time to Get Real
    

    View Slide

71. View Slide

72. View Slide

73. View Slide

74. View Slide

75. Thanks!
    @jeremysmithco
    

    View Slide