Absolutely would have moved the needle towards Linux for 12-year-old me. (Already on Linux now.)
@programming.dev
don't post pictures of my face online, that's rude >:(
In all seriousness I wonder why I always realize I could have explained myself better/left something out/omg formatting error better fix it/holy shit typo after the initial commit, and have like 4 different ones (or a bunch of rebases in an effort to keep the repo clean of this crap) fixing it, instead of pushing just a correct and complete readme from the beginning.
This is also why most of my Lemmy comments have edits. Not some weird sketchy crap editing things in to make others look bad or totally change my point after getting refuted, but just… oops typo or I could reword that to be more understandable or I meant to say this and totally forgot about it.
Shamelessly stolen from a Reddit post that made me laugh when I randomly remembered it today. Figured it was worth reposting to Lemmy if I laughed upon remembering it and not just upon first sight.
!programming_horror@programming.dev and !software_gore@programming.dev if you were not being facetious
I have no idea what to think because this sounds reasonable, but so do the arguments that it's a slippery slope and complying now makes it easier to surveil us all later. (Yes, I know this is the name of a fallacy. I'm curious as to when is it a fallacy and when is it not. I can absolutely imagine people saying "slippery slope fallacy" and being right, I can also imagine a different situation where people say "slippery slope fallacy" to something and it happens exactly as the people whose claim is being denied with "slippery slope" fallacy said.)
I guess that is why controversial issues are controversial, no easy and obvious resolution?
I was going to learn !hare@programming.dev just because it is called "Hare" and I like rabbits, but then I saw that I am not on a supported OS.
I'd imagine that you graduate high school at 18 and choose to go to college for the next 4, meaning you graduate as a 22-year old. Add or subtract a year for birthdays that align oddly with the academic year.
I literally just posted this in !software_gore@programming.dev because they had the same energy so I found it on the original Reddit post remembered this one too. Great minds think alike?
My computer would often have trouble connecting to WiFi on Windows 11, literally to the point that the WiFi option wasn't showing up at all. I switched that computer to Linux late December and I have not had that problem yet.
Some people actively desire this kind of algorithm because they find it easier to find content they like this way. I'm not sure if they are immune to doomscrolling and actually have gotten it to work in a way that serves them and doesn't involve doomscrolling, or if they are doomscrolling and okay with it. But for me, I really wish I could go back to the chronological feed era.
I shoot for this but am detectable by constantly making edits to make my point more understandable, adding something relevant that I thought of later (literally editing this post right now to include "adding something relevant that I thought of later") or to correct typos.
Stenberg, saying that he's "had it" and is "putting my foot down on this craziness," suggested that every suspected AI-generated HackerOne report will have its reporter asked to verify if they used AI to find the problem or generate the submission. If a report is deemed "AI slop," the reporter will be banned. "We still have not seen a single valid security report done with AI help," Stenberg wrote.
I appreciate this because I'd hate to get my issue removed as AI slop because I wasn't enough of an asshole and didn't make enough English mistakes. All for rejecting AI slop but it'd feel bad being the false positive deemed "not human enough" and getting my efforts tossed out too.
I may or may not be one of those autistic people who tried to compensate for my social deficiencies and inability to read the room by doing my best to be polite, nice, and inoffensive. (It helps that those qualities do not conflict with who I want to be at all.) And "nice and inoffensive" helps you easily subclass/multiclass into corpo dialect…
Article text:
The phrase “no brilliant ass-holes” gets a lot of lip-service around software companies, but the degree to which it is truly believed is only revealed during pivotal moments when a difficult decision has to be made. If you’re lucky, you’ll have avoided such dilemmas for most of your career, but you are unlikely to avoid them forever. Eventually some high-paid troublemaker will be in a position of influence over your team or your company, and you will have to decide how to address the acrimony that they breed. The challenge is exacerbated when the person in question has control of a critical code-base or is an irreplaceable resource: in other words, when they are holding a “hostage”. In such situations, most people — and most companies — will chose to turn a blind eye; they’ll try to put off the inevitable confrontation, hoping it will resolve itself.
The goal of this post is to outline the consequences of not taking action, or of delaying it, by relating one such experience from my own career, at a time when I was leading a multi-platform software team at B2C company. Like with technical debt, the pain of the eventual confrontation was compounded the longer the it was put off, until in this case the entire company ended up being held hostage. My example — one of many — should serve as a warning against what happens when a company tries to appease a hostage-taker.
As a technical lead, my own philosophy has always been to spread code ownership around the team as much as possible, to whichever team members feel they can handle it — regardless of tenure or seniority. This is the approach I was using at the aforementioned B2C company as well, and it was proving effective on all but one of the platforms. In this latter case, a long-tenured developer — who we’ll call “Martin”¹ — had taken full ownership of all architecture decisions and development on the platform, and maintained that control with an iron grip.
When I arrived at the company, the rest of his team were only being given menial or tangential tasks. He never allowed any of them higher-level decision making responsibilities on critical aspects of the code, and this was hindering their technical growth. Martin had also instituted a number of unusual (read: sub-optimal) design decisions, which he continued to defend, and which made understanding the code difficult. Obscurity served as an effective defence mechanism — anyone who wanted more ownership of the code had to go through him. This meant he would know what was happening and either shut it down or find a way to redirect it.
I spotted this toxic pattern fairly quickly, and had hoped to address it, but there was a problem. Despite being an individual contributor and reporting to me, Martin had tremendous clout and influence throughout the company. Not only had he been there since its inception, he was also the only one who could work with the critical platform, and all feature and bug requests had to go through him. To his credit, he was fairly responsive. When bugs showed up, at any hour of the day, he would drop what he was doing and push a fix. This established his credibility and was likely one of the reasons he was given the amount of leeway he had.
During one-on-ones I heard from his co-workers that they, unsurprisingly, didn’t like working with Martin. One or two of the juniors respected his intelligence and influence, but all of them expressed a feeling of living under his shadow, since they were not being given responsibilities that matched their skills. I tried to convince Martin to spread ownership around the team. Though he seemed to agree in principle, he never carried through. He asserted that only he knew how to manage the code-base — which was true, given its inscrutability — and he consistently pushed back on any architectural improvements from other team members that would make the code more accessible.
I’ll admit I was naive at the time. As a young, idealist manager who believed in fully developing my reports’ skills (that’s why I had gone into management in the first place), I didn’t yet realize the political consequences of confronting toxic team members like Martin. The back-and-forth between us escalated over time until it turned into all-out war. HR had to be brought in. The head of my own department — my boss — didn’t want to believe that Martin had to be dealt with quickly, because he didn’t fancy dealing with the technical repercussions of getting on his bad side.
This fear, coupled with Martin’s willingness and ability to address code problems quickly, became the carrot and stick that shifted upper management against my own recommendations. Martin also played dirty. He began to undermine my reputation at every opportunity, complained, gossiped and even lied, and ultimately, through his influence on HR and the execs, he scuttled my career as a lead at that company. By coincidence, around the same time the company lost a large chunk of its business, and so I and the majority of the engineering department were let go anyways. Martin, of course, was retained.
Although I soon moved on to a better position, I continued to keep in touch with former coworkers at the company, including his new manager who was a long-time friend of mine, and so I managed to learn the coda to this story. Martin continued to exercise control over the platform, until eventually the rest of his platform team unilaterally quit, citing Martin’s oppressive tactics as the explicit cause. Now the company was in even more of a bind than before. They couldn’t let Martin go, since he was the only remaining developer on that critical platform. When they tried to hire new team members, Martin — who was expected to be included in the hiring process — sabotaged the interviews, demanding interviewees answer ridiculous questions, and rejecting them based on spurious criteria.
One candidate confronted him on the absurdity of his approach to code design during their interview. Since he had never been forced to accept feedback from anyone on his design choices, it is likely he genuinely believed that his approach was the right one, and so when candidates mentioned best practices that didn’t align with his “expert beginner” philosophies, he rejected them. Either way, the hostage situation was now complete — he had become a bus-factor of 1.
In the end, management’s attempt to appease Martin and get on his good side, driven by fear of him quitting, didn’t soften his hard-line stance — it only validated it. I had originally blamed myself for not finding a better solution to the conflict between him and his team. But now I realized that Martin never wanted to play nice. He was playing a game of power, and didn’t intend to lose or to forget what game he was playing. He cared more about winning than management cared about the long-term success of the engineering department.
Martin also suspected that he wasn’t going to be fired by the weaklings in the upper echelons, including the CEO, so he knew he had all the leverage. When the rest of the team quit, they lost their only opportunity to balance the scales. The more they waited, the harder the decision got, until it was nearly impossible to address, and they had to accept an uneasy truce working under the same roof as the tyrant. The last piece of news I heard about this situation was that the engineering team had been downsized even further, and Martin and his manager were the only two remaining engineers on the product. Martin had won.
I have since seen this same pattern play out in another company as well; it begins with fearful management, unwilling to confront a difficult developer who refuses to collaborate, who doesn’t want to lose power, and so maintains a stranglehold on a critical piece of infrastructure until it is too late. The execs end up having to concede to all his demands. Their short-sightedness mistakenly glorifies and provides justification for a philosophy of appeasement; their desire to procrastinate on a difficult confrontation until some unspecified later time (perhaps when it becomes some other manager’s problem), ends up poisoning the rest of the team who then leave for greener pastures, thus solidifying the hostage-taker’s position. When said hostage-taker amasses enough money and experience to leave — which they undoubtedly will — the company is left up a certain creek without a paddle. But why should they expect such a person to do differently, to show gratitude for all the concessions the company has made over the years, or sympathy for the bind they are leaving the company in?
My guess is, when the time comes for Martin to leave, he will start making increasingly more untenable demands from his superiors, and when the execs inevitably push back, he will use that as moral justification for quitting and leaving them high and dry. Not that the moral justification is even necessary— it would merely be a way of enhancing his own self-perception as the party on the side of right.
How do such hostage situations take root in companies? Why do managers and even execs embark on a strategy of appeasement, sacrificing long-term security for short-term ease? In my estimation, managers hesitate to address such problems because they know they will end up “heroically” putting their career on the line when it seems no one else will. Why help a company that is ready to throw them under the bus for making tough choices? It is a case of the tragedy of the commons. Even if some brave soul tried to address the hostage-taker and managed, kamikaze-like, to take them out, their own job and credibility would likely be ruined with it. So most prefer to juggle the hot potato until they can pass it to the next person, and make it their problem.
I enjoyed this animation of the meme in the OP.
thanks for using Leebra!
go to feed...