"Ship daily" only works with web applications. If I were to ship my applications daily (or rather: each day where there occur changes), I would just be compiling packages all the time. (Before you ask: This cannot be automated further. I will not give my GPG key to some automation to sign the packages with.)

I automate my deploy process by passing my password as an argument to my automation script. maybe you can try figuring something similar out.

Because yeah, by hand, even deploying my webapp would take a couple hours. it took me maybe 8hrs of labor to setup my deploy script but given as I've deployed maybe 50 times so far it's paid off.

Hours? Could you elaborate a bit what exactly you mean with "by hand"? I'm probably not thinking manually enough, I can't come up with what could possibly that time intensive about any deployment.

"By Hand" I mean running each command required to deploy line-by-line, at the command line.

For me, that would be:

1) provision VM

2) configure the new VM (security hardening, install utils)

3) download app from git and configure it

4) take image of vm

5) install new image into my autoscaler

6) hot-replace live instances of previous version with new version.

doing each of those commands by hand and waiting for each to complete could easily take 1.5 or 2 hours of work. I did it by hand the first couple times but once I figured out my workflow I automated it (bash script) as fast as possible.

I spent a couple days looking into ansible, but as I have a very specific need I didn't want to spend 2+ weeks adding another chunk of "technical debt" to my product.

I already have a Makefile to automate most of the steps, but you still need to write changelogs, push a signed tag to Github, update the package specs and create and push all the repos.

Surely you can give it to another box in your house that tries to build on commit all day?

You can ship daily even if your process is not automated. I usually automate building and deployment later in an application's life -- not at the beginning.

You can automate all steps for building an application but the signing to make your life easier. You can also automate things locally if you're worried about what you're signing.

The bottom line is that this applies to all apps (though your users might be irritated if they need to keep downloading updates).

But trying to automate everything is why I never get shit done.

I think the basic idea is get it running and keep it running making incremental improvements. Whether your project is in an interpreted language or takes a day to build only changes the pace. I've worked on both time scales and focusing on getting something basic running then adding to it has worked for me.

Well to be fair, this is mostly what we're all discussing on here. Web Applications.

Any advice for non-web applications? Building a library, desktop application, and soon.

When I was working on a game, we created a Patreon and promised new demo to backers every month. It's very motivating - you have clear deadline, money and feedback.

Web apps have the advantage that users don't have to actively update anything. One page load and they use the updated product.

Receiving daily updates for desktop apps would suck because it typically requires the app to quit and start again. A good compromise would be updates every four weeks. At the same time you as a developer always leave your app in a state were you could push an update anytime. So you still work incrementally in daily units of work.

Daily updates for libraries … if it's only publicly available code, I don't see a reason not to push daily. Anyone interested can check the commit logs. For compiled binaries on the other hand I can see update fatigue for users (other developers). Once a month or longer seems fine.

In the end, push regularly (daily, weekly, monthly, whatever fits you) without annoying your users by spamming them with updates, while at the same time reduce work units to a size that does not feel overwhelming.

You could have a "nightly" release, which is updated as often as you like, alongside the "real" versions. Those who want the nightly can have it, those who want steady, stable releases can avoid it.

Push to your own local repo daily. Push to the actual users less frequently. Weekly, monthly, 3 months, just pick something reasonable and -stick to it-.

We have a desktop app and build several times a week sometimes.

ship weekly!

"the biggest challenge for side projects is marketing"

This is so true. I, as well as a few others I know, have built some pretty cool things that have never gotten the attention they deserve.

I've built a good base for mplyees in about 4 months. Marketing it and getting it out there will take a lot more time unless I get lucky.

Don't agree. I think that is like saying you can become a professional athlete by just working out everyday. We mostly know what works. It's comradely, career and cash. Most things worth doing isn't going to result in much professional progress or money in the beginning, so working with and showing things for your community is generally the most important. That's what driving every sports team, music group, enthusiast etc. in the beginning. You still of course need the time, knowledge and motivation to do something.

Shipping can be the result of, or one way, to do the right things. But if you look at projects on Github it's usually not a lack of "shipping daily" so much as a lack of packaging it as something useful. Often you see daily commits until the motivation wears off and the project stops. But the software is still buggy, there's no screenshots, it's not straight forward how to build it, lacks documentation etc. They haven't made it into something that is easy for other people to appreciate, so they don't get much positive feedback.

> Ship daily

This is great advice, but when it's not possible to ship daily, I find that even just committing once a day is a good micro-goal to keep projects moving. The GitHub streaks feature can help motivate you too.

In terms of incomplete projects, "Ship daily" could apply to shipping something that sorta works to your non-tech business partners, pre-launch. If you don't have business partners then use your friends or, heck, even yer mom. Just show daily progress to someone (anyone) else. Doesn't have to be your users (which you may not even have yet).

100% agreed. I used to think that I "understood" this. But as you said it's much harder to do in practice. To anyone else who thinks "oh yeah I know all about that" without having actually done it, don't get so self-confident until you pull it off.

Once you have a working project, it's OK. But what until then? At first, you will have to invest a lot of time to have the base running.

Ship daily is the best advice.

Excellent advice, 100% agree