I suspect depends a bit on what you're doing... but for me and the things I tend to work on, I tend to get scared by "big" projects that won't be "done" until s

I suspect depends a bit on what you're doing... but for me and the things I tend to work on, I tend to get scared by "big" projects that won't be "done" until some far off point in the future after loads of work, so my motivation is kept up by: - Getting something "out there" + "working" as soon as possible. Even if _really_ rough, buggy, ugly, can't scale, only works in 1 case, needs a code change to work in any other etc... - Keep it working with every change - Every change is small. Potentially, teeny-tiny Examples: - Forking a project from GitHub. Have something working straight away! I've done a few project that literally have no lines of code in common with the original, except perhaps the license [so not appropriate for all projects] - Releasing a website with whatever it is really early. Even if unstyled, no documentation, but does a tiny sliver of what you want it to do eventually. Then iterate, releasing the new version every single change. - I think some people suggest avoiding tests in early stages of projects, but for me... some high-level tests on the "public facing" behaviour really helps give me the feeling that it's working as changes are made, and I'm never stepping backwards. Things to avoid: - Long running feature branches where lots of things are broken - Refactoring without some sort of externally-facing feature in mind - Low level tests of implementation details - Working too much on "behind the scenes" stuff. You probably don't need a really fancy CI system that supports 100 developers deploying every day... [But: enough of a system for _you_ to release often is good]