Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Solo: Building Successful Web Apps By Your Lone...

Jeremy Smith
November 18, 2022
490

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.

Jeremy Smith

November 18, 2022
Tweet

Transcript

  1. 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
  2. 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
  3. We can live with the occasional maintenance window, but we

    must keep infrastructure costs below $X.
  4. We can tolerate missing a delivery deadline, but we can’t

    afford to ship a poor user experience.
  5. 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.
  6. 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.
  7. No time spent on building consensus No time wasted fighting

    over tools or approaches No time needed to coordinate the work
  8. Yes: Speculative projects, high tolerance for failure, or “default dead”

    Maybe: One-offs for near-term speed (with acknowledgement) No: Constant pressure for speed
  9. 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
  10. 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
  11. 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