Actually, there are more fatal traffic accidents for the next several weeks after the switch to daylight savings time. Basically you get sleepy pedestrians and stressed, running late, sleepy drivers both navigating the roads during darkness and at the same time with the expected result of more pedestrians being hit. In car-pedestrian interactions of this sort, it's usually fatal to the pedestrian.

Cheers,
Dave

My perl looks like my C that looks like my FORTRAN.

Cheers
Dave

Explain that to the families and friends of all the people who die each year due to the switch to daylight savings time.

Some of us have a very hard time forcing ourselves to get up an hour early. When you put all of us who have that issue on the road at the same time and all suffering from lack of sleep, bad things happen. You can belittle the problem all you want but daylight savings time KILLS people.

Cheers,
Dave

I'm still waiting for FORTRAN to make a comeback. And none of this sissy FORTRAN 77 or FORTRAM 95 stuff either; real FORTRAN IV. If I wanted to program in something that looks like PL/1, I'd program in PL/1.

Cheers,
Dave

Sometimes I actually find it amusing when people criticize some unmentioned, tangental aspect of an assertion and then don't bother to connect what they've said or offer an alternative. In your case it's just sad.

Cheers,
Dave

"Ah, but teaching them coding is a vehicle for teaching them logical problem solving," said the ex-math teacher in rebuttal. I used to use the same rationale for explaining to students why they needed the logical problem solving abilities they were learning in my math classes as much (if not more) than they needed the actual math techniques. I don't know how you would teach "logical problem solving" without some vehicle like math, programming, etc.

Cheers,
Dave

In any technical project requiring more than a few people a small number of the people assigned will gradually emerge as the technical leads, the alpha geeks. This isn't by designation. It's a meritocracy in action. Even though there is no official process, the results are fairly objective. Lower levels of management retain some vestiges of requiring technical competence but, the higher you go, the more the results of who gets promoted are governed by how well an individual shmoozes, kisses fanny, acts as their own PR and other subjective qualities. It is very difficult for higher management to differentiate between an easy project and a competent manager or a hard project and an incompetent manager.

If the above situation isn't enough to keep good engineers from becoming engineering managers, the reward you get for moving to the management track is technical obsolescence. The only thing you become qualified to do is be a manager. In larger companies the only thing you may be qualified to do is be a manager at that company since the bulk of you time is consumed by navigating the arcane bureaucracy that you are part of.

Cheers,
Dave

http://www.despair.com/consult...

Cheers,
Dave

My wife and I have been remodeling our house one room at a time so I know exactly what you mean about houses, cars and any number of reasonably complex consumer products. On the other hand, Microsoft is a company that has perfected "close enough" in software. I started off working in the DoD software world where a much higher standard was expected of any product and don't even get me started with regard to "man-rated" software where a failure could mean loss of life.

Cheers,
Dave

You don't use many Microsoft products...

Cheers,
Dave

Real example:

I was working on a radar project. The spec for the tracker had an error in one of the equations used for converting from doppler shift to actual velocity. The programmer coded it as it was in the spec. We didn't discover the error until testing showed some simulated tracks zooming off at mach 10. First thought was that the programmer made a typo. Programmer showed that the implementation matched the spec. No doubt about the spec until the test results showed a problem.

Programmer scew ups are usually met with an "Oh shit. I can't believe I did that." Other bugs usually take significant effort to uncover what's wrong. It remains an open question as to who is responsible when something like an API is part of the problem. My take is that if the programmer chose to use a particular library to solve the problem at hand then the programmer has a responsibility to confirm that the code plus the library actually solves the problem (e.g., unit test). If the API is inflicted on the developer by management then management has a responsibility to ensure that the API does what is claimed.

Cheers,
Dave

Having spent about one-third of my career in software QA, it's really not that hard to tell which bugs are programmer screw-ups and which ones have a deeper cause. Although there is that grey area where the programmer didn't understand the underlying system or some interfacing system because the documentaion sucked.

Cheers,
Dave

or the design of the foundation is incorrect, or the client wanted a wooden wall instead of brick, or the brick manufacturer changed how the bricks are made becuase of a change in the brick standard, or the bricks had to be changed because they were found to be vulnerable to attacks by clay termites, or ....

Bugs are rarely just he result of a programmer screwing up.

Cheers,
Dave

Inexpensive ear plugs work reasonably well. I've actually been glared at by the parent(s) who seemed to think entertaining their spawn was a public requirement as I stuck my ear plugs in my ears. Personal music works, too, but may harm your hearing if loud enough to drown out the kid. Back when you had to turn off such things during climb out and descent was also a problem.

Cheers,
Dave

Cost. The phone in the back of the seat cost about a dollar a minute (or more) to use. Great for making a quick call to someone to say your flight changed, was late, is early, whatever. Not good for chatting inanely. Self-limits people wanting to just yak continuously.

Cheers,
Dave