Becoming the most efficient one-man team [closed]

Question

• Daily list of what I am going to do.

• Remove as many distractions as possible to focus on tasks. Turn off email, turn off IM, etc... even if for a set period of time and then during a break check them.

• Take time to learn about other coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget. I know this one really sounds counter productive but it really isn't. Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.

• Take breaks and be aware of your body. When we are tired we don't think as well and will make more mistakes, become frustrated more easily, etc...

• Learn to use the 80 / 20 rule to your advantage. I don't mean skimp or be lazy. Often though we will work our tail off for that 20% when it wasn't necessary.

• Set goals for yourself (daily, weekly, bi-weekly). Make sure the goals are also in line with those you are coding for or you may find you have wasted some time.

From a technical aspect consider:

• Consider Unit testing / TDD. I have found in my own work that this actually saves time. It takes a while to get the hang of but with anything you will get better.
• Care for your code. Refactor it (especially if you start unit testing). The better your code is the easier it is to maintain which takes less time. The easier it is to understand the faster you can change / implement features.

I'm learning to spend a lot more time planning out my day than I used to. This includes planning out projects, down to writing psuedo-code for the programming I need to do. I find that with all the interruptions in my schedule, it's difficult for me to get started at something. Having everything broken down into small tasks makes it much easier to start after an interruption.

According to operational research, shortest job first is the best scheduler to get most amount of things done.

I write and run integration and system tests, but no unit tests, because I've no need for early (pre-integration) testing: Should one test internal implementation, or only test public behaviour?

A corrolary of Conway's Law is that you need to test the internal software interfaces which separate/integrate developers, whereas a "one man army" don't need to explicitly test his internal interfaces in this way.

A lot of the other tips are good but they equally apply to developers working in a team as well as a lone developer.

I think the hardest thing as a one man team is effective communication with the rest of your company. You will always be a lone programmers voice in any meeting or discussion around how best to build software.

As a result I'd advise trying to improve negotiation skills and focus on improving the way you describe technical concepts in terms a non-programmer can understand. Reading books such as Getting to Yes and How to win friends and influence people are a good way to start.

When there is more than one person agreeing on a viewpoint, the viewpoint automatically gains credibility with those you are trying to convince. In the absence of this possiblity you need to work extra hard at preparing your arguments with well-researched evidence and a balanced view.

I'm in the same situation. There's already a lot of good advice above but one thing I'd add is find when your best coding times are and make sure you're coding during that time. I have a few hours in the morning that I seem to be at my best for coding. I try to keep that time free of all distractions. Plan things like meetings, writing documentation, testing (at least the tedious, repetitive stuff), and all that other stuff for your less productive time. Keep those coding hours when you're 2 to 5 times more productive for coding.