GeekyOldFart
Three languages
And I'm not talking about programming languages, where most of us are fluent in half a dozen or so.
1: Regulatorian: This is the language of politicians and lawyers. It sets the mandates on banks, hospitals, schools etc. It contains nuances and terms of art that sometimes make a word mean something totally different to what you would infer if you heard it in general conversation.
2: Beancounterese: Spoken by accountantrs, salesmen and middle manglement. It sounds very similar to regulatorian but is sufficiently different in some of its meanings that it's as big a gulf as between old scots and english.
3: Geekian: The language of hard science, mathematics, real-world realities and the only one to use when specifying what a programmer needs to code. Because they will code what you tell them to, and it will work the way this language describes it.
The same word can mean different things in these three languages.
We have to be fluent in all three to accurately interpret requirements and predict what the emerging software will look like, to take error logs and demonstrate to (sometimes hostile) manglement what corrective action is needed and where it needs to be applied.
Michael H.F. WilkinsonSilver badge
Reply Icon
Re: Three languages
It gets worse, as there are quite a few Geekian dialects. I have learnt to speak a couple over the years, and know the word "morphology" can have radically different meanings, depending on whether you are talking to a medical doctor, an astronomer, or an image processing specialist. Great fun when you are in a project with different geeks each speaking their own dialect.
Shirley Knot
Reply Icon
Re: Three languages
Well said!
When writing specs for dev projects and talking to those speaking Regulatorian or Beancounterese it involves finding out what they actually mean, without saying "What the fuck do you actually mean?!" The skill is in performing iterative attempts without making them blow their stacks! The most frustrated person I had to deal with was a lovely chap that'd been doing his thing for decades, in manufacturing/engineering. He knew exactly what he was doing, but couldn't articulate it - quite understandable, not part of his world. Once he understood that I was just a white collar noob and he was the expert he calmed right down and enjoyed going into as much detail as needed. Explosive decompression averted and job done!
Ersatz-11 emulates an entire DEC PDP-11 system in software while running on low-cost PC hardware. It outperforms all of the hardware PDP-11 replacements on the market, outstripping them by a particularly wide margin in disk-intensive applications.
What operating systems were written for the PDP-11?
My son, Max, once worked for social media companies. Now he makes his living speaking to students about how phones hook them. He compares smartphones to casino slot machines.
"All the things we love about social media, those are the reward in the slot machine ... we get that 'hit' once in a while ... That's there to keep us scrolling for hours."
Haidt agrees, calling smartphones a "gambling machine."
They say some apps are worse than others.
"Instagram, Facebook, Snapchat, TikTok. Those really shatter attention spans. In terms of exposure to things that are really dangerous, Snap is the worst," says Haidt. "In terms of destroying your ability to pay attention, TikTok is the worst. In terms of destroying a teenage girl's sense of confidence, self-esteem, body image, Instagram is the worst."
He says social media affects boys and girls differently.
"Check in on the kids at age 14, girls are doing worse. They're more depressed and anxious, more messed up."
But a few years later, he says, "Girls are more likely to have gone to college, gotten a job and moved out of their parents' home. Boys are more likely to still be in their parents' basement playing video games. They never grew up. Real life is incredibly boring compared to a video game or porn."
Teachers say phone addiction makes it harder to teach.
If you're writing an open source system utility, for example, your chance of widespread adoption depends on its reputation as trustworthy, and that will reflect on you.
Who watches the watchers?
Talon is a case in point. A Windows de-bloater made by an outfit called Raven and distributed through GitHub as open source, it nonetheless got a rep as potential malware. Open source by itself guarantees nothing, and the conversation around whether or not Talon's bona fides checked out simply grew and grew. Enter YouTube cyber security educator and ethical hacker John Hammond. His day job includes answering the question "Is it Malware?" He has the chops, he has the tools, he has the caffeine. Speedrun is go. //
How might Raven have avoided being considered suspicious? There's a concept called defensive coding, where you consider each decision not just as how it contributes to functionality, but how it would cope if given an unexpected input. With Talon, the defensive process is whether a choice of technique will trigger malware scanners, and if it might, but is indispensable, how to make it clear in the code what's going on. You know, that pesky documentation stuff. The design overview. The comments in the code. If your product will need all those open source eyeballs to become trusted, then feed those eyeballs with what they need. There aren't many Hammonds, but there are lots of curious wannabes, and even the occasional journalist eager to tell a story.
Creating security is a huge task, and everyone who launches software for the masses has the opportunity to help or hinder, regardless of the actual intent of the product. Open source is a magnificent path to greater security across the board, because it keeps humans in the loop. Engineering for those humans is a force amplifier for good. Just ask the future historians speedrunning the history of cyber security centuries from now. ®
I'm a ISP network engineer, and across all teams working on the same platform we have agreed on Read-Only Friday. //
Yep, never start/continue/work on a project on a Friday. Or Monday... //
We have a strict "no live deployments on a Friday".
And if a Friday happens to be a public holiday, the rule then applies to the preceding Thursday instead. //
The last day of the working week is virtual or logical Friday, even if it's not calendar Friday.
All Friday rules still apply!
So... this is all you do all day is it?"
"Most days. Other days Carl or Peter does it."
"Carl or Peter?"
"Yeah, we work shifts - because the market never sleeps."
"So let me get this straight. You don't have any servers, you don't have any real work - AND THERE ARE THREE OF YOU - so you just make problems to keep yourself in a job?"
"Yep, That's pretty much it." //
A minute of silence passes, then finally the geek cracks. There's no server hardware. Nothing. Over the last five years the entire company operation has moved into online services - theoretically leaving our geek with no job.
"So what do you... do all day?" the PFY asks.
"SOME days, I'll take a complete snapshot of our cloud infrastructure," he says.
"Once a month you mean?" the PFY surmises. "So what do you do with the rest of your time?"
"I, um, manufacture outages," he admits.
"Manufacture outages?"
"Yeah, I'll light up the RED lamp on a server and, uh, take a cloud service offline."
"Why?"
"Because then they'll call me and get me to fix it. I'll bring them in here, fire up a linux laptop with the Matrix screensaver, edit a JPEG with a Hex editor, pretend to find a virus signature or an internal consistency error, then 'fix' it and bring the service back online again."
It seems so simple now that he says it.
What is a GUID?
A GUID is a globally unique identifier that can be generated through several different algorithms. The GUIDs on this site are generated using a secure random number generator.
Years ago, when I read The Mythical Man-Month, I found lots of stuff which I already knew from other sources. However, there were also new things in there, despite the book being from 1975. One of them was:
The Surgical Team
Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
This is a very interesting pattern for organizing a software development team, but I never found it described in any other Software Engineering book, not even mentioned anywhere.
Why is that?
The Common Charger Directive demands that a "USB-C receptacle" be equipped on "radio equipment" that is "equipped with a removable or embedded rechargeable battery" and "can be recharged via wired charging." If it has a battery and can be powered by up to 240 watts through a USB-C connection, it's generally subject to the EU's USB-C requirements. The directive applies to devices "placed on the market"—sent to a distributor or buyer—after December 28, even if they were initially designed and sold before that date.
Laptops get until April 2026 to comply, but most other things—phones, tablets, handheld gaming devices, computer accessories, and wireless headphones—will have to be powered by USB-C to be sold inside the EU from now on. //
In addition to simply demanding that a USB-C port be present, the Directive requires that anything with "fast charging"—pulling more than 5 volts, 3 amperes, or 15 watts—enable the USB Power Delivery (USB PD) standard. This should ensure that they properly negotiate charging rates with any charger with USB PD rather than require their own proprietary charging brick or adapter. //
The EU's celebratory post on X is heavy with replies from doubters, suggesting that mandating USB-C as "THE charger" could stifle companies innovating on other means of power delivery. Most of these critiques are addressed in the actual text of the law, because more powerful devices are exempted, secondary power plugs are allowed, and wireless largely gets a pass. "What about when USB-D arrives?" is something no person can really answer, though it seems a vague reason to avoid addressing the e-waste, fragmentation, and consumer confusion of the larger device charging ecosystem.
In the high-stakes world of semiconductor manufacturing, Europe has unveiled a groundbreaking achievement that rivals the cost and complexity of an Airbus A350. This state-of-the-art machine, meticulously assembled by a team of 250 engineers over six months, stands as a testament to European innovation in microtechnology. With ambitions to capture a significant share of the Chinese market, this marvel could reshape the global semiconductor landscape.
Since its inception in 1984, ASML has been at the forefront of semiconductor lithography. The company’s latest creation leverages Extreme Ultraviolet (EUV) technology, a bold move that has paid off handsomely. EUV lithography allows for the precise etching of intricate chip patterns, essential for the next generation of artificial intelligence and high-performance computing. According to industry leaders at the International Semiconductor Association, ASML’s commitment to EUV has not only doubled its revenue in the past five years but also set new standards in chip manufacturing.
The new ASML system promises to revolutionize microprocessor fabrication by reducing transistor sizes to an astonishing 1 nanometer.
The 20 most-commented-on tech support columns from On Call's first 500 instalments
Welcome once again to On Call, The Register's weekly column in which we recount readers' reactions to the drudgery of digital duties. This week, meet a reader we'll Regomize as "John Smith" who once worked for a very large bank. No doubt you've never met anyone with such an unusual name.
LY Corp's QA team struggled to manage projects while wading through prolix posts
Questions raised as one of the world's largest PC makers joins America's critical defense team
Have you ever had a teacher who was very smart but terrible at teaching? An expert who used so much jargon you could not follow their explanation? This is called the “curse of knowledge”, a term coined in 1989 by economists Colin Camerer, George Loewenstein, and Martin Weber.
It’s a cognitive bias that occurs when someone incorrectly assumes that others have enough background to understand. For example, your smart professor might no longer remember the challenges a young student faces when learning a new subject. And the expert might overlook the need to simplify concepts, assuming everyone knows what they know. //
You can avoid the negative effects of the curse of knowledge by constantly questioning your assumptions as to how much exactly your audience knows.
Curse of Knowledge - Mitigating Strategies
- Get to know your audience. Try to know how much they know. If you’re talking to a friend or colleague, assess the extent of their knowledge before starting your explanation. If you’re talking to potential customers, ask a few questions before starting your sales pitch.
- Simplify your language. Don’t hide behind jargon and complex terminology. Use simple language and clear examples to make your point easier to understand even with limited knowledge.
- Use storytelling. Stories can make information more relatable and memorable. Relate complex concepts to familiar experiences. Analogies and metaphors can also make abstract ideas more concrete and understandable.
- Show, don’t tell. A picture can be worth a thousand words. Instead of a lengthy explanation, see if you can create a visual, a graph, or an illustration that conveys the same content in a more accessible way.
- Engage in active teaching. Encourage questions and discussions. Pause at every step to ensure the person is following. By engaging your audience, you can better gauge their level of understanding and adjust your explanations accordingly.
What’s great about simplifying your explanations is that it reinforces your own knowledge. If you can’t explain something without using complicated jargon, you’re probably not as familiar with it as you think. Making the effort to explain concepts in simpler terms ensures you truly understand them.
What are they and why do they matter. //
In fact, every display you’ve ever seen only shows a small portion of the colors that your eyes are capable of perceiving. That portion is what’s referred to as a “color gamut.” A color gamut refers to the range of colors within the visible light spectrum that the display is capable of reproducing.
It might not seem like there are colors missing from your display, because you see approximations of most colors, but there are certain colors that simply can’t be shown. For a simple comparison, SDR (standard dynamic range) TVs are capable of displaying over 16.7 million colors—more specifically, there are 16.7 million unique combinations of the 256 different levels of red, green, and blue that the display can produce.
An HDR TV, on the other hand, is capable of at least 1,024 different levels of red, green, and blue each, for over 1.07 billion unique color combinations. This dramatically expands how much of the visible spectrum that displays can reproduce. But it also means that all the content that you see on your display—every show, movie, or video game—has to be created with those new color options in mind. ///
Computer monitors
Technology Consulting
We know not all the needs of your church fit into one of these buckets. We want to help you with all the technical needs of your church. Anything from guidance on AV and camera equipment, to network setup or delivering video messages to classrooms. We have helped meet the technical needs of over a hundred churches and would like to help you as well. We do not charge any consulting fees at all. We are not a vendor, we are your ministry partner.
The catastrophe is yet another reminder of how brittle global internet infrastructure is. It’s complex, deeply interconnected, and filled with single points of failure. As we experienced last week, a single problem in a small piece of software can take large swaths of the internet and global economy offline.
The brittleness of modern society isn’t confined to tech. We can see it in many parts of our infrastructure, from food to electricity, from finance to transportation. This is often a result of globalization and consolidation, but not always. In information technology, brittleness also results from the fact that hundreds of companies, none of which you;ve heard of, each perform a small but essential role in keeping the internet running. CrowdStrike is one of those companies.
This brittleness is a result of market incentives. In enterprise computing—as opposed to personal computing—a company that provides computing infrastructure to enterprise networks is incentivized to be as integral as possible, to have as deep access into their customers’ networks as possible, and to run as leanly as possible.
Redundancies are unprofitable. Being slow and careful is unprofitable. Being less embedded in and less essential and having less access to the customers’ networks and machines is unprofitable—at least in the short term, by which these companies are measured. This is true for companies like CrowdStrike. It’s also true for CrowdStrike’s customers, who also didn’t have resilience, redundancy, or backup systems in place for failures such as this because they are also an expense that affects short-term profitability.
But brittleness is profitable only when everything is working. When a brittle system fails, it fails badly. The cost of failure to a company like CrowdStrike is a fraction of the cost to the global economy. And there will be a next CrowdStrike, and one after that. The market rewards short-term profit-maximizing systems, and doesn’t sufficiently penalize such companies for the impact their mistakes can have. (Stock prices depress only temporarily. Regulatory penalties are minor. Class-action lawsuits settle. Insurance blunts financial losses.) It’s not even clear that the information technology industry could exist in its current form if it had to take into account all the risks such brittleness causes. //
Imagine a house where the drywall, flooring, fireplace, and light fixtures are all made by companies that need continuous access and whose failures would cause the house to collapse. You’d never set foot in such a structure, yet that’s how software systems are built. It’s not that 100 percent of the system relies on each company all the time, but 100 percent of the system can fail if any one of them fails. But doing better is expensive and doesn’t immediately contribute to a company’s bottom line. //
This is not something we can dismantle overnight. We have built a society based on complex technology that we’re utterly dependent on, with no reliable way to manage that technology. Compare the internet with ecological systems. Both are complex, but ecological systems have deep complexity rather than just surface complexity. In ecological systems, there are fewer single points of failure: If any one thing fails in a healthy natural ecosystem, there are other things that will take over. That gives them a resilience that our tech systems lack.
We need deep complexity in our technological systems, and that will require changes in the market. Right now, the market incentives in tech are to focus on how things succeed: A company like CrowdStrike provides a key service that checks off required functionality on a compliance checklist, which makes it all about the features that they will deliver when everything is working. That;s exactly backward. We want our technological infrastructure to mimic nature in the way things fail. That will give us deep complexity rather than just surface complexity, and resilience rather than brittleness.
How do we accomplish this? There are examples in the technology world, but they are piecemeal. Netflix is famous for its Chaos Monkey tool, which intentionally causes failures to force the systems (and, really, the engineers) to be more resilient. The incentives don’t line up in the short term: It makes it harder for Netflix engineers to do their jobs and more expensive for them to run their systems. Over years, this kind of testing generates more stable systems. But it requires corporate leadership with foresight and a willingness to spend in the short term for possible long-term benefits.
Last week’s update wouldn’t have been a major failure if CrowdStrike had rolled out this change incrementally: first 1 percent of their users, then 10 percent, then everyone. But that’s much more expensive, because it requires a commitment of engineer time for monitoring, debugging, and iterating. And can take months to do correctly for complex and mission-critical software. An executive today will look at the market incentives and correctly conclude that it’s better for them to take the chance than to “waste” the time and money.