More detail please
"some the size of fridges"
What kind of fridge?
11 publicly visible posts • joined 31 Jan 2007
Not very interesting research.
Being a believer (and leaving the question of my intelligence as an exercise for the reader) I can't say I buy into it much. Not really a suprise, I suppose.
If the research says that the more intelligent you are the less likely you are to believe in God, it surely follow that the less intelligent you are the more likely it is that you believe in God.
Now, go into your local town center and find a decent sample of the most stupid people you can find (measured in a way separate from their religious beliefs) and count how many are devout followers of one religion or another. I don't know, but I'm fairly confident in my guess, that there won't be a high percentage of believers.
Maybe belief isn't linked to IQ after all.
No IT angle, no science-y angle and no Paris angle. Is my disappointment in relation to my intelligence also?
I can't agree with this article either. The easiest methods to read are the ones that are shortest and clearest. So the example;
<code>
if (account != null)
{ // 20 lines of code
// (that are totally irrelevant if account is null)
// later...
}
// and out we pop
</code>
is actually a bad one. My rule of thumb is that a method shouldn't be longer than the height of the window it's displayed in, but I would say that even a 20-something line method is probably too long.
Also if you have a method with "excessive nesting of "if..else" " then I'd also say that such a method would be (more) difficult to read than a series of methods each of which dealt with only one condition no matter the number of exit points.
It should be refactored to remove the excessive branching regardless of how many return points there are.
In my experience, once your methods are of a suitable length and simple (which is a personal quantification) you're likely to find you have single return points anyway.
You're right about exceptions though. They're dangerous and overused. They should only be used for, er, exceptional cases and are vastly overused by all and sundry.
Why not have all MPs "work from home", where home is actually some kind of super-secure facility (no windows or doors).
This has the following benefits;
- Reduces the strain on the police - no more having to follow daft MPs around
- Reduces need for uber-security in a high-traffic building
- Keeps the MPs safe, I recommend burying their compound somewhere
- Introduces another IT angle for the Reg to report on
- It keeps the MPs out of trouble since their new home-from-home only has media-safe entertainment facilities
- The public knows where all the MPs are incase we need to do a quick bit of revolution-ing
Obviously, we would need some kind of Web 2.0 mobile flying MP-Bot for when they need to visit other places. I figure this MP-Bot would be customisable depending on current project; there's the baby-kissing interface, the finger wagger, the hand shaking attachment, machine gun etc.
Thinking about this, can't we use our extradition treaty with the US to our advantage? Maybe set up some kind of office over there to have our British criminals sent over there?
It worked however many years ago with Australia... I suppose the most important risk with this strategy is; do we want American's beating us at cricket?
We need more police on the streets with the ability to deal with crime as they come across it.
Let's see how much crime* we see when we have squadrons of death-dealing Judge Dredd types patrolling the streets.
Who do I speak to in order to apply for that kind of job?
* According to current legislation rather than any new ones la-buh can come up with
Most* programmers don't work on really interesting, exciting and clever things. Most* spend their time in banks and large enterprisey corporations "doing IT". In these situations pair programming works because the emphasis is (or should be) on quality, reliability and maintainability. Even if it takes a pair longer to implement some method than a lone hotshot Rockstar programmer, these benefits remains.
There appears to be some kind of snobbery among programmers** who consider themselves to be faster/better/more efficient/more clever then other developers. Their attitude (at least as I have experienced) is "Why should I share with you?" They miss the point that they're employed to write code that is quality and can be maintained by a _team_.
In some cases, e.g. contractors, the focus may instead just be "implement this as fast as you possibly can" in which case pair programming isn't the way to go.
Obviously intelligent decisions need to be made between "need it now" and "need it good". But to throw out pair programming just because "I can do it faster on my own" is just plain daft.
As an aside; Brennan's cybernetic principle is actually an argument FOR pair programming. Yes, if you have a plastic gear and a metal gear after time the plastic will start to degrade and get stuck to the teeth of the metal gear. But if the Senior Developer is modelled in plastic and the Junior is modelled in metal then you're effectivily saying that knowledge and (hopefully good) habits have been passed down the chain of experience. The analogy now fails because the Senior Developer still has those good habits and knowledge, whereas the plastic gear now has no teeth.
* I don't actually have any figures to back this number up, but it feels right.
** Note the difference between "programmer" and "developer"