For many projects, I set up scripts for building (if necessary), running, deployment, etc. That way, when I return to it later I don't have to remember (or take the time to Google) the incantation to run some obscure framework that I haven't worked with in a few years. At the very least, I put some instructions in a readme.
I make a shell script to accompany all code; I basically think of it as an "executable README". A README or blog post often contains shell commands. So I just copy those into a script.
And more often than not I add my own tests and demos. Sometimes I write a main() program, if it's C. If it's JS, then add an HTML skeleton and a script that runs a web server to demo it (e.g. python -m SimleHTTPServer). If it's Python, install any deps necessary. And often you will want to run the same script with many parameters to fully demo it.
The idea is to basically prove to yourself that the code works, without necessarily having to understand everything about it. Then when you see it later, your brain knows you can go back to it. You won't feel lazy like "oh man I have to go back and find the web page I saw 3 months ago, download code, pore through instructions to figure out how to build it". That part is already done.
For example, here's a snippet I did when testing out cityhash. It's usually much messier/longer than this.
I think the assumption was that the code was not fully fleshed out and would require some form of glue code to provide an interface. Even fully fleshed out git repositories usually take a little setup of the environment / compile setting to get it running.
Not sure if that's what chubot meant, though.