Coding tip: Leave your code in a broken state
plus.google.com
plus.google.com
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.
If you leave your code in a broken state, it will take some practice, but the idea is that it will liberate you from having to try to carry the cognitive load, because you have a natural reminder.
Also, if you are juggling 30 things, you're likely not writing your code well as a principle; limiting your work in progress will allow your "breaking" to be limited to a specific function/algorithm/task/unit test (or whatever).
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.
Then, just mark your commits with WIP.
So I assume he means code that he hasn't checked in yet, but might do when he gets back if he can't remember what was doing and it compiles.
Personally, I like to check in broken code late on that Friday evening before I take 2 weeks holiday. Unfortunately, these days with these new fangled source control systems you can't check it out again and keep it locked while you are away.
I have no problem with broken commits locally, but I don't want to see those in a public tree. Merge or rebase with squashing, please.
Agreed, but that's not what you should do.
Many times I have finished the day with a working commit and push, then I add a compiler-error "todo ..." line to the code locally so that it's clear where I have to resume tomorrow.
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!
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.
Also, to be pedantic, I think it would actually be a mild kind of OCPD.
/* WIP: make sure to initialize buffer by calling function foo() */
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.
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.
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."
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().
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...
so it now compiles (but will at least throw a not-implemented error).
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.
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).
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.
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).
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
And for your information...I do have a test, but it doesn't fail, it returns positive. I search for "NotImplementedException()".
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.
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?
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.
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.
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...
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.
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.
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.
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.