I felt
A great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced.
Our senior technician has retired. He is irreplaceable. His skills come from a different era, and are no longer being taught by anyone, and are no less imporant for that.
38 comments Og | Uncategorized
This will happen where I work when I leave or retire. There is simply no one left with my institutional memory.
Indeed. All that tribal knowledge, gone.
So buy a modern PC and stop using MS-DOS.
(sorry about your friend). So much is changing in this country. Rule of law is dead. I have to shake my head in wonder at what could possibly be next.
Really? That’s a disconnect with reality I rarely see. The skills we have just lost are as important to 30 year old machines as they are to machines that have yet to be built. This is not about buggy whip manufacture, but the ability to solve problems. Tribal knowledge is less about facts than about processes
I work with people 25 years my junior. They never had to set an IRQ jumper or terminate a SCSI bus. Probably they never will. But they’ll also never have the troubleshooting skills I learned from having to figure out why that old crap stopped working; and most of them look at me like I’m crazy when I try to explain something to them in hopes that they’ll find it useful one day for solving a problem which can’t even exist with today’s technology.
Rejection of the old in favor of replacement by what is new … isn’t that just generating sales income for your company? In most business settings isn’t the emphasis on selling the new over maintaining the old? “Planned obsolescence” is just good business as far as most companies are concerned. Yes, they probably could get along for a long time or maybe even forever with what they have … but your sales force ain’t in business for that.
Just saying.
Jenny
Many companies want to know that their investments are supportable and will be supported for as long as they are otherwise useful. The only proof of that pudding is in the ongoing maintenance of existing equipment. A manufacturer’s tech standing there scratching his head with no one to call is not confidence-inspiring.
And, for what it’s worth, there’s a lot of money to be made in maintenance and upgrades to existing equipment. That sale is a lot easier than a multi-million $ capital expense.
Jenny: nothing whatsoever to do with obsolescence. Troubleshooting skills do not become obsolete.
As I’ve noted before, I’ve been a programmer/analyst for 30 years. I come across supposedly experienced programmers who don’t know how to test programs. I had a woman once (who I was leading) tell me her program compiled clean, and that I should look at her code to prove to myself it would work because finding test data and running it would be hard.
I’ve spent my career believing that if it hasn’t been tested, by definition it doesn’t work. A good percentage of the time if it HAS been tested it doesn’t work either, because there are two types of programs, those that are working but have bugs, and those that don’t work at all.
The real reason the dinosaurs went extinct is they got tired of listening to crap from idiots.
Dad taught me trouble shooting on cars.
It needs a spark and fuel. Does it have a spark? Does it have fuel? Are the spark and the fuel getting there at the same time? If you have all that, the engine is running.
Creating test data was one of my jobs about ten years ago. I would give programmers the specs for the code and the test data set to prove it worked at the boundary conditions.
Wrong again, hale. You need fuel and compression. Diesels run without spark, no recip engine runs without compression.
Man, I hope we get to meet face to face someday. I can’t wait to find out if the bear is as much fun to poke in person as on the internet.
Prof Hale: I’ve encountered a few engines that were getting spark and fuel, at the same time, and weren’t running. Clogged air intake comes to mind…..
It was a pretty good explanation for a ten year old who wasn’t working on diesel engines. I got Boyle’s law later.
And I’m much more fun to poke in person (in a non gay way).
Prof Hale: If you provide specs and test data, all you’re assuring is that the program works for your test data. Ideally test data should come from a third party not involved with the coding or developing the specs (but who should understand what the specs are intended to do), but unit test data should come from the coder.
Interesting concept. I will bring it up with the guy I used to work for ten years ago, if I ever see him again. I think he is dead.
I created the test data because I cared that the program would work for those specified conditions. And I didn’t care about the non-specidied conditions. Mostly boundary conditions changes. Changes in the inputs that I knew should trigger changes in the outputs that I could track.
If I had a dollar for every time a condition nobody cared about came back to bite us in the buttocks, I could retire quite comfortably. Murphy’s Law is always strictly enforced. I’ve had many late night phone calls and interrupted nights of sleep because things that couldn’t possibly happen did happen.
Yeah, you can always write code around shit you think may happen. It takes a real sick bastard to write code against the unimaginable.
Hey! My parents were married!!!!
Lol. Sometimes bastard is a state of mind.
I try to make my programs completely foolproof. And they keep coming up with more determined complete fools.
I will only ever poke you in ways that can never be misconstrued as gay.
We saw the same thing in the military (specifically Naval Aviation….but I am sure the other branches and subsets had their versions as well). When the F/A 18 was fully in the fleet and operational. It was “troubleshot” via computer, and (of course) a specific program was developed to do so. If you followed what the program told you to do, to fix the “problem”, and it worked…great! If it did not….well, lots of us old timers were asked “What do we do now? We keep trying to fix the aircraft, but the problem doesnt go away when we do what it tells us to do.” Basic trouble shooting is (was) no longer being taught. All the (avionics/anti-submarine warefare/electronic counter-measure) techs at all level of maintenance were being turned into black box changers or card changers as the case may be. Systematic troubleshooting was not being taught…and the tools for being able to do so (indepth schmatics and flow charts) were no longer being included in the appicable tech manuals. (One of the reasons I only made it to one tech pub review…but that is a story for another time.)
Perhaps it is better onboard ships at sea, away from the fantasy world of make belive the folks who foisted this on the military (and the military along with their DOD civilian counterparts, who were in a position to either buy or approve same) that this was the way to go….should all be run outta town on a rail….
Oh, lost corporate/institutional/technical/”how to” knowledge … naaa, we are better then our predicessers, we will never have to “re-invent” that wheel…
Just today, used the “included tools” to troubleshoot. “If it throws errors, replace the terminal.” That didn’t stop a good terminal from throwing errors. Next step? Data cable replacement. Fixed and working! Somehow, with no movement, under a counter, it failed.
Not even mentioned in the support documentation. We are to follow the docs without question, but they are written by folks WITHOUT field support experience. We jumped the shark last year…. Just a matter of time till our customers find out.
Sadness…..
Users. The bane of all code.
After 30 years of software engineering, my employer saw fit to replace me with a couple of hindus. Maybe also because I told them the software they purchased wouldn’t fit the business. 3 years and several million dollars later they still have to make it work. Makes me smile every time I think of it.
Youthful enthusiasm in the wrong level of management can be expensive.
I’ve been the victim of that too, don, and I concur about youthful enthusiasm in management. Nothing deadlier.
Don, I made the mistake of telling the vp who bought it, it would not work. 5 years later they have not as yet replaced the software they bought the program to replace. They are now trying to develop a replacement in house.
I have long since moved on, but it still tickles my funny bone.
youth is wasted on the young.
When I first enlisted in the military, every vehicle had a “Dash 10”. The manual for doing checks and services at the operator level. It was called the “Dash 10” because the manual numbers for operator, mechanic, 3 Shop, etc were all the same except for the last two. Operator was 10 level, Mechanic was 20 level, so on and so forth. Anyways, the Dash 10 was good for figuring out what was wrong, and if you could fix it. Granted, a lot of times the fix was above your level, but you could at least tell the mechanic what was wrong.
Fast forward almost two decades. I’m going out to the field after several years behind a desk. We’re borrowing trucks from a different unit. I tell one of my troops to grab the Dash 10 so we can do our start-up PMCS. (Preventive Maintenance Checks and Services). He gives me a glass-eyed look. “The manual, kid. Where’s the manual?”.
“What manual, Sergeant?”
You may insert a rant of your choice regarding youth, military senior leadership and training if you wish. What I said was unprintable and probably too long to transcribe.
“the skills we have just lost are as important to 30 year old machines as they are to machines that have yet to be built. ”
Same with software. Doesn’t matter what latest framework, agile-scrotum processes, or .whatever you’re working with, trouble-shooting, problems solving with large complex systems and many fools tinkering with it are universal skillz into the near future…maybe the far future…
Ragin Dave. I grok you man!! Sadly, it isn’t the “kids” falt. You hit the nail on the head when you mentioned senior military “leadership” (yes, those are indeed scorn quotes).
I’ve been a code slinger since 1996.
I have always said software is a craft not an assembly line.
These days I’m looked at as a heretic when I say so.
Patrick Kelly: I’ve made most of my 30 year career as a programmer/analyst with my trouble shooting skills. I’m the first to admit I’m not a great developer, but give me a bug and I’ll step on it.
When I first came to my current job 16 years ago they handed me a problem they’d been trying to find for YEARS. Everyone in the office got a crack at it, no one could find it. Basically, payments were coming into the system and disappearing, never hitting the database, never showing up on exception reports, just being dropped. Only a couple payments a month out of thousands processed. So I started by capturing EVERY payment before it hit the system, then after the payments were posted I checked EVERY payment to see if it had been posted. Once I found one that was dropped (took about a week before we hit one) I traced it thru, found that the vendor hadn’t updated all the fields properly, especially the field we used as an end-of-package marker (a close-out record if you will), so the system thought it was a marker record and never processed the payment. Contact the vendor, tell them to stop doing that, problem fixed.
In other words, I found a problem that had plagued the system for years, that everyone in the office took a stab at and couldn’t find. And I found it before I collected my first paycheck.
“I’m not a great developer, but give me a bug and I’ll step on it.”
I’m stealing that for my resume…..
What little self promotion I’ve done as a programmer usually involves presenting myself as a fire fighter and bug hunter…..charging in where others fear to tread……stubborn perseverance both my greatest weakness and strength….for pinhead interviewers who still ask those cookie cutter questions….
That is a good line.
“for pinhead interviewers who still ask those cookie cutter questions….”
I once saw an ad for a job that insisted on five years of experience with a product that had only been OUT for three years at the time. I had an interviewer once spend the entire interview asking about what team sports I played in college (none, I was busy, you know, STUDYING). And I had a headhunter tell me that if I learned (web-based programming language of the week, I think it might have been C# at the time) he could get me a job making about half what I currently made. And of course he’d help me with my green card, which I didn’t need because I’m a natural-born citizen.
I was once turned down for a consulting job because the account rep told the client that, although I didn’t have experience with Fortran, I DID know PL/I, and the two were basically the same language. The client (predictably) found out he’d been lied to and told me “We won’t be doing business.” Mind you, I TOLD the account rep I had no Fortran experience, but that I thought I could handle it.
I’m convinced that some people become recruiters because they lack the moral fiber to be pimps. Yeah, I know not ALL recruiters are scum, but my experience is that 90% of them give the rest a bad name.