Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a laptop and bunch of 5 min segments throughout my day. I used to think this was simply too short a time to do 'anything'. Though with a little practice and a few minor behavioral changes (like unplugging) I have realized that I can get something done in each segment. So now I am reaching out to all you quick-draw-programmers out there for more tips that will let me get something done in the shortest time segment.
What did you do?
How long do you work?
Here's an idea: when you have larger chunks of time, write some unit tests for functionality you plan to implement. Then, when you have a 5 minute increment, choose a test and write code to satisfy it. This way you aren't spending any of your 5 minutes deciding what to work on, you already did that and documented it in the form of unit tests.
And hey, you get TDD and test coverage for free. Bonus.
Adopt Test Driven Development.
A big cost in task switching is figuring out where you were last.
If you always write the test before you start, it's a no-brainer to pick up where you left off. Run the tests, whatever fails, that's what you do next.
Believe it or not, there's a website called Five Minute Videos, and they have a Software section.
http://www.5min.com/Category/Tech/Software
Read through random posts on SO and learn something new :-)
Boring back story: I was in a similar situation when I had to look after my ten year old sis for a day. While we were waiting for a friend to come over I really wanted to get some features done on a personal project.
I found that playing a ~20 second acoustic bit of music and clearing my head before I wrote anything was really useful, along with spending the first 5 minutes making a threadbare list of things I wanted to complete.
Massive use of TODOs. When you start on a new class (I'm a java programmer), write all the method names, and TODOs instead of code, this usually takes (the infamous) five minutes. Then, when you have your next five, start with chosing a random TODO, and write the code. I prefer doing them in a random order, but you might find that writing all the TODOs in a method first works better, just try:)
As I'm not a full-time programmer, but a student and hobby-hacker, most of my programming is done at home, the library or a cafe. I'll complete one or two TODOs, and surf the web a bit, watch people walking by, order a new coffee or get some snacks from the kitchen.
This propably won't work in a production-setting, but for personal projects it's king!
Learn all the keyboard shortcut keys.
I also sometimes program in short bursts, like while waiting for trains. My method is to throw an exception that says 'TODO: Next step is to return a query here'. When I open my laptop, I run the module I'm working on and it blows up, telling me what to so with a stack trace telling me where in the code to start.
Also, don't ever bother closing your IDE...
Project Euler!
Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.
http://projecteuler.net/
Also you can read The Daily WTF, 5 minutes worth spent.
I think the biggest hurdle is knowing what task can fit into 5mins. So the first thing I'd do is break down a bigger piece of work into a bunch of bite sized tasks, each of which will fit into 5mins. That way when you have your spare 5mins, you don't have to context switch to a large problem, then try to work out what needs doing & then try to get something done. Instead you just look at your task/todo list & grab the top item.
Programming involves two processes: thinking about your program, and typing the code into the computer. Try defining everything into small projects that should take no more than ten minutes. If you pre-compute what you want to type in and learn how to type well, you can knock some good work out in 5-10 minutes.
I use standby on the laptop instead of Hibernate because it gets me to the IDE faster. I had expected to have battery problems because of this but it seems to work quite well.
Read a few pages of Code Complete 2
I think an answer to another question has a good idea. jalf suggests:
A very simple trick might be to
subscribe to the RSS feed for C++
questions here on SO.
A wide range of questions get answered
here, on every difficulty level, and
they generally get very detailed
answers.
It won't replace a good book on C++ of
course, but it might be a good way to
discover a wide range of concepts,
pitfalls and solutions you might not
have known about otherwise.
So when you have 5 minutes here & there, check out an RSS of a particular tag in Stack Overflow and read (and answer?) questions.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
While novice software designers expect their users to behave rationally, it's far from being the case ; I've seen many times the user perception being totally disconnected from reality, or it's feedback obviously irrational.
I think we are the one who should adapt, not the other way around.
There's only one way that I know of to achieve this : listen to users, especially about what they don't like in software they use.
If there's one thing I've learned so far ; they often complain about things one wouldn't expect
What unexpected things did you learn from your users?
A few years ago, hospitals (at least French hospitals) were run using old win 3.11 software’s. Every single task was tedious; moving someone from one room to another would take 5 minutes to an expert user
A friend of mine was working on selling up-to-date software to those people. The same simple task would take 30s to a total beginner.
While most of the users were very happy with the new software, a handful were complaining, which wasn’t a surprise (there’s always a handful of users complaining). What was more unexpected was their reason: the software was damn slow. “The same simple task was instantaneous, now it takes ages to achieve. Give me my old software back”, they would say.
My friend decided to meet them, and asked them for a live demo of the slowness they were complaining about.
“Look, said the user, with my old software : I input the first name, enter, the name, enter, the admission number, enter, the old room number,[…insert 5 minutes here…] the new room number enter … and it’s done….. See… Everything is instantaneous”
“Now, look at your software. I do a drag and drop, as you taught me. And I wait, I wait… look, it’s done..I’ve waited for almost 30s….”
That’s a real world example. It really happened. I’m pretty sure that if the software had been modified to ask for useless information that it would have discarded afterwards during the 30s period, this user would have had a far better feeling with the new software
If you think about it there's no such thing as irrational user behaviour, there's just a mismatch between your expectations and theirs. The only way to close that is through dialogue. That doesn't necessarily mean going and doing usability studies, often the right dialogue is for them to read the help where the discrepancy is easily dealt with.
The only wrong thing to do is to not listen to what they are saying - or to listen and not really hear them (see the post on here about IE on the Mac - it's the height of arrogance). Of course you are going to get some people who just don't like change and will whinge about anything, but in general if a user will take the time to point out something in your software which bugs them, then you should listen. You may choose to ignore them, but if you listen right you may just as easily uncover a real gem.
I don't believe your users or customers will often innovate for you, but I strongly believe that they are the key to your software being usable, and usability leads directly to success. So to characterise them as irrational probably doesn't serve your best purposes - or theirs. Better to take them seriously to start with and filter out what you consider not to be good feedback.
Developing for a hand held unit many years back, I got contacted by a user who complained that their unit kept on turning off immediately after power on. It turned out to be a bug; the startup message ended with the line "Press any key to continue". It should have said "Press any key, except the big red key marked power, to continue".
One thing I have learned over the years is that time spent with end-users on requirements analysis prior to going anywhere near design is hugely important, as is understanding the culture and educational background of the users. Designing computer systems that look and work like existing manual systems is a good start, as is understanding the workflow. Another hand held van sales delivery system I was involved was specced to look for on-screen customer signatures on delivery, and this was necessary to complete the transaction. It turned out that most of the deliveries actually occurred early morning before anyone was there to sign for them, so the perceived workflow didn't gel with reality at all. The client IT staff didn't actually know this, nor did the business analyst. If you design systems without input from actual end users you do so at your peril.
In my previous job, I was designing a huge trading software for a huge bank.
The software would typically take around 5 minutes to launch.
Of course, the users were complaining a lot about the startup time, especially when the software was crashing during the day, which was happening from time to time.
From the day we added a detailed progress bar (progressing quite regularly, with an indicator of the number of remaining items), the complaints almost stopped.
Typical users would say "I used to take ages to load, but now, it's quite fast"
The next step for us was to display the user interface before the data is loaded instead of after (which makes more sense for an IT point of view)
This time, the modification resulted in a slight performance drop (from 5mn to 5"30), due to the cost of impacting the UI during the loading time.
From a user perspective, the software was much faster this way !!
I was once working on a cms for images. The admin would basically browse though pages of user-made images, and check the ones he wanted to publish. I wrote a nice manual on how the system works, but since everybody knows people don't read manuals, i put some guides on the page telling what to do (in this case, something like: "Check the box for every image you want to publish").
It wasn't long before some guy came pull my sleeve: "There's a bug in your program. It actually tosses the images i don't select, and not the ones i select".
The problem was solved by asking him to read aloud the text on the page.
While novice software designers expect
their users to behave rationally, it's
far from being the case ; I've seen
many times the user perception being
totally disconnected from reality, or
it's feedback obviously irrational.
I think we are the one who should
adapt, not the other way around.
Are you saying we should adapt to irrational behaviour? Software development is already irrational enough (dynamic languages, test driven development, ...), and you expect us to unilaterally bend over backwards to accommodate some distorted expectations?
A few years ago, I designed a small application which was mainly aimed at helping users to input complex data in a database.
Their old method was to input everything into an excel sheet (without validation of any kind), and then to use a vba macro.
My new program added validation, and was able to auto-fill almost half of the data they previously manually entered.
I expected to be a success... which it wasn't ... at all:)
"It's just impossible to use", they said...
I had tested it, asked my mother to test it... my software was fine...
In fact, those users were so used with inputting repetitive data that they used only the keyboard, not the mouse. And of course, I hadn't thought of managing the tab order correctly, so the cursor was just jumping all over the place each and every time they hit "tab", thus the "impossible to use" comment !
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I'm in Des Moines, Iowa and we have a good number of user groups in our area considering our size. Ruby, .Net, Java, Agile, *nix, etc... Well, tonight a good number of us "leaders" of said user groups got together for a couple drinks and to talk about how we can work together to help make the "DeMo" (I keep seeing this on Twitter) user group scene better.
We came up with a number of rather good ideas, but I'm curious. What compels you to attend your local user group(s)? Dig deep here guys. Maybe it is the free pizza, or the give aways. But I'm more interested to know about things out side of the freebie stuff.
I've always found the professional networking to be completely invaluable. I got my current job because of the Denver Java Users Group and it was one of the best choices I've ever made.
I know of 3 different types of events around here for local user groups where each has its own pull:
1) Presentations/Talks - Where someone comes in and talks for an hour or two on a subject to either introduce or advance the knowledge of a technology. So, an introduction Dependency Injection or Windows Workflow are a couple of examples. There are also what are called "deep dives" where the idea is to get really down into the topic and see various tips and tricks and try to improve how all of us develop software well. There are times where Microsoft will rent a movie theater screen for a day and have a series of 4 presentations about their latest technologies would be another example here. This can also include things like the Agile Project Leadership Network.
2) Code camp - These are sooo cool, I love these where part of the idea is that people volunteer to show something off, and the work isn't canned. By canned I mean that the demonstration code is all prepared and we can't see how long it took to get the code to be that way, e.g. a dozen files of code that took a dozen hours to get from nothing to this state that in a demo may seem like this should just come out within a few hours which isn't realistic. Here they have taken a few rooms at a local university to do it. One blogger's view of one a couple of years ago.
3) Open spaces - This was an awesome event that I really look forward to the next one. A bunch of other developers come together and self-organize discuss whatever we want in a sense. The discussions had were varied and in some cases the results weren't great, like how do we get others to take their off time and come to these things or other ways to volunteer our skills beyond open source projects. What was going on the first day link.
Each of the last two occur on a weekend so it isn't during work hours. Sometimes the joy of seeing something new or a better way to do something can really be rewarding, in addition to the good networking opportunity where you'll never know where the people are that come to these things as the Open Spaces had a few people from other countries present which added a nice diversity dimension to things.
Are there other local user group type events?
Many people really have different reasons for attending, with many of them denying it but are really just after the food and schwags (of course I kid ^_^). But there are a few other things that interest me, particularly:
Professional networking (as Eric stated above)
Ability to find out what I've missed out on (if I'm not "drinking from the fire hose" on Google Reader because I was uber-busy)
Certificate of participation (some employers use UG participation as points towards merit)
Brownie points on resumes (if you are the speaker, that is)
Food and schwag (oops, mentioned that already)
I really just like the idea of meeting people who are as excited about a certain topic as I am; it's exciting and inspiring. Especially since I live in a fairly small midwestern town, people with common interests in computer technologies will not be very abundant, so the social aspect is really appealing
I agree with Eric. I also enjoy seeing how others approach problems and what solutions they have in place. The reason is, if you're not a consultant, you work with the same set of individuals and it helps to bring fresh new ideas into the group.
I have been attending local JUG meetings for some time and based on that I would say:
Networking, this is important for me as I have recently relocated
Organizing the event itself can be fun
Free beer!
A little different approach, but I can tell you what keeps me away... I've always been interested in going, but just don't make it to any of them.
Most of them seem to be in small towns an hour away, right after work, so I'd miss a significant portion of the meeting.
The rare one that meets here in the city seems to want to meet at night in a part of town I don't want to go to even during the day.
Because I get to see cool things like this (video - RFID deadbolt with embedded RFID tag. And I do mean embedded!)
Of course, this is one of the few groups I make time for - I don't have time to attend every group I'd like to, but this one has a mix of interesting Make, software, etc so they're never boring.
Try to understand what your users need, and provide it is the best advice I can give. Only you know your audience.
-Adam
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Working with software day-to-day usually means you have to juggle project work, meetings, calls and other interrupts.
What single technique, trick, or tool do you find most useful in managing your time?
How do you stay focused?
What is your single biggest distraction from your work?
The trick the Getting Things Done system teaches is to have a trusted system you can put action items into. That way you don't have to keep "juggling". To keep with the metaphor, you can put the other balls down and have confidence that they will not be forgotten. Then you can concentrate on a single ball at a time. There are many, many other excellent tricks GTD teaches. Well worth getting the book.
I read this rule somewhere, and I use it every day...
If someone asks you to do something - if it takes less than 2 minutes, do it immediately. If it takes longer, put it on your list and come back to it.
This really works for me.
You should see this:
Randy Pausch Lecture: Time Management
It's a teacher from Carnegie Mellon who is near dying, giving his final lecture about time management. It's the best tips and tricks you can find.
To manage the general mayhem of the job, I try to use a toned down version of GTD focusing mainly on trying to maintain Inbox Zero and pushing tasks into a todo list (I use Remember the Milk for task list management).
As for maintaining flow in spite of interruptions, leaving a TDD project in a state where tests are failing tends to give you a place to jump right back in when you come back from a meeting or other interruption. Leaving a batch of uncommitted changes might serve a similar purpose -- to get your mind instantly back into the flow of the project without having to go look around to remind yourself what state things are in. Beyond that, using a fairly detailed task list for the projects at hand can help keep you on task and moving forward.
Often times, I've found my manager's manager to be the biggest distraction! :-) He likes to feel plugged in to the day-to-day work of his dev teams and frequently comes around on "walk-abouts" to see how things are going.
I find email the most distracting, so I've really cracked down on receiving certain types of email. I've unsubscribed from many mailing lists, job alerts etc. Shutting down email for a period of the day is quite useful too.
I enjoy going to the library. The quiet but busy, concentrated atmosphere basically forces you to work. The change of venue also seems to shut out some of the busyness and maybe worries you have in day-to-day life.
I use most of ZTD (http://zenhabits.net/2007/11/zen-to-done-the-simple-productivity-e-book/). GTD is too sophisticated and to big for me.
Basically, I make lists of tasks. Every morning I select three which I really need to do that day. I work on them until they're done. I struggle not to get dragged to other things.
In an office, I sometimes book a conference room and work there, distraction free. I emerge from the lair when I'm finished with the three most important tasks.
Encourage people to push their correspondence with you down the distraction chain:
Phone / Face-to-face
Instant messaging
Email
You can do this by deffering them: "I'm really busy right now, can you send me it in an email?"
This should reduce the amount of interruptions you receive allowing you to stay "in the zone" for longer periods of time, increasing your productivity.
Finally, allot time for processing emails at set times of the day. I, for example, have my email set to send and receive once every two hours. This bulking of activities allows you to get more done in the day without impacting customer relations.
My single biggest distraction is myself - I tend to go all hare-brained, chasing emails and internet links much of the time. Therefore, I'm using a simple trick to discipline myself into staying focused and on-task for larger parts of the day. The principle is to stay accountable for the use of my time:
1) Have a scheduled job in your operating system, that pops up a small messagebox every 15 minutes (in Windows, it should run the command C:\windows\system32\cmd.exe /C "start /B msg jpretori /W /V "15-minute check"")
2) Have IDailyDiary running in your system tray (a text file will work fine, too). Every time the box pops up, fill in what you've been up to the last 15 minutes.
I've caught myself with an ugly day filled with procrastination before... It's quite a good motivation to stay on-task.
Recently I've started using a great little free windows app called NextAction which you can get from here.
It's greatness comes from it's simplicity and it really helps to refocus and stay on track when dealing with all the days distractions ... email, co-workers, scrums, rss feeds, twitter, lunch, coffee breaks, etc. Having a list of what I'm working on always there on the desktop makes it very easy focus after any context switch.
Much better than pencil and paper, check it out for yourself.
NOTE: There is a more comprehensive web based 'NextAction' at code.google ... not so good for me, but maybe for others.
A single answer to all of the listed questions is David Ellen's Getting Things Done (GTD) ( "The Art of Stress-Free Productivity" )
A 45-minute presentation of the process can be found on youtube, and you can get the book on Amazon
Also you could think about the kind of things which make you want to browse the net, check your email, etc. For example, if a build I'm working on is taking too long my mind will wander.
So it actually pays off to make the build process as quick and efficient as you can make it, so you can make changes and test quickly.
I also find it helps to get enough sleep (tiredness is bad for concentration) and not to drink too much caffeine (seriously. I feel so much better after cutting down the amount of caffeine I drink. Try naturally caffeine free teas!)
(I seem to have wandered slightly off-topic into concentration there... still, I find the better I can concentrate the better I will use time!)
If you want to improve something, you first have to measure it.
I like Rescuetime. It logs all applications and websites you visit and how much time you spend there. You can tag applications/websites, i. e. with "work", "waste", "news" and get nice charts, productivity measures etc.
I find that http://www.rescuetime.com/ lets me know what I was actually doing all day, rather than what I THINK I was doing!
It also lets you put a "productive" level on each process/website you run or do so you can see how productive you are being.
The single most useful piece of time-management advice I could give is just get on and do it. If something is going to take less than 5 minutes to do, do it now.
Single most useful? http://www.nowdothis.com is AWESOME for focusing on what currrently needs to get done, and has raised my productivity by tons. (Bonus tip: Use Google Chrome to make it its own application and then make the app always be on top of other windows)
Biggest distraction? Google Reader.
(Slightly off-topic)
They says there is no such thing as time management. You can't manage an hour and get extra 20 mins out of it. Well, I recently discovered that you can. It you're listening to podcasts or watching recoded web casts, you can speed up the play speed. I found that it also helps me stay focused on the content rather than drifting off and starting check my email during the natural pauses. Then I saw Jeff's post on the same topic.
Email, IM, Skype... all those can distract. But biggest distraction is when my fellow colleague ask me why I wrote some year old algorithm this way and not that way. It brings my work to halt even if I know the answer.
To stop this interruptions, we have a 5-minute break every hour outside the office where we can talk about such problems.
There are a lot of things to do and I'm not sure you'll find any single technique to get organized and stay focused.
But...
Do list the things you have to do. Several short lists will be needed (today, later, inbox == to be sorted out, etc...). Review these lists once in the morning, and then in the evening. These related posts are worth a read: The Taste of the Day and The Trickle List
Timeboxing: allocate time in your calendar to get the tasks done
As suggested by harriyott, switching off email is kind of essential too!
This question has already been asked, so you might search for it.
I personally use Zen to done which is a simplified version of "Get Things Done". For the trusted system I host Tracks application for myself.
The best way to get through a big chunk of work while staying focused is to list your priorities on paper before you start. Trying to keep a big list in your head is a sure path to procrastination. Plus, it's a great feeling to tick off items as you finish them. Put on some music, close down your email, and get busy.
But then you have people trying to get your attention. Make sure your colleagues and clients know that you prefer to receive their queries in email rather than in person or by phone. Bugs go directly into the tracking system, without anyone having to tap you on the shoulder for each one. Sounds obvious, but stopping your work to discuss something for 5 minutes can sometimes cost you 30 minutes productivity by the time you are focused again.
You can find a great document about time management in Wouter van Oortmerssen (aka Aardappel, the developer of famouses Open Source games like cube and http://sauerbraten.org/ )
The article I'm talking about is this
I guess you're after something practical. What I do is keep my action items away from my work environment, it helps keep me focussed. I keep a pad next to my desk, I write down each action item for the day at the top and half way down start keeping notes. When I've finished a task I tick it off, anything not ticked can be carried over to the next day (if it's still relevant). Been using it for about 3 years, I find it keeps me productive and helps me remember things. I've tried all kinds of software solutions, nothing works better for me.
I have an old laptop that I remove the wireless card from and sit on a completely quiet room away from distractions. Whatever I can't get done without the internet is just leave until later. My biggest problem is that I gooel to find a solution and end up doing 30 minutes research on something a blogger has mentioned in passing. I still find it takes me a good hour before i get into the flow of not distracting myself.
On the 'how to stay focused', I think once you decide to close your email and put your phone on send, the next things to control are the sounds around you that might derail your thoughts. People talking, phones ringing, etc.
I have started putting the headphones on and surfing to http://www.simplynoise.com/. This is a noise generator that gives you the option of white, pink, or brown/red noise. It drowns out most of the audio distractions that often poke at my concentration.
Stay productive: When I'm working on a boring project and notice I don't do anything useful but reading news, I set a timer.
Simple enough, set your mobile on a 1-2 hour timer. Work during that period. When the timer rings, take a break and feel good about yourself :)
For some reason, this works (for me and a couple of other people I know)!
The single most valuable tool that I can recommend is a "todo" list.
This may take the form of a specialised app, gadget or pen and paper, however the most important thing to remember is that new tasks should be added to the bottom of the list and tasks to be started must be taken from the top - ie. don't cherry pick your tasks, as this will leave you with a task list full of time-consuming (and often boring) jobs that will begin to drag you down.
Possibly better for programmers than GTD is Time Management for System Administrators. Same basic principles (reduce interruptions, keep a list) but with a nerdier bent.
I close email and listen to soothing music. Of course, this tactic really is all about minimizing distractions.
The lecture of Randy is great, especially since he knows that he does not have much time left in this world.
Meetings are the biggest time wasters. Try to avoid them wherever you can.
I don't believe in those tools popping up every so often asking me what I'm currently doing. That's very distracting as well.
It might be good to make a time-log for for a couple of weeks, but just to understand where you are spending your time so you may be able to improve things.
I like the time management stuff by Steven Covey.
... and by the way I'm lecturer for time management for IEEE for Europe/Middle East and Africa.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
When working on a project, after the interesting parts are coded, my motivation is severely diminished. What do you do to get over this problem?
Don't leave all the "boring" bits to the end - make sure that each component works, with regression tests and documentation, as early as possible in the project.
That said, the last few weeks are still going to involve chasing down the really elusive bugs, dealing with last-second requirements changes, finalising the documentation, and generally getting the damn thing out of the door. My approach is just to suck it up: put your head down and know that the sooner it's done, the sooner you can start on all the lower-priority, more interesting things that have been queued behind the current release.
You can't completely avoid last-minute requirements/docs changes other than by arranging for your customers to all be on holiday just before release. Or get yourself in a dominating position like Apple and Google, so that customers have no prior knowledge of releases.
You "should" chase elusive bugs (by which I mean the ones so hard to reproduce that you don't have a consistent test case) early, because you cannot estimate how long they will take to fix. But in practice some proportion of them will become less elusive as the project goes on, or turn out to be side-effects of another known issue, so you save time on average by giving them a limited chance to do so. The downside of this is that towards the end there will be a few left. If there are more than about two, though, you've done it wrong.
Taking a short "break" after a major deadline to do whatever you find most fun is a good way to avoid burn-out in the long run. Even if you end up throwing most of it away because you skipped some difficult planning, you'll have made yourself more productive.
Use test-driven development. A failing test is always a strong motivation.
Let some testers loose on it. Nothing is more motivating than seeing people use your interesting bits and finding obvious improvements.
Repeat to myself: My code doesn't exist until it is checked in.
Or if you're not using version control, 'until it is published' or 'until it is launched.'
You could also use fear and say that if YOU don't finish and launch it, someone else will.
Usually I try to tell myself that getting things to work in the real world is just as interesting, because there is where your code will get credits or will be improved by discovered bugs and feature requests.
Don't do all the interesting parts first.
I motivate myself to do the boring code by always leaving a decent bit until last and being strict about completing the boring section first.
"if YOU don't finish and launch it, someone else will."
Told myself that one before. Sometimes however its good to take a break for a couple hours then come back to it. Then you are not as burned out on it as you were.
I try to push the concept of bug days / evenings. Set a target of bugs/issues to address and when you hit that number everyone gets to go out for (paid for!) pizza/beers. Keeps the morale of the team up and acts as a focus in an otherwise boring period.
Also you can add into this concept prizes/cudos for the best piece of refactoring or performance improvement etc
I agree it is tough. The only thing that keeps me going is to keep in mind the feeling I would have after seeing it complete / shipped / in the hands of customers.
My motivation is just to Get It Done. Like onebyone said, you just have to hunker down and do it. It's all a matter of priorities. The quicker the priorities are out of the way, the sooner you can get back to the interesting stuff.
Try to see if you can take a very short break for a day or two and come back more refreshed.
Don't leave boring bits to the end
Test it yourself
Ensure that your diet/exercise/sleep/etc level don't get lower
Tell the others that you are feeling a bit down, can you swap areas of work for a day?
In general, when you've done 90% of the work, it's almost ended, you just have to do the last 90% :-)
Always think about that, and you'll see that's a long way until it's working.
I'm happy doing the creative fun bits of programming.
But after that I think about making the user happy.