39

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?

  • 3
    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
  • 23
    You could always talk to yourself - this is especially good for insanity checks :-) – Danny Varod Jul 14 '11 at 20:40
  • 4
    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
  • 6
    Working by oneself can be better than working with idiots. – Job Jul 14 '11 at 22:12
  • 2
    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
36

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.

  • Good one! ...15 – Marjan Venema Jul 15 '11 at 6:36
  • 2
    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. – Thomas Bonini Jul 15 '11 at 10:27
  • 3
    @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? – Thomas Bonini Jul 16 '11 at 0:13
  • 3
    @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
17

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

No.

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.

  • 4
    Many professional writers do this. – JeffO Jul 14 '11 at 23:37
10

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.

  • I fail to see how TDD is an answer here. – Aaronaught Jul 14 '11 at 23:55
  • 1
    @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
  • 1
    @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
  • 2
    @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
6

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.

4

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.

4

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.

3

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.

2

I don't know details of your situation, but where I am now there are many hungry for experience students who are more than happy to work as an intern and learn something.

It may sound extra job for you to handle them and teach them this and that, but we've been all there when we first started and I guess it's our turn to pay back.

They are not experts and they might even mislead you sometimes, but usually they challenge everything and are full of ideas and are great for a discussion where you have to defend every detail of your code.

2

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.

I experience the same for >75% of questions I post.

However, that is not an argument for not bothering to do so. This is effectively rubber duck debugging. You're finding answers to questions that you think might crop up in response to your question; which means you're thinking about the problem from different people's points of view; which means you're thinking about the problem from all possible directions; which is the best way to find the flaw.

At best, you've conclusively proven that you clearly cannot think of the answer here. At "worst", you end up answering your own question. Mind the quotes, because this isn't bad at all. It was maybe a little time inefficient, but solving the problem slowly is better than quickly deciding to not tackle the problem. You'll get faster at solving the problem eventually.

Case in point:

When I was a fledgling developer, I dealt with the ASP.Net eror page plenty of times. I needed to Google the message to figure out what's wrong. it could take several hours before I got the right solution. I basically made every mistake in the book and subsequently had to deal with with the consequences of having to debug the issues.

Now, when an error pops up, I already know the "usual suspects" of what could be causing the issue. My mental list of "usual suspects" is effectively based on the problems I've had issues with the most during my career. Without first having done the time-inefficient leg work of hours of Googling, I would never have made this mental list. But now that I have that mental list, I'm considerably faster at troubleshooting.


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.

I somewhat disagree here. You're right that internet communication is less responsive, but you're (in my opinion) wrong that this is bad for you.

As a lone developer, you'll be reliant on rubber duck debugging. The key ingredient to making RDD work is that you anticipate questions that the rubber duck may have for you. You obviously can't rely on what the rubber duck actually says.

When dealing with slow messaging systems (posting on StackOverflow or communicating by writing letters), you are inherently incentivized to make sure that you get it right the first time. Because needing to correct a mistake will be a slow and arduous process.
By comparison, consider that fast messaging systems (conversation, instant messaging), you can immediately correct something. The ability to quickly correct something makes people less incentivized to ensure that it is correct.

Four cases in point:

  • When I'm making my own personal analysis/todo list as a developer, I still use pen and paper. I've noticed that I gloss over assumptions and falsehoods when I'm typing my notes, because my mind thinks that "I can easily fix this later". However, having to correct something you've written on paper is annoying, you need to cross things out and write between the lines and the document looks so much worse when it has scribblings on it. Writing on paper makes me fact-check myself before I commit to writing it. This catches a lot of misunderstandings early, before I even write code that would produce bugs.
  • My grandmother was a secretary (age of the typewriter). Making a typo in a formal document meant having to type the whole page again. My aunt is a secretary (age of the word processor). She can rely on an automatic spell checker, and mistakes can be fixed easily and with minimal effort. Unsurprisingly, my grandmother makes considerably less typing errors and spelling mistakes compared to my aunt.
  • Video games used to be printed on cartridges. Fixing a bug after release was nigh impossible. You'd need to reprint all cartridges, distribute them to all vendors, and hope that the vendors could somehow get in touch with the customers who already bought the game. It would cost tons of money (double the physical production cost) and would still not reach some customers. Now, in the age of internet patches, game developers have shown to be considerably less invested in testing their games so that they can avoid release day bugs, because it's so much easier to simply push a fix to every customer directly. The impact of making a mistake is minimized to a point where it's better to fix a handful of problems after the fact, compared to having to test for all possible errors that could occur.
  • I used to live in a third story apartment, no elevator, and had to often park one or two streets from my building. I hardly ever forgot to take something from my car. Now, I live in a house with my car right next to me in the driveway. I forget to take things from my car all the time.

The underlying idea here is that a difficult exchange system incentivizes people to make correct and fact-checked exchanges. The severity of the punishment (= difficult correction process) teaches you to not make mistakes.


Also, hiding away details to ask a well defined question eliminates the possibility of someone spotting problems you hadn't thought of.

When you make an MCVE, you shouldn't just create it and post it in the question. You should first make it for yourself, so that you can isolate the problem. And then, when you think the problem cannot be reduced anymore, and you still don't see the cause; then you have a valid question for StackOverflow.

Case in point:

I always have a second Visual Studio running with a simple console app called Sandbox. Whenever I run into a technical issue, I copy the offending code into the sandbox and start playing around with it.

  • What happens when I change this setting?
  • Can I reproduce the issue if I shorten the code?
  • Which settings make it possible/impossible to reproduce the issue?

In 90% of cases, I find the cause of the issue because the sandbox helped me look at the offending code without being distracted by the surrounding context (or, for example, any uncertainties about values that come for different parts of the code.

In the other 10% of cases, I am left with the minimal code to reproduce the issue, which serves as a perfect example snippet to post on StackOverflow.


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.

When you already have your MCVE, you shouldn't have much in the way of personal (or company) information in it. If you do, since the code is minimal, it's easy to rename things to a more basic foo/bar/baz example.

protected by gnat Aug 7 '18 at 11:29

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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