How do you mitigate the inherent risk of a one-person team? [closed]

Question

What steps can one take to mitigate the risk of a one-person team working on a project, especially when that one person is a rather junior programmer?

I ask because I am that junior programmer, and there is no one available/willing to do things like code reviews. Part of the problem, I suppose, is that I am working on web applications in an embedded software company, so most employees' expertise is in a different area.

Answer 1

Recognising this as a problem is more than most "junior programmers" would be able to do :)

Unfortunately most employers don't see the benefits (only the downsides) in multiple people on the same task.

With lack of understanding from your employer on this point, just stick to all the usual rules, such automated testing, documentation, and source control. I know too well that when working alone on a project, it is all too easy to become complacent.

The truth is that the documentation is not just to help others know what your code does. It helps you too. Source control is not just to enable multiple people to work on a project and merge changes, it helps productivity (in the sense that you can easily revert changes), enforces backups, and gives you good tracking of where your time and effort has been spent.

Answer 2

Source control and automated tests are two things that will help in any environment. Those two things alone will mitigate some of the major disasters (lost work, buggy code resulting from constant changes and refactoring).

Beyond that, stick to the basics: K.I.S.S. Keep your code design as simple as possible, keep your classes simple, follow the Single Responsibility Principle and above all, avoid duplication (which will greatly guide your designs). Make use of every resource you have: message boards, other programmers at other companies, friends from school, whatever you have available to you. Even having a mentor you can send e-mail to is helpful.

Answer 3

Best practices aren't much different than for a larger group. Source control, unit testing, follow a style guide for your language, script everything instead of using manual processes, and try to have at least some high level documentation and comments in the tricky parts of code. For specific decisions that are important and hard to change, like how your code interacts with the database, try to find out what approach a well-designed project uses, if necessary by checking on this site.

Unit tests especially are a great way for other people to quickly figure out how your code is supposed to behave, and to check whether their changes have broken anything.

Answer 4

StackOverflow is full of available and willing people to help solve problems and give advice.

Other than that, be prepared to make mistakes and learn from them.

Oh yeah, and get a copy of Code Complete!

Answer 5

As @MattJ mentioned, the fact that you care enough to try to mitigate that risk implies much more seniority than your current job title purports.

I would say that you should do all of the normal things you do to mitigate risk and, where it's not possible to get another resource, just either do it yourself, or skip that step.

It's the best you can do.