I'm used to working in a large development environment where code is peer reviewed and tested by the client, who is usually an IT person themselves. I am now working at a very small company where I'm not just the only developer, but the only IT person at all.

I'm inclined to have my coworkers and/or boss take a look at my work every time I finish a agile story, so they can either accept it or reject it, as is the pattern I'm used to. However, too often my coworkers either don't understand my work well enough to judge it or they misunderstand it and accept bad code or reject good code based on surface looks alone, like the color of links.

So I'm wondering how I should decide when to accept/reject tests now? Should I try to assess my own code like an outside person? Should I just skip it and accept everything? Should I try to educate my coworkers a bit and get them to do proper tests?

  • 1
    I changed title and tags to make more sense. "Accepting a user story" means something completely different.
    – Euphoric
    Commented Jan 20, 2014 at 21:08
  • You said in a comment that your customer is your company, but who is/will be using the software?
    – Cephalopod
    Commented Jan 20, 2014 at 21:32
  • 4
    in environment like that, I would simply review my own code a month or 2 (better 3) later. As time passes, blind spots against the code I wrote tend to go away and it gets easier to catch my mistakes in there
    – gnat
    Commented Jan 20, 2014 at 22:00
  • 2
    "Accepting a user story" and "reviewing your code" are two very different activities. Perhaps two questions might have been more appropriate... Commented Jan 21, 2014 at 3:15
  • 2
    relevant to the review part: programmers.stackexchange.com/q/139321/10563
    – jk.
    Commented Jan 21, 2014 at 13:20

8 Answers 8


User stories should be written in conjunction with the customer.

Are you the customer?

If so, then accept your own stories. If not, schedule review/writing time with the customer.

  • The customer is the company, but I've been put solely in charge of developing our online system. There isn't really anyone else at the company who would have any kind of authority here, so am I the customer? I don't really know.
    – Dylan Karr
    Commented Jan 20, 2014 at 20:02
  • Hmm. This answer was spot on when the question was originally posted. :/ Commented Jan 20, 2014 at 23:08
  • 5
    @DylanKarr: if you are not a user of the software, you cannot be the customer. Go find a user, or three, and talk them into helping you. But don't ask them to review your code, those are two different things! Commented Jan 21, 2014 at 3:11

If you are developing an online system for your company, that would imply that somebody besides you must have an idea of how it supposed to work at least at the UI level. So that would be the level at which your work can be reviewed by others within the company.

Unfortunately, that means that there is nobody to review your code. One possibility is that you can review your own code. It may be helpful to go back and look at your code a week or so after you finish it, and see if you can still understand it. Alternatively, you can try to get your company to hire another developer.


As the sole developer, I think you just have to let go (hopefully temporarily) of some of of the professional techniques bigger teams has. But you CAN make some substitutes!

You should always use repositories. You should probably make more tests than before (since there is no other person who can catch mistakes).

If you are able, make each feature or addition a separate changeset / shelveset (or branch in git), so that you can create some feature, test it and then ignore it for 1-2 weeks(longer is probably better). Then read through the entire shelveset. Now: If you have no problems understanding every line of code immediately, consider it acceptably code reviewed(as 1 person I think this is the best you can do). If there are parts of the code where you do not immediately understand every aspect of the code, spend some extra time to see if you can make it simpler, or more understandable.

Better than everything above is to get your boss to hire another programmer and peer review each others code.

Good luck!


Welcome to the world of micro-management.

The place where the boss lose money, and the technicians made ​​coffee for others

Most of the agile development techniques that you have learned up to now, in this moment become non-applicable. The main problem is that in the absence of a development team, what remains is perhaps "extreme programming". My advice is to make it clear to the company (no matter the size of this one), this situation is sustainable only if the software is developed to an amateur level. This has nothing to do with your role, you can continue to develop by applying all the techniques you know, but only at the level of software design and development. Continue, perhaps, to develop using TDD, drawing use cases in UML, etc.. But a product, it needs more members to be developed, debugged, tuned, deployed, advertised...

Do not forget that the development of a product, must pass through a strong criticism, survive this, and then have its path of continuous integration. as programmers, we do not digest well the criticism of others and we often need a brilliant idea from others, BUT when they are not there, we become omnipotent and all the errors becomes ours.

I believe that the boss (as defined), has a rejection to the explanation of a technical, these normally lead to the need to spend money, and in a company where there is not a defined budget for the technical department, this can generate conflicts between administrators and technical.

My advice is to invest in training managers, without giving much explanation and even in small projects, organize your work ready to welcome new members in the development team.

Some tips

  1. Always use repositories, maybe a nice project on github, with your code organized as Super Project
  2. Spend your time in at least define what are the milestones of the requests that are made to you;
  3. Organize your milestone in simple online spreadsheets, now you do not need great project managers, Gantt diagrams, resource control, money flows, etc.
  4. Always communicate the progress of your work via e-mail, and attach the status of your milestone in PDF;

I think the method that you choose today, must show what you do, and how much time do you spend on.

last consideration

if you show to a Boss, 10 milestone, 3 of these were writing code, and the other divided between, debug, design, install, test, at that moment you have a great tool for dialogue with the administration...

at that time, you speak their language.

  • 1
    So your answer is to review my own code?
    – Dylan Karr
    Commented Jan 20, 2014 at 22:04
  • @DylanKarr in my opinion yes, even if it slows down the process of development, you will need to take responsibility of your code, exactly as if you were working with another programmer. What you can not do, is to decide on the customer's needs, the rest remains unchanged.
    – kedoska
    Commented Jan 20, 2014 at 22:12
  • Extreme doesn't require a team, but it really likes to have pair programming, which is difficult without a team. It does, however, require significant work with the business owners on a regular basis... which they typically don't want to do.
    – user40980
    Commented Jan 21, 2014 at 1:33
  • I don't believe a single-person dev team is doomed to produce only amateur-quality software (it'll produce less than a proper team, for sure)... if the one developer is an experienced professional.
    – James Adam
    Commented Jan 27, 2014 at 14:13

I'm not just the only developer, but the only IT person at all. I'm inclined to have my coworkers and/or boss...

Sometimes in that situation it is useful to invite a friend even if he knows absolutely nothing about computers. You could meet at home, or another place, and you can show him your code, or he can show you his code. In my experience he was my friend, and usually poked at a piece of code, whereafter I often found an error.

Also a good approach can be that you just try to forget somehow what the code does. Just sleep, go for a walk, or even change the project. When you completely forget the completed task, try to get back into the project, read the code and reconstruct the purpose of the code. Try to understand the code again, you will see many new ideas, and even mistakes in it. Don't wait too long, though!

This approach can also be applied when you write an article.


To assess your code you can use automated tools like PMD, Findbugs, Sonar, etc. Which one of these have a set of rules that evaluate your code against best pratices and design patterns. They also let you create new rules to match your patterns and architecture design. You can run them integrated on your IDE, on a CI Server (like Jenkins) or on a simple batch script.

They are not perfect but can give a help while you don´t have another developer to review your code. They are free and can be scheduled to run every night so you get a fresh report every morning. :)

  • without an explanation, this answer may become useless in case if someone else posts an opposite opinion. For example, if someone posts a claim like "To assess your code you can not use automated tools like PMD, Findbugs, Sonar,... They are not perfect and can not give a help while you don't have another developer to review your code.", how would this answer help reader to pick of two opposing opinions? Consider editing it into a better shape, to fit How to Answer guidelines.
    – gnat
    Commented Jan 24, 2014 at 18:37
  • 1
    @gnat just updated my answer as you requested. Tks. Commented Jan 27, 2014 at 11:24

If you are the only IT worker, then there's little point in getting anyone around you to review the code. Nobody will have any idea what it means, and will just point out trivial stuff like spelling mistakes.

Make extensive use of unit tests. Take heed of compiler warnings, and consider using automated code quality tools (but be prepared to ignore or turn off many useless warnings from them).

Only bother asking the people around you whether or not your code does what they want. If it's confusing, or doesn't work for them, fix it. If they are happy, then your code must be OK.


When you are working in small companies, its normal to have to wear several hats. Take the most extreme example, when the company is first created, you still have developer, tester, analyst, sales, book keeping, marketing etc... roles, but probably only 2 or 3 people to share the work.

In this case, its quite possible that you are doing the analysis of what is required, developing, testing, deploying, maintaining and supporting. Whilst its preferable for there to be multiple people covering these roles from both a quality and business continuity perspective, in a small company that may be an expensive luxury.

The best advice I can give is to always be clear about what the roles are, and to think as though you are performing each of these roles when you are performing their tasks on the project. Over time this process will become more fluid, and you will become more comfortable with thinking ahead and handling the competing responsibilities.

If I was currently your manager, I would be looking to see if you can step up to the challenge ahead and take ownership.

Not the answer you're looking for? Browse other questions tagged or ask your own question.