Hacker News Reader

Comment by keyle | Hacker News Reader

1600 commits by one dude? 700 commits in January? An average of 23 commits a day? 12,000 lines written and 7,000 removed just that month. An average of 640 commits per month.

I may be naive. Am I missing something or this guy is an incredible code machine?

View on HN

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

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

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.

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.

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.

Just turn off twitter and Facebook and you can reach that kind of level.

And Hacker News, of course. Otherwise you'll be here every 5 minutes reading the comments and... DAMN!

Implementing vm opcodes is not what you'd call demanding. Look at the jvm spec, a lot of opcodes are really very similar. Pop, pop, binary op, push.

Reply on news.ycombinator.com