…new and previously undreamed-of devices for exciting mobs have been invented. There is the radio, which has enormously extended the range of the demagogue’s raucous yelling. There is the loud-speaker, amplifying and indefinitely reduplicating the heady music of class hatred and militant nationalism. There is the camera (of which it was once naively said that ‘it cannot lie’) and its offspring, the movies and television…Assemble a mob of men and women previously conditioned by a daily reading of newspapers; treat them to amplified band music, bright lights, and the oratory of a demagogue who (as demagogues always are) is simultaneously the exploiter and the victim of herd intoxication, and in next to no time you can reduce them to a state of almost mindless subhumanity. Never before have so few been in a position to make fools, maniacs, or criminals of so many.
(с) Aldous Huxley, The Devils of Loudun, 1952
(с) Aldous Huxley, The Devils of Loudun, 1952
Forwarded from Team Lead Talks Подкаст (Дима Рожков)
ПЕРЕВОД: Скрам — это рак.
Я пишу код 25 лет и ничего не делает команду настолько бесполезной как скрам.
Несколько случаев из жизни:
1. Они пробовали убедить меня, что планинг покер это не игра, а инструмент планирования.
2. Если вы хотите быть более эффективным, то должны добавить процесс, а не убрать его. Они заставляли нас принимать участие в “церемониях” — просто модное называние для прорвы митингов: дейлики, груминги, планинги, ретро, скрам скрамов. Мы тратили больше времени на разговоры, чем на дело.
3. Мы запретили лаптопы на митингах. Мы должны были принимать участие стоя. Мы передавали мячик, чтобы заставить всех удерживать внимание.
4. Мы потратили больше времени оценивая стори поинты задач, чем на код. Стори поинты измеряют сложность, а не время, но мы должны были решить сколько стори поинтов поместится в спринт.
5. Я должен был использовать размеры футболок, чтобы оценить софт.
6. Мы измеряли сколько денег стоит выполнить 1 стори поинт и потом подписывали контраты, где клиент покупал пакет 500 стори поинтов.
7. Менеджеры были в ярости, когда осознали, что 500 сторипоинтов на одном проекте, не равны 500 сторипоинтов на другом. У нас было много митингов, чтобы это исправить.
8. Представьте, что у вас есть менеджер, скрам мастер, продакт овнер и тех лид. Вы подчиняетесь всем им и никому из них одновременно.
9. Мы платили людям, которые говорили нам, жжем ли мы поинты достаточно быстро. Но стори поинты это же мера сложности, а не времени? Уже не важно.
Я верю в Гибкость, но это не гибкость.
Мы привлекли профессиональных скрам мастеров. Мы оплачивали сертификацию людям из нашей команды. Как только мы не пробовали делать скрам. Мы потратили на это годы.
Результат был всегда один и тот же: скрам не работал.
Скрам — это рак, который жрет вашу команду разработки. Скрам не для разработчиков — это очередной инструмент менеджеров, чтобы они чувствовали, что контролируют ситуацию.
Но вишенка на торте это когда проповедники скрама говорят вам: “Если скрам не работает для вас — вы делаете его неправильно Только скрам и работает"
Ну конечно же.
https://twitter.com/svpino/status/1695806027256475777?s=20
Я пишу код 25 лет и ничего не делает команду настолько бесполезной как скрам.
Несколько случаев из жизни:
1. Они пробовали убедить меня, что планинг покер это не игра, а инструмент планирования.
2. Если вы хотите быть более эффективным, то должны добавить процесс, а не убрать его. Они заставляли нас принимать участие в “церемониях” — просто модное называние для прорвы митингов: дейлики, груминги, планинги, ретро, скрам скрамов. Мы тратили больше времени на разговоры, чем на дело.
3. Мы запретили лаптопы на митингах. Мы должны были принимать участие стоя. Мы передавали мячик, чтобы заставить всех удерживать внимание.
4. Мы потратили больше времени оценивая стори поинты задач, чем на код. Стори поинты измеряют сложность, а не время, но мы должны были решить сколько стори поинтов поместится в спринт.
5. Я должен был использовать размеры футболок, чтобы оценить софт.
6. Мы измеряли сколько денег стоит выполнить 1 стори поинт и потом подписывали контраты, где клиент покупал пакет 500 стори поинтов.
7. Менеджеры были в ярости, когда осознали, что 500 сторипоинтов на одном проекте, не равны 500 сторипоинтов на другом. У нас было много митингов, чтобы это исправить.
8. Представьте, что у вас есть менеджер, скрам мастер, продакт овнер и тех лид. Вы подчиняетесь всем им и никому из них одновременно.
9. Мы платили людям, которые говорили нам, жжем ли мы поинты достаточно быстро. Но стори поинты это же мера сложности, а не времени? Уже не важно.
Я верю в Гибкость, но это не гибкость.
Мы привлекли профессиональных скрам мастеров. Мы оплачивали сертификацию людям из нашей команды. Как только мы не пробовали делать скрам. Мы потратили на это годы.
Результат был всегда один и тот же: скрам не работал.
Скрам — это рак, который жрет вашу команду разработки. Скрам не для разработчиков — это очередной инструмент менеджеров, чтобы они чувствовали, что контролируют ситуацию.
Но вишенка на торте это когда проповедники скрама говорят вам: “Если скрам не работает для вас — вы делаете его неправильно Только скрам и работает"
Ну конечно же.
https://twitter.com/svpino/status/1695806027256475777?s=20
X (formerly Twitter)
Santiago (@svpino) on X
Scrum is a cancer.
I've been writing software for 25 years, and nothing renders a software team useless like Scrum does.
Some anecdotes:
1. They tried to convince me that Poker is a planning tool, not a game.
2. If you want to be more efficient, you must…
I've been writing software for 25 years, and nothing renders a software team useless like Scrum does.
Some anecdotes:
1. They tried to convince me that Poker is a planning tool, not a game.
2. If you want to be more efficient, you must…
TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become
(c) https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
any. No thanks!(c) https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01
Hey
Turbo 8 is dropping TypeScript
By all accounts, TypeScript has been a big success for Microsoft. I've seen loads of people sparkle with joy from dousing JavaScript with explicit types that can be checked by a compiler. But I've never been a fan. Not after giving it five minutes, not after…
Were I starting bash from scratch, I probably would have written a parser by hand. It certainly would have made some things easier.
(c) https://aosabook.org/en/v1/bash.html
(c) https://aosabook.org/en/v1/bash.html
Yaml aims to be a more human-friendly alternative to json, but with all of its features, it became such a complex format with so many bizarre and unexpected behaviors, that it is difficult for humans to predict how a given yaml document will parse.
(с) https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
(с) https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
67 Weird Debugging Tricks Your Browser Doesn't Want You to Know: https://alan.norbauer.com/articles/browser-debugging-tricks
(c) Alan Norbauer, so old that you should call him "gramps." ... He still doesn't know how to use Snapchat or TikTok
(c) Alan Norbauer, so old that you should call him "gramps." ... He still doesn't know how to use Snapchat or TikTok
Norbauer
67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
Advanced browser parlor tricks
Forwarded from Информация опасносте
прекрасная история про польский поезд, в котором есть компания производитель, установившая, по сути, некий DRM на ПО для поезда, чтобы предотвратить ремонт третьими сторонами, и польские хакеры, которые взломали этот самый ДРМ после того, как их наняли "починить" ПО. если я правильно понял цепочку, то компания-оператор поездов чинила их силами своих подрядчиков, после чего поезда переставали ездить (брикались). Из последних сил компания наняла хакеров, которые заглянули в софт и нашли закладки, блокирующие работу поездов при стороннем ремонте. Теперь компания-производитель поездов хочет подать в суд на этих хакеров.
https://gizmodo.com/hackers-hit-with-legal-threats-after-they-fixed-a-brick-1851097424
https://gizmodo.com/hackers-hit-with-legal-threats-after-they-fixed-a-brick-1851097424
Gizmodo
Hackers Hit With Legal Threats After They Fixed a 'Bricked' Polish Train
The hackers claim Polish trains were deliberately bricked by the manufacturer and they were just providing a service. “It’s DRM gone wild.”
Абсолютно проклято: Most Gateway API implementations are API Gateways to some extent, but not all API Gateways are Gateway API implementations.
(с) https://gateway-api.sigs.k8s.io/#whats-the-difference-between-gateway-api-and-an-api-gateway
(с) https://gateway-api.sigs.k8s.io/#whats-the-difference-between-gateway-api-and-an-api-gateway
Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
(с) Dijkstra, раскопано https://t.me/emacsway_log/1349
(с) Dijkstra, раскопано https://t.me/emacsway_log/1349
I think given two teams producing things, it’s an irresistible temptation, for many managers, to compare them. I think it’s irresistible enough that I’d drop the notion of story points, and even the notion of estimating stories at all, where possible.
…
The key question is to find the most valuable things to do, and to do them quickly. Doing them quickly comes down to doing small slices of high value, and iterating rapidly. Story cost estimation doesn’t help much with that, if at all.
…
Related to the estimate / actuals concern is the natural pressure of management to want “more”. However much the team is getting done, it’s not enough. More, more, more.
Increasing pressure to do more almost inevitably has a bad result: the team tries to go faster, and wind up skimping on code quality and on tests. They soon begin shipping more defects, slowing down because of the increased rework to fix the defects, and slowing down even more because the code quality rapidly declines. Things get worse and worse, pressure increases, and it becomes a race to disaster.
(c) https://ronjeffries.com/articles/019-01ff/story-points/Index.html
…
The key question is to find the most valuable things to do, and to do them quickly. Doing them quickly comes down to doing small slices of high value, and iterating rapidly. Story cost estimation doesn’t help much with that, if at all.
…
Related to the estimate / actuals concern is the natural pressure of management to want “more”. However much the team is getting done, it’s not enough. More, more, more.
Increasing pressure to do more almost inevitably has a bad result: the team tries to go faster, and wind up skimping on code quality and on tests. They soon begin shipping more defects, slowing down because of the increased rework to fix the defects, and slowing down even more because the code quality rapidly declines. Things get worse and worse, pressure increases, and it becomes a race to disaster.
(c) https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Ronjeffries
Story Points Revisited
This is RonJeffries.com, the combination of new articles, XProgramming, SameElephant, and perhaps even some new items never before contemplated.
Copyright © 1998-forever Ronald E Jeffries
Copyright © 1998-forever Ronald E Jeffries
…people running the tech industry are no longer those that built it. Larry Page and Sergey Brin left Google in December 2019 (the same year as the Code Yellow fiasco), and while they remain as controlling shareholders, they clearly don’t give a shit about what “Google” means anymore. Prabhakar Raghavan is a manager, and his career, from what I can tell, is mostly made up of “did some stuff at IBM, failed to make Yahoo anything of note, and fucked up Google so badly that every news outlet has run a story about how bad it is.”
(с) https://www.wheresyoured.at/the-men-who-killed-google/
(с) https://www.wheresyoured.at/the-men-who-killed-google/
Ed Zitron's Where's Your Ed At
The Man Who Killed Google Search
Wanna listen to this story instead? Check out this week's Better Offline podcast, "The Man That Destroyed Google Search," available on Apple Podcasts, Spotify, and anywhere else you get your podcasts.
UPDATE: Prabhakar has now been deposed as head of search…
UPDATE: Prabhakar has now been deposed as head of search…
Google spokespeople have gone out their way to misdirect and mislead us on a variety of aspects of how their systems operate in an effort to control how we behave as SEOs. I won’t go as far as calling it “social engineering” because of the loaded history of that term. Let’s instead go with… “gaslighting.” Google’s public statements probably aren’t intentional efforts to lie, but rather to deceive potential spammers (and many legitimate SEOs as well) to throw us off the scent of how to impact search results.
(с) https://ipullrank.com/google-algo-leak
(с) https://ipullrank.com/google-algo-leak
iPullRank
Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
Learn what you always wish you knew about Google's algorithms.
If AI-ese sounds like African English, then African English sounds like AI-ese. Calling people a “bot” is already a schoolyard insult (ask your kids; it’s a Fortnite thing); how much worse will it get when a significant chunk of humanity sounds like the AI systems they were paid to train?
(c) https://www.theguardian.com/technology/2024/apr/16/techscape-ai-gadgest-humane-ai-pin-chatgpt
(c) https://www.theguardian.com/technology/2024/apr/16/techscape-ai-gadgest-humane-ai-pin-chatgpt
the Guardian
TechScape: How cheap, outsourced labour in Africa is shaping AI English
Workers in Africa have been exploited first by being paid a pittance to help make chatbots, then by having their own words become AI-ese. Plus, new AI gadgets are coming for your smartphones
Я думаю, что вся концепция «обработки» исключений слегка напоминает игру для дураков. Я, наверное, могу посчитать на пальцах одной руки количество случаев, когда я был действительно в состоянии обработать специфический тип исключения и сделать в обработчике что-то интеллектуальное. В 99% случаев ты должен ловить или всё или ничего. Когда выбрасывается исключение любого типа, восстановите стабильное состояние и затем либо продолжайте, либо прерывайте исполнение программы.
(c) https://habr.com/ru/articles/221723/
(c) https://habr.com/ru/articles/221723/
Хабр
Никто не умеет обрабатывать ошибки
Из одной книги в другую, из статьи в статью кочует мнение о том, что выражение try { //do something } catch(Exception ex) { } является плохой практикой. Возврат кодов – также плохая практика. Но...
The inquiry discovered that the firm that outsourced the work – on a staff intranet for nuclear submarine engineers – to Russia and Belarus initially kept it secret and discussed whether it could disguise where the workers were based by giving them fake names of dead British people.
https://archive.ph/3Jujz
https://archive.ph/3Jujz
archive.ph
Britain's nuclear submarine software contract handed to Belarusian en…
archived 2 Aug 2024 22:24:04 UTC
Forwarded from Лингвопанк
Мы привыкли, что языки программирования основаны на английском языке.
Но язык Uiua основан на математической записи.
Особо красиво, как формулы превращаются в графику или звук.
https://www.uiua.org
Но язык Uiua основан на математической записи.
Особо красиво, как формулы превращаются в графику или звук.
https://www.uiua.org
Forwarded from tropical saint petersburg
"Что такое "геометрия без аксиомы параллельных линий"?-- Ребятишки забавляются тем, что прыгают на одной ноге. Быстро подвигаться вперед этим способом! они, разумеется, не могут; и передвинуться далеко, -- например, версты на две -- не могут. Но при усердии все-таки не очень медленно передвигаются на расстояния, не вовсе ничтожные: иной, прыгая, не отстает от человека, идущего тихо; и провожает его целую четверть версты. Это очень трудный подвиг. И достойный всякой похвалы. Но лишь когда это -- шалость ребенка. А если взрослый человек, -- и не для шалости, а серьезно, по своим серьезным делам, пустится путешествовать, прыгая на одной ноге, это будет путешествие не вполне безуспешное, -- нет!-- только совершенно дурацкое."
Из Чернышевского, очень понравилось.
Из Чернышевского, очень понравилось.
A drum I’ve been banging for a while is that LLMs are power-user tools—they’re chainsaws disguised as kitchen knives. They look deceptively simple to use—how hard can it be to type messages to a chatbot?—but in reality you need a huge depth of both understanding and experience to make the most of them and avoid their many pitfalls.
If anything, this problem got worse in 2024.
...
I like people who are skeptical of this stuff. The hype has been deafening for more than two years now, and there are enormous quantities of snake oil and misinformation out there. A lot of very bad decisions are being made based on that hype. Being critical is a virtue.
...
I think telling people that this whole field is environmentally catastrophic plagiarism machines that constantly make things up is doing those people a disservice, no matter how much truth that represents.
(c) https://simonwillison.net/2024/Dec/31/llms-in-2024/
If anything, this problem got worse in 2024.
...
I like people who are skeptical of this stuff. The hype has been deafening for more than two years now, and there are enormous quantities of snake oil and misinformation out there. A lot of very bad decisions are being made based on that hype. Being critical is a virtue.
...
I think telling people that this whole field is environmentally catastrophic plagiarism machines that constantly make things up is doing those people a disservice, no matter how much truth that represents.
(c) https://simonwillison.net/2024/Dec/31/llms-in-2024/
Simon Willison’s Weblog
Things we learned about LLMs in 2024
A lot has happened in the world of Large Language Models over the course of 2024. Here’s a review of things we figured out about the field in the past …
...interesting part of this announcement is that the former vanguard of the NoSQL movement in the late 2000s now supports SQL in 2024
https://www.cs.cmu.edu/~pavlo/blog/2025/01/2024-databases-retrospective.html
https://www.cs.cmu.edu/~pavlo/blog/2025/01/2024-databases-retrospective.html
Andy Pavlo - Carnegie Mellon University
Databases in 2024: A Year in Review
Andy rises from the ashes of his dead startup and discusses what happened in 2024 in the database game.