BiKodes

Technologist | Programmer 💻

[Ihtesham Ali @ihtesham2005]

A mathematician coined the term "artificial intelligence" in 1955, built the language that dominated AI research for 30 years, and predicted cloud computing 40 years before AWS existed and almost nobody outside the field knows his name.

His name was John McCarthy.

He was born in Boston in 1927, earned his PhD in mathematics from Princeton in 1951, and spent the next 55 years working on a single question that most of his peers considered either impossible or insane.

Can a machine think?

In the summer of 1955, McCarthy sat down and wrote a two-page proposal for a workshop at Dartmouth College. The proposal opened with one sentence that changed everything: "every aspect of learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it."

He needed a name for the field he was proposing. He chose "artificial intelligence." Before that document, no such field existed. After it, every researcher working on thinking machines had a name for what they were doing, a home discipline to publish in, and a founding document to point to. McCarthy did not just contribute to AI. He created the container it lives in.

The Dartmouth Conference ran for eight weeks in the summer of 1956. It was the moment AI became a real scientific discipline.

McCarthy kept building.

In 1958 he invented LISP, the second oldest high-level programming language still in use today, older only than FORTRAN by one year. LISP was designed for a specific purpose: symbolic reasoning. It could manipulate ideas, not just numbers.

It became the language every serious AI researcher wrote in for the next three decades. From 1958 through the late 1980s, if you were working on AI, you were almost certainly working in LISP.

Inside LISP he invented garbage collection in 1959, the technique that automatically frees up memory a program no longer needs. Java uses it. Python uses it. JavaScript uses it. Every modern language that manages memory automatically is using the idea McCarthy worked out while building LISP.

In 1961 he stood at a centennial celebration at MIT and said something that everyone in the room thought was science fiction. He proposed that computing would one day be delivered as a public utility, the same way electricity or water is delivered to a home. You would not own the computer. You would pay for access to it over a network.

AWS launched in 2006. Azure launched in 2010. Google Cloud launched in 2011. What McCarthy described in 1961 is now a trillion-dollar industry. He was 45 years early.

In 1962 he founded the Stanford Artificial Intelligence Laboratory, SAIL, which became one of the most important research centers in the history of the field. The researchers who trained there shaped the next 40 years of AI.

He won the Turing Award in 1971. The National Medal of Science in 1990. The Benjamin Franklin Medal in 2003.

He retired from Stanford in 2000. He died on October 24, 2011, at his home in Stanford, California. He was 84.

The researchers at OpenAI, Google DeepMind, and Anthropic building the models you use today are working in a field McCarthy named in 1955, using memory management he invented in 1959, inside an industry structure he predicted in 1961, toward a goal he spent his entire career insisting was not only possible but inevitable.

He was right about all of it.

He just did not live to see the part where the rest of the world finally believed him.

[Millie Marconi @MillieMarconnni]

A self-taught Irish schoolteacher wrote a book in 1854 that almost nobody read for 80 years, until a 21-year-old MIT student picked it up and realized it could be used to design every computer in human history.

His name was George Boole. The book is called An Investigation of the Laws of Thought.

Boole was born in 1815 in Lincoln, England. His family was poor. He left school at 16 to support them. He taught himself Latin, Greek, French, German, and Italian.

Then he taught himself mathematics. By 19 he had opened his own school. By 24 he was publishing original papers in the Cambridge Mathematical Journal, competing with men who had spent decades inside the best universities in Britain.

He never had a degree. He never had a mentor. In 1849, Queen's College in Cork hired him as a professor anyway.

In 1854, he published his masterwork. What he built inside it was something nobody had attempted before at this scale. He turned logic into algebra.

Before Boole, logic was philosophy. You argued in sentences. You reasoned in paragraphs. It was powerful and completely impossible to automate, because there was no formal system underneath it, just language.

Boole stripped it down to arithmetic. He showed that every act of human reasoning could be reduced to operations on two values. True or false. One or zero. AND, OR, NOT. If both conditions are true, the result is true. If neither is, the result is false. Every judgment a human mind makes, every decision, every deduction, could be written as an equation following those rules.

Logicians read it. They found it interesting. Engineers building machines had never heard of it.

For 83 years, the book sat there.

Then in 1937, a 21-year-old MIT master's student named Claude Shannon was working on a thesis about electrical relay circuits. Switches that could be open or closed. Current that either flowed or didn't.

He read Boole and understood something nobody had connected before.

An open switch is a zero. A closed switch is a one. A circuit with two switches in series only carries current when both are closed. That is AND. A circuit with two switches in parallel carries current when either is closed. That is OR. Shannon proved that every possible logical relationship Boole had described could be physically built using wire and switches.

That single insight is the foundation of every computer ever made.

After Shannon, chip designers stopped thinking about electricity and started thinking about logic. Every transistor on every processor running right now is implementing a Boolean operation. Every if-statement in every codebase is Boolean logic. Every database query using AND or OR. Every neural network threshold that fires or doesn't fire. All of it is running the algebra of a self-taught schoolteacher from Lincoln who died 160 years ago.

The strangest part is what happened to Boole at the end.

He was walking to class in November 1864 when he got caught in a rainstorm. He lectured for hours in wet clothes. He went home sick. His wife, Mary, believed in homeopathic medicine and thought the cure should mirror the cause. She wrapped him in wet sheets and poured cold water over him repeatedly.

He died a few days later. He was 49.

He never saw a transistor. He never saw a circuit. He never saw a single physical machine run a single one of his rules.

His book is in the public domain. Free to download. Most engineers use the word Boolean dozens of times a week. Almost none of them know who they are saying.

The man whose logic runs inside every phone, every server, and every AI model on Earth died soaking wet in a small Irish town, 83 years before anyone figured out what he had actually built.

[Tony Fadell @tfadell]

Nobel Prize winning economist Kenneth Arrow wrote about "learning by doing" decades ago. He knew that productivity and expertise improve through experience.

The messy, repetitive works is often where you learn the patterns that eventually become judgment. Knowledge can be taught, but judgement is built through lived experience.

The first draft you rewrite. The customer call you listen to. The bug you fix and fix again. The factory floor you walk.

Small decisions you make every day teach you judgement. And, judgement is the thing everyone wants from senior people in the workplace. If we automate away every entry-level task without replacing the learning loop, we are removing a part of the process that creates experts.

The goal should be to use AI to accelerate learning, remove friction, and give people better tools to build expertise faster.

https://t.co/MpFZzCk1An

Thanks @Fortune & @tbove4 for sharing this story. Link in the comments.

[Millie Marconi @MillieMarconnni]

A journalist in 1987 rewrote the 2,500-year-old Tao Te Ching as a series of short parables about programmers, and the book became required reading inside Silicon Valley because every line of the joke turned out to be deadly serious.

His name was Geoffrey James.

He was not a famous engineer. He was a technology journalist who had spent years inside the offices of early software companies watching the same disasters play out over and over again.

Managers piling more programmers onto failing projects. Codebases collapsing under their own weight. Corporate hierarchies producing endless documents that nobody read. Geniuses being interrupted by meetings until they quit and went home.

He could have written a serious management book. Plenty of serious management books already existed and almost nobody in software was reading them. He decided to do something stranger.

He picked up a copy of the Tao Te Ching, the foundational text of Taoist philosophy written in China around 500 BC, and he rewrote it line by line as if Lao Tzu had been a master programmer.

The result was published in 1987 as The Tao of Programming. 151 pages. Nine books. Roughly 50 short parables. A comedy book on the surface and a philosophy book underneath, written in deliberately ornate language that made you smile while you were absorbing arguments that have aged better than almost anything else published about software in the last 40 years.

The opening line of the book is the giveaway. Thus spake the master programmer. When you have learned to snatch the error code from the trap frame, it will be time for you to leave. The joke is that he is parodying the kung fu master from the old Kung Fu TV show. The argument underneath the joke is that real mastery in software is not measured by what you can build. It is measured by how cleanly you can recover when the system fails.

The book has been passed around hacker communities continuously since the late 1980s. It sits alongside Fred Brooks's Mythical Man-Month on the required reading list of serious software teams. People who have never heard of Geoffrey James still quote his lines without knowing where they came from. The reason it has refused to die for 40 years is that every line of the parody was always disguising a piece of real wisdom that nobody else was willing to say plainly.

Here are some of the lines, and what each one is actually saying.

"Even a perfect program still has bugs."

The line is funny because it sounds like a contradiction. The truth underneath is that there is no such thing as a finished program. Every system you ship is alive. It is going to encounter inputs you did not anticipate, hardware you did not test on, and edge cases your imagination could not produce.

Treating any piece of software as finished is the single most common reason production systems fail. The masters in the book are calm about bugs because they have stopped pretending bugs are exceptions. Bugs are the default state. The programmer's job is to keep them from compounding.

"Let the programmers be many and the managers few. Then all will be productive."

The line is funny because every software company in the world does the opposite. The truth underneath is that programming is a kind of work that runs almost entirely on uninterrupted thought, and the more layers of management you stack on top of it, the more interruptions you create, the more meetings the programmers have to attend, the fewer actual hours of deep work get done.

Every manager you add to a software team subtracts more productive hours from the engineers than the manager could possibly add through coordination. Brooks proved this formally in 1975. James said it in nine words in 1987.

"After three days without programming, life becomes meaningless."

The line is funny because it sounds like an addict talking. The truth underneath is that genuine craft work produces a kind of meaning that almost nothing else in modern life provides. The programmer who has not touched real code in three days is not just bored.

They are emotionally underfed. The masters in the book understand that the work itself is not a means to a paycheck. The work is the reward. The paycheck is a side effect. Everything that interferes with the actual work, no matter how prestigious or well-paid it looks, is making the programmer's life worse, not better.

"A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master, how long will it take to design this system if I assign five programmers to it? The master replied, it will take one year. The manager said, but we need this system immediately or even sooner. How long will it take if I assign ten programmers to it? The master programmer frowned. In that case it will take two years."

The line is the punchline of Brooks's Law disguised as a koan. Adding programmers to a late project makes it later, because every new person has to be brought up to speed by the existing team, which slows the existing team down, which extends the timeline. The book teaches this in 60 words. The same lesson takes most managers 20 years of failed projects to learn, if they ever learn it at all.

The deeper pattern is the one most readers miss the first time through.

James was not really writing about programming. He was using programming as a setting for a much older argument that Taoist philosophy has been making for 2,500 years.

The argument is that the world is governed by simple principles that get harder to see the more cleverness you stack on top of them. Force does not work. Pressure does not work. More resources do not work. The only thing that works is restraint, simplicity, and the patience to let the right shape emerge.

Lao Tzu was talking about how to govern a kingdom. James was talking about how to ship software. The wisdom is the same. The kingdom is the codebase. The emperor is the project manager. The advisors are the developers. And the entire collapse of every doomed software project in the last 40 years has had the same root cause that the collapse of every doomed dynasty has had for the previous 4,000.

People mistook complexity for competence.

The book has been sitting on the internet for free for almost 30 years. You can read all 151 pages in an afternoon. Most people who run it as a joke walk away quoting it for the rest of their careers.

What James understood in 1987 is even more true in 2026. AI can now generate millions of lines of code in seconds. The bottleneck has shifted entirely. The bottleneck is no longer typing speed. The bottleneck is judgment. The bottleneck is taste. The bottleneck is the ability to look at a generated codebase and feel, without quite knowing why, that something is wrong with it. That kind of feel is exactly what the book was teaching all along.

The Tao of Programming flows far away and returns on the wind of morning.

The masters in the book were never joking. The world just took 40 years to figure out they were not.

[Vivek Galatage @vivekgalatage]

Quite an interesting read, relevant even more now - High Quality Software Engineering by David Drysdale!

https://t.co/muh7KlCNGf

[judah @joodalooped]

i need this for more things man

[Vivek Galatage @vivekgalatage]

Various schedulers, available in the Linux kernel, are documented here.

https://t.co/qQUy91nK7z

[Glitchbyte @0xglitchbyte]

What every programmer should know about memory

Still one of the most goated reads

[Ryan Hart @thisdudelikesAI]

An English engineer wrote a calculus book in 1910 opening with the line "what one fool can do, another can," and proved that almost everything making math feel impossible was put there on purpose by people who wanted it to stay exclusive.

His name was Silvanus P. Thompson.

He was a physicist, an engineer, a Fellow of the Royal Society, and a professor at the City and Guilds Technical College in London.

He had spent his entire career teaching calculus to working-class engineering students who needed the math to actually do their jobs, and he had watched generation after generation of bright kids walk out of math classrooms convinced they were stupid.

He knew they were not stupid. He knew exactly what was wrong, and he was about to say it in print in a way that would get him quietly hated by every academic mathematician in Britain.

In 1910 he published Calculus Made Easy. He published it anonymously at first, listing the author only as F.R.S., which stood for Fellow of the Royal Society. He did not want his name attached to it until he saw how the establishment was going to respond. Because the prologue of the book was not a polite introduction. It was an accusation.

He wrote that calculus was not actually hard. He wrote that the people writing the standard textbooks were what he called "clever fools" who deliberately took the easiest parts of the subject and presented them in the most complicated way possible, because doing so made them look more impressive.

He wrote that they "seldom take the trouble to show you how easy the easy calculations are" and instead "seem to desire to impress you with their tremendous cleverness by going about it in the most difficult way."

Then he opened the first chapter by telling readers something nobody had been willing to admit out loud. The reason calculus felt impossible was not because calculus was impossible. It was because the symbols had been chosen to feel impossible. The notation looked like ancient ritual on purpose. The Greek letters, the formal epsilon-delta definitions, the abstract limit proofs that opened every standard textbook, were not how Newton and Leibniz had originally thought about the subject. They were a 19th century renovation of the field done by professional mathematicians who wanted calculus to feel like a closed shop.

Thompson refused to use any of it.

He went back to the way Leibniz had thought about it 250 years earlier. The letter d in front of a variable, he told his readers, just meant "a little bit of." That was the whole secret. dx meant "a little bit of x." dy meant "a little bit of y." dy/dx meant "a little bit of y divided by a little bit of x," which is just how steep the curve is going at that exact moment. Integration was the opposite. It just meant adding up all the little bits.

That is calculus. That is the entire subject. Everything else is technique, and the technique only works once you understand what you are doing.

A 12-year-old can follow that explanation. A 12-year-old cannot follow the opening chapter of a typical university calculus textbook. The gap between those two facts is the entire reason most adults walk around believing they are bad at math.

The book became one of the bestselling math books in history. Over a million copies. Still in print 115 years later. Still recommended by physicists, engineers, and self-taught learners as the only calculus book they actually finished. Martin Gardner revised it in 1998 and the foundation of the book did not need to change because Thompson had built it on Leibniz, not on the academic conventions that have come and gone since.

The deeper point Thompson was making is the part that should haunt anyone reading this in 2026.

Difficulty is often a marketing strategy. It is not always a property of the subject. When a discipline is taught in a way that feels impossible, the difficulty is doing a job for someone. It is keeping the field small. It is protecting the salaries and the status of the people already inside it. It is filtering out the kinds of people who would otherwise show up and crowd the room.

This happens in math. It happens in law. It happens in medicine. It happens in finance, in machine learning, in philosophy, in software. Every field has a layer of jargon and notation and ritual sitting on top of a core idea that is usually much simpler than the people inside the field want to admit. The jargon is not there to communicate. It is there to gatekeep.

The way you recognize a real teacher is that they keep stripping the ritual off. The way you recognize someone protecting their priesthood is that they keep piling it on.

Thompson finished his prologue with five words that are the entire spirit of his project. "What one fool can do, another can." He meant it as both a joke and a threat.

If a working-class engineering student in 1910 with no Greek and no Latin and no university privileges could learn calculus from a 200-page paperback, then so could anyone the establishment had been excluding for the previous 200 years.

Most subjects you have given up on were never as hard as the people teaching them needed you to believe. You were not stupid. The course was designed to make you feel that way.

What one fool can do, another can.

[trish @TrisH0x2A]

in 1988 Jack Crenshaw wrote Let's Build a Compiler because most compiler books were impossible for beginners to follow

in 2017 Nora Sandler did something similar for C

while working through Abdulaziz Ghuloum's paper on incremental compiler construction she adapted the ideas from Scheme to C

the series starts with a compiler that can do exactly one thing return an integer from main

then adds one feature at a time until it becomes a real compiler generating x86 64 assembly

the entire series is free online

it eventually became a 750 page No Starch Press book in 2024

the original blog posts are still available and still work as a step by step guide

[Aliaksandr Valialkin @valyala]

This is a foundational publication which taught me how to optimize code for speed on modern computers. CPUs are bottlenecked by slow memory access most of the time. Optimize the code for memory access and get >10x performance improvements.

I've read this publication ~19 years ago at https://t.co/oT6plLunJu - https://t.co/TaAW7GRdre

[Mustafa @oprydai]

mathematics is not just symbols.

it is language for compressing structure.

> numbers
> sets
> functions
> spaces
> limits
> transformations

we understand them by building mental bridges between ideas.
how we understand mathematics by jacek woźny

looks at how mathematical meaning forms through conceptual integration.

the important idea:
math is not only calculation.
it is metaphor, abstraction, language, and mental modeling working together.

> a line becomes a function.
> a function becomes a machine.
> a space becomes a set of possibilities.
> a proof becomes a path through logic.

most people struggle with math because they only see notation.
real understanding begins when symbols turn into concepts you can move around in your head.

[Vaishnavi @_vmlops]

Artificial Intelligence & Machine Learning Explained by Stanford

https://t.co/eQzrFH4CcY

[Millie Marconi @MillieMarconnni]

A Stanford mathematician spent 40 years watching brilliant students fail at hard problems.

Not because they were stupid.

Because nobody taught them what to do before they started solving.

His name is George Pólya.

His 1945 book has sold over a million copies and never gone out of print.

Marvin Minsky, the man who built the first neural network machine at MIT, said publicly that everyone should read it.

Most people have never heard of it.

The failure Pólya watched repeat itself for four decades was always the same.

A problem appears. The student feels anxiety. They immediately start calculating.

Not because calculating was the right move. Because it felt better than sitting with not knowing.

The calculation was almost always wrong.

Not from lack of skill. From lack of understanding what was actually being asked.

He called it the most neglected step in all of problem solving.

Step one is to understand the problem. Not skim it. Not assume you've seen something similar. Actually understand it.

His filter was one question: can you restate the problem in your own words without looking at it?

If you can't, you haven't understood it. You've only read it.

Most people skip this and spend hours stuck on a problem they never actually understood.

Step two is to make a plan. Not execute. Plan.

The pattern Pólya saw in every successful problem solver was the same. When something feels impossible, find a simpler version and solve that first.

Not because the simpler version is the goal. Because it gives you a method you can carry back.

He phrased it once with precision: if you cannot solve the proposed problem, try to solve a related one.

That question alone is worth more than most problem-solving courses ever taught.

Step three is to execute. Everyone thinks this is the whole game.

It is the third of four steps. Pólya spent the least time on it because it is the most obvious. Once you understand and have a plan, execution is mostly patience.

Step four is the one almost nobody does.

Look back.

Not to check the arithmetic. To ask: can I verify this with a different method? Can I use this method somewhere else? What would I do differently?

This is where the real learning lives.

Every expert Pólya studied had this habit. Every struggling student skipped from the answer to the next question, carrying nothing forward, starting from zero every single time.

His deepest insight was not a technique. It was a diagnosis.

Intelligent people feel bad at problem solving because they confuse reading a problem with understanding it. They confuse starting to work with having a method. They confuse getting an answer with having learned anything.

These are not the same things.

The students who get genuinely good at hard problems are not the ones who practice more.

They are the ones who slow down at the two moments every instinct tells them to rush.

The beginning and the end.

The problem was almost never as hard as it looked.

They just hadn't understood it yet.

[Kirk Borne @KirkDBorne]

Financial Machine Learning (159-page PDF)

Download here: https://t.co/RwA4BQ9Ty4

Chat with the document and ask it any questions here: https://t.co/jrRaPSwH97

[BookNote @BookNoteApp]

10 books that could replace computer science degree:

1) Artificial Intelligence by Russell & Norvig

[Nitin.nn @NitinthisSide_]

𝟯𝟬 𝗕𝗹𝗼𝗴𝘀 𝘁𝗼 𝗟𝗲𝗮𝗿𝗻 𝟯𝟬 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀:

1. APIs: https://t.co/rotPrzmqsW
2. API Gateways: https://t.co/H8o6JdAvtK
3. JWTs: https://t.co/xDKeDaUwKc
4. Webhooks: https://t.co/DnlnlnQHeA
5. REST vs GraphQL: https://t.co/nxE4WDGLtv
6. Load Balancing: https://t.co/oHhi0BCJg4
7. Proxy vs Reverse Proxy: https://t.co/9yybEKFKpY
8. Scalability: https://t.co/RZAnwKWRfc
9. Availability: https://t.co/6otmmY4qab
10. SPOF: https://t.co/hMwAshtd9W
11. CAP Theorem: https://t.co/1mtupEuHiS
12. SQL vs NoSQL: https://t.co/Yiuz6ohNeG
13. ACID Transactions: https://t.co/oJfATYxxtw
14. Database Indexes: https://t.co/zIUkaDPtxy
15. Database Sharding: https://t.co/f9X4H3nBhf
16. Consistent Hashing: https://t.co/T3kslsUovA
17. CDC: https://t.co/AbAEINF7Ql
18. Caching: https://t.co/wZ9jvagVgg
19. Caching Strategies: https://t.co/4VgCVdCZV4
20. Cache Eviction Policies: https://t.co/2ki1YZPVSv
21. CDN: https://t.co/9BJXTl6osT
22. Rate Limiting Algorithms: https://t.co/IxdITzUgjI
23. Message Queues: https://t.co/qG1LmQdZSS
24. Bloom Filters: https://t.co/HgS8txD8aW
25. Idempotency: https://t.co/jboMnpQjAV
26. Concurrency vs Parallelism: https://t.co/gNDO7kiNUu
27. Long Polling vs WebSockets: https://t.co/yrxQTC4Gip
28. Stateful vs. Stateless Architecture: https://t.co/IoF9d93ECe
29. Batch vs Stream Processing: https://t.co/iLOkjLjKOh
30. Geohashing: https://t.co/T2xROIXPEj

🔁 Repost to help a friend.
📌 Save this post for later.

[Swapna Kumar Panda @swapnakpanda]

You will be a WORLD-CLASS SOFTWARE ENGINEER once you read these 20 books:

[Michael Thrower Chowdhury @BevansAdvocate]

Some of my favourite economic papers that changed the way I think

[Manisha Mishra @manishamishra24]

A man spends 50 years teaching at MIT.

He knows his time is running out.

So he records one last lecture — everything he knows, distilled into a single hour.

He died 5 months later.

This is that lecture.

The most important hour you'll watch this week. 👇
Bookmark it for later