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
2. ! Why Solo?
3. 1. Broad Competence Over Narrow Excellence
5. 2. Optimizing for Autonomy
7. 3. The Pleasure of Accumulated Sophistication
9. " Finding Projects
10. Early-Stage Projects Small, Indie Products Internal or Ancillary Apps Throttled Projects
11. # Three Keys
12. 1. Be Good 2. Be Fast 3. Don’t Die
13. $ On Being Good
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
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
16. Making Yourself Better
17. Find a Community of Practice
19. Scan for Gaps
21. Shift Between Creator and Editor Modes
22. Wear All the Hats
23. DAMMIT JIM, I’M A DOCTOR, NOT A…
24. Making Your System Better
25. Clarify What You’re Optimizing For
26. We can live with the occasional maintenance window, but we must keep infrastructure costs below $X.
27. We can tolerate missing a delivery deadline, but we can’t afford to ship a poor user experience.
28. Intent, Content, Form, Function
29. Learn from Failure
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.
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.
32. Ratchet Up
33. % On Being Fast
34. No time spent on building consensus No time wasted fighting over tools or approaches No time needed to coordinate the work
35. No parallelizing work No momentum from others No one to get you unstuck
36. Making Yourself Faster
37. Tackle Biggest Unknowns First
39. Steal as Much as Possible
41. Reduce Work in Progress
42. Shift Gears Based on Terrain
43. Minimize risk through: Extra research Incremental changes Plans and checklists Predetermined rollback strategies
44. Making Your System Faster
45. Choose Simple, Boring Technology
47. Use Technical Debt Carefully
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
49. Build Feedback Loops
50. Level One: Automated tests Level Two: Production observability Level Three: Customer support
51. Prefer Less Code
52. ☠ On Not Dying
53. Satisfaction of knowing you built this yourself Complete ownership and responsibility
54. Can’t easily leave Project is in danger of failing without you
55. Making Yourself More Sustainable
56. Be Your Own Best Manager
57. Communicate Your Value
58. Move to Successively Higher Levels of Consideration
60. Work on Multiple Projects
61. Making Your System More Sustainable
62. Stay in the Big Boat
64. Foster Trust
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
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
67. Build “As If…”
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
69. Have a Succession Plan
70. Time to Get Real
75. Thanks! @jeremysmithco