I find that the following helps:
- Go into the office a few hours before anyone else gets there (you also get to leave early)
- Or some late, and stay later (after everyone else leaves).
- Work from home.
- Get headphones and play music (if you can tolerate music).
- Learn to tell people "I'm busy", or when they ask you "Do you have a minute?", response with, "Actually, right now I don't. Can you come back ____ ?"
- Make a big Stop Sign or other graphic that you can hang on your cube wall that says, "Hacking in Progress - Come Back in ____ Hours"
The above suggestions focus on external distractions, but do not address what, or should i said, who, is the most important contributor to product: the individual doing the work. The following modifications to your work habits can also make you more productive:
- Learn the features of your IDE or editor. If you use Eclipse, learn the Refactor commands and commit the keyboard shortcuts to memory. Your editor should be an extension of our mind in the same way that a kung fu master's fists are an extension of his.
- Have the documentation you'll likely need nearby and easy to access. For hacking Java in Eclipse, that means having the Javadoc locations to the libraries you use configured so that you can hover over a method and know what it does.
- Again, if you use Eclipse, you need to create Editor templates for redundant code that cannot be refactored. For example, 'ifnull CTRL+SPACE' for me inserts 'Validate.notNull([drop down list of visible variables, most local first], "{variableName} is null");', including adding the import for the Validate library from Apache Commons (throws IllegalArgumentException when validation check is false).
- Don't Write Code: E.g., Don't write methods such as isEmpty(String), isBlank(String), trimToEmpty(String), etc., instead, use StringUtils from Apache Commons (or another suitable library for your environment).
- The above mostly assume that you use a good IDE, but in case you don't, use one.
- If you like VI (as I do), learn VIM well: I have done LOADS of text processing in seconds that would take people that don't know VIM hours!
- Learn how to write code that makes you more efficient - e.g., if you find yourself constantly typing or copy-pasting a particular routine (the usual practice of the inept is to refer back to a previous source file they wrote that does the same thing), 1. add the code to a utility class that can be easily accessed and shared or 2) following the advice in step 3 above creating editor templates.
Program with technologies that make coding more efficient - e.g,. prefer Spring POJO services with custom advice for cross cutting concerns to copy-pasting or generating ugly boiler plate code for cross cutting concerns all over your code based. An example from a recent project was implementing some 'around' behavior for all web service methods: The code I inherited did this:
public void performBusinessAction()
{
Context previousContext = null;
try
{
previousContext = getCurrentContext();
Context temporaryContext = getNewContext();
setContext(temporaryContext);
handlePerformBusinessAction();
}
catch(Exception e)
{
throw translateException("Could not perform 'performActualWork()'",e);
}
finally
{
if(previousContext != null)
setContext(previousContext); // put things back like they were!
}
}
private void handlePerformBusinessAction()
{
// simple business logic!
}
I changed that to the following:
public void performBusinessAction()
{
// simple business logic! (the handlePerformBusinessAction() method is not needed!)
}
The configuration for the class containing the methods uses an AOP around advice to wrap each business method invocation with the context boiler plate code (which must happen for every method call). Because the cross-cutting concerned was implemented as an advice, it exists in one place in the code base; and if the business rules for the context code changes or the technology used for the context is changed, the performBussinessAction() method does not need to be changed (nor the class that contains it).
I could go on and on, but I'll stop now. :)