Where I am presently, we use pods/quads--similar to four cubicles that open up into shared middle space in which is a nice round table. We each have semi-privacy as everyone works in their corner of the pod/quad. We are close enough together that we can share ideas very easily, and have enough privacy that we can withdraw from the others when needed. All it takes is a quick roll of the chair. The centre table also makes it a convenient place for lunching together, code reviews, design brainstorming....

It might not be for everyone but it works for us.

Additionally, when populating the pods, we try to mix the new programmers into a pod with the seasoned programmers. It helps them learn faster as help (if necessary) is right there, and they can learn a lot just by listening in to the design conversations.

For what it is worth (especially this late in the game) the quality and type of comments added to the code is a combination of several factors.

1. Number of expected eyes. The more people that I expect to see it, the better the comments need to be.
2. Length of development time. The longer the code takes to write, the better the comments need to be. For some of my personal/hobby projects that have lasted for months or years, I was lucky to find 20 minutes a day to work on it. Adding comments to the code was absolutely necessary so that I could get stuff done.
3. Code complexity. The trickier the code, or the more modules/files that impact the code, the better the comments have to be.
4. Prep-work time. The longer it took me to figure out what I needed to do (and why), the better the comments need to be.

Re-reading through this, the longer I expect the code to be around, the better I expect it to be written and commented. I don't want to waste time trying figure out both the intent AND what the code is actually doing. Nor do I want others go through that as well. The better the comments in the code, the faster someone else can get up to speed on the code I have written, which means that it costs the company I work for less $$$ down the road.

When writing comments, I try to include ...the 'why' where applicable, and what it is supposed to do, and on the complex code I state
      1. The INTENT.
      2. The 'WHY' where applicable.
      3. Expected state information at various locations for more complex code.

Readability is a must. If it is not readable, then from my position it is flat out wrong. If it is not readable, you (or someone else) can not know if it is right.

If your family is like mine, they will not learn unless the cost of not learning it becomes too inconvenient. As it stands, you are probably bearing the brunt of the inconvenience. Spread it around. Each time you have to do the same things to fix their problems, charge them more, and let them know it. What you charge does not necessarily have to be $$$. Let them clean your place, yard, cook meals for you, fix something, baby sit, .... but get something out of it. You are giving up your time to fix the same mistakes of theirs time and again. This is time that you could be improving YOUR life.

This is getting late in the posting, so I don't expect many people to read this but ...

20 years of developing software has taught me that good enough is good enough. What is good enough for one project, is overkill for another, and nowhere near good enough for yet another. As a software developer, I see my job as turning code into $$$. Good enough means that you have to perform a mental cost-benefit analysis on what you develop.

  But what is good enough? That is the variable. Sure, there are twits out there who try to argue that there is exactly one level of "good enough" for ALL projects. Clearly for the products that you cite, 50% is not good enough. But for some things, if something works only half the time, it could (does not translate to will) still be useful enough to be put to use.

Over time, user demands, and competition will push the "good enough" bar higher.

... assembler programmers to be atheists?