Hacker News Reader

Comment by georgemcbay | Hacker News Reader

I practice a variant of this where I have some small, well-defined task to do at the beginning of the next day to ease into the flow of things, but the thought of leaving the code in a known uncompilable state (even if just my local copy of it) would just make me feel uneasy until I've gone and fixed it.

View on HN

I'm with George on this one. I like to finish off a day with the atomic module/query/code I'm working on working nicely (optimized or not; it needs to function). Somehow, in my mind, it's like closing the trailing bracket. I like to finish the day 'clean'.

Sure, this might cause the next day to be a slower start, but you have to balance this out against the peace of mind you get from leaving the office and having no worry about. That is worth a lot (and might cause me to sleep better and be more productive the next day?)

It's like doing the dinner dishes before going to bed so you don't have to wake up to them (or not enjoying the rest of the evening because you think you'll have to do them in the morning).

Like George, I'll often plan my next day ahead so that I know what I'm going to do to hit the ground running (Optimize the code I wrote last night, add input error correction, cough add comments or tighten up the format ...)

All these things aside. Do what works for you!

As the OP, I get that mentality and have it too. One could call it an extremely mild and very normal kind of OCD we all have. For that reason, there are times (or moods) when I do the completion thing.

But because of the motivation benefits, I also try to bend my brain to focus more on the checkin as the snapshot that must be pristine in any time slice, and the editor as just a flowing set of arbitrary frames between checkins.

Personally I try to make the code work by the end of the day as kind of a motivational thing. (Like you described above.)

Also, to be pedantic, I think it would actually be a mild kind of OCPD.

I notice a definite sense of satisfaction if I finish the day with things working as opposed to not working (especially if I have been working on that feature for more than a day). Though the scope of my tasks varies so much it is difficult to "try and make the code work by the end of the day". I don't think I ever plan anything that I think should take more than a day, but more often than not downloading a new library and configuring it to work should be simple and takes as much time as any coding. (Still it will likely be quicker than me writing all the functionality and tests myself).

>I practice a variant of this where I have some small, well-defined task to do at the beginning of the next day

I start with some large task, with the intention of getting fully absorbed and in the zone. Then get interrupted to fix an excel upload error - users who insist on using excel also seem to be the ones who are incapable of reading error messages. Then someone asks me a question about something. Turns out a 2 line bug/change needs fixed. Might as well do that before I get into the zone. "Can you get a list of all projects with blah, blah". Might as well do that before I get in the zone as well.

Before I know the day is gone and I have achieved nothing satisfying.

What I like about leaving it uncompilable is that way, I know I won't forget to finish that unit of work. Sometimes I'll leave it uncompilable, sometimes I'll just leave my self a little note with what I've done, and what I have left to do.

Agreed in this regard. Whenever I have to leave in the computer before I have the chance to finish something, I usually just make a comment with the string `WIP` in it:

    /* WIP: make sure to initialize buffer by calling function foo() */

... the idea is that I'll remember that I left my code in an unfinished state, search for the `WIP`, get my bearings and then go off. Of course, that's easy to forget -- but impossible to forget if your WIP note is uncompilable.

I'm more in this latter camp. I'll perhaps leave it completely compilable, but with logic incomplete, e.g. a stub function that always returns true. My task the next day is easy, then; it starts as finishing the stub, and as I do that, the rest starts flowing.

I've had days where I start by just running the code end to end and seeing what's egregiously broken, but I find this puts me in whack-a-mole mode the entire day and it's extremely tiring. Though, I do feel like Sherlock doing it.

Reply on news.ycombinator.com