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 load-bearing assumption, the one 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

The honest hedge: 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.

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 is only fair to say so. Funding does buy citations: an instrumental-variable study of China’s National Natural Science Foundation found competitive grants raise both the output and the citation impact of the work. 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?

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.

That is the part worth noticing. This was not patience and it was not generosity. It was procrastination wearing their clothes. 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 that comfort was bought with the wrong currency. 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, if I am honest, 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. It was the more expensive option the whole time.

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.

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.

Loud Camel news

This week on Loud Camel, a tool that helps researchers get cited and recognized, I shipped exactly this idea into the product. The Reddit opportunities view used to go blank when there were no good threads to reply to, which is the worst thing you can show someone fighting a cold start. Now it always proposes at least one post to publish, with angle-level dedup so even saturated accounts keep getting fresh angles instead of an empty screen. The honest version of an empty state isn’t “nothing here”, it is “here is the next thing you can do”.

Frequently Asked Question

What is the cheapest way to start building visibility before anyone is paying attention?

Start with the cheapest threshold-crossing action there is: profile hygiene. Open your Google Scholar profile, count the papers listed, and compare against your CV. Most researchers find one to three papers missing or duplicated, and every duplicate quietly splits your credit between two half-yous, which is the Matthew engine working against you. Loud Camel automates this kind of low-effort, high-leverage upkeep on a recurring schedule, but you can do the first pass yourself in about ten minutes.

Takeaway

If you are staring at an empty dashboard, no audience and no track record, don’t wait to be noticed before you act. Make the first deposits now, while nobody is watching, because that is the only part of the system you actually control.

Several years ago I was at a network science conference in Tel Aviv, organized by Albert-László Barabási and Baruch Barzel. After the talks a few of us walked to a pub next door. It was full. A woman asked if she could take the empty chair at our table, then asked what we did. Network science, we said. She smiled. “I know a little about that. At the end of my PhD, Paul Erdős offered to write a paper with me. I was too shy, so I said no.”

If you are not a mathematician: Erdős was one of the most prolific mathematicians who ever lived, and the field measures closeness to him by how many co-authorship steps separate you from him, so writing a paper with him directly gives you an Erdős number of 1, a small and lifelong badge of honor. She could have had it. Even before earning her PhD!!! She was too shy to say yes.

She told it lightly, with a smile, decades later. That is the part that stayed with me. Nothing too serious. Just a door she did not walk through, and a life that quietly closed around the decision. She was, I would guess, barely 60 that night. Back then that looked old to me. I am now not far from it myself.

Why am I telling you this?

People are shy about their own work, and many of us were raised to treat self-promotion as something a little shameful. This is not spread evenly. Women self-promote markedly less than equally-performing men, a gap that shows up as early as sixth grade and persists even when there is nothing to gain by holding back (Exley and Kessler, “The Gender Gap in Self-Promotion,” Quarterly Journal of Economics, 2022). And when women do self-promote, they are often penalized for it, judged less likeable and less hireable (Rudman, Journal of Personality and Social Psychology, 1998). So the reluctance is not a character flaw. It is a rational response to a real bind.

But shy people, men and women alike, shortchange themselves and the rest of us. If you do good work, it is your job to make it visible. A good job nobody can find is not really a good job. Unless you are a deep-cover spy, in which case, carry on.

So what do you do about it?

First, reframe it. You are not bragging, you are leaving a trail. “Here is what I did and where to find it” is documentation, not a peacock display, and that framing also sidesteps most of the backlash, because it points at the work and not at you.

Second, tell the few people who would actually care, directly. You do not have to shout into the void. A short note, with no ask in it, to the handful of people who would genuinely want to know is real visibility, and it almost never feels like self-promotion.

Third, make it a habit, not a performance. A small, regular trickle of “here is what I learned this week” beats one agonized announcement a year, and it never requires you to work up the nerve for a big reveal.

And if a weekly visibility habit is exactly the kind of thing you will quietly let slide, automate it. That is the bet behind Loud Camel, a tool that helps researchers get cited and recognized: it runs the visibility steps on a schedule, so good work gets surfaced even in the weeks you do not feel like showing up.

The shy person’s favorite excuse is “I have nothing worth sharing right now,” and a blank screen is happy to agree. So this week I changed how Loud Camel handles that moment. It now always proposes at least one thing to publish, even when nothing obvious is in the queue, and more when good openings are scarce. It varies the angle each time, so even a saturated account keeps getting fresh suggestions instead of repeats or an empty page. You still have to do the un-shy part and hit publish. Loud Camel just makes sure there is always something there to publish.

She did excellent work for decades. She just never let most people see that part of it. מי שמתבייש מתייבש, the saying goes: the shy one dries up. Do the good work. Then make sure someone can find it.

PS. I never asked her name. The pub was loud, the night wound down, and I was too shy to ask a stranger for her email. I still think about it. She had spent a whole career in the same field Loud Camel works in, and I could have asked her to look at what I am building. I did not. So this is a post I had to write to myself too.

My friend and mentor Danny Lieberman writes an excellent newsletter about antipatterns: the moves people make instinctively that quietly cost them (https://substack.com/@dannylieberman). 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. That is the feature, not the bug. 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. Loud Camel, the tool I work on, helps you attract that feedback faster.

Question: what type of ties have better potential to help you in your career? Strong and close ties, or weak ones?

There is a Hebrew saying: כשיש קשרים לא צריך פרוטקציה. Roughly translated: when you have ties, you do not need pull. The word kesharim means connections, exactly what social scientists call social ties. Protektzia is the well-placed favor, the powerful patron who picks up the phone for you, the quiet override of the queue. The saying claims that a wide network of ordinary kesharim makes that patron unnecessary.

A sociologist named Mark Granovetter said something similar in formal terms in May 1973. His paper in the American Journal of Sociology, “The Strength of Weak Ties,” is one of the most-cited in social science. The twist: it is not your strongest ties that matter most for finding what you need. It is the weaker ones.

Why your closest people carry the least new information

Granovetter’s mechanism is simple. Your strongest ties tend to know each other and know what you know. If you have a strong tie to two people, the odds are good that those two have a strong tie to each other. You all go to the same events, share the same circle. The cluster ends up closed and densely overlapping. New information has nowhere new to enter from.

Acquaintances live in other clusters. They go to different events, work in different places, read different things. A weak tie acts as a bridge between you and a part of the world your strong ties never touch.

Figure 2 from Granovetter (1973). Solid lines are strong ties, dashed lines weak. The dashed bridges connect otherwise separate clusters.

What the job-finding numbers showed

Granovetter’s empirical study made the abstract argument concrete. He surveyed professional, technical, and managerial workers in Newton, Massachusetts who had recently changed jobs. Among those who found their job through a personal contact, only about 17% had been seeing that contact often. About 56% had seen them only occasionally, and 28% rarely. Most of the useful job leads were arriving from people on the edge of the person’s social life, not from the center.

How to put yourself near the next opportunity

The practical move is counterintuitive. If you want news, opportunities, or perspectives your inner circle does not already carry, do not lean harder on your closest people. They have already given you most of what they have. Spend time on the people you see twice a year. The colleague from a project five years ago. The acquaintance you barely know but quite like. Reply to the email you almost did not reply to. Show up at the meetup.

Loud Camel, the app I work on, does exactly that: it helps academics grow the network of weak ties their tight circle cannot give them.

The Hebrew saying gets to it in a single line. When you have ties, you do not need pull. So pick three people you used to be close to and barely speak with now. Send one of them a real message this week.

“Is it ethical to use AI to generate content that promotes my research?”

A researcher asked me that recently. My answer: not only is it ethical. It is unethical not to.

“Of course you would say that, Boris. You founded Loud Camel, a service that uses AI to promote academics’ research and careers.”

Fair. Loud Camel is a tool that helps researchers get cited and recognized, and yes, I sell it. So hear me out, and judge the argument, not the messenger.

The research already shows that promotion works

Start with the evidence. A large body of research shows that scientists who actively promote their work do better. They get cited more, read more, and noticed more, often for the same findings as quieter colleagues. You can dislike that attention works this way. It still works this way.

Good science means putting your claim on the line

Karl Popper, the philosopher of science, argued that a serious scientific claim sticks its neck out. It makes refutable predictions. In Hebrew we call this ניבוי מסתכן, a risk-taking prediction. Popper was describing theories, not promotion, so this is an analogy and not a quote. But the instinct carries over. A claim worth making is one you are willing to state in public, clearly enough that it can be challenged and, if it is wrong, refuted.

Karl Popper. Photo: Wikimedia Commons.

Nassim Taleb, in Skin in the Game, makes the neighboring point. You should bear the consequences of your claims. If you are not willing to attach your name to a finding and let the world push back, you have not finished the job. Promoting your work honestly is a form of skin in the game. It is you saying, out loud, that you stand behind this.

The real risk is leaving the floor to the loud and the wrong

Now the part I care about most. If you think that promoting your research with AI is not ethical, think about this. You are an ethical person. You value integrity and careful claims. Not everyone does. Some people produce shoddy or dishonest work, and those people will not stay shy. They will use AI to make as much noise as they can.

So if that is true, staying quiet is not neutral. It is a choice with a cost. If the careful researchers hold back on principle, the reckless ones inherit the microphone. It is your responsibility, to your field and to the public, to make sure their voices are not the only ones heard in the air.