5 ms·

Ship daily This is the advice I can give to anyone who has a side project. Get to the point where you can show something to the users and just start adding stu

by gerlv 10y ago

Ship daily This is the advice I can give to anyone who has a side project. Get to the point where you can show something to the users and just start adding stuff. Even if it's just two lines of code or changing the favicon - still worth it. In practice, it's harder to do than it sounds, but I've been doing it for some time and it's been going great. In reality, you won't have millions of users on day 1 no matter how great your product is. If you start small and keep adding stuff you will have more success. In fact, the biggest challenge for side projects is marketing and not the tech or infrastructure. However, it also depends on the goal - if you want to build the project that makes money it's completely different story to experimenting with tech. In the end, you get the experience. For example, a few years ago I managed to build an overengineered CDN product that compressed images on the fly (almost on the fly). I shipped the project and it even worked great for testers, but I didn't get to the point where it makes money, so I shut it down as with half unfinished features as it was taking too much time. While building it I managed to learn Go, improve my AWS skills, plus some other tricks. Now it sounds like a great investment even though I feel that I haven't completed the project.

poorman 10y ago
Ship daily is the best advice.
janklimo 10y ago
Excellent advice, 100% agree
borplk 10y ago
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.
majewsky 10y ago
"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.)
- overcast 10y ago
  Well to be fair, this is mostly what we're all discussing on here. Web Applications.
  - 0x54MUR41 10y ago
    Any advice for non-web applications? Building a library, desktop application, and soon.
    - jakedahn 10y ago
      ship weekly!
    - GvS 10y ago
      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.
    - tqkxzugoaupvwqr 10y ago
      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.
      - chriswarbo 10y ago
        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.
freebs 10y ago
"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.
throwaway743824 10y ago
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.
skdotdan 10y ago
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.
sodapopcan 10y ago
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).
bodecker 10y ago
> 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.

by gerlv 10y ago

poorman 10y ago

Ship daily is the best advice.

janklimo 10y ago

Excellent advice, 100% agree

borplk 10y ago

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.

majewsky 10y ago

"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.)

overcast 10y ago
Well to be fair, this is mostly what we're all discussing on here. Web Applications.
- 0x54MUR41 10y ago
  Any advice for non-web applications? Building a library, desktop application, and soon.
  - jakedahn 10y ago
    ship weekly!
  - GvS 10y ago
    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.
  - tqkxzugoaupvwqr 10y ago
    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.
    - chriswarbo 10y ago
      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.

freebs 10y ago

"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.

throwaway743824 10y ago

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.

skdotdan 10y ago

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.

sodapopcan 10y ago

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).

bodecker 10y ago

> 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.