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?
When working on a project, after the interesting parts are coded, my motivation is
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.