Shared publicly  - 
 
Coding tip: Leave your code in a broken state

Here's a little practice I do. Before I take a break, or before I finish for the day, I like to leave code broken. As in, cannot compile. And with a note indicating what needs to be done next. This makes it easy to get into coding mode when you start again, because you have a direct goal instead of having to do a big planning session in your head.

The idea came from Richard Gabriel's "Patterns of Software", where he explains he always leaves his writing in the middle of a paragraph. I've done that quite often too, since reading that.
200
81
Amira Adel's profile photoEmma Davis's profile photoMauricio Sánchez's profile photoMark Law's profile photo
55 comments
 
And the extreme version....

leave a database deleting call in your code when you are done for the day. You'll remember where it was during test... or demo. :)
 
Hah that's putting a lot of faith in the Demo Gods.
 
This is brilliant. In writing, they have a very similar thing, where you stop your writing mid-sentence, at a point where you're still in the flow. Result: no writer's block.
 
+Filip Hráček Yep that was what Richard Gabriel was talking about (he's a poet+writer as well as coder). IIRC he didn't actually mention this coding technique, I think I just ended up gravitating to it after doing it with writing.
 
Mine is just "XXX HERE". A memory jogger makes sense, I should try that! 
 
The only problem with this is it means you either 1) leave work uncommitted (and therefore vulnerable to loss) or 2) are committing incomplete work (which can break tooling or cause confusion--e.g., when someone branches your incomplete code)
 
+Paddy Foran 1) is covered by your backups. 2) is covered by a "WIP" commit or branch, or even the git stash. These aren't problems. 
 
Nice tip. Always easy to pick back up when it is broken, but hadn't considered doing it on purpose. :)
 
+Paddy Foran +Robert Norris 
Using `git` as source control and following a strategy similar to Atlassian's "simple git workflow" I don't see committing broken code to be a problem in a DVCS. (http://blogs.atlassian.com/2014/01/simple-git-workflow-simple/)

My current workflow requires rebasing my WIP branches on top of the release branch before merging to release. (So all merges to release are fast-forward.)

Since my WIP branch is going to be rebased anyways that automatically rules out sharing my WIP branch with colleagues.
In addition I can squash the "broken" commit w/ the next morning's commit that would fix it so that such a broken commit doesn't end up on the release branch :)
 
I always use #warning  and #error  before leaving, a friend of mine recommended leaving a broken test too !
 
I agree with +Robert Norris in that "git stash" is really all you need. Your code doesn't vanish into the ether, nor does it get committed to the repo. When you're ready to start again, just pop the stash and go on with your business.
 
If I must leave a feature/fix not completed, i'll write a comment without // at the start that describes where I'm at in the implementation.

The reason I do this is so that when I come back to it I attempt to compile, see the error and after reading the comment I'm magically up to speed. My mind is at the same place now as it was before I stashed the code. 
 
Invoking Sod's Law of Git, I personally avoid doing anything involving stashing and branching unless I absolutely have to. 
 
$ git stash list | wc -l
76

I am not for a moment suggesting this is a good thing ;)
 
If it works for you, that's fine. But with my git-fu, anything that goes mildly wrong ends up in a mv, some tears, and a fresh git clone followed by more mvs.
 
I do this all the time. Even the ide helps you find where to start working from. I don't break a working code. I just type something that won't compile.
 
We use a "central" repository for our "official" repos, so a WIP branch should never get pushed there. This in combination with squashing commits before a rebase or merge should address most of my concerns about this coding strategy.

That said, I still prefer not to use the technique as a general rule.
 
I thought I was the only one with this nasty habit.
Translate
 
I think the key is: the note about what to do next
 
Interesting. I see the point that you mentally want to complete it asap. Don't you think about the incomplete work at different times though?
 
+Paddy Foran I think it's easy to avoid losing work.  Near the end of the day, you have completed an item.  You commit it and push it -- it's done.  Then you start with something new.  After a short while, you add the "continue here" indicator.  Then if something bad happens, you have only lost the "short while" and the "continue here" indicator.  Doesn't sound too bad.
 
And leave those squigly red lines in my code? OCD won't allow..
 
+Deepak Kapoor I thought the same thing! I've been doing this ever since I started coding to "mind hack" me back into the flow. When I'd tell others of this trick, I'd get a "you must be crazy" look. Nice knowing I'm not alone.
 
yep, a miserable crash is more honest than a program that seems to work but fails to match the requirements
 
A small improvement is to leave a failing unit test. Your tests will fail but your code isn't actually broken. You also are probably leaving a little bit more intent about what you were trying to do.
 
I usually write "THIS IS WHERE I STOPPED", a note about what I should do next, and then a silly message to my future self.
 
Interesting... I've definitely found that it is easier to fix bugs in the morning. And I do often find it easier to pick up writing mid-sentance too!
 
I've done this with tests.  Write a failing test and then take a break.  Come back and you have instant context to the first thing you should do.  Can be done with unit tests or acceptance tests.
 
I used to leave an
#error You were doing X
But now I check in so often that its rare that I leave something half finished, but even when I do, it's easy enough to diff against source control to figure out exactly where I was.
 
I hate this. Makes me restless at the end of the day. The comment thing makes it better, but I prefer quitting my day at a moment with relative peace of mind over half-sentence. Gives me room to think about the next big thing as well instead of frustrating over a bug.

Edit: doing it with tests sounds like a better idea.
 
I leave a broken test, not broken code. You just have to run the test suit the morning and you know what has to be done.
 
So this is why we see more and more buggy code every coming day.
 
I also leave a broken test. I commit it as [Ignore("In Progress")] and then remove that Ignore for my local code and walk away.

No one saying leave a broken test has explained that they are TDDing and what they mean is...  

I write the next test, and don't do (or even think about) the implementation at all, ie only doing the R in the RGR (Red Green Refactor) cycle.  So when you come back and pickup, you can start with the Green in RGR which is far easier than finding where to put the next Red.
 
I'll nice idea shall try sometime 
 
I always like to leave on a red test, for exactly the same reasons
 
Heh, that's a great practice, I'll start doing so too.
 
Similar to this, during coding sessions, I give my breaks just after I have found a bug in the code. This makes me turn back to work sooner than normal. If I were forcing the limits late at night, I sleep less than the normal to immediately fix the bug and see the results. :)
 
This could also help prevent the "just one more thing" behavior pattern that can lead to late nights in front of the computer monitor.
 
It would put me in a really bad mood for the evening, which my family would have to endure.
 
+Andre Tannus Awesome, I've always done this, wasn't sure if it was common place. I just start putting notes and to dos in my code so it won't run. Then I have  a good starting place.
 
It is understandable during breaks, but I wouldn't be able to sleep at night knowing code is broken :/, I guess it needs a bit of practice. 
 
If you don't want to leave broken code, write an unfulfilled test.  That way you're putting no one in danger, but your development cycle is held at a specific, actionable roadblock.

"Go home red."
 
+Kai Grossjohann I have a rule for myself: don't ever commit at the end of the day (you will leave soon), but only if what you are changing is already broken on the repo
Lup Ma
 
what percentage of programmers leave their incomplete code partially working? I would be surprise if less than 90% of them don't leave with compile errors at end of day.
 
+Lup Ma Really? I didn't think it was such a common practice tbh. As with many commenters above, there's an opposite tendencey to want to complete the job.
Add a comment...