Becoming the most efficient one-man team [closed]

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?

Incestuous

Just wondering: What happens when you go on holiday? How does the business deal with not having a developer for an extended length of time? – Forby

@Forby I actually have only taken 1 vacation in all the years I've been working. In the past, I simply cashed in my vacation days for additional pay. I just took my first week of actual vacation about 2 weeks ago. During my "time off," I still worked ~30 minutes a day or so to keep things moving. – Incestuous

Answer 1

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

Elasmobranch

+1 for learning and caring for your code (though the rest is good too). I've written sections of code using different development styles (as I learned them) and have refactored the less efficient/harder to maintain ones to match the other. Worked quite well. – Corinnecorinth

It's in your list, but setting a daily bunch of small achievable objectives whenever possible works for my being productive and feeling productive. At the beginning of the day I just apply 80/20 rule to plan in what I should work on during the day. Another important thing is to keep updated concerning technology otherwise we'd still be programming in assembly and imperative paradigm strictly... – Homogeneity

Answer 2

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.

Coupon

Answer 3

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

Warhead

any links to said research? I'd be very interested in that. – Beefwood

While not a study here's the wikipedia: en.wikipedia.org/wiki/Shortest_job_next – Glasgo

The point about process starvation should be stressed tho! So, start the day with a few short tasks that have impact, but continue working on larger tasks as well. – Warhead

indeed whilst I like the idea overall I could easily see some tasks never being done because newer, shorter ones keep coming in. I guess it is about balance, as in all things. – Beefwood

Answer 4

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.

Chryselephantine

+1: I'm a lone programmer and getting the boss or the team (one will almost always convince the other) on my side is priority 1. – Corinnecorinth

Answer 5

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.

Albumin

Answer 6

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.

Stadium

Answer 7

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

Lysimeter

Answer 8

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.

Yolondayon

ToDoList might be a better way to manage your work items. You may want to check it out. – Sparry

Are you talking about the app shown at codeproject.com/KB/applications/ToDoList2/todolist.png ? That thing looks like an absolute mess... I would much rather have my flat text file! – Yolondayon