rprospero

That's interesting, because I had the opposite experience. I started getting into Lisp around 2004, but bounced off of the community because the culture I was experiencing hewed heavily toward imperative code and global variables in the name of efficiency.

I specifically remember the breaking point being third-party library where none of the functions had any parameters. Instead, everything was controlled by using dynamic binding to adjust the variables within the functions. Various forum members kept praising its beauty and elegance, but I found it needlessly confusing.

I have a soft spot for the Lisp family of languages. I've been using Emacs for almost thirty years and have used both Scheme and Clojure in production. However, my experiences back in 2006 have left me with a permanent bias against Common Lisp.

It's been an odd running theme for me today that I've misinterpreted posts. Up until your final sentence, I thought that the thesis of your post was:

The standard document may say one thing, but what people do in the real world is the real standard. If your software has issues with the world's most popular IMAP server, you need to adjust your software to be compliant with the standard.

I'm personally more sympathetic to your actual conclusion, but it's odd how often a single argument can be used to support two conflicting beliefs.

I'm curious if you count Pass (https://www.passwordstore.org/) as not being "in town" or if it has issues with user freedom that I'm ignorant of.

When I was in the Boy Scouts, a local judge came to speak with us about the legal system. I asked a similar question and he admonished me that innocent people never wind up in court. He explained that every person who is in a trial (criminal or civil) is guilty of something. A judge's job was merely to determine if the prosecution or plantiff was correct about what the defendant was guilty of. He was very annoyed that ignorant people, who had never been to law school, kept spreading this nonsense that some defendants were innocent.

The COM file exploit worked because it is relatively unknown. I remember a worm going around when I was in grad school where you'd get an e-mail with a link to https://giftcard.customerservice.savemoneyonanew.tv/amazon.c.... Users who had been through the phishing training would see the HTTPS at the beginning and the amazon.com at the end and know that this was a legitimate Amazon email. The e-mail instructed them to click the link and "open the PDF file". Users would click the link, down load the COM file, and the open the file, installing malware all over the machine and forwarding the worm to all their contacts.

The truth is that, if a candidate competent enough to work for us, then they can get hired by a firm thirty miles down the road who pays way better than we do. Thus, one line of questioning during the interview process is figuring out why the candidate wants to work for US instead. Usually it's because they want more exciting work or are interested in the work we are specifically doing. If someone just wants ANY job, it's a red flag that they've applied to the wrong place.

I also find this thread interesting from the opposite direction as someone not in the Bay Area. In the past ten years, the longest job interview I had was two hours long. Honestly, most of the interviews I've been in (on both sides of the table) have been closer to half an hour.

Honest question: how often do you do Tornado drills in Japan? A quick look look at the wiki[1] indicates that you do get them, but fairly rarely. I honestly don't know your cultural perspective on them.

[1] https://en.wikipedia.org/wiki/List_of_tornadoes_and_tornado_...

I grew up on the edges of the New Madrid fault area and, while earthquakes were never discussed, we did tornado drills about every two months while in school. After I entered the workforce, that got closer to once a year, but you were still expected to have a plan and supplies. It was basic emergency preparedness, like any sensible person. Granted, big F5 tornados are rare, but small ones were common enough to not even be noteworthy.

Having left that region as an adult, it was a small culture shock meeting people who never had this kind of training. After all, the places I've visited all experience tornados, though not as often as my old home town. Still, the usual attitude I encounter is "I've never seen a tornado - they don't happen here". It's true that tornados don't happen often, just like my birthplace hasn't seen a serious earthquake in my lifetime, but they do happen.

I guess that's why I'm curious about your experiences. I've never been to Japan and I've read enviable reports of your disaster preparedness, but I honestly have no idea how your schools and culture handle tornados.

Many things about that company were not idea - the founder left his CEO position in handcuffs. However, the policy was not communicated to new and future hires in any manner. So why would anyone stay?

The founder was very public with other companies in the area about both his policy of firing 10x developers and hiring any warm body that could put a resume in his hand. He told stories at local business meetings of the various people he hired who couldn't find a computer and were fired on the same day. So, when you found out what the corporate culture was like after about a month on the job, you had two options.

1. Stay on for a year. This cemented to every hiring manager that you were a 1x developer (because you kept the job), but absolutely not a 10x developer. You might get a junior developer position somewhere else, but never more than that. 2. Immediately quit the job. You now had a one month stint at the firm on your resume. Every hiring manager in town knew that 5% of people with a short stint were good developers and the remaining 95% were people who just finished "COBOL for Dummies". You'd best just leave the gap in your resume if you didn't want your resume in the trash.

I happen to work at a government job partially because I saw how my father was treated by the private sector. However, our institution is failing at the requirements that you put forth. The government ministers complained back in 2015 that the independent quantitative measurements weren't accurately capturing employee productivity. As you would expect from Goodhart's law, there certainly were certain employees being underpaid and overpaid, respectively. Thus, the measurements were scraped. However, the bureaucracy has prevented a new set of metrics from being put into place. As a result, I've been working for eight years on what I was told would be a six-month probationary salary because there is literally no mechanism for anyone to receive a raise. Thankfully, recent events are looking like this might change to something sane in a year or two, but the last proposal I saw for someone moving out of the bottom of a salary bracket was: "candidate has won awards from professional bodies in at least three countries across at least two continents".

When I was young, my father worked for a place where asking for a raise was a fireable offence. The founder had been a pioneer in the modern cattle-not-pets attitude toward servers, except he applied it to developers. When an employee asked for a raise, it meant on of two things:

1. The employee was a vain troublemaker who had over-value what they were worth in the market. Firing them would not only remove an inefficiency from the system (as they were likely not to work as hard if they believed that they were underpaid), but it would also helpfully remind the other developers that they were all expendable.

2. The employee was a 10x developer who was vital to the company processes and could command a much higher salary somewhere else. Even if you gave them a raise today, they could be hit by a bus tomorrow. The best course of action was to simply rip off the band aid. Fire the employee, have security immediately escort them from the building, and begin triage to ensure that the critical systems that they wrote/managed could be handled by the next resume in HR's pile.

The line I will always remember is: Developer are like eggs. They are heavily undervalued, but also will crack under too much pressure. Thankfully, like eggs, you can buy them for cheap in packs of twelve, so it doesn't matter if you break a few.

> It's impossible to plan without an internal monologue

I once had a teacher claim that people who claimed to have aphantasia were lying, because those people have read books and it is impossible to read a book without picture the scene in your mind's eye. Are you citing the same source that she was?

Even more self-explanatory is "Duck into the bathroom. Cover the toilet seat with toilet paper. Hold your bladder until you're on the toilet."

I'm still not sure what I'm supposed to be holding onto. Do I briefly cover my head with my arms, then stop covering my head to hold onto the table? Do I hold onto my head while I cover it? Do I cover my loved one's head and they cover mine, sharing our last moments in a loving hold?

Now I'm beginning to wonder if I made a massive assumption that I would be covering my head with my hands. That's what I would do during a tornado, but maybe I'm supposed to be covering my head with a blanket so my hands are free for the hold on part?

Honestly, my facetious hold my bladder advice seems more apropos than anything I've managed to come up with for part three.

What I find extra-annoying about the tracking is that it stopped pretending to be helpful. I remember chatting with my spouse on Google Messenger around 2012. We were discussing what to have for dinner when whatever the google assistant was called at the time popped up a message

"Traffic is unusually heavy right now due to an accident on Kirkwood. If you want to pick up a pizza from Avers and be home by six, you should leave work in the next seven minutes."

Was it creepy? Hell yes, but at least it was useful. The companies haven't cut back on spying on me, but, in an effort to pretend that they aren't, they've stopped sharing the useful information with me. Instead, they keep it to themselves to mine for the perfect car advertisement to send to a guy who doesn't have a license.

You're right that this place is ridiculous. However, as I mentioned in a cousin comment, I don't see the stigma and you haven't done a good job of explaining it.

Is it because the word "pig" implies that the victim hasn't kept Kosher and that the scam is god's punishment for that? Is there a general consensus that people who are "butchered" deserve to be murdered? This stigma was obvious and immediate for you, but I'm not picking it up. I don't wish to perpetuate the stigma, but you haven't shared what it is.

I'm also in the UK and I'm not seeing the victim blaming part of it. I don't think it's a great term, given that I had no idea what it meant until I read the article. Then again, I would have assumed "financial grooming" was a service offered by a concierge banker to lower my direct debits. Out of the two phrases, I do feel that saying "my uncle is being butchered" will get law enforcement to act more quickly than saying that he's being "groomed".

I'm obviously missing some context or nuance here, since you're the second person to identify the connotation. Is it the "pig" part?

Concrete examples:

The web interfaces for both Jitsi and Zoom fail to recognise my web camera. I've gone through the permissions settings a dozen times and Firefox says that it sees camera, but it only displays a black feed. Vivaldi correctly accesses the camera on both sites.

imascientist.org.uk makes it "impossible" to sign up for outreach sessions under Firefox. The div with the sessions has a `max-width` parameter, but the contents are significantly larger than this width, resulting in the buttons being outside the rendering area and inaccessible. I have to go into the dev tools and edit the CSS every time I open the page.

These are just the issues that I've dealt with today. Don't get me wrong - I'm literally typing this in Firefox at this moment. However, it doesn't help anyone to pretend that these issues never pop up. I simply feel that the benefits outweight these annoyances.

I had always heard that the "single exit" focus on "break" and "continue" was a misunderstanding. When wild GOTOs roamed the earth, with was common for a subroutine to end by jumping to a new part of the code, with the jump location being different depending on conditionals within the code. The "single exit" commandment was that a subroutine should always exit back into the routine that had called it. That makes it less an injunction against a function having early returns and more a rejection of continuation passing style.

> unless you actually build something, the money isn't going to arrive, and you'll be out of a job.

The sad part is that many employees have come to the rational and correct solution that the above is not true. Out of the people I've known, more have lost their jobs to the results of C-suite malfeasance (e.g embezzling, illegal behaviour) than have ever lost their jobs to their own actions.

Conversely, unless the organisation you work for is exceptionally incompetent, your own personal failures shouldn't put them out of business. Think about all the cancelled Google projects. If the devs that worked on them had just come into work and played Minecraft all day, Google would still be in business. My personal opinion is that, if the Google Reader devs had never delivered a product, Google would be better off today than it actually is because it wouldn't have such a devoted community angry at it for killing off a beloved product.

The navel gazing framework discussion is like selling your own lotto tickets. If someone's number actually comes, you're on the hook for millions of dollars and probably broke for life. However, a person with a risk taking mentality will recognise that the odds of someone winning the lotto is tiny and, barring that outcome, selling your own lotto tickets is free money.

Support tickets don't increase costs. Whether you have one support ticket or a trillion, the one guy responsible for clearing those tickets gets paid the same salary.

The "if you are lucky and get a good text" is carrying a lot of weight here. My school identified certain young students as having high mathematical aptitude. While other students were learning the basics of addition and multiplication, the advanced students spent hours practicing multiplying nine digit numbers by hand.

The school was then always disappointed by by their performance in mathematics competitions. After all, the other teams were "wasting" their times unimportant reading about algebra, geometry, and combinatorics while our team was "practicing" math with hours of manual long division nightly.

The practice is certainly vital, but it's useless without a good text to guide you. Unless you're lucky and grab a good one on the first go, you'll need to read a few texts to find the good one.

I'd say that reading is as important to learning mathematics as breathing. You'll be a lousy mathematician if you spend all your time focused on your breathing, but you'll be worse one if you skip breathing entirely.

I'm Adam Washington. I was a couple of years behind you, but we bumped into each other socially a few times over the years. As a refresher, I was also the sophomore with the glasses in Shadiow's class that accidentally kicked over the trash can while trying to explain how graphs work.

Back in high school, I thought you were the brightest and chillest guy on the planet. My first Linux install was because I overheard you talking about it in class and I wanted to see what the fuss was about. Anyway, it's been a treat seeing you pop up again after all these years and discovering that my nostalgia lenses were right - you really are that smart and cool.

Congratulations, Greg! You've come a long way from Mr. Shadiow's CS class

It's interesting that you mentioned the good devs leaving, because they never got the chance. The owner had a policy of only hiring average devs and 10x devs were fired with extreme prejudice. His hiring theory was similar to modern server management: Cattle, not pets. It should be possible to fire a dev on Monday and have their replacement closing tickets by Friday. Good devs were harder to replace than average devs, so every good dev was a liability.

This policy was also useful for retention. Other firms in the area knew that he fired all of the good devs, so they never tried to poach his employees. In fact, if you got tired of the toxic environment and quit, the firm's name on your resume meant that you probably weren't going to get another dev job without leaving town. When a dev sees their former colleagues making sandwiches at Subway, another weekend of unpaid overtime doesn't sound as bleak.

Along those lines, one of the most toxic places I've ever encountered for developers was at a company that sold b2b software. You would think that developers would be valued for creating the product, but they were fully treated as a cost centre. The profit centre was the sales team who went out and got companies to send money. The developers merely existed because legal said that, for compliance reasons, the firm was required to provide the costumers with software after the client paid for said software (legal accounted for 24% of the company's budget while software development was 15%). If the sales team promised something that the software couldn't do (e.g. track the position of any cell phone in the country with just a phone number in the early 90's before smart phones), then any refund owed to the client would come out of the product team's budget. The salesman (they were all men) would not be required to return his commission, since he did his job and got someone to sign a cheque.

Surprisingly enough, the company was not Oracle.

I remember a grad student who went through a similar incident. While I appreciated his frustration, I also understand the anxiety of the poor server trying to remember how to mix a Woahtuh before my colleague decided to enunciate the coda.

We've recently tried Game Pass and it's been saving us money, though not in the way that it's usually framed. We've been using it to demo games that we were thinking about buying. Multiple massive disappointments have probably saved us £150 on the games we will NOT be buying and I suspect it will save us twice that amount by the time we've gone through the catalogue and cancelled our account.

Having been in a similar, but not the same, situation, I resorted to an HTML file with some JavaScript code in a script tag. Was IE locked from running, even though the machine was air gapped? Or did you find VBA more convenient that JavaScript?

No, I've worked in enough countries to know that my experience cannot be extrapolated to the remainder. I'd love to hear your experience and how this did work out for you.

Honestly, this is more of a problem for blockchain than it is for the old system. Let's say that an 80's movie villain gets his goons to beat you until you sign over the deed to your house (he wants to open another dojo). Today, you could go to court, present your evidence that you made the transaction under duress, and you get your house back. Even if he won't sign the deed back to you, the court can just print a new one on a laser printer, give it a fancy stamp, and the house is yours again.

In the blockchain world, there's two options. The first is the "code is law" option. Since you sent him the house, it's his and there's nothing you can do about it. The court might arrest him, but there's no way of ever recovering your house. If he's particularly spiteful, the villain might kill himself. With proper security, his private key is lost forever and that property becomes inaccessibly for eternity.

The other option is the "reasonable" option. Here, you go to court and have his token for your house officially invalidated. Additionally, a new token is minted for the property is minted and sent to your account, making you whole again. However, this only works with a modified blockchain that allows a centralised authority to invalidate and mint new tokens. Since we're already trusting this centralised authority, then we're back to the old laser printer and stamp, just with extra steps.