Becoming the most efficient one-man team

Question

Like many here, I am a one-man development team. I'm responsible for everything from gathering project requirements, designing concept-screens, planning and developing databases, and writing all code.

Being a one-man team is nice, but has its negatives. I don't have the ability to quickly consult with other developers, I rarely get a second set of eyes for my code, and I'm sure you guys can come up with many other negatives too.

To make the most of my time, and commit myself most efficiently to my work, what tips or practices could I implement into my day-to-day routine to be the best one-man team possible?

Answer 1

• Make sure you refactor early and often. That serves almost like a second set of eyes (for me, at least).
• Don't work insane hours (especially tricky if you're working from home). Actually, working less hours often proves more productive as the impending break/end of day pressure increases your efficiency.
• You may want to look up Parkinson's Law for work/time management.

Answer 2

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

Answer 3

• 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.

Answer 4

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.

Answer 5

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.

Answer 6

I use a text file to collect all the things I do every day. Every time I run into a problem or have a question or find a solution, I add it to my file. It's very low-tech but it provides a wealth of information, like "where am I spending most of my time?" or "how did I fix that problem before?". Also makes it super-quick to give your client a list of hours at the end of your billing cycle.

I also use another text file (per client) that contains all the work items on my plate, arranged in order of priority, and updated frequently. It helps both me and my clients focus on what I should be working on next, so the pump is always primed.

Eventually I'll move away from flat text files to using something like FogBugz, but for now I can't beat the price, or how easy it is to search, or how easy it is to e-mail.

Answer 7

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.

Answer 8

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.