To *think* like a programmer you must have that sense that Murphy (of the law) is inside you [ie. Be humble no matter how clever you are] and in the real world [eg. A valid date might be 'June' which isn't 00:00 on 1st June]. An age ago when I wrote my book on the subject (text freely available at http://vulpeculox.net/ob/Programming.htm) I twigged that programming is not about splitting problems into bits but understanding the need then building the solution from bits. Of course there are well-known methods for doing this. Now to me a programmer is a mental athlete. I expect them to train, have good facilities and consistently run good races but why on earth would I expect a high performance person to be operating at their peak 7.5 hours a day? Resting, recuperating and reflecting goes with achievement. Enthusiasm and interest in the next challenge keep up the momentum. Constraints and management targets destroy it. Once you've got the mechanics you can graduate to the principles then the patterns then the practice and finally being able to communicate with people.

Young brains at work with basic materials that are tedious to work with MAY result in mega-technological-breakthrough or not. As most of us here are concerned we left our machine code/assembler/etc behind us 20+ years ago so who are we to judge? The way 'progress' has worked means that a very fey possible choices have been followed. These may not have been the best.

And while you're pooh-poohing 'wasted effort' in bare-metal computing ask yourself what proportion of 'programmer-man-hours' (rough term) end up being wasted at high-level modern day systems? And for those that are implemented that don't cause grief, how long do they last? Of course some pootle on quietly for a very long time, but many never hit the mainstream or if they do for a short while until revision or abandonment.

background There are three types of personality who get a buzz from different things and are comfortable with different things.

• (Left) Techie - "Leave me alone so I can get this right"
• (Middle) Admin - Risk adverse, likes routine, satisfied by servicing the organisation
• (Right) Outward facing - Likes external challenges. Satisfaction can come from good relationships or 'commission'

People don't have to be compartmentalised but often they will find their niche and want to stay there. ( To read the detail see http://vulpeculox.net/treems/LRC.pdf )

You can imagine the conflict when the sales people are desperate to have something they can demonstrate but the engineers don't want to release something that is buggy and not ready yet.

Possible answer part 1 Get the sales bods to talk to buyers and let techie speak unto techie. Each will be experienced and effective communicators in their roles. Obviously this requires team work - perhaps you should 'assign a techie to a sales bod' and see if they can work out how to complement each other.

Possible answer part 2 Pay sales people for getting the business and techies for delivering. If both understand their interdependence then they may work together.

I have researched this. The answer is at http://vulpeculox.net/treems

• Limited bandwidth makes it better to get to know a few people really well
• Management oversight is more difficult so build mini-team responsibility and development and ownership of objectives
• Make sure people are in the part of the organisation that suits them (see link above).
• Provide separate communication protocols for gripes and discussions as opposed to getting the job done. (You need a 'grumblee' to be a lightning conductor for things that might get worked out in physical corridors.)

When you're remote everyone needs to feel valuable, cared for by the organisation and spared annoyances.

Never heard of LEET before. But I do know what "internationalisation" is ... normally abbreviated to I18n.

When IP addresses are abundant block lists are going to be huge and still ineffective. A naughty downloader (or uploader) can have the server allocate an IP address just for them, and change it in a few minutes time.

I can't think of a better example of the resilience of open source.

Also, once you have a lot of devs around they may take the 'application' to 'other places'. I'm thinking that word processing has only really ever addressed the 'front-end' of documents when there is a huge need for the back-end document management (what we old-timers once called office automation).

I went to ds.test-ipv6.com and was amazed by the clarity of explanations of the various tests. It gave me a technical result and a 'what that result means to you' which I could understand.