markdown guide

One thing I always do prior to beginning to code is the "Rubber Duck" method. Basically you speak to the duck, carefully explaining every single detail of your project. Each step, each bit of logic, how you will organize it into code and what order it will go in your workflow. Gives me great clarity.


This is awesome! I feel like I've been really missing out on conceptualizing everything and getting a clear image of what I'm actually building and what will be needed. I'm copying the "Rubber Duck" method :D


Hey Daniel!

From your other post, it seems like your comfortable with the technical aspects of bringing something to production (type code, shovel code onto the Internet) but are struggling with the time and attention management side of your side project.

As a serial/parallel "prod-crastinator", I feel your pain. I have all these ideas for products, things to design and build and so on and so forth. I get excited, start typing into the magic code box and then lose interest some number of hours, days, weeks, months, or (sometimes!) minutes later.

The thing that helped me the most was reading Weinberg on Writing. In it, Jerry Weinberg, one of the most prolific technical authors of our generation breaks down how he goes about "shipping" so much. My main takeaways were:

  1. Start from a position of accepting the unknown end result of my (writing || coding || whatever). If I ship a few commits or take some notes or whatever, and it doesn't "do" anything that's OK! It's far better to get some stuff out of my head and into an artifact (even if it's private) than it is to have it swirling around inside my head.
  2. Make sure you can find whatever you do wind up making. Every idea you jot down or every few lines of code you write to solve a problem is an asset. In many cases the value of simply creating the asset is enough. You learned something! But by making a habit of taking inventory of those assets, you can build upon them much more directly.
  3. Find fellow-travelers. Having peers working towards a similar goal of turning an idea into reality can really help when you're in the doldrums of "oh no this will never work" as well as help manage your expectations. I'm a member of a slack community that is specifically for solo/small team contractors/entrepreneurs and it's been an incredible lifeline.
  4. Put it out there. Ideally where other people can stumble upon it. It's so easy to get caught up in tweaking and revising and making an idea perfect. Everyone has different standards of excellence for themselves; and this can be good! However, it can also be a blocker for getting something into production.

Hopefully this helps! Happy to answer follow up questions as well if this isn't what you're looking for!


I'll check out the book. That some really great advice by the way. I'm trying to find some fellow travellers as you said because I think I can't be accountable to myself yet. It's something I'm working on though. That was something I had no idea I needed. Although, I also wanted some technical help or advice specifically on things to look out for when deploying a project. Like you said, I can code and all that but what next? CI/CD? Maintenance? I'm completely blank


Hey Daniel,

Gotcha! I can provide a bit more help (I hope!)

Getting the app into other peoples hands requires you to get your app hosted on a service such as Google Cloud Compute, Heroku, Now, Amazon Web Services, or something else.

At the end of the day, the question I always want answered by my hosting provider for hobby-projects that I want people to use is is "How much of my time and attention will be spent wrangling the hosting and networking infrastructure?" Each of the above referenced deployment platforms have different answers for that depending on the resources the app needs.

  • Do I need a database, and if so do they provide one? Heroku has very affordable and very good managed Postgresql and Redis support; which places it in the lead for most of my one-off apps that rely on redis/postgresql.
  • Can it be hosted without a database (or with a database-as-a-service such as Firebase or similar?) In those cases, I tend to choose Now; as it has an incredibly simple and flexible deploy process.
  • Can it be hosted as a static site of HTML and CSS? In this instance, I really like Netlify; since it's essentially free and has some really powerful tools.
  • Do I want fine grained control of all aspects of the deployment? Then I want AWS or a Digital Ocean or a similar "batteries not (entirely) included" service.

There's a lot to be said for CI and Continuous Deployment, but I wouldn't place that on the critical path to getting your app into production. Ensuring your app is maintainable is another really deep and complex topic that also shouldn't get in the way of getting your app into the hands of users. If you really want to dive into that, there's a few things to think about:

Maintainable software is all about cost of change vs frequency of change. An app that requires very little changes beyond security patches has different maintenance needs than an app that is going through frequent updates in attempts to find product/market fit. I don't know if I've ever seen a set of strategies or tactics that are appropriate in every single situation, but here is what I would suggest in most cases:

  • A small suite of tests that exercise the happy-path end-to-end through the main user interface on the most critical features. I like using either selenium-webdriver for these or cypress.io
  • A place you can deploy your changes to before placing them into production that you can run your happy-path tests through the user-interface. This is often called a "staging" environment; but you may also consider a continuous integration service like CircleCI. It is a bit more time-consuming to configure and set up a Continuous Integration service, but it will pay itself off pretty quickly in time saved by not having to manually run the test suite.

These end-to-end tests that are executed through the user-interface are often very slow and can be fragile, unfortunately. So as your applications feature set expands and as the details become more nuanced, you may want to consider writing a suite of not-end-to-end-through-the-ui tests. For node and react and vue, the jest suite of tools is pretty accessible and easy of use. For ruby, I like rspec. I am not plugged-in enough in other languages to make concrete recommendations for them, however.

At the end of the day, maintainability is about understanding the risks to users and your business associated with making changes; and then taking steps to mitigate those risks. There are two books which I would recommend skimming or reading that help identify the risk areas and provide tangible tactics for uncovering and then mitigating those risks.

The first is lessons learned in software testing this is an oldie-but-a-goodie that I recommend all programmers read at least once. The second is agile testing, which provides a more team-oriented approach; and provides an alternative perspective that I found quite useful to balance out the slightly more dogmatic perspective from Lessons Learned in Software Testing.

I hope this is a bit more in line with what you're looking for!


P.s. I don't know if this platform supports direct messages, but if you want an invite to the afore-mentioned community of solo/small-group non-vc backed entrepreneurs send me a DM with your email either here or on the twitters.

Hi, first of all, thank you so much for all the gems you dropped and all the time you took out to clearly explain everything. Things are getting less and less cloudy and I can see what the way forward is and what decisions I'll have to make going forward. Never heard on Now, looks like pretty nice.

Also, thanks for the insight on testing and CI, its something I've never done. Really nice boiled down explanation.

I have DM'ed you about the Slack channel. Seems like a really cool community.