Productivity by forcing yourself

It's hard to get work done when you're not in the zone, and distraction comes in. To help productivity, let's enforce good practices instead.

Focusing on problems in a hard task such as software development can be a difficult process. I have previously blogged about idea refactoring as a measure to help getting in the zone as quickly as possible, by having a refined, written path to follow when you step into unexpected issues.
There are other techniques that can help process improvements. And as Quality Assurance people say, a good process is mandatory to a good product, which in the software perspective is the code you write plus the other artifacts like documentation, and the design that they implements.

Premise
There's a lot of talk on software engineering in the blogosphere; the web is biased towards the technologies and practices which is built with. So a developer like you and me reads many tips on coding for his particular platform, language, framework, and normally says "it is reasonable" after learning the existence of practices like Tdd and build automation. Where he fails is in applying consistently this techniques: if only half of your code is written in a tdd fashion, the restant part will suffer; if you automate compiling of you application but not its archiviation and compression (tar/gzip), you will find yourself executing the same dauting task that you could easily factor out earlier but not having the time or stamina to bring it to an end.
Why does it happen? Because as humans, we are not always in the same state of mind (or level of awareness if you prefer). When we are in the zone (aka flow if you prefer) it's straightforward to build from scratch beautiful features. When we are a bit less concentrated, the temptation to hack some code together comes, like death and taxes. It's nice to say "I have to get up at 6 am tomorrow", but it's another problem to keep the 6-am-yourself to hit snooze and turn away from the dawn light. Many of us lack the discipline, and even the ones that have it are not always in that higher level of awareness where discipline resides.

Constraints as aids
That's why the way to go is to force yourself to do the right thing, the one you would choose in a higher level of awareness moment. You program the alarm clock in the evening, knowing that would be useful to rise early and that will be very productive by your experience: the same applies to software. You know a test-driven development will lead to less coupled and less error-prone code. You just have to start writing testcases before domain classes, even when it seems an overkill; because there's always some complication that will arise and that tdd clears out.
So, I wrote a list of practices that enforce the best practices to be adopted. Some can seem exaggerations, but I assure that they have lead to much satisfaction repaying themselves in a short time.

• some organizations have subversion commit hooks that runs a language linter against the checked in data, not allowing the commit of source files that contains syntax errors. Obviously logic bugs are not caught, but this is a nice procedure.
• I often turn off my webserver machine to do much work on the command line with PHPUnit instead of testing in the browser; the same applies with other xUnit toolkits and to everything that forces tdd instead of a top-down approach.
• turning off the net connection to not be distracted by various websites is a classic: I personally feel closing Im programs and not using applets that pops up when you receive mail is enough. However, I removed my facebook bookmark in the browser bar.
• my phone is kept far from the workstation. Since it lights up when there are unread messages, it is also out from view. Speakers are turned off to avoid annoying sound.
• Steve Pavlina says it has a Writing troll - Get back sign that he place on the door to not being disturbed while writing. Locking the door will be enough?
• Rubberducking: a teddy bear or a rubber duck is placed in some university help desk centers and before being allowed to speak to an human students are force to speak out to the teddy bear. Half of the problems are solved during this process, by the student itself. It has happened to me that, while writing to a mailing list, I reached the solution of my issue before complete the email. And if you're being watched by a duck, you'll be more composed. :)
• leave only battery power to a laptop could make you under pressure and motivated to get a job done in the remaining time before the charge ending.

These are only example of what works for me. Feel free to share your productivity tips!