3 ms·

Nah, that's a perfectly reasonable pace to work at when you have: * Predefined explicit requirements (a tight spec). * No distractions. * No colleagues (i.e.

Nah, that's a perfectly reasonable pace to work at when you have: * Predefined explicit requirements (a tight spec). * No distractions. * No colleagues (i.e. you're working on a non-blocking single thread of execution). * Enthusiasm. * An unhealthy enjoyment of coding. I have worked at this pace and I'm sure many others have, but you need to have those pre-requisites (and they are RARE!). Bare in mind that if you're the only developer those commits probably haven't been tested and you're not worrying about damaging other people's code. Of course, you can't scale that model :-) Which btw is a fantastic real world analogy of why multi-threading can suck horrifically in some cases and why that parallel execution isn't always a good thing. NOTE: None of that takes a way from a totally awesome and fearless project to take on and complete (which I believe it is?).

afarrell 12y ago
Alternately, if you are going super-TDD on things and committing after every test, that pace is also reasonable under the conditions you list. I was at about that rate when I once tried to write a scheme interpreter in javascript in a weekend. I mostly succeeded, but ran out of time before getting done with some special forms.
keyle 12y ago
I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But 2.5 months?
- MagerValp 12y ago
  When I fall in love with a personal project, it happens to me too. The important factor is that I don't have anyone else to explain myself to, no one blocking my changes, I own the whole project from the bottom all the way to the top - it's basically just a giant positive feedback loop. I checked my stats and over the last six weeks I have dedicated my spare time (of which there has been more than usual, but I have a family and work 9-5) to my current project, and I've averaged 7 commits per day with 59308 lines added, 22903 deleted. I am feeling a little burnt out now, but fortunately the code is essentially done and all that's left is a little mop up and writing a blog post.
- Someone 12y ago
  If you have a list of hundreds of APIs to implement, you can easily skip the ones that are hard to (properly) implement in the first months. You also may choose to keep TODOs in your code that indicate 'minor' issues whose implementation is tricky, or that may already be correct, but 'just' need checking. For example, if a call that throws must not make any partial changes before throwing, you may whip out something that likely is correct, but postpone the actual verification of that fact.

afarrell 12y ago

Alternately, if you are going super-TDD on things and committing after every test, that pace is also reasonable under the conditions you list. I was at about that rate when I once tried to write a scheme interpreter in javascript in a weekend. I mostly succeeded, but ran out of time before getting done with some special forms.

keyle 12y ago

I don't know about you, but I could maybe keep that pace 3 days. Maybe 5. But 2.5 months?

MagerValp 12y ago
When I fall in love with a personal project, it happens to me too. The important factor is that I don't have anyone else to explain myself to, no one blocking my changes, I own the whole project from the bottom all the way to the top - it's basically just a giant positive feedback loop. I checked my stats and over the last six weeks I have dedicated my spare time (of which there has been more than usual, but I have a family and work 9-5) to my current project, and I've averaged 7 commits per day with 59308 lines added, 22903 deleted. I am feeling a little burnt out now, but fortunately the code is essentially done and all that's left is a little mop up and writing a blog post.
Someone 12y ago
If you have a list of hundreds of APIs to implement, you can easily skip the ones that are hard to (properly) implement in the first months. You also may choose to keep TODOs in your code that indicate 'minor' issues whose implementation is tricky, or that may already be correct, but 'just' need checking. For example, if a call that throws must not make any partial changes before throwing, you may whip out something that likely is correct, but postpone the actual verification of that fact.