Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have no choice but to work on my own, and can't find an adequate solution for getting my work looked over, sanity checked, having someone to brainstorm ideas with, discussing best practices and so on.

I thought I'd get an answer via Jeff Atwood's article: In Programming, One Is The Loneliest Number, the best I could find on the subject, but it turned out to just reiterate my question.

I know stack exchange sites such as this, and Code Review are an obvious potential answer, but as many would appreciate, it's FAR from ideal:

While I can't list all the pitfalls, often, formulating a question and boxing it up into a self-contained problem often takes so much work that by the time you've prepared it sufficiently, you've answered your own question in more time than it would have taken otherwise. Also, hiding away details to ask a well defined question eliminates the possibility of someone spotting problems you hadn't thought of. Also, while I can't quite put my finger on it, the responsiveness of free conversation can't be matched by the any form of textual internet discussion that I can think of. Last but not least, I don't want to post my whole project for the world to look at for the rest of eternity, for obvious reasons.

Are there any answers other than paying a consultant to look over my code?

share|improve this question
I have this problem as well (with for-fun projects, though), only I am lucky enough to have a few close programmer friends willing to look through my code. – Austin Hyde Jul 14 '11 at 20:04
You could always talk to yourself - this is especially good for insanity checks :-) – Danny Varod Jul 14 '11 at 20:40
If you can afford it, this is one reason why its good to rent an office/desk in a business park (ideally where IT people cluster). I had many good chats with the IT people in my neighbouring offices when I was a lone-programmer working in an office. – JW01 Jul 14 '11 at 21:06
Working by oneself can be better than working with idiots. – Job Jul 14 '11 at 22:12
Not really a solution, but you can hang out on SO chat or an appropriate IRC channel; that might alleviate some of the burdens of working by yourself. – Tikhon Jelvis Jul 14 '11 at 22:50

I have been in your shoes and I don't think there is any easy solution. Paying a consultant to look over your code is not a good way to spend money. If your problem is that you feel lonely and don't have anyone to talk to about programming then I can't help you there but if you are really interested in improving the quality of your code then the best thing to do is to set it aside and come back to it in a week or so. If the code is really bad then it will be obvious because you will not be able to make any sense of it and you can start refactoring it to make sense. After a few iterations of this process you'll start to notice the code patterns that make code easy to understand and your code quality will improve.

share|improve this answer
Good one! ...15 – Marjan Venema Jul 15 '11 at 6:36
In theory this could work, in practice there is NO WAY IN HELL he's going to go look back at code he wrote 2 weeks ago if it works. Nor should he, probably.. If it works going back to spend time on it for the sole reason of making it "prettier" is a waste of time, it should be done when and if it is touched again. – Andreas Bonini Jul 15 '11 at 10:27
@Krelp: I look at past code all the time and there is no way you can add features and in general maintain software without looking at previously written code. There is no such thing as a perfect architecture and leaky abstractions are the rule rather than the exception so looking at previously written code is unavoidable. I know that marathon coders are idolized in programming circles but marathon coding quickly leads to burnout and derelict projects so on top of improving code quality taking breaks and coming back also keeps me sane. – davidk01 Jul 15 '11 at 20:29
@david: you mentioned looking back at code after a fixed amount of time, even if there is no need to at the moment. You didn't initially say to look back at the code only when you have to do so in order to add new features.. So if - according to what you said - you have to eventually look back at all old code, why not do so in a moment that's relevant instead of after a fixed time period? – Andreas Bonini Jul 16 '11 at 0:13
@Krelp: If you're confident enough in your abilities then go right ahead and only look at working code when you feel like it but if you're just starting out and are unsure of how well you're structuring your code then continually looking back at what you wrote a few weeks ago and refactoring it is a really good way to learn proper code structure. My advice was for people looking to improve and reach the point where restructuring previously written code becomes less and less necessary because the initial version has the proper extensible structure. You are more than welcome to ignore my advice. – davidk01 Jul 16 '11 at 0:59

Are there any answers other than paying a consultant to look over my code?


My advice is join a local developer\user group, and talk out your ideas with others. Talk about your design. Ask other how they have approached certain problems.

If they verify your design, even without looking at your code, that should be good enough.

share|improve this answer
Many professional writers do this. – JeffO Jul 14 '11 at 23:37

There are self check techniques such as test driven development that can help provide feedback. When it becomes difficult to do you know your architecture is likely out of whack.

formulating a question and boxing it up into a self-contained problem often takes so much work that by the time you've prepared it sufficiently, you've answered your own question in more time than it would have taken otherwise.

Problem solved. You don't need external feedback on every single line of code in order to improve, just a good sampling at key forks in the road, and careful self-checks at points in between.

You have to get over the idea that you can maintain the same level of quality working alone in the same amount of time as someone working in a team. There's a reason people work in teams. The good news is you don't have conflicts about design decisions. The bad news is you don't have conflicts about design decisions. Hopefully the extra time you spend maintaining quality is offset somewhat by the advantages of working alone.

share|improve this answer
I fail to see how TDD is an answer here. – Aaronaught Jul 14 '11 at 23:55
@Aaronaught I'm in the same boat as the TS and I can assure you that writing tests (either before code as in TDD or after it) is THE way to check if your code is sane. If you can't test it, it's bad. – stijn Jul 15 '11 at 7:04
@stijn: It may be (somewhat) true that bad code is more difficult to write tests for, but it is never impossible - it's how legacy systems get upgraded. Even if we accepted at face value the dubious claim that good code leads to good tests, the inverse claim is still not proven; a passing test does not mean that the code is of any reasonable quality. In fact, the premise of TDD - "red, green, refactor" - essentially means writing sloppy code that passes the test and then refactoring it to improve the quality, so at the end of the day you're right back where you started, just with tests. – Aaronaught Jul 15 '11 at 11:12
@Aaronaught: you do make valid points, but still I stand by my point that tests are a very very good way to check for code sanity (though not the only way indeed); experience has proven me so, it's especially usefull to see where SRP gets violated heavily. – stijn Jul 15 '11 at 12:06
@Mark: That's nice, but all these anecdotes are worth even less than an "I lost 50 pounds in 2 weeks" advertising claim, because the thing being talked about hasn't even actually been measured, let alone observed under controlled conditions. Yes, there is evidence that TDD reduces pre-release defects, and that's a great thing; code reviews solve an entirely different problem and there is no basis for assuming that TDD solves the same one. "Old-school" unit tests are probably actually better for this because they place testability constraints on individual classes instead of groups of them. – Aaronaught Jul 15 '11 at 15:39

I would reccomend doing as much networking as possible at conferences and local user groups. I know lots of developers who shoot sanitized code snips back and forth through email or im all the time just to keep sharp and look over algorithms together. No, it is not a face to face conversation, and yes it is a pain to sanitze code sometimes, but a 20 instant messager code review from time to time can be pretty useful, especially when you are desperate for a second pair of eyes.

share|improve this answer

I'm in a similar situation and I rely heavily on Stack Overflow for getting feedback on gnarly questions. I also find by virtue of actually having to write down a description of the problem that the answer often becomes obvious. In terms of best practices, I'm a .Net developer and I use ReSharper which will offer suggestions of good practice alternatives to code I'm writing (which I sometimes just ignore - it can be a little pedantic). And another useful tool is FxCop which will do a static code analysis and highlight any issues that don't match its ruleset.

Otherwise it's up to you to read and stay up to date on current practices. I like Alvin Ashcraft's Morning Dew for links to what's new and improved in the .Net world.

share|improve this answer

I would suggest trying to create (or find) a small user group. Make your code available, and get everyone to commit making it work - a half hour or more daily.

share|improve this answer

A constructive feedback from my experience is that during the initial years of your development it would be very important although not mandatory that an experienced developer reviews your code to lay the foundation. Once your are experienced, you can follow the approach suggested by @ davidk01 i.e Reviewing your own code periodically to improve code quality.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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