I had asked Jonathon to respond on a warblogger quote about Japan before I read his posting today, I am very intense.

In the posting, an extraordinary exposition of self, Jonathon writes about an online relationship he once had:

We drove each other crazy. Minor issues of emphasis or tone in an e-mail led to massive misunderstandings and flurries of conciliatory messages. I longed for the unspoken understanding and emotional restraint that I’d shared with my Japanese girlfriends.



Eventually it blew up in our faces. A virtual relationship was—paradoxically—simply too intense. People told me this wasn’t a real relationship but that’s not how it felt. At the time, it seemed absolutely real. As real as the lilting tone of her voice, as real as the lingerie on her bed.

I had once asked, long ago in this weblog, can true relationships develop with people we meet online. I was answered by many that, yes, they can. Jonathon’s experience was not so fortunate.

It would seem that online relationships work well for some, and quite badly for others. And when the relationship doesn’t go well, one is then left with the question: if the connection is so virtual, why then is the pain of the loss of the relationship so real?

Jonathon, my sympathies for Pudding.

Political Weblogging

The argument in defense

Recovered from the Wayback Machine.

Oddly enough, two separate threads related to two totally different subjects and both leading to this posting.

As stated earlier, B!x posted a reference to the Weblogging Consortium idea to Blogroots. At this time, I rather wish this hadn’t happened because the idea was just something I was throwing out to see what kind of discussion it would generate in my own comments; to see if interest was strong enough to take the idea further.

Well, it generated discussion at Blogroots. Lots of discussion. It also generated a great deal of dismissiveness, from me, and from others. Anil says I proposed the idea because I’m promoting my return to weblogging; Matt says that the idea is far too idealisitic; Melody states the proposal is ill-formed; and someone going by the name of ‘watermelonpunch’ sure doesn’t like the reference to ‘weblogging community’.

I’m feeling trapped behind bars that allow me little room for movement. Result: Oh, Yeah?

Conversations shut down before they even started, for what was nothing more than a simple idea. Slam! Hear that door shut! And not just on the ‘proposal’, but also on the criticism. Playing the game “What animal are you”, I could have been a hedgehog. Bristle! Defensive manuever! Lick them tennis shoes and foam at the mouth!

Or: How Not to Keep a Conversation Going 101.

And as I was trying to smooth the quills down on my back, I stepped over to Glenn Reynold’s and read:



The problem, essentially, is that Dave came into this debate late, and he’s not up to speed. He’s a smart guy, God knows, and as entitled to an opinion as anyone, but a lot of people have been wrestling with these things in somewhat more depth. Vague, general statements about playgrounds and bullies are merely inapt analogies, not arguments. You can make an intelligent argument against invading Iraq. And — here’s the other post I don’t have to make — Jim Henley has done so. I think he’s wrong, but it’s a question of the weight you assign to various factors, which is something about which reasonable people can differ.

And this

MARTIN DEVON is echoing a question of my own: why are the arguments offered by those opposing the war of such generally poor quality? I can make up better, more coherent arguments against the war than those who seem to have made it their mission to oppose it.

And this

MEETING THE CHALLENGE: HappyFunPundit is proving that warbloggers are better than anti-warbloggers even when it comes to thinking up arguments against the war.


You can hear the door slamming in each of the quotes that I pulled from Reynold’s site. The condescension as he dismisses other opinions, the refutation of other arguments as being poor according to his standards, the very fact that he doesn’t even reference most of the other arguments — only those of like mind — are all discussion killing tactics. He is using his position of influence to control the flow of the discourse.

Rather than refute the arguments, he’s disparaging the player; surprising behavior for someone who should be skilled in debate as one would assume a law professor would be.

If I taught “How Not to Keep a Conversation Going, 101” this morning, Reynolds has been teaching the advanced course all day long.

But then, he is a professor.


The Line-of-Sight Developer

I heard the term “Line-of-Sight” in reference to certain breeds of dogs, such as the Afghan.

It seems that these dogs have this instinctive urge to run towards the horizon, and if they get loose, they’ll keep running towards the horizon at full speed until their owners catch them (fat chance) or until they run out of steam.

My brother and his family have a Greyhound/Great Dane mix dog named Hillary that’s a line-of-sight dog. The problem is that she has the speed of a Greyhound and the size of a Great Dane — not a dog one takes for a walk without a great deal of trepidation.

These pooches just can’t help themselves: they see, they do.

Odd thing, though, is that I know of developers that are like line-of-sight dogs: they see, they do. The problem is that you can’t leash these folks up, at least not without breaking several laws of the land.

The Characteristics of a Line-of-Sight Developer

How do you recognize if you work with a Line-Of-Sight (LOS) developer, or are one yourself? Well, there are several warning signs to look for.

You receive an email from another team member that they have “improved” the performance of a key element in the application your team is working on, have checked in the change and is ready to move it into production. Unfortunately, none of the rest of your team knew that the developer was working on this key piece of code, much less what the change was, and how it will impact on the rest of the application. Congratulations, you’ve just identified a LOS developer.

During a team meeting, you discuss the possibility of making a change to the user interface of an application, but decide to wait and get additional information. The next thing you know, the change has been made. You track the change down to a specific developer who states “Well, I had some time so I thought I would go ahead and implement the change”. Yup, one of the classic characters of the LOS breed is the words “Well, I had some time …”.

In an environment where clients have direct access to the developers, they always approach the LOS developer with requests for changes. You see, it’s an established fact that Clients instinctively know which developer will make the requested change without question. This ability is part of the client’s built-in survival instinct.

The LOS developer can program better than anyone else — at least, that’s their own opinion. So, they’ll fix other team members code whether the code was broken or not, inefficient or not, up to specs or not. After all, it’s a tough job, but someone has to do it.

The LOS developer: they saw, they did.

Two Different LOS Breeds

There are actually two different breeds of LOS developers.

There is the “I’m inexperienced and very eager” LOS developer. I call this type of LOS developer the “WOWIC” (Watch Out World I’m Coming) developer.

The WOWIC LOS developer brings the unanticipated changes they make to you for praise and at that point, all you can do is tell them they’ve done a good job, and give them a stock option to chew on. After all, to beat them about the head with a project plan will only break their spirit — you have to approach their training more cautiously than that.

The second type of LOS developer is harder to work with but thankfully less common than the WOWIC LOS developer. The chief signs of this type of developer is their arrogance, so I call this breed the AAH (Arrogant A**H***) LOS Developer.

You can easily recognize the AAH LOS Developer — one of their chief hobbies is to go through their teammates’ code and change it to what they believe is better code. If the teammate disagrees with the change, the AAH LOS developer looks at them as if they were an amoeba that just started to sing the “Star-Spangled Banner”. No one disagrees with The Programmer.

Dangers of LOS

Anyone who has worked on a larger application knows how dangerous a LOS developer can be. What may seem to be a simple change in the code for one application module can have disastrous effects on the application as a whole. If the change is in shared code, the developer has a responsibility to inform others before making the change. Better yet, the change should be incorporated into a staged development rollout, to ensure appropriate testing.

Another danger of the LOS developer is to the morale of the team. If you have a developer, particularly an AAH LOS Developer, grabbing other people’s code and changing it without legitimate cause you’re going to have dissension in the group. This type of behavior is discourteous. This type of behavior is costly to the development effort. Really, this type of behavior is just plain rude.

To make changes daily or even weekly and just plunk the code in without a plan only disrupts the work of other developers. I’ve found that any language that supports class inheritance, such as Java or C++ is particularly susceptible to this type of “ad hoc” code changing.

Is there a cure for LOS?

As stated there are two breeds of LOS developers, so there are two cures.

Having a well-established change control system and good software development procedures in place are about all you need to train the WOWIC LOS developer. They’re eager to please so showing them that good programming practices and teamwork support are just as valuable as lines of code will get the point across, quickly.

How about the AAH LOS Developer? Well, sometimes all you have to do is tell the AAH LOS Developer that they’ve tromped all over the team’s code and to please not do so in the future. If they’re more arrogant than A**H*** this could work.

However, the best approach with the AAH LOS Developer is to again set procedures in practice that curb the more I, PROGRAMMER urges of the AAH LOS Developer. In other words, track what the person is working on, and keep them busy enough with their own assignments to leave other people’s work alone.

Oh, did I mention that you need to have good programming practices, change control, and well understand project plans in place? I did? Just wanted to make sure.