The Don Stewart Method: write code every day, release a project every week | Hacker News Reader

The Don Stewart Method: write code every day, release a project every week

shimweasel.com

104 pointsionfish29 comments

“Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.” Kurt Vonnegut, Jr. quote

I love maintenance. But that's because I'm usually called in to build what should have been built in the first place.

So perhaps it's better to say that I like to make things work. And to me, working implies maintenance over time. Which itself implies that maintenance is possible and viable.

disagree with releasing a project every week. what makes a project worth using is continued maintenance, thorough tests, comprehensiveness, and battle-tested API; not just a few snippets of code you uploaded somewhere on a sunday.

Co-incidentally, a few months back I took up this vow. My stats were bad. I completed 2 small projects every month instead of 1 per week. But still the motivation levels were higher to do something better the in next schedule.

IMO, the size of the project being small is the key.

Building bigger stuff may sound nice, but not everyone can spend time on something for too long. It's not time as in hours or days. But time as in motivation. For me long development times, without releasing prototypes would be de-motivating. I love to show it off to people and hear them call it "cool" or atleast "good idea, but not usable". So then when you have a prototype in a week, you can make your next project as working towards v1.0 of the previous week's project.

Disclaimer: The site is down, so I haven't read the post. I read the title and the comments were interesting, which pushed me to post my experience.

Could you tell us more about your projects (to whatever level of detail you're comfortable)? I'm interested in exactly what scope you were able to pull off, and if any of them turned out profitable.

Thanks for asking. I have no problems talking about them.

All the opensource stuff listed here http://akash.im/code since Jan-2011, were according to the 1-per-week rule and none of them commercial. The arduino ruby gem was a little bit popular. When there's only 1 project in the month, you can assume that I've been working as a remote intern or have been doing my last freelance work :)

You can see that I clearly did not keep up with the 1-per-week expected results. Like I said, it was 2 per month in the end, but I still practice it. Along with it, since last month, I also make sure I read one-interesting-paper-a-month (was the Amazon Dynamo paper last month).

Yet to work on something this month. This month, it'll mostly be a scheme interpreter (R7RS-small spec draft#1) and a light-weight key-value store for fun and then (possibly) get a job as a remote full-timer at some startup (remote jobs are tough to get I guess).

Besides, what opensource stuff do you write? (just interested in stuff and trying to make friends to collaborate).

I think it's all about context. If you are working on a single large project, it's reasonable to treat a concrete completion of a a part of that project as a "release".

For example, I'm working on recoding my mogade project. It'll take a couple months for the hour or two I spend on it a day. However, this week I managed to "release" the leaderboard component of it.

This is a particular method of training: like a kata. Obviously you aren't going to be able to build every sort of application in a week, but if you take it on as training, then your big applications will go faster too.

Are the two mutually exclusive?

Only if you require that your projects be disjoint!

cached version - http://webcache.googleusercontent.com/search?q=cache:http://...

Somewhat related, Don's site: http://donsbot.wordpress.com/

code every day: writers say "write every day"

reduce scope: similar to "release early, release often", "iterate", it's always valuable to consider what is important and what is important (how can you tell? that a feature exists is more important than some quality of that existence: being easy-to-use, fast, efficient, correct for all cases, flexible, general, reliable - all those things you care about!), how can you perfect something before you know what's wrong with it? (e.g. maybe you misunderstood the problem).

I think releasing often is harder for commercial projects (who would pay for something incomplete? maybe they will if there's promise in the project, and they are really concerned about a problem it can solve: the value of code comes from user situations, not the code). I should try this. What's the worse that can happen? Nothing (i.e. it's ignored).

This attitude is why so many open-source projects are shit. That said, the habit of shipping often is a good one to have. But I think it's important to follow through and deliver something of quality every time you ship.

In no way is Don Stewart responsible for anything being shit.

I totally agree. My point is that misunderstood and/or misused this attitude can lead to trouble.

You can't make good shit without having made bad shit first. Were you always the programmer you are now?

just because you're trying to improve doesn't mean you have to share your bad code with the world.

there's nothing wrong with writing code and trying to improve, but there's something to be said for being a good editor and not releasing every keystroke you type. why release that which isn't good or useful?

> why release that which isn't good or useful?

Because we're not the best judge of what is good or useful. The person who chooses whether or not to use our code is the best judge.

It could be a good starting point for someone else to come along, polish it up, and release it

In the beginning validation is more important than maintenance. A one-week project is kind of the equivalent of a developed Lean landing page; it's just there to see if the idea will begin to stick.

author here. so, this was an object lesson in not running every single one of your services on a single ec2 micro instance. sorry about that.

Don't know anything about typo, but an alternative to throwing more hardware at it could be to optimize your site.

My story (redis/mongodb) peaked at the same time as yours, and my linode 1024 ($40/m), which also houses about 7 different projects, didn't go past 5% cpu usage.

Going with Disqus lets you outsource the only dynamic part of your blog post. This lets you set a long cache header, or at least to serve it from cached memory. Even if you don't outsource your comments, I bet caching the page for 2-3 minutes in memory would solve most of your problems.

Also, cache headers on your other assets wouldn't hurt. Nor would moving away from Apache. Sounds like a good weekend project :)

turns out i had typo configured to serve everything through rails, as well as having 10 instances running. not a happy combination.

my way: write code everyday, and write at least one test case every week, and release as needed.

release every week, problem: users are unable to learn and adjust, specially humans, and of course the others' codes.

The site appears to be down hard :(.

What types of projects are you talking about releasing every week? I can't imagine that they're terrible complex, are they?

The only problem with building too many things is you will not have the time to give every project a chance to succeed.

I disagree. Having more released projects increases the chances that at least one of them will succeed, or at least start to show some promise.

Though, it probably depends on the kinds of projects. And assuming, of course, that the quality is decent enough for a first iteration.

I think a better variation of this method is to break down your big projects into 1 week iterations for new features. It will feel like new projects each week, you'll be adding value to a product rather than starting fresh each week.

When you're not just hacking and instead trying to profit and run a business, you need to be constantly improving and iterating.

Reply on news.ycombinator.com