
Coding tip: Leave your code in a broken state - mmahemoff
https://plus.google.com/u/0/+MichaelMahemoff/posts/LQUV9bBd8dL
======
crazygringo
I understand the rationale, but I see a problem with this, and a better
system.

The problem is that you might be juggling 30 things in your head while writing
that code. When you come back tomorrow, you have to start remembering them
all, and you're more likely to forget one of them, and spend time debugging
later to fix the resulting lesser-quality code.

The better system (in my opinion) is to finish your code for the day, it will
leave you feeling good and accomplished. But before you leave, _write a to-do
list for tomorrow 's code, with detailed notes_, while the code is still all
fresh in your head. Then you can go home and not think about work, and truly
relax, and know you'll get to the office tomorrow knowing exactly what you
need to start with, and won't be forgetting anything important.

And I'm not sure the analogy with fiction writing is useful -- writer's can
suffer from writer's block, so leaving a paragraph can help jump-start the
creative part. I've never heard of programmers suffering from coder's block.

~~~
barrkel
There are two separate problems.

One is getting something easy to gnaw on, to get into flow, to remove the
inclination to procrastinate.

The other is picking up where you left off.

------
wikwocket
This is all well and good, but if you check in intentionally broken code, or
if you _fail_ to check in your code _because_ it is intentionally broken, it
will drive me bananas, and I will look for you, and I will _find_ you.

~~~
krupan
Have you heard of distributed revision control? Local check-ins are awesome.

~~~
pipeep
Unfortunately, that doesn't keep some idiots from pushing broken code to
`origin master`.

~~~
kodablah
Why can they do so on a mature project? Why can they not only push to their
branch, have the repo have commit/push hooks for fast linting, have CI builds
for each commit, and only merge into master when comfortable (e.g. after QA)?
And if it's a fairly new project and they're working in master directly,
what's the harm of broken code?

------
georgemcbay
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.

~~~
bcbrown
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.

~~~
jlees
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.

------
danso
If I have TDD set up...I'll add a breaking test...it's a little more verbose,
but the fact that everything else passes gives me a nice sanity test when I
revisit the code. And of course, unless I totally bunked the test, I can
actually keep the test as part of the suite (yes yes, I'm aware that tests
themselves become legacy code that demands maintenance and that nothing comes
for free)

~~~
gbog
I call bs on this tests have a cost mantra. They may have value, i.e. be
useful, and then it is ok to spent a few minutes fixing them if needed. But if
fixing them is costlier than their expected value, then just skip them.

I see many reasoning for not writing tests everywhere and very few reasons are
acceptable. In some cases in some non mockable languages it is really too
hard, this reason is ok. The only other good reason to not write tests is "I
don't want to."

------
12343q5daasdf
My brother works in publishing and came very close to ruining a 6 figure order
of calendars because he put his personal birthday on them to test his proof
readers.

Don't break your code to remind yourself where to start.

Instead, leave a failing unit test. Not only does it tell you were to start
but you also told yourself what you were doing ShouldDoThisNext().

------
jbert
I like to use a syntax error if I'm implemented in the middle of a number of
related changes. As long as I follow basic hygiene of running/compiling the
code before committing, I'll be reminded of where I was.

I typically use '...' for this, since it is/was invalid syntax in pretty much
all languages.

Then perl went and added it as a placeholder...

[http://search.cpan.org/~jesse/perl-5.12.0/pod/perlop.pod#Yad...](http://search.cpan.org/~jesse/perl-5.12.0/pod/perlop.pod#Yada_Yada_Operator)

so it now compiles (but will at least throw a not-implemented error).

------
steveh73
I believe this tip originated from writers. By leaving your thoughts
incomplete, but with an end in mind, you can begin writing the next day and
get into the flow immediately.

------
sirmarksalot
I think this is backwards from what works for me. For me, the difficulty is
always in starting something new. It doesn't matter what time of day it
happens, if I finish something, and I'm proud of it, I have almost zero
motivation to get to work on the next thing.

I get that you're trying to prevent morning lethargy from coinciding with
decision avoidance, but I think I have a better system. Don't end the day just
before you finish. End the day just after you start, just at the part where it
starts getting good. The next morning, you'll be excited to come in, because
you know what to try next.

You can ride that high into your morning standup, confidently say "this is
what I will do today," and ideally a half hour before quitting time, you'll
finish what you're working on, and while you might be tempted to say "done
enough, time to go home," you won't do that. Instead, start on the next thing.
Spend 30 minutes figuring through it. Figure out an approach, write it in your
journal, and then go home. Start implementing again tomorrow, and repeat the
process.

~~~
philbarr
I like the idea, but I find it really difficult to actually stop when I'm "in
the zone". I tend to recognise when I am and treasure those moments of hyper-
productivity to get lots done.

I use the technique in the article and have for a while. I find that the
relatively easy task of fixing a compile error will gently lead me back into
coding.

I expect it's a personal thing, though.

As an aside, I like to leave a bunch of TODOs lying around in code for things
like documentation, so I can come back and do that boring stuff when I'm
feeling brain dead. I never use TODO for something important that needs to be
done because chances are it won't! (I don't know why, I think it's just
something about the nature of TODO).

------
krstck
I won't leave code intentionally _broken_ , but I always save some small
trivial task for the next morning to immediately get into the swing of things.
I really like being able to come in first thing and get something done, even
if it's small. If the first thing I have to do requires a lot of deep
thinking, I'm likely to procrastinate.

~~~
tetrep
>If the first thing I have to do requires a lot of deep thinking...

That's why I try to think about what I have to think about, the night before.
E.G. Try to enumerate all possible solutions/causes to a problem (most likely
to least likely) to give yourself something to just dive into the next
morning.

~~~
andrewfong
Does this affect your sleep? I occasionally think about tomorrow before I go
to sleep, and I find that my sleep that night was not as restful as it could
have been.

~~~
collyw
I noticed this recently. I started my job 3 years ago, building a database
system from scratch for my organization. Learning Django, and building
something new sparked my interest in coding again.

3 years on, it is now mainly maintenance programming, actually fixing stupid
excel upload errors (I have argued for hours that we should not be using such
an inappropriate method for uploading data, but important people insist).

Anyway, the point is, I don't usually bring problems to my sleep with me (I
have outside interests). But recently I was asked to add a new feature. It
turned out to be a complex problem - along the lines of the P versus NP
problem. Now this got me thinking. In my sleep. I did have strange code like
dreams (not had that since studying at university). I wouldn't say I sleep
badly, more with a sense of excitement (excitement may not be the exact word,
but something similar).

------
moheeb
In my C# code I like to leave a " _throw new NotImplementedException();_ "
behind if I can't finish something. I'm with some of the other posters though
in that I like to leave stuff working at the end of the day.

~~~
kristiandupont
Do you then add a test that fails from this exception?

Otherwise, you are simply leaving a bug that is only discovered at run-time
rather than one that is discovered at compile time. Doesn't seem like an
improvement to me

~~~
moheeb
Seems like an improvement to me! And I'm the one doing it, so I'd know.

And for your information...I do have a test, but it doesn't fail, it returns
positive. I search for " _NotImplementedException()_ ".

------
slashnull
Better yet:

Vim can save a session via :mksession file_name.vim which can then be restored
by vim -S file_name.vim

It's nice when I have to quit programming while in the middle of task where
I'm drowned in context spread across multiple tabs and splits. I'm not trying
to spread the Vim gospel; this feature is nothing really extraodinary so I
guess it's available in other editors/IDEs as well.

Overall this is roughly equivalent to putting your machine to sleep mode while
your edition session is still on.

My personal opinion is that both methods make OP's look pretty primitive and
hacky.

~~~
collyw
I am an IDE (Aptana / Eclipse) user.

VIM / Emacs sound like they have so many cool features. Can someone not build
a decent interface that doesn't rely on remembering cryptic commands for all
of the features?

To people who know both. Would it be worth me learning either Vim / Emacs in
this day and age? Eclipse has a lot of features and plugins. And way more
intuitive interface (I use git through it, without having really learned all
the syntax and options, it does most of what I want).

Vim / Emacs seems like a lot of learning (that I could spend on possibly more
useful things). Opinions?

------
ams6110
Similar but more general advice I got early in my career, was to not try to
leave work with everything in a tidy state. If you are hunting a bug, for
example, you'll be tempted to stay until you've fixed it, or at least
understand it. Don't do that. Go home. Your mind will continue to work on the
problem subconsciously and you may very well wake up the next morning with new
insights.

------
duffdevice
I believe Ernest Hemingway invented this technique (or the writing equivalent,
on which this is based).

------
yaongi
My code is always in a broken state...

~~~
gfodor
I know you're joking, but I've heard this 'tip' before and am puzzled because
there is always a backlog in my head of "shit that is fucked up" on any given
project. There doesn't seem to be any need to throw some made-up bug on top of
that list for me to have something to start fixing if nothing else comes to
mind.

------
gesman
There is also unspoken benefit of this - training yourself that _IT IS OK_ to
leave code in broken state. An feel good about it. Too many developers kill
themselves by trying to end the day in a perfect code state. And it has
nothing to do with happiness :)

------
quicksilver03
As long as this stays local, or on a secluded branch, why not... but if you
push a broken commit to master then you fix it immediately. And there's no
place in a team for someone who intentionally pushes broken commits to master.

------
vinceguidry
TDD.

When you get to work, run your tests. All green? Great! Write some more tests
that fail then make 'em green again. Failing? Even better, now you have
something to fix.

TDD made programming 5x more fun for me.

------
cyphax
I actually do this sometimes when it's near the end of the day and I know the
problem at hand might cost a few hours. I'll write a comment but not in a code
comment, exactly like the article suggests.

Funny enough, it never had to serve this exact purpose and had I written the
comment so that it wouldn't prevent a build, I would've still continued where
I left off. I think (but am not sure) the fact that I wrote it down at the end
of the day makes sure I don't forget.

------
jheriko
my gut reaction here is to cringe and generally be revolted.

with some thought it seems like an okay idea... it gives you a place to start
in the morning that is easy and helps you overcome the 'start working' hurdle
at the beginning of the day.

with more thought it reveals bigger problems in methodology which enable this
to be practical imo. ranging from not having a plan through to not having
discipline.

imo you should be able to leave things in 'a convenient state' which may be
broken or not, and then pick it back up... as long as you are working to a
plan, and the code is sufficiently clean and friendly then you should be able
to approach /someone elses unfinished work regardless as to what state it is
in and start working immediately/.

On the other hand I know that most people struggle with reading code... maybe
this is part of the problem more than anything else?

The context switch involves some dallying around reading code and making sense
of it in the morning - I don't see how leaving things broken removes this.
Rather this seems like a prescribed way to force yourself to leave at least
the bare minimum documentation you should to do your job as a programmer with
a little more efficiency.

Write things down, don't trust your memory, its easy to think when you are in
your late teens or twenties that its an immutable record and highly reliable -
especially if you have been inflicted with an especially good memory - the
truth is that its a bug riddled system where data constantly degrades. Work
around it like you would any other faulty system and keep backups too...

------
sbirksted
I totally agree with this. Leaving things working... partially, is the best
way to forget tomorrow and ship half finished code with tomorrow's
distractions.

I also find this is a good strategy to step away from something and renew your
perspective on the solution after a good break. Especially at the end of the
day. That's worst the 'I just want to get this working by poking around, not
writing unit tests' leave here in a rush, trap time.

------
systematical
Don't do this. Try and leave you code working at the end of the day. What I do
instead is leave a bunch of @todo comments in my code when I'm done
programming. This does two things: It gives me some obvious starting points
tomorrow and leaves those tasks fresh in my mind as I go through out the rest
of my day. I often come up with really great solutions just from writing a
very simple @todo sentence.

------
nickbauman
I've been doing this for years. If it's a compiled language, I prefer a
compile error. It's easy and I might as well get SOME value for the compiler,
as specious as it may be. If it isn't, I stick to a failing unit test that was
asserting the last unit of work I was working on. Helps me get into the "zone"
faster and I feel less anxious about getting started in the morning.

------
easy_rider
I usually do this end of the day, just throw in some pseudo code for what I
want to accomplish the next day. In the case of Rails I still have to learn
about everything, so it is really easy to adhere to this practice :)

However it is a bit conflicting, I don't necessarily want to commit this
stuff, but I always want to push my work in case of disaster.

------
w4
This is great advice, and something I do all the time with #warning and #error
(works with both Clang or GCC, not sure about other compilers) for partially
completed methods or to-dos. When I'm mid-project I'll have "#warning TODO:
Fix this" and the like all over the place.

------
krapp
I keep a notes.txt and errant random files in a folder hidden in .gitignore
and keep that open in sublime text, or else just leave myself a note in a
comment at the top of the main source file. It's easy enough to break my stuff
as it is.

------
jcutrell
Along the same lines,

Write a function that captures your TODO's, and set an urgency level. If the
urgency is high, make it a fatal error (or whatever in your given language).

This is a great way to make TODOs much more functional and actionable.

------
jqm
What a great idea! I'm going to try it.

All too often I dither around for an extended time when starting. Then, when
finally started, everything just flows.

Maybe this will help reduce dither time.

------
collyw
Pen and notebook (paper type, not a knee burning laptop), with a checklist of
things to do tomorrow works for me. q

------
general_failure
I have to try this out to

