Electron-to-joule conversion formulae? Cute. Welcome to the school of hard knocks There are some things they don't teach you in college, as a Register reader explains in this week's instalment of tales from the On Call coalface. Our reader, safely Regomised as "Col", headed up the technical support team of a PABX telecom provider and installer back in the early 1990s. PABX, or Private Automatic Branch …
Once I stopped by a PFY trying to fix an user's Access application that had stopped generating email reports. He was at wit's end, having tried for hours everything he thought might possibly solve the problem. I nonchalantly asked the user if IT had done any upgrade that day. "Hm yes, they installed new printer drivers".
Ah.
After changing the default printer to PDF, the emails started once again being generated. It seems Access (at least the old version in this case) needs the printer driver to generate reports, even if they're not being actually sent to be printed.
The number of times I've dialled into someone's pc to troubleshoot something and the person at the far end exclaims "ah, i should be able to print now..." and, without warning hits the print button, has been reamsworth. "Oh? It's still not working." Me: "Not there it's not, but it's coming out fine at my end."
We were developing some military kit. Hardware dev. in UK, s/w in US. The US had a mock-up rig of the h/w so that they could debug. In the UK we were always having problems which the US couldn't replicate - startup fails, BSOD, etc. They blamed us, of course, and things were getting rancorous. In the end they sent some SW engineers team over to find the problem. After a fair bit of work they found that the SW configuration of our kit was different from the mock-up in the US. We'd obviously been messing round with it, which wasn't allowed, and heads were going to roll.
The US team had a support contract with a UK company to maintain/repair the servers, processors, printers, etc. Turns out that when the support company sent someone to check or repair something they also did a scan of the system and updated any drivers that were out of date. The support contract had no means of ensuring that changes like these were either authorised by the US or mirrored in the test rig. Since the US company was responsible for the contract it was their fault. US heads never rolled and the Yanks never apologised.
We had some cellular image processing software which would write out details for each object (eg cell or nucleus) it found to CSV. It worked fine on the Linux workstations but when we tried to get it running on the HPC cluster it wouldn't write anything out and the scientists were getting a bit grumbly...
It turns out that the software required the MySQL client to write out CSV files, oddly enough the client wasn't in the cluster's image...
They're great for recording battery charge/discharge cycles, etc.
Only problem is: the proprietary Fluke software necessary to download the data from the meter requires Excel to run. It's too lazy to do the graphics and UI itself, so it outsources it to Excel. Which is great if your lab computer has Excel, but not so great if all you want is a CSV file to run through your own processing, say with Python or Maple.
And they have the nerve to actually charge for this software, as if the price of the meter wasn't enough.
God help you if your lab computer happens to run Linux or if your Corporate IT department (in the interests of security, of course) prohibits things like network-connected lab computers (which, I suppose, is a whole different problem).
Ugh... mamy moons ago I had a Linux system generate a nightly report. A script (probably PERL) queried a MySQL database and sent the results to our customer by piping the output to Sendmail as a .csv.
Worked great for a year or so, then we were bought out by another company. Our new IT overlords moved our email to Exchange, which decided that my plain text emails were boring, and mangled them (I think it actually tried to wrap some HTML) which broke the customer's input process.
IT said it's my problem, because the resulting email was "valid SMTP".
One "enterprise-level" customer of mine would slam their global printer configuration down to your PC as soon as you connected to their VPN. Being a lowly contractor I didn't have permission to print to any of them, and I had no desire to send random printouts to unsuspecting users in an office 500 miles away (oh the mischief I could have caused...)
I was having seemingly random freezes in Excel, I'd open it, start using it, and soon enough it would freeze for 30 seconds before returning as if nothing had happened. Initially I thought Microsoft had discovered a way to get cell A3 addicted to Spice.
Turns out the fault was triggered the first time Ctrl+B was pressed to make a cell bold.
This causes Excel to load a new set of font metrics. The fonts are somehow linked to the printer driver (a hangover from the pre-TrueType days perhaps). So it needed to initialise the printer (via a VPN and a blocked firewall) to measure how wide a bold "A" should be.
I soon learned to reset my local printer choice every time I connected to their VPN...
Not entirely true. They count on the paper the HR drone looks at.
Someone with a decade or more experience in the field will always know the incidental things that no university course can possibly teach (since the teachers do not go on client site), and will therefor be able to evaluate the total environment of the problem to find the real solution.
My grandfather used to create foundations for buildings. This often meant pumping out the water from the holes in the ground.
A Newly Qualified Engineer connected a pipe to the pump, and nothing happened.
My grandfather said turn the pipe round - end to end.
NQE: No - it can make no difference
Grandad - just do it.
NQE: It works!
There was a lining to the pipe, and which had got detached at one end. If you pumped the right way, the lining became smooth and lined the pipe. If you pumped the wrong way, the lining collapsed and caused a blockage.
As Grandad said "teaching new dog old tricks!"
The pipe is necessary, they were pumping water up out of a foundation, if the pump failed or ran out of fuel nothi g runs back down the hole.
Considering those pumps could be running a 6" or bigger tube, it would be a pain if the hole fills back up.
That is also why the outlet on a lot of site pumping uses layflat.
We must also remember that a novice view on a problem can be embarrassingly accurate. We had a very large gearbox where the oil pressure-sensors indicated a major problem and the control system correctly prevented start-up. Blocked filter? Faulty pump? Pipes wrongly configured? Sensors faulty? Control fault?Wrong oil? Missing components? With the whole assembly in pieces several times, components replaced, reassembled and much scratching of heads, the new graduate asked if the by-pass valve might be incorrectly configured. After all, the handle could be placed in two ways...... "Don't be daft. Cup of tea would be good". They must have found the real problem whilst I fetched the tea because the system was up and running when I got back.
Where I used to work there was a microscope that connected via optic fibre to some hugely expensive card in the back of the PC. To make it work you had to connect in the wrong way round to the markings on the card. I have no idea who it was who worked that one out...
"To make it work you had to connect in the wrong way round to the markings on the card. I have no idea who it was who worked that one out..."
At some point you just say "screw it " and try everything. If the thing is busted, hooking it up wrong isn't going to make it any worse (that you care about).
"It is necessary for technical reasons that these warheads be stored upside down; that is to say, with the top at the bottom and the bottom at the top. In order that there may be no doubt as to which is the bottom and which is the top, it will be seen to that the bottom of each warhead is immediately labelled with the word TOP."
British Admiralty, 1960s.
Quoted by David Langford - The Leaky Establishment
Icon for obvious reasons. Good funny book.
At school/college I was shown how to do a clove hitch... simples... make two loops, cross the loops over, slide them over the post
Back out in the big wide world, I was then taught the PROPER way to do a clove hitch... after all, "how do you pass those loops over the top of a tree or telegraph pole?"
Reminds me of a joke:
A mathematician, an engineer, and an English teacher were asked to measure the height of a flagpole. The mathematician and engineer started a long debate on the best and most accurate method - measure the shadow and sun angle? Place object of known height in front of flagpole and compare the apparent lengths from a distance? Etc.
In the meantime, the English teacher pulled the pole out of the ground, laid it down, measured it with a tape measure, and put it back. The mathematician turned to the engineer and said,
"That silly English teacher measured the length, not the height!"
Back in the day, there was supposed to be a test question:
You have a Mercury barometer. How would you use it to measure the height of a building?
There were several off the wall answers, such as tying a tying s tying a string to it, lowering it to the ground from the top of the building and then measuring the string.
One of the best was... Go to the building engineer. Tell him, "I will give you this fine barometer if you will tell me how high this building is."
---
For a bonus, a test my father used when he taught electrical and electronics systems to Maritime Service Cadets.
You are on an oil tanker. You have a ohmmeter, a weight and spool of wire. You are by the inspection port of one of the tanks (of which you know the dimensions). There is some oil in the tank. Under the oil is some amount of sea water. Determine how much oil there is in the tank.
Building height:
Measure air pressure at ground level. Measure air pressure at top of building. Subtract. Use a table that correlates air pressure change to altitude to get a rough idea of the building height.
Tanker:
My first thought is to tie the weight to the spool of wire, connect ohmmeter to wire and side of tank, and slowly lower the weight into the tank. First change in resistance would be the top of the oil, second would be the seawater level.
Of course, "under the oil" (and tanker) is the seawater of the ocean, which may be what he was talking about...
You are on an oil tanker. You have a ohmmeter, a weight and spool of wire. You are by the inspection port of one of the tanks (of which you know the dimensions). There is some oil in the tank. Under the oil is some amount of sea water. Determine how much oil there is in the tank.
Ok, I'll bite - I can think of a way that involves two weights...
Attach one weight to the wire and drop to the bottom of the tank. Cut the wire and attach the loose end to the ohmmeter. Attach the other end of the spool to the other side of the meter, attach a weight to the other end and slowly lower it into the oil. When the measured resistance suddenly drops, pull the second wire up, and measure how long the oily bit is. That gives the depth of the oil. Multiply by known cross-sectional area of the tank. Don't get blown up by any electrical discharge igniting the petrochemical fumes.
A tiny radio studio in South America - no more than a basic room in a shared, largely residential, block of flats had problems with an upstairs neighbour stomping around in hobnailed boots and generally being a bit noisy.
They asked me to look at the sound-proofing, as the normal solution (acoustic box-within-a-box) would have been both expensive and would have significantly shrunk the available space. My solution? Buy the neighbour a nice thick rug... cheap, worked a treat, and he though the studio was wonderful and sang their praises.
We had a technical person who was great at solving problems. He had a photo on the desk next to him, (I think it was of his dog). Before you could ask the person a question you had to ask the photo of the dog - it was said to have an 80% success rate!
The conversation went a bit like
"Hello Dog, this feels really stupid, but I have a problem where... ah I know the answer". Score +1 to the dog.
This was because if you had to explain the problem in simple terms and get your thoughts in order, you often could solve the problem yourself.
I read an article where it described if you are looking for something, ask yourself the question aloud "Where is the ..." this causes a different part of the brain to be used, and bypasses the temporary blindness
"Sounding board... I've been the one to listen to the users issue, and ask them to walk me through their issue, only to have the coin drop and resolve the issue themselves! That's a Win-Win!"
That can work well or they might ask you the question that makes you look at the problem from a slightly different angle and get your answer.
https://en.wikipedia.org/wiki/Rubber_duck_debugging
Although, with me, it's not a rubber duck I talk to but a non-programmer. I've lost count of the number of times I'd be explaining a knotty coding issue to someone when they'd notice the light coming on behind my eyes. "Gotta go!"
I'm a PM with a technical background but definitely not a developer. I always encourage devs who are struggling with a thorny issue to describe the problem to me, If they spend the time to describe what they are doing in terms I can understand then they almost always have the answer before they have finished talking.
If they get all the way through and we don't have an answer they have enough detain for us to get the team together and we'll walk through it until we find a solution.
Invariably they will have uncovered something during our discussion that will give someone else an insight that leads to a fix, often a quick chat between two developers leaves a lot of assumptions about what's been done, sometimes we do need to go down into the detail, even walking g through the code to get a resolution
The opposite.
Two guys in a team were having a technical discussion and could not resolve which of two solutions to use. They went to their manager. They had a meeting to discuss it, and after a while the boss said, I think you've made some progress, go away and work on it. Come back in 2 days.
The same thing happened, and again.
I heard the two guys complaining that their manager was useless - he didn't decide which solution to use. Totally useless etc. .
Eventually they came to a decision.
The manager said you are both experts in this field, how did you expect me,who only knows the concept to make a technical decision. My job was to get you guys to resolve it.
Afterwards (this was down the pub) the two techies said "he's right. he should not have been asked to make the decision. His job was to make us decide. Perhaps he is a good manager after all"
Ah, yes. I used to refer to that as "Teddy Bear debugging" ...
... until the fateful day when I turned to my colleague, explained the problem, worked out the issue and then, while he continued to remain silent and with no further context, I announced "You are my Teddy Bear".
I briefly considered exiting via the window.
I think "you are my rubber duck" would have been better, but still weird
I do that with crossword clues. The act of reading the clue out loud makes you hear it as well as read it, and a different part of the brain thinks about it and bam you have the answer, often before you've finished reading the clue out, which annoys/frustrates everyone who's listening.
Reading aloud can sometimes work when trying to make sense of documents in a foreign language. At one place I worked we occasionally got technical specs in Italian; we didn't need to fully understand them, just be able to tell if they were what the supplier had claimed. None of us in the team spoke Italian (and this was before Google translate, et.al. was available). We found that reading parts aloud in a mock/comic Italian accent actually made enough clear to know what we needed.
It's a bit like Greek. I know the Greek alphabet because almost every letter has been used in some technical/mathematical/scientific context. If you read a word aloud it often becomes understandable, when the written form was - just Greek! I found the same with Cyrillic, once you know how to sound the letters. Most European languages come from the same stems and, whilst you could never use this technique in conversation, it's often been useful. Of course, if you only speak English, you have the advantage that almost everyone else you're likely to meet (in the business or technical world) will also speak it. Not an excuse for not trying to learn some of the local languages when visiting...
Context, context, context. My team often sees problems reported in German, French, Spanish and Portuguese. Italian, not so much. We've been dealing with the same set of products for so long that we can all read the problem reports pretty accurately before the official translation arrives. Not one of us can actually speak any of those languages.
Yup once you transliterate Restaurant into Cyrillic you get the Russian. Lots of Russian words are like that, there’s heap of Latinate/German loanwords in Russian. Crack the Cyrillic and they leap out at you.
And most of the maritime idiom is derived from Dutch (a result of Peter the Great spending time in the Netherlands).
I heard of a company that had two developers who always pair programmed. One seemed to do all of the actual development and the other just sat and listened. The company considered sacking the developer who appeared to be doing nothing. But then they realised that these two were achieving far more than any other two developers were able achieve individually.
That's actually the sign that you have put together a good team: they are collectively far more productive than the individuals would have been.
Personally, I prefer to use the other metric this generates: it's fun to work in and with such a team, and the team enjoys this too. It's stupidly addictive to work in such environments, for all the right reasons.
Naturally, this requires management that sees staff as people which is unfortunately rare.
I ask the Pixies.
I know it sounds mad, but if I've lost something I ask the Pixies to help me find it. They don't hide things, its me who does that by accident, but they know where they are. Last time I'd looked for a pair of glasses for days, no sign of them. So I asked the Pixies, and 5 minutes later I spotted them in plain sight, right where I'd left them.
I'll try asking them for answers to difficult questions next!
I was overhauling a classic car, replacing any rusted bolts with new ones, and had reached the stage of refitting the brake calipers. I had previously ordered new, very special, bolts to attach the (safety critical) calipers, but did not get around to using them immediately, so had put them away it the box containing all the other brake parts. Come the day, no bolts! I searched all day long, turned the garage upside down, even searched in the house (why should car parts have been in there?), all to no avail, so I had to order some more 'very expensive' bolts. The day after they arrived, I took them into the garage, only to find the original set of bolts in plain view on the workbench. I know they had not been there the previous evening as the last thing I did was to sweep the bench and the garage floor. I have never solved the mystery of the wayward bolts, but now I have a spare set, should any of the second set fail (and why might they?).
"This was because if you had to explain the problem in simple terms and get your thoughts in order, you often could solve the problem yourself."
On the rare occasions I've been stumped out in the field and had to phone back to base for additional help, there's probably about a 33% "ah ha!" moment while dialling, another 33% of "Ah ha!" moment while explaining the problem to a colleague and another 33% where said colleague has made a blindingly obvious suggestion i already knew but for some reason my brain hadn't bothered to tell me about sooner. The final 1% is where it's a genuine head scratcher and we're all struggling for a solution :-)
Sometimes, walking away from a problem and thinking about something else for a few minutes helps the brain to reorganise itself :-)
For a while I started writing out what I wanted to talk to people about before I spoke to them, to save the embarassing "oh, now that I've explained it it's obvious" moment. I've found that I don't actually need to do this all that often anymore, since I've sort of trained myself to naturally perform this exercise.
What would <FellowEngineer> do...
That’s because when we look for things we look for an image in our heads of the thing. Say you want the cheese grater (A common one here), attentional blindness means you cannot perceive it. Maybe it’s lying down or seen side on.
Speaking the need forces the brain to engage more images of the object, solving the attentional fixation on one. I solve it by thinking about what it looks like. Which is why last night I briefly entertained the lid of a jar being the large slotted spoon. Both are black you see, I was looking for black things. I found the spoon shortly afterwards, it was behind me.
Always reminds me of an episode of Star Trek (TOS) where an Evil Mr. Spock in an alternative universe said "Set phasers to a million electron volts" to destroy a city on the surface of a planet, and I wondered if even a microbe would notice such a small amount of energy.
Not to excuse the lack of correct science in a sci-fi TV show with warp drive and famously unreliable transporters, but phaser settings in electron volts wouldn't necessarily be calibrating the strength of the entire beam.
It could be a million electron volts per micron per attosecond or something, so depending on the specific area and time base used could easily be enough to destroy a city at full beam width.
Though on the evil Enterprise you'd think the bridge officers would know the correct settings to destroy a city by heart without Spock telling them, as they'd be doing that all the time. That would happen as often as "assume standard orbit, Mr. Sulu".
No, it's ill-defined, since an electron is an object while a joule is a unit of work.
Generally you would regard the electron as a charge in which case the conversion factor is "voltage" [1] - 1 volt is 1 joule per coulomb.
V = E/Q -> VQ = E
If Q is an electron charge and the potential difference is 1V you end up with an electronvolt as E - it's just another unit of work like the joule, albeit a tad smaller.
However because the electron is a physical object it has other properties as well as charge so it does remain fundamentally ambiguous. The only other one I can think of which is of any relevance to conversion to work is its mass, governed by good old E = mc².
[1] Yes, OK, it's actually voltage times electron charge but it's the voltage that is the unknown factor.
Many years ago when I worked for the local power company we checked clearances from the >100kV power lines to ground with a laser survey. Turns out there were quite a few places where the stringing calculations done in the 1950s to 1970s weren't so good and the mandatory clearances weren't there, so there was a big program to fix it up, and to get more clearance (and hence more power capacity) for critical spans. All costly especially as the power couldn't be turned off until other lines had been upgraded.
One of the property offices had the realisation that the reason the clearance on one site wasn't good enough wasn't helped by a farmer building an illegal dam on the transmission easement. The farmer was 'encouraged' to remove the dam, and then to remove a bit more of the hill. Just shows that line clearance can be achieved by raising lines or lowering ground.
I forget which locomotive it was, and Google hasn't helped, but I remember some time ago that a newly refurbished steam locomotive hit a bridge and damaged its chimney and the top of the cab. The loco had been cleared for main line running, so an inquiry was held. Eventually it was discovered that recent reballasting of the track had raised the level of the rails significantly, and had therefor reduced the bridge clearance enough to cause there to be an "interference fit" between loco and stonework.
One of my previous employers had a server room in one end of the warehouse (think warehouse large enough to have 2 lorry loading docks) - loads of dust, variable temps and then we get to the access for the room..
Gap underneath, a mag lock (that could be opened with a hard drive magnet) and a door made of the finest in bottom of bargain basement plywood that flexed significantly when opening or closing it.
About as fireproof as a PFY'S underpants and as secure as locking a bike up with a paperclip...
Oh and their PABX was behind a network switch server rack and required squeezing past enough cabling to freak out a certain Dr. Jones with cries of "why is it always snakes?". Didn't help when age finally started to kill the cards.
I worked in one building where one server room was completely off limits. It was in a Victorian building and over the time the weight of the racks had increased to the point that one of the floor beams had cracked.
This had been the original server room when the company started but as it grew additional rooms were build in other buildings.
All the kit in that room was all approaching end of life and so if it failed it was replaced in a rack in another server room.
It was in that condition for a couple of years until they moved to new premises.
During decommissioning the kit was taken out 1 server at a time with only one person being allowed in the room at any point. Only the two youngest (and lightest) engineers were allowed in.
Yes, the correct way. We did that when I worked for a UK government agency. Unfortunately, manglement didn't coordinate the project at all well - no surprise there! Went in to work one morning, to complaints of service outages. Went down to the data center, which was a few miles away from the offices, and found that those qualified builders had demolished one of the walls to the data centre, with everything still (supposedly) up and running. While many were down, a surprising number of the servers, which I believe were some early Dell variety (this was decades ago), were still up and running, despite a thick coating of brick dust and rubble!
"a stout post to shove under the cracked beam"
Structural engineering is harder than you imagine. That would be unlikely to help, and might make things worse. If the beam goes, the post would add a sideways component to the movement unless it's so firmly fixed upright that you might as well have fixed the problem properly.
Not to mention the time when I went to visit Norton Networks at Maidenhead in the good old Ionica days.
it was the day when the Norton share price went over $100 for the first time.
All you could hear was the clicking of mouse buttons, the employees were doing no work, they were refreshing the stock price on their browsers waiting for the $100 to come up, as they all had share options!
Whether they vested them and took the money before it all went titsup is another story....
"The client had failed to mention the fire door upgrades during the initial fault finding, meaning that the time spent dealing with the problem was therefore chargeable." If I was the client I'd dispute the invoice, as the equipment should have been more robust. The cause wasn't obvious to the university grad as well as the customer. Maybe spit the bill 50:50?
It is implied that the service contract required any significant changes to the server environment to be notified as soon as possible (or maybe during planning). If "Col" and his team had been notified, preferably during the planning stage, something could have been done to mitigate the damage (perhaps, mount to something better than fibreboard). That wasn't done, so the service contract did not apply for damage caused as a result of the changes.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
