Eight years ago my team lead posted a photo of me giving a talk in Barcelona, and a colleague reacted to it with a pile of poo.

I wrote about it at the time, in When “a pile of shit” is a compliment. The short version, for those who will not click. The talk was about the three most common mistakes in data visualization. The first mistake was about attitude and the third was about not writing conclusions, so I had an A and a C, and I wanted a B. The second mistake was about a low signal-to-noise ratio, and the best B word I could find for noise was “bullshit.” I was not sure I was allowed to put that on a slide, so I asked my colleagues in Slack. Four out of four said go ahead. Martin, who ran the data division at Automattic, added that for a non-native English speaking audience, American coinages like “bullshit” come across funnier and less aggressive than they do to some American ears.

So the slide said “Cut the bullshit,” half the data division had watched me agonize over it, and when the photo of that talk went up, the poo emoji was not an insult. It was a callback. It was affectionate.

The lesson I drew in 2018 was a human one: do not jump to conclusions, assume the best intentions.

I still believe that. There is now a reader in the thread who cannot do it.

The reader who was not in the room

Ask yourself what a language model would make of that thread if you handed it over today. Not the whole story. Just what is in the channel: a photo of a man presenting, and one pile-of-poo reaction. There is exactly one reading available, and a model will produce it fluently and with total confidence. Negative sentiment. Mild ridicule of the speaker.

It would not be malfunctioning. It would be doing exactly what I asked, with what I gave it. The joke lived in context the model never had, and here is the part that bothers me: unlike Sirin, or Martin, or anyone else in that channel, it has no way to notice that something is missing. A human who does not get a joke usually feels the gap. They ask, or they hedge, or they let it go. A model does not feel the gap. It fills it.

I published something a few days ago about my folder of markdown files, and I described the failure mode of an AI assistant like this: it “confidently does the wrong thing, because it guessed at something it should have asked you about.” Guessed. That is the same word I would use for the poo emoji, read cold. The 2018 story turns out to have been an early, funnier version of the thing I now spend my working day managing.

Context stopped being a courtesy

What changed between 2018 and now is not the technology. It is who is obliged to supply the missing piece.

In 2018 I could reasonably expect other people to supply it themselves. Everyone in that channel had watched the poll happen. If somebody had missed it, they could ask, or they could extend me the benefit of the doubt. That is what “assume the best intentions” actually asks of a reader: fill a gap you can see, using goodwill.

You cannot ask a model for goodwill. It has none, and it will not tell you it is short of anything. So the obligation moves. Context is no longer a courtesy I extend to a colleague who missed the meeting. It is an input I owe to a reader who was never at the meeting, never will be, and will answer anyway.

That is the actual reason my Claude setup is a folder of boring text files instead of a cleverer prompt. Those files are the poll. They are Martin’s note about non-native speakers. They are the thing that makes “Cut the bullshit” read as a joke about signal-to-noise instead of as a man swearing at strangers in Barcelona.

So write down the thing everybody knows

That is the whole technique, and it is much less satisfying than a clever prompt. Write down the thing you assume everyone knows, and put it where the machine can read it.

The test I use: if a competent stranger read only the artifact, and none of the conversation around it, what would they get wrong? Then go and write that into the artifact.

I might be over-reading my own emoji here. It is perfectly possible that the right answer is to keep the jokes in Slack, where the people who get them live, and to stop feeding threads to machines that were never invited to the party. I have some sympathy for that view. But the threads are being fed to the machines whether or not I approve, and nobody is asking me first.

Would your last six months of Slack survive a stranger reading it with total confidence and no context? Mine would not. I suspect yours would not either.

Screenshots from the original 2018 post. The poo, as established, was a compliment.

I use Claude Code every day, and I love it. Ever since the ChatGPT wave of 2022, we have been hearing that the work of programming is about to be automated away. I teach in a computer science department, so I watch it land from the front of the room: fewer students each year want to learn to program, and I hear the same prediction from colleagues who have written code their whole lives.

The prediction of the end of programming is not new.

I’ve grown suspicious of it, because I’ve now read it with a date attached, and the earliest date is 1959.

Here is the pattern. Every ten or fifteen years since then, someone announces that programmers are about to become unnecessary. The pitch barely changes: the machine now speaks your language, so the specialist in the middle can go home. And every time, two things happen that don’t fit the prediction. The specific kind of programming under attack really does fade. And the number of people who program goes up. Not sideways. Up.

The people who make this prediction are not stupid, and they are not dilettantes. They are experienced industry leaders, academics, and journalists who have spent their lives around programming, and they are genuinely convinced the end is near. That is what makes the pattern worth taking seriously rather than laughing off.

And still, the prediction keeps being half right in the way that makes it feel completely wrong.

1959: the machine will speak English, so you won’t need a programmer

COBOL was designed in 1959 and 1960 by a committee that, as the record puts it, “agreed unanimously that more people should be able to program.” The language was to “make maximal use of English” and be “suitable for inexperienced programmers,” even at the expense of power. That’s why COBOL reads like MOVE amount TO total instead of a row of symbols. The hope riding on top of it was louder than the spec: if the code looks like English, a manager could read it, maybe even write it, and the programming priesthood would lose its monopoly.

Sixty-five years later, managers still do not write COBOL. But plenty of people who would never have called themselves programmers ended up writing something. The circle of people who program got wider. It did not close.

1965 and 1967: the machine will think, so it will program itself

Then the general optimism arrived. In 1965 Herbert Simon wrote that “machines will be capable, within twenty years, of doing any work that a man can do”. In 1967 Marvin Minsky wrote that “within a generation … the problems of creating ‘artificial intelligence’ will be substantially solved”. Writing programs was quietly filed under “any work a man can do.” If the machine was about to do everything, it was certainly about to do this.

1973: then the money stopped

The trouble with a promise that large is that it can be defunded in a single document. In 1973 James Lighthill delivered a report to the British Science Research Council that concluded, flatly, “in no part of the field have the discoveries made so far produced the major impact that was then promised.” The British government used it to end most academic AI funding. The first AI winter followed. The lesson I take from Lighthill is not that the skeptics were right. It’s that overselling has a bill, and when it comes due, the honest work gets cut alongside the hype.

1981: application development without programmers

The eighties opened with the promise moved into the product name. In 1981 James Martin published a book literally titled Application Development Without Programmers, which is where the term “fourth-generation language” got its formal start. The same year, a small British company shipped a program called The Last One. Its creator explained the name: it was meant to be “the last human-produced program that needs to be written.” You picked options from menus and it generated the BASIC for you.

What actually came of the 4GL wave was SQL, spreadsheets, and report builders. Every one of those let more people do more without a programmer. Every one of those also created new categories of work, and demand for programmers kept climbing straight through the decade that promised to end it.

1982: an entire country bet on it

Japan’s Ministry of International Trade and Industry launched the Fifth Generation Computer Systems project in 1982: roughly ¥57 billion, about 320 million dollars, over ten years, to build machines that reasoned in logic and talked to people in something close to natural language. It is now generally filed as a commercial failure. Ordinary hardware from Sun and Intel outran the specialized machines before the decade was out.

1987: “a profession with no future”

The feeling that this time is finally different is not new either, and I have a clipping to prove it. On Friday, 4 September 1987, the Israeli daily Maariv ran a piece under the headline “תכנות - מקצוע ללא עתיד”: programming, a profession with no future.

Maariv, Friday 4 September 1987. The headline reads “programming, a profession with no future.”

It quotes a specialist, Ezra Ben-Kochav, making a case that would sound at home in any 2026 keynote. “The programming component in systems keeps shrinking over the years,” he says. The cause, in his telling, is the arrival of fourth-generation languages, “artificial-intelligence languages,” and application generators, tools that demand far less professional knowledge and cut a project’s development time in half. Operating systems, he adds, are getting friendly enough that you need less skill to run them.

Then comes the line that made me keep the clipping. Ben-Kochav cites studies from the United States showing that fewer and fewer students were choosing to study computer science, and names the reason: the shrinking demand for people in the field. I read that, thought of the drop in my own department, and then checked the date. Thirty-nine years ago. In the decades that followed, the profession it was burying became one of the largest and best paid on earth.

The tell: even the replacement was called an apprentice

Here is the detail that convinced me the pattern is real and not just a run of bad marketing. The most serious academic attempt to automate programming in that era, MIT’s Programmer’s Apprentice (Charles Rich and Richard Waters, from the mid-1970s on), was explicitly designed as an assistant, not a replacement. The apprentice handled the mundane details; the human made the higher-level connections and checked the apprentice’s work.

That is almost exactly the division of labor I have with my AI assistant today. The people who understood the problem best, forty years ago, landed on “apprentice,” not “successor.” They had the right word the whole time.

What the numbers actually did

In 2000 the two occupations were the same size, about 700,000 workers each. By 2019 “software developer” had grown to 1.71 million while “computer programmer” fell to 425,000. They are related but distinct jobs: a developer analyzes needs, designs the software, and builds it; a programmer writes code to a design someone else produced. Source: BLS Current Population Survey (full-time wage and salary workers), via FRED. The developer series was retired after 2019 in a reclassification; BLS counts about 1.7 million software developers in 2024.

This is the part that makes the whole cycle legible, once you notice that “programmer” and “developer” are not the same job. A computer programmer, in the way the statistics count it, writes code to a design somebody else handed over. A software developer figures out what to build, then builds it. The narrow role is the one that’s dying: it stood at 121,200 jobs in 2024, which Fortune reported is the lowest level since 1980.

So the work didn’t disappear, and it didn’t simply change its name badge. It moved up a level. The job of turning a finished spec into code, the part a machine can most plausibly take, shrank. The job of deciding what the spec should be, and standing behind it, grew to about 1.7 million software developers, median wage $133,080, with another 15 percent growth projected over the decade. Every wave of “no more programmers” took aim at the narrow role and kept missing the broad one, because the broad one is mostly deciding, and deciding is the part nobody has automated.

So is this time different?

Yes and no.

The yes is real: the machine genuinely writes the code now, in a way no 4GL ever managed. But look at what writing the code always was. Writing the syntax was hard the way a chore is hard, real skill and real hours, and easy to mistake the effort for the essence. It was a “chore,” though, not the “mission.” The mission was to decide, exactly, what the program should do, and to answer for that decision. That is the programming, and it is the one thing sixty-five years of tooling never took off our hands.

Read the whole list again through that lens and it stops being a run of failed predictions and turns into a single, patient process. Each wave automated a chore and left the mission alone. COBOL took the chore of writing assembly. The 4GLs took the chore of hand-building the same forms and reports. The AI is taking the chore of writing the syntax. None of them touched the mission, because the mission was never the typing. The prediction keeps failing for one reason: from the outside, the chore looks like the job. It is the visible, effortful, teachable part, so people mistake it for the point. It never was the point.

In my own week, the AI’s most valuable move isn’t writing the code. It’s the command that stops and makes me state my assumptions and answer “why” before it builds anything. That is specifying: pinning down what the thing should do precisely enough that even a machine can’t wander off. Specifying is the mission with the typing stripped away, and no wave of tooling ever made it easier.

If I had to bet on where the job goes next, I’d bet up, not out. The work that grows is the work closest to deciding what to build: naming the problem, choosing the shape of the system, drawing the lines between the pieces. We already have a word for the person who does that, “architect,” and it’s telling that the people whose job is to classify jobs keep inventing new versions of it. The US occupational taxonomy had no “database architect” code until 2018; it added one because the role had quietly become real. I’d expect more of that. Not “no more programmers,” but the center of gravity of the work sliding toward whoever decides the structure, whatever we end up calling them. Will we keep calling them “software developers”? “programmers”? “architects”? “product managers”? I don’t know. But the work is moving up the abstraction ladder, and the machine keeps taking the rung below. It writes more of the code every year; a person still has to be accountable for what the code is for.

A schematic, not data. Each wave of tooling automates the rung below, and the human work climbs to the next one. The top rung, deciding what to build, is the one that has never automated. The “architect” rung is my guess at the next name for it, not a measured trend.

So I might be completely wrong. Everyone on this list was certain, and most of them were wrong, which means certainty is clearly not the safe side of this bet. What I’ll commit to is narrower. I’ve now watched the “no more programmers” headline get published, with a straight face, roughly once a decade since 1959, over a line that never stopped climbing. The next time it runs, notice that you’ve read it before. Then ask for better odds than “this time for sure.”

The short version.

You’ve paired with an AI coding assistant by now. You know the two faces of it. For ten minutes it’s the sharpest junior engineer you’ve ever worked with. Then it confidently does the wrong thing, because it guessed at something it should have asked you about, and you spend the next hour unwinding the guess.

People assume the fix for that is a better model, or a cleverer prompt. Mine wasn’t. My Claude super tool is a folder of boring markdown files.

Over the past months I took the software-engineering habits I’d otherwise have to remember to apply, and wrote them down as Claude Code slash commands. Now the habits run themselves. I put the whole set on GitHub as claude-shipyard. Here is what a normal day with it looks like.

The plan is where the thinking happens

Got an issue to fix? I run /make-plan.

It explores the current state of the code, builds a plan, and actively hunts for open questions. When it finds one, it doesn’t guess, which is the whole point. It lays out the alternatives with their pros, cons, and implications, and lets me choose.

And the top of every plan lists the assumptions we’re making. That sounds like a formality. It isn’t. A wrong assumption doesn’t announce itself. It sits there quietly and turns into a wrong step three commits later, when it’s expensive to undo. Reading the assumptions first is the cheapest bug-catching I do all day. State your premises before you build on them. It’s the least glamorous idea in Jean-luc Doumont’s toolkit and the one I lean on most.

One command to start clean

/git-work-on-issue takes it from the very top. It marks the GitHub issue as “in progress”, prepares a worktree and a branch, then calls /make-plan for me.

One command, and I’m working in an isolated checkout with the plan already drafted. My main branch never gets touched. If the whole thing turns out to be a bad idea, I throw the worktree away and nothing else knows it happened.

Brainstorming is just interrogation

Not everything starts as a tidy issue. Sometimes it starts as a vague “I think we should build X, but I haven’t thought it through.”

For that I have /brainstorm, and /brainstorm interrogates me. It opens with “why”, and then it asks, and asks, and asks. Question after question, each one narrower than the last, until everything is clear. It’s slower than I’d like. That slowness is the point.

The reason I keep it around is that the relentless questioning is the only reliable way I know to surface the unknown unknowns: the decisions I didn’t even know I hadn’t made yet. Those are the ones that sink projects. Not the hard problems you can see coming, the small ones you never noticed you were quietly assuming.

From a fuzzy idea to merged PRs

The output of a /brainstorm doesn’t just sit in a document. It can become a GitHub milestone, split into issues. From there, /milestone-plan and /milestone-run take the whole pile and work it one issue at a time: plan, implement, review, merge, next. I go from “I have a fuzzy idea” to “there are merged PRs” without personally babysitting every step in between.

The unglamorous end, where the code actually gets good

The interesting part of software is the thinking. The part that decides whether the code is any good is the boring stuff at the end, and the boring stuff at the end is exactly what I skip when I’m tired. So I wrote that down too.

• /git-pre-pr self-reviews the diff before I open a PR: tests, leftover secrets, sloppy exception handling, the things I’d be embarrassed by in review.
• /gh-code-review reads the review comments back to me grouped by severity, so I fix what matters before I go bikeshed a variable name.
• /git-pr-merge merges and cleans up the branches and worktrees behind it, so I don’t leave a graveyard of stale branches.

Why a folder of text files beats a better prompt

Here’s the part I didn’t expect. None of this is clever AI. There’s no fine-tuning and no secret prompt hiding in the repo. It’s years of software-development practice, written down as plain markdown.

What the markdown buys me is that the discipline stops depending on me being disciplined. On a good day I’d remember to list my assumptions, question my own plan, and review my diff before pushing. On a tired day, a Friday-afternoon day, I wouldn’t. The commands don’t have tired days. They carry the process so I don’t have to.

That, for me, is where AI-assisted coding actually pays off. Not a smarter model. A model that runs your process, the same way every time, including the times you would have cut the corner yourself.

The caveat

This fits how I work. It might not fit how you work, and some of these commands encode opinions you’d reasonably disagree with. I like worktrees; plenty of good engineers find them more trouble than they’re worth. So don’t adopt it wholesale. It’s all open source. Read it, take the two or three ideas that map onto habits you already have, and leave the rest.

Steal what’s useful.

“I only care about what a few people think of my work and they are already aware of what I produce. Think of me as a ‘professional loser.’”

A researcher wrote that to me last week. I’d cold-emailed them to pitch Loud Camel, the thing I’m building, and instead of the brush-off I expected, I got two thoughtful replies and a PDF: A. C. Leopold’s 1973 paper “Games Scientists Play,” the one that coined “professional loser.” They wanted me to know which segment of my market they belonged to, and to register that they considered the label, in their words, “silly and testosterone-driven.”

I want to defend them, mostly. And then I want to point at the single assumption holding their position up, because I think it’s quietly breaking.

What Leopold got right, and what’s ugly about it

Leopold describes scientists chasing prizes, gaming citation counts, publishing in prestige journals even when, he notes, “most people who are interested in the subject of your paper may not read that journal.” Swap a few nouns and he’s describing LinkedIn. He wrote the attention economy in 1973, before anyone called it that.

The ugly part is the title. A scientist who won’t compete for attention is, to him, “tantamount to being a professional loser,” and he found an “alarming proportion” of them. That’s the part the researcher rejected, and they’re right to. Reticence isn’t a moral failure. Some of the best people I know would rather be correct than be noticed.

The loser’s bet, stated fairly

“The few people who matter already know my work.” For a human field, that isn’t denial, it’s an accurate model of how reputation actually moves. Leopold himself, later in the same paper, lands on the same mechanism: scientists run on what he calls “strokes,” small signs of recognition, and “a stroke is only as good as the stroker.” Being known by the three people who define your subfield is worth more than being seen by ten thousand strangers. The professional loser has simply noticed this and refused to chase the strangers. Rational.

It even has range. The researcher granted, generously, that “being noticed is better than the alternative,” only that it is “necessary but not sufficient.” I agree with every word.

The assumption underneath it

Here’s the assumption nobody states, because until recently it never needed stating: the people who decide whether your work gets found are people.

That’s the part that’s changing. More and more, the first pass over the literature isn’t done by the three colleagues who know your name. It’s done by a model. Someone asks ChatGPT or a research tool what’s known about X, and the tool returns what it can retrieve and silently drops the rest. A paper nobody can find isn’t judged on its merits. It just isn’t in the room.

Reputation-agnostic is not obscurity-proof

The researcher saw this coming, partly. They wrote that by “being more agnostic to reputation,” LLMs “may erode current practices.” True. A model doesn’t care that you’re a full professor, or that you publish once a decade. The optimistic read is that this rescues the professional loser: a reputation-blind reader should surface good obscure work on merit, no self-promotion required.

I don’t buy it, and the reason is one short distinction. Agnostic to reputation is not the same as agnostic to findability. The model doesn’t skip your paper because it’s unimpressed by you. It skips your paper because it can’t retrieve it. Reputation-blind, yes. Obscurity-proof, no.

This is what actually changed for the professional loser. The old stance was protected by human colleagues who carried your work around in their heads and brought it up when it was relevant. They remembered you. The model remembers no one. It doesn’t snub the obscure, it just can’t reach them. “The few who matter already know my work” was a fine bet while the few were people. It gets shakier every quarter that the few include something that has never heard of you and never will.

I might be wrong

Maybe the tools get good enough that retrieval stops rewarding the findable and starts genuinely finding everything, indexing the forgotten preprint and the badly titled 2009 paper as readily as the loud stuff. If that happens, the professional loser was right all along and I’m selling umbrellas in a drought. It’s possible. I’d just rather my work be in the index while we find out.

I wrote the broader, less science-flavored version of this argument over in my newsletter, On professional losers. And I owe the whole train of thought to the researcher who called themselves one, and then handed me a 53-year-old paper to argue with. The best kind of reply to a cold email.

Where is my $400,000?

Do AI researchers know what a citation is worth? Do economists, the people who literally study what things are worth? No. They write for the science, the result, the next question. The price of a citation never comes up.

Do you know what your citation is worth?

No. Nobody told you, because you were busy doing the work.

Albert-László Barabási put a number on it. In his 2018 book The Formula, he treats citations as currency and sets an exchange rate: take what the United States spends on research, divide by the citations that money produced, and you land at roughly $100,000 per citation.

Since I launched Loud Camel, a tool that helps researchers get cited and recognized, I have picked up four new citations. So where is my $400,000?

Why the $100,000 citation is an average, not a price

It is an average, and a treacherous one, because it sits on top of one of the most lopsided distributions in science. Citations follow a power law. Most papers are cited well below the mean, a large share are never cited at all, and a small elite collects the bulk of the total. An average over that shape tells you about the elite, not about you. It is the street where everyone is a millionaire on paper because Bezos just moved in.

The skew is also getting worse. Mathias Wullum Nielsen and Jens Peter Andersen, writing in PNAS in 2021 across 4 million authors and 26 million papers, found the top 1% of scientists lifted their share of all citations from about 14% to 21% between 2000 and 2015, with the Gini coefficient rising from 0.65 to 0.70. The detail that matters: over the same years the elite’s citations per paper actually fell, from 3.10 to 1.79. Their share grew while their per-paper impact shrank. Concentration tracks position and volume, not better science.

Does the money side hold up at all?

Partly, and it’s only fair to say so. Funding does buy citations: an instrumental-variable study of grants from China’s National Natural Science Foundation found that competitive funding raises both the quantity and the quality of the publications it pays for. Public research earns large real returns to the economy through spillovers. So Barabási is not inventing value out of nothing.

But two things puncture the tidy $100,000. First, the dollar figure is an average over the whole national bill, not the price of your marginal citation. Second, the citation is a weak and gameable yardstick: counts and impact factors are inconsistent predictors of research quality, and once a number becomes a target, paper mills, citation cartels, and self-citation rings move in. Goodhart’s law does not exempt scholars.

So whose citation is worth $100,000?

Not the average researcher’s, because the average is a fiction the giants create. The value of your next citation is decided by where you sit in a distribution that is getting steeper every year, and position there is set less by how good the work is than by how many of the right people ever find it.

So I will end where I started, with a question. Whose citation is actually worth $100,000? And what are you doing this month to make yours one of them?

I finished the billing months ago. I never switched it on.

Loud Camel has been live for months. People sign up and use it, all for free. The billing has been finished almost that whole time. It works, I tested it, it is ready to turn on. And week after week, I have quietly decided that this is not the week.

Each time, I had a reason, and the reasons were real, which is exactly what made them work. There are few users, so what is the hurry. The ones who do sign up, I upgrade by hand, because I want them to enjoy the product without thinking about a credit card. Traffic is low. The timing is never quite right. None of these is a lie. Put together, they made a wall I did not have to climb, and I told myself I was being patient and generous.

This was not patience and it was not generosity. It was procrastination. Ordinary procrastination feels bad while you do it; you know you are avoiding something. This kind feels responsible. Every week I chose not to ship billing, I felt a small sense of relief, and I read that relief as proof I had made the sensible call. It was the opposite. The relief was the tell.

Underneath the sensible reasons was something smaller and less flattering. As long as the product is free, “people use it” can quietly pass for “people need it.” The day I ask for money, those two stop being the same sentence. And I did not want to learn which one was true. If I turn on billing and nobody pays, that is not a bug I can fix over a weekend. That is the market telling me it does not need the thing I have been pouring myself into. So I left the test un-run, and the question comfortably open.

But free usage was never the signal I needed. People will take anything that costs nothing, and the free upgrades I handed out by hand were me manufacturing the appearance of demand for an audience of one: me. The only real evidence that work matters is that someone is willing to pay for it. By hiding from the answer I was afraid of, I was also turning away the only answer that would have meant anything. Months of activity, none of it able to speak to the single question worth asking.

And the test does not get easier by waiting. The answer is already whatever it is. Delaying only postpones the moment I learn it, while I keep building on an assumption I have refused to check. Fear felt like safety.

There is an irony I cannot pretend not to see. I spend my days building a tool that helps researchers stop hiding their work and get it in front of the people who should see it. There is a Hebrew saying, מי שמתבייש מתייבש, the shy one dries up. And I had been too shy to put a price on my own work and ask to be paid for it.

So I stopped waiting. By the time you read this, billing is live on Loud Camel. I still do not know what it will tell me, and that is the point. I would rather find out than spend another month not knowing.

If you are sitting on something you keep deciding not to do, and every reasonable excuse to wait shows up with a small wave of relief, look harder. It is usually pointing at the test you are most afraid to run.

What you just read is a form of Omphaloskepsis, navel gazing, a term and a technique I learned from my former manager Martin Remy. Done honestly, it is how you catch yourself rationalizing before the rationalization costs you.

It’s not the Matthew effect. It’s the Daniel effect.

When I worked at Automattic, the company behind WordPress.com, one of the things my team looked into was what makes a blog post get likes. We had data showing that people who don’t get likes early tend to quit blogging. The likes aren’t vanity. They’re the fuel that keeps someone writing.

Why does early success predict later success?

So we went looking for the best predictor of whether a post would get likes. We checked the obvious candidates: topic, length, time of day, whether it had an image. The strongest predictor, by a wide margin, turned out to be embarrassingly circular. It was whether the author’s previous posts got likes.

That’s it. The best way to get likes on your tenth post is to have gotten them on your ninth. It’s a chicken-and-egg trap, and it’s a little sad. The people who most need the encouragement, the ones starting from zero, are exactly the ones least likely to get it.

Blogging isn’t special here. Authors who made money on their last book are the ones most likely to make money on the next. The same circular pattern shows up almost everywhere you look for it.

Sociologists have a name for this. In 1968 Robert Merton called it the Matthew effect, after a line in the Gospel of Matthew: “to everyone who has, more will be given, but from the one who has not, even what he has will be taken away.” Merton chose that verse precisely because it sounds unjust. He was describing how famous scientists collect the credit for work that less-famous scientists did just as much of. Recognition accrues to whoever already has it. (Robert Merton, “The Matthew Effect in Science,” Science, 1968.)

Will AI finally level the field for newcomers?

For most of history this trap looked permanent. You needed an audience to get an audience, a track record to earn the next one, capital to attract capital.

And then AI arrived and looked, for a moment, like the thing that finally breaks it. Suddenly anyone can produce a clean essay, a working script, a competent analysis. The surface of expertise, the polished output that used to take years to fake, now costs twenty dollars a month. If the Matthew effect ran on access to knowledge, AI should be the great leveler.

Here’s the claim I want to make. The phenomenon Merton named after Matthew was described more accurately about six hundred years earlier, by Daniel, in Aramaic.

When Daniel interprets the king’s dream, he opens with a blessing: יָהֵב חָכְמְתָא לְחַכִּימִין וּמַנְדְּעָא לְיָדְעֵי בִינָה, “He gives wisdom to the wise, and knowledge to those who already understand” (Daniel 2:21).

Read it the way the Matthew effect is usually read and it sounds just as unfair: wisdom handed to the people who already have it. The rabbis noticed. The Talmud (Berakhot 55a) says it flatly. The Holy One grants wisdom only to one who already has wisdom, and it cites this exact verse.

But the commentators flip it. A Roman noblewoman once challenged Rabbi Yose ben Halafta on precisely this point: surely God should give wisdom to fools, since they’re the ones who need it. He answered with a question. If two people came to you for a loan, one rich and one poor, which would you lend to? The rich one, she said, because he can pay it back. You’ve answered your own question, he told her (Midrash Tanchuma, Vayakhel). Give wisdom to a fool and he wastes it in the bathhouse. Give it to someone prepared to hold it and they build something.

Daniel isn’t talking about credit. He’s talking about capacity. Wisdom is lent to whoever has built a vessel that can hold it. Access was never the constraint. The vessel is.

Which is exactly why AI doesn’t level the field the way it appears to. AI hands everyone the surface and nothing underneath it. It floods you with access and leaves untouched the foundation that decides whether any of that access turns into something real. When everyone drinks from the same firehose, the thing that matters is who has somewhere to put the water. The dabbler with infinite knowledge at his fingertips still can’t hold it. If anything, the Daniel effect gets stronger in the AI age. Depth was always the real moat, and now it’s close to the only one left.

How do you escape a cold-start problem with no audience?

You don’t wait for the recognition. You can’t, because waiting is the trap. The only way out of the empty state is to manufacture your way out of it: show up, publish, build your presence deliberately, do the work before anyone is watching. Recognition comes after that, never before it. Every post you write does two things at once. It adds to the presence you don’t yet control, and it adds a layer to the vessel you do.

The ‘not ready to share’ antipattern

My friend and mentor Danny Lieberman writes an excellent newsletter about antipatterns: the moves people make instinctively that quietly cost them. This post is in that spirit. The antipattern: keeping important work to yourself until it is ready. The fix turns out to be the thing the old saying tells you not to do.

When is your work actually ready to share?

The instinct is universal. When people work on something they consider important and big, they retreat into a shell and wait for the work to be done before they show it to anyone. A report for leadership. A presentation. A new product. A Python module. A pitch deck. The instinct is the same: I will share when it is ready.

There is a saying in many languages: do not show half-done work to a donkey. It sounds like discipline. I think it is one of the more harmful rules people carry around. It tells you to optimize for not looking foolish today, while saying nothing about whether your final product will be any good.

A donkey, the audience the saying tells you to fear.

“Show me your work”

This is the trap the donkey saying sets. It tells you the audience is the problem. Show your work only to people who can already see what you see. Otherwise they will misread, miss the point, ask a question whose answer is on page two. They will. Good. The “donkey” from the saying, the reader you were told to hide rough work from, is the most useful reader you have. They cannot see the picture you carry in your head, which means they will show you where it fails outside it.

What sharing rough work actually gets you

If the legal or IP situation allows, share your work long before you think it is ready. The half-done draft. The rough plot. The function that almost compiles. The demo with three broken screens.

Most of the feedback will be off-target. You will think, this person did not get it. Sometimes they did not. More often, they got something you stopped noticing: that the framing was not clear, that the order of the argument was confusing, that the assumption you treated as obvious is not obvious to anyone else. You think you know what you know, but you might not know what you know.

The embarrassment cost of sharing rough work is small and one-time. The cost of polishing the wrong thing is large and compounds.

So pick the piece of work you have been keeping in your shell because it is “not ready to share yet.” Find one person who will give you an honest reaction. Send it to them today, in the state it is in, with one sentence:

“I am still working on this and I do not know what it will be. Tell me what you see.”

You will get back something useful, often only one sentence. That sentence is worth more than another week alone with the draft.

If you are in academia and work on a paper, publish a draft on arXiv or preprints.org. You will timestamp your findings so nobody scoops you, and you will attract feedback that makes the review process smoother.

When your LLM pipeline silently returns zero

One Sunday morning the daily scan ran for a user of Loud Camel, a tool that helps academics promote their research and get cited. It came back clean: a couple dozen items scored, zero relevant, zero results delivered. That looked like the system telling me there were no good matches this week. It was the system screaming, with nothing logged.

The silent-but-deadly failure mode

Pardon the analogy. Silent failures in LLM pipelines work like the worst farts in an elevator: nothing audible, nothing on the surface, then you notice the room has emptied. The LLM call returned. The parser returned a Python dict. Every type check passed. The number returned was zero, and zero looked like the truth.

What actually went wrong

The model hit its max_tokens cap and the response was truncated mid-string. No closing brace, no closing fence. The JSON parser had a clever repair fallback: it scanned for key-value pairs regardless of nesting depth and reassembled them into a flat dict. The repair returned an object that was technically dict-shaped but contained the wrong keys, all from the truncated inner level of the structure. The consumer iterated, found nothing it recognized, defaulted every item to a score of zero. The dashboard showed zero relevant, the user got an empty scan, and the cost line read like everything was normal.

Two days later the same shape showed up in a different LLM call site. The model output truncated at a different limit, the parser returned a dict-shaped object with the wrong keys, the consumer produced zero results. The day after, a third call site failed the same way. Three places. One bug class. No alarms.

How to make a silent failure loud

Two cheap defenses, neither of which I had on Sunday morning.

First, the parser cannot be allowed to lie about shape. A truncated array should return None or the complete prefix, never an object. A truncated nested object should return only the outer-level keys that were complete, never the inner ones hoisted up. The fix is unit tests at the parser boundary that assert this shape contract. Zero LLM cost. Deterministic.

Second, the consumer must validate the shape before defaulting to zero. If the function expects a dict keyed by request IDs, it should check that the returned keys are request IDs and warn loudly if they are not. A single line that reads ‘scored 0 of N items, response shape unexpected’ would have turned a four-day silent outage into a four-minute fix.

Why this is the bug class to invest in

LLM call sites multiply faster than you can audit them. Every prompt change, every model change, every batch size change opens a new path to the same failure. Patching each call site after it bleeds is stop-gap engineering. The structural defense is to make the parser refuse to lie and the consumer refuse to be silent. Both run in tests, in milliseconds, with no token cost. Both would have caught all three of my outages before any user saw a zero.

Silent but deadly is funny once. It is not funny when a real user gets an empty scan four days in a row.

Customers see your tunnel vision before you do

Last week an early user of Loud Camel, a tool that helps researchers get cited and recognized, caught two failures in my product. I had built, reviewed, and shipped both of them.

You can’t see your own tunnel vision. A customer can.

What I shipped

The first paper Loud Camel surfaced for that user was attributed to the wrong author. The named researcher hadn’t written it.

Then they flagged something heavier. The cold-email drafts the product writes for users imply that the sender read the recipient’s paper. The sender didn’t. I built that flow, I read those drafts, and I shipped them anyway.

How I lost the star

When I started Loud Camel, I told myself integrity was the north star. Every recommendation honest. Every email truthful. Then I spent four months deep in OpenAlex joins, email parsing, and pipeline plumbing, and I was looking at the code, not at the star.

The thing I cared about the most became the thing I stopped checking.

Why I couldn’t audit myself

I tried the standard remedies, like a weekly review of priorities and asking myself whether I was still building what I said I would build. None of it helped, because the frame I used to evaluate the work was the same frame that built the work.

The user didn’t know anything about my north star. They just read what the product said, and noticed that it wasn’t true. If you are building something, schedule those conversations on purpose. They are the only check I’ve found that works from outside the tunnel.

What I am changing

I’m adding a validation step that confirms the attributed author actually appears in the paper’s author list before any recommendation is surfaced. I’m rewriting the cold-email drafts so they don’t pretend the sender read what the sender didn’t read. And I’m writing back to every user who flagged something, to thank them.

Will that be enough to catch the next drift? I doubt it. Four months is a long time to not notice something, and I have no reason to believe I’ll be more alert next time.

The worst way to visualize geographic data

Country choropleth maps are the wrong chart for visit counts. Or for any kind of count. They encode magnitude as land area, but the question you actually want answered is “where are my users?”, not “which country owns the most square kilometers?” The two have almost nothing in common.

I recently launched Loud Camel, a tool that helps researchers get cited and recognized. I opened the Google Analytics geographic report and got the “before” map below.

Look at it for five seconds. Cover the title. What are the top five countries by active users?

You probably said the United States. Maybe Canada and Russia. The blue blobs are big and obvious.

Now find Israel.

You can’t. It is one or two pixels somewhere east of the Mediterranean. Israel is currently the country with the most active users on the site. It is the leader. The map hides the leader.

Why country maps mislead about counts

A choropleth fills each country with a color whose intensity encodes a value. In theory the reader compares colors. In practice the reader compares areas, because area is the loudest visual signal on the page.

A country with a huge area and a low value looks important. A country with a tiny area and a high value disappears. The reader’s eye correlates magnitude with land mass, not with the data.

This works only when geographic proximity matters: epidemiology, regional logistics, climate maps. Visit counts have no spatial structure. A user in Texas is not “close” to a user in Mexico in any way that matters to the data. The map adds noise, not insight.

Use a sorted bar chart instead

The same data, sorted from largest to smallest as a horizontal bar chart, looks less sophisticated, but reads in one second.

Bar length encodes the value directly. The reader’s eye runs top-down by magnitude. Israel is at the top because Israel has the most users. The United States is second because it has the second-most. There is nothing to interpret.

The numbers in the chart are illustrative; the ordering is not.

The hardest part of being a solo founder wasn’t what I thought

The hardest part of running a one-person company is not the workload. It is choosing the right work.

What I expected

When I started, I assumed the hard part would be wearing every hat. CEO. CTO. CMO. VP Product. Four jobs in one chair, no one to delegate to, no one to escalate to.

All of that while working full time as a lecturer and researcher at a college.

The workload is real. It is not the bottleneck.

What is actually hard

A solo founder is one person, and that person has a default mode. Mine is building. I want to ship features, fix bugs, and tighten infrastructure until it hums.

Building feels productive. It is measurable. It is satisfying. At the end of a coding day the diff is real, the bug list is shorter, the system is leaner.

The work that pays the bills feels like distraction

Sales conversations. Watching the market. Learning what customers actually need. Talking to people instead of typing into a terminal.

This work has no diff at the end of the day. No ticket closed, no graph that moves on a dashboard you control. It feels soft, slow, like you are getting away with something.

It is also the work that decides whether the product survives.

The real lesson

A perfectly built product nobody wants is worse than a half-built one customers are pulling out of your hands.

The hardest part of being solo was not doing everything. It was resisting the role I am best at when another role needed me more.

Building is the comfortable seat. Talking to customers is the uncomfortable one. The discipline is to spend more time in the uncomfortable seat than feels natural.

A small weekly check

Each Friday I ask one question: did I spend more time this week with code or with customers?

If the answer is always code, that is the bug to fix.

When rigid blocs break, they break together

A rigid voting bloc is supposed to be the boring case. People vote the same way, election after election, because their identity tells them to. The interesting story, the textbook says, is what happens when the bloc weakens.

I want to argue the opposite. The interesting case is when a rigid bloc breaks — and it breaks at every address at once. That synchronized fracture is not the bloc weakening. It is the bloc working.

The puzzle

Israel’s ultra-Orthodox (Haredi) population is one of the most disciplined voting blocs in any democracy. Two parties — UTJ for Ashkenazi voters, Shas for Sephardi voters — have split that vote with 90-95% loyalty for decades. Cross-ethnic voting (a Sephardi voting UTJ, or an Ashkenazi voting Shas) is so rare it is treated as measurement noise.

Then, in the March 2021 election, that noise jumped to 12-19% of Sephardi voters in five different cities, all at once. By the next election it was gone again. The voters did not move house. The borders did not shift. Same people, same streets, one election of mass cross-ethnic switching, then back to baseline.

The chart

Cross-ethnic switching jumped from a typical 1-3% to 9-19% across geographically dispersed Haredi cities — within a single election cycle. Demographics cannot move that fast. Something else did.

Why this matters

There is a tempting reading: the bloc was finally weakening. Identity politics fading. Voters acting as individuals.

That reading is wrong, and the geography is what tells you so. Independent voters do not switch in five cities in the same election in the same direction. Independent voters do not return to their original party 13 months later. What you see in the chart is coordination, not autonomy.

The corpus evidence — about 58,000 Haredi forum and news items from those 13 months — points to a specific channel: senior rabbis, working through yeshiva networks, told Sephardi voters to vote UTJ that one cycle. They listened. When the directive softened, they returned.

The framework

I call this ‘rigidity with stress fractures.’ The same machinery that produces decades of unbroken loyalty — centralized authority, dense networks, voting framed as collective duty — is the machinery that produces an instant, country-wide swing when leaders ask for one. Rigidity and synchronized switching are not opposites. They are two outputs of the same system.

This generalizes. Any identity-based bloc with centralized authority, organizational reach, and a population trained to follow directives can do this. Italian Christian Democracy under bishop replacements (Lanzara et al., 2024). U.S. evangelical voter guides (Campbell et al., 2011). Ethnic broker networks across sub-Saharan Africa (Horowitz, 1985). The Haredi case is unusually clean because elections came every 6-12 months and let us watch the disruption and the recovery in the same window.

The takeaway

When you see a sudden swing inside a population that was supposed to be politically immobile, do not jump to ‘the bloc is fragmenting.’ Check first whether the swing is synchronized — same direction, same magnitude, multiple places, single window. If it is, you are not watching the bloc weaken. You are watching it obey.

The mechanism that holds the bloc together is the same one that can move it. Stability and discipline-driven volatility are not opposite diagnoses. They are the same diagnosis read at different speeds.

When in some places work meetings start with people introducing their preferable pronouns, in Israel we start with a briefing about the closest bomb shelter. When in other places people skip important meetings to take care of their pet goats (true story), in Israel people join meetings on Zoom from Army Reserve Service during breaks from patrols or other duties.

I wrote about this last June. The war will end, I said, and when it does, hundreds of thousands of Israelis will come back – to work, to building, to a country in crisis. And crisis breeds resilience. They’ll come back hardened as fuck.

Nine months later, nothing has changed my mind. If anything, I’m more convinced. The people who learned to operate under rockets, who managed companies while covering for half the team on reserve duty, who wrote code between sirens – they are coming back with muscles that can’t be trained in peacetime. Extreme communication, chaos management, creative problem-solving under constraints that most people can’t imagine.

Good luck competing with them. Good luck competing with us.

After my previous post about Anthropic’s spider chart, several people asked me how I would actually go about fixing it. So here is how – with a single prompt.

I gave Claude the original graph and the following instruction, based on my C for Conclusion approach:

the visualization is not good. First, formalize the image into a single-sentence conclusion of up to 8 words.

Then, use the approach of Stephen Few and Edward Tufte, maximize the data-ink ratio, use Information layers (Jean-luc Doumont) to generate the graph based on the same data that is much better and that conveys the conclusion you made above

That’s it. Here is the before and after:

The conclusion – “AI adoption vastly lags its theoretical capability” – is now the title. Categories are sorted, the gap is immediately visible, and there is nothing left to decode.

See the standalone version of the graph (the raw data, as extracted by Claude, is in that file).

For more on why radar charts are almost always a bad choice, see my earlier posts on spider charts and radar charts.

But, Boris, vibe plotting is not a real expertise!

Sure, but Anthropic people have access to the same vibe plotting tool I have (even better). It’s knowing what to ask for that is the real expertise. And if you don’t have that, you can always ask someone who does.

I have put together a collection of lecture, workshop, and course proposals on AI and AI-assisted programming. Each one is tailored to a specific audience and comes in three delivery formats: a one-hour lecture, a three-hour hands-on workshop, and a multi-session course.

The topics range from a non-technical introduction to AI (for students from any department) to hands-on AI-assisted programming for CS students, CS lecturers, industrial engineering students, managers, and life science researchers. Most proposals are available in both English and Hebrew.

All proposals are now collected on a single Lecture & Workshop Proposals page.

Anthropic has published an interesting study about labor market impacts of AI: Labor market impacts of AI: A new measure and early evidence.

It is hard to overestimate Anthropic’s contribution to the world of technology. Their innovation and professionalism are remarkable. But sadly, in the report they included a spider graph that leaves their entire post with a bad taste. (I wrote about spider charts many times before.)

It takes a good minute or two to understand what the image is about. Spider charts are almost always a bad data visualization technique. So how do we fix it?

First, we need to define the conclusion. A short sentence of up to 8 words that conveys the general idea of the graph. After that, we create a graph that does exactly that – conveys the conclusion.

Here, the conclusion is the difference between theoretical AI capability and the observed AI adoption across occupational categories. So we need to show exactly that difference.

Look at the improved graph. All the categories are sorted according to the observed adoption rate. The differences are immediately visible, and the conclusion is right at the top of the graph, leaving no room for guessing.

The tech changed, the questions barely did.

Look at this Computer and Society syllabus from 1975.

Apart from some archaisms like “data banks” and the typesetting, almost everything here feels painfully current: privacy, surveillance, economics, law, education, public perception, even “can machines think?”.

With minimal edits, this could be a strong and necessary course in any CS curriculum today.

The tech changed.

The questions barely did.

One short prompt message that made my vibe coding life easier

Before every git commit, I paste this into Cursor / Claude / GitHub Copilot—whichever is working that day:

“examine the changes since the last commit – can you simplify anything?”

That’s it.

One line. No magic. Just a tiny push to refactor, delete, and clarify.

Since adopting it, I commit less junk.

I rewrite more than I add.

And future-me swears a little less.

#VibeCoding #DevTips #Git #AIpairProgramming #CleanCode

How Sausages Are Made (and How a Vibe Research Was Born)

It started with an idea.

Months ago, long before there was a paper or even a draft, I found myself circling around a question: why do some reasoning models seem to “fail” in ways that feel strangely human? I kept turning it over in my head on walks, in the car, in those in-between moments when you’re not really working but your mind refuses to let go.

Then one night I stumbled upon the Apple paper, The Illusion of Thinking, and one week later came The Illusion of the Illusion of Thinking. It was like someone had dropped a match into a pile of dry twigs. It didn’t give me the idea, it sparked the one I’d been nursing quietly for months. Suddenly, I couldn’t stop thinking.

I opened a new project, started pulling papers, sketching diagrams, whispering to myself while driving. I even used ChatGPT in voice mode during commutes, pouring my thoughts out loud so I would not lose them. I spinned up every deep search product I had access to, I wrote, rewrote, used Claude and ChatGPT to expand, clarify, and critique the ideas. It was like vibe coding, but in academic writing. For me, this collaboration with an AI was new, so I started a diary.

For me, this collaboration with an AI was new, so I started a diary and invited friends to read in in real time.

My diary shows 17 hours logged, spread over a few weeks. But those 17 hours? They are not the full picture. They are just the visible part of a much longer story, the part where I sat in front of a keyboard. The invisible part was the months of thinking, discarding, distilling, connecting dots that only started to make sense later.

Then came the reviewing process.

If you’ve ever sent a paper out for peer review, you know that’s when the sausage grinder really starts. Reviewer 1 was constructive, nudging me to explain how my work went beyond prior critiques. Reviewer 2, let’s just say their feedback was less than kind. They questioned the contribution, the clarity, even the usefulness of the whole thing. Two striking remarks stayed with me: Reviewer 2 wrote

“There is no contribution of the paper, the discussion is low-level quality and the conclusions do not seem to have practical or theoretical usefulness.” Another line hit just as hard: “The paper proposes a discussion on an extensive subject, but fails only analyzing shortly specific topics of that subject.”

For an hour or two, I was angry. Then I got to work. I rewrote the introduction, reframed the entire contribution, tightened every paragraph. I added design implications I hadn’t planned to include. I went back through decades of references to make sure every citation pulled its weight. Working on the original draft and the submission took 17 hours (MDPI.com’s author process is smooth as silk). Answering the reviewers took 14 more hours.

And then, something surprising happened. I realized that Reviewer 2’s harshness had actually made the paper stronger. Their criticism forced me to look hard at the messy, half-ground meat of my argument and turn it into something people could actually digest. Reviewer 2, by the way, was only slightly impressed and still recommended not to publish the paper, even after the improvements.

Now there’s a screenshot sitting on my desktop, full of tracked changes. It’s the clearest picture of what vibe research really is: an idea sparked, shaped by months of invisible labor, tested in the fire of critique, and finally molded into something you can hold in your hands.

So yes, my diary says 17 hours. But the real work started months before that, and it never really stops.

That’s how sausages are made.

What’s your own behind-the-scenes story? 👇 I’d love to hear it.

Celebration time

🎉 Not only has was my paper accepted to publication in Applied Sciences, its preprint has already been downloaded 100 times on preprints dot org! 🚀

BTW: if you are into #AI and think how it affects the humanity, you should totally read it. If you host podcasts on AI, you should totally invite me to talk . I LOVE talking about myself :-)

#Research #Science #Publication

A Bird in the Hand… and Two? Even Better!

Tonight I received two separate emails from two different journals – both saying the same thing:

Two of my papers have been accepted for publication.

One of them started its journey back in 2016 and finally crossed the finish line.

The other was written from scratch and accepted within a month.

No clear moral here, except: keep going, and keep trying.

(Also… check the timestamp on those emails 🙂)

Feel free to reach out if you’d like to hear more about the journey or the lessons learned!

Not a meeting – a ceremony 🥴

The worst communication antipattern I’ve ever seen?

A daily (or weekly) “sync” where 7–10 people go around reporting to the manager. One by one.

Everyone else? Daydreaming.

Zoom crowd? Writing emails. Scrolling LinkedIn.

Occasionally, someone tries to justify their presence and sparks a side discussion.

Guess what – it derails the meeting and helps no one.

In 99.9% of cases, these meetings end late a and have zero results.

How do you spot this waste of time?

Easy:

– Look at the faces. If most are bored? It’s a ceremony.

– If the only one getting value is the manager? It’s a ceremony.

– More than six people? No way it’ll be efficient. It’s a ceremony.

Why this happens? Because it’s easier for the manager to have everyone in the same room or call, it removes the responsibility to held and be on time in seven different 1:1s, and sometimes it makes them feel important. The result? Frustration, loss of initiative (Google

Why Group Brainstorming Is a Waste of Time

), no job is done.

Want your team aligned? Start with trust, not ceremony. Call me if you want a fresh look at your communication routine

How do your team syncs actually work?

#communication #workculture #meetings #leadership

I don’t believe I need to say this in 2025 🙄

But here we go: group brainstorming doesn’t work.

You gather 6–12 smart people, throw them in a room (or Zoom), say “let’s be creative” — and expect magic?

Here’s what you actually get:

– Loud voices dominate. – Quiet ones shut down. – No critical thinking — why bother if others are already talking? – Everyone feels the need to say something — even if it’s useless. – The real thinkers? They bring their best ideas after the session ends.

You know what does work? Give people time to think alone. Then review ideas asynchronously or in small, structured conversations.

Still think brainstorming is productive? Google “Why Group Brainstorming Is a Waste of Time site:hbr.org” — the article is from 2015. It was true then. It’s still true now.

#leadership #communication #creativity #workculture #brainstorming

Hardened as Fuck

This war will be over.
Maybe not in a week.
Maybe not in a month.
Maybe not in a year.
But it will be over.
And when it’s over, hundreds of thousands of Israelis will return.
Return to work.
Return to building.
Return to a country in a crisis.
And you know what crisis does?
Crisis amplifies creativity.
Crisis demands innovation.
Crisis breeds resilience.
They’ll come back hardened as fuck.
People who learned to operate under rockets, under pressure, under loss.
People who mastered extreme communication.
People who managed chaos, served both hierarchy and autonomy.
People who formed new networks, new skills, new muscles.

High-schoolers who learned for exams in bomb shelters,
college students who wrote assignments between battles,
developers who covered for half of the team who couldn’t work,
managers who managed companies, while taking care of broken families.

They will all come back.
They’ll come back as entrepreneurs.
As builders.
As devs.
As leaders.
They will come back hardened as fuck.
Good luck competing with them.
Good luck competing with us.
You’ll need all of it.
#war #israel #leadership

#war #israel #leadership