Alan Turing (28 May 1936) - The Mind That Dreamed in Logic

Alan Turing wasn’t just ahead of his time; he was ahead of any time. He formalized the concept of computation itself by introducing the Turing Machine, an abstract model that still underlies every CPU instruction cycle today and the entire idea of computation. During World War II, his work on the Enigma naval code in Hut 8 at Bletchley Park shortened the war by years and saved millions of lives. I’ve been inside the recreation of Hut 8, and it is as inspiring and moving as you can imagine.

While his contributions to computing and, for that matter, mankind cannot be overstated, it is his paper, “On Computable Numbers, with an Application to the Entscheidungsproblem,” presented to the London Mathematical Society in 1936, is quite literally the Genesis for Computer Science. If you are a computer scientist or aspire to be one and have not read it, one, you are out of your mind; read it, two, it is shockingly prescient. Alan was living on another plane of existence.

In it, he describes a Turing machine, a device that does computation on an infinite tape that is divided into cells, each containing a symbol acting as memory. In this device, there is a read/write head that can read the symbol or write new ones. Lastly, there is a set of instructions that specifies what to read or write. If this sounds familiar, this is exactly how the device you are reading this blog entry on works.

But Alan was more than just the father of Computer Science; he was a unique and charismatic individual about whom many have shared anecdotes over the years, helping us, eighty years hence, to identify with the man. He chained his tea mug to a radiator at Bletchley to keep it “safe.” I’m not sure what the risks were from the Germans in Hut 8, but he had his tea secured. He bicycled with a gas mask on to prevent hay fever. But my personal favorite is one of his jokes that has been passed down in time, “Two atoms were walking down the street, and suddenly one says, ‘I think I lost an electron!’ The other replies, ‘Are you sure?’ And the first one says, ‘Yes, I’m positive!’”.

I could write whole blog articles just on Alan and his accomplishments. His amazing efforts to help get NCR in the USA up-to-speed in code breaking in WW2, his co-creation of the Bombe that helped find Enigma settings, Bandurismus, and inventing encrypted telephone conversations . . . While his life ended tragically, his spirit and creations define our modern world, and we should always be thankful.

Tommy Flowers (8 December 1943) - The Engineer Who Embraced the Impossible

Imagine being given the task of building a computer, from scratch, in 1943. Tommy Flowers was not a highly educated man; instead, he was a working-class telephone engineer from the British Post Office (GPO). During the hectic time in Britain during the Second World War, when many people were doing the impossible, Tommy Flowers designed Colossus, the first programmable electronic computer, to help win the war.

He started at Bletchley Park in February of 1941 when his supervisor introduced him to Alan Turing, who was looking for help on Enigma. Alan was impressed by Tommy’s engineering abilities and introduced him to Max Newman, who was working on “Tunny”, the British code name for the Lorenz SZ 40/42 cipher machine.

The result, Colossus, became operational on 8 December 1943, the world’s first programmable electronic computer. It wasn’t built to compute numbers but to listen to the German Lorenz SZ-40/42cipher, used for encrypted teletype messages between Hitler’s high command (OKW) and their field generals. The Lorenz cipher used twelve spinning wheels that generated a pseudo-random key stream, with billions of possible wheel settings. In 1943, the mathematics looked hopeless, unless you had a computer.

Colossus generated the wheel patterns electronically, using more than 1,600 thermionic valves (think highly complicated lightbulbs) to emulate the cipher’s logic. Using paper “ciphertext tape” racing past optical sensors at over 5,000 characters per second, Colossus, with plugboards and switches implementing Boolean comparisons, was the first large-scale digital logic system ever built. And if it sounds like Alan Turing’s hypothetical Turing Machine, it is no coincidence. When the machine detected statistical correlations between the intercepted text and hypothesized wheel settings, it printed counts on a teletype, giving cryptanalyst Bill Tutte’s team the clues needed to recover the Lorenz keys and thus decipher the message.

It was an astonishing technical feat, a working programmable computer using 1943 technology. Most experts at the time believed such a valve-laden device would never stay operational, as valves were fragile and prone to failure and heat. Flowers countered that if you never turned them off, they would remain stable, and he was right. His machine ran for days without fault.

Tommy even paid for Colossus’s components himself when funding was denied.

Colossus cut the time to break a Lorenz message from weeks to mere hours. And those messages were invaluable in helping the Allied leadership know that no more German reinforcements were coming to Normandy in early June 1944, just before D-Day.

Sadly, after the war, he was sworn to secrecy; he couldn’t even put his creation on his résumé. It took 30 years before his contribution was acknowledged. When he sought a bank loan to build a commercial computer after the war, he was turned down because no one believed such a machine would work. It took three decades for his contribution to be declassified and honored. And yet, today, Colossus is universally acknowledged as the direct ancestor of every computer we use.

You can go and visit a reproduction of Colossus at Bletchley Park; it is beyond incredible. And yes, not only is it fully functional, but it is still running and has even participated in a cipher challenge.

John von Neumann (30 June 1945) — Computers that Remember

How long did John von Neumann think it would take to build the computer he envisioned, “A year, maybe two… if we stop talking and start wiring.”?

John was a Hungarian-born mathematician with a mind that spanned from quantum mechanics to economics. Von Neumann joined the Manhattan Project in the early 1940s. There, surrounded by physicists and engineers, he saw something no one else did: that the same logical principles used to compute a nuclear trajectory could be applied to any computation, provided the machine could store and modify its own instructions.

But how to do it? How to create a thinking machine that could remember? On 30 June 1945, just 17 days before the Trinity Test, John circulated his now-legendary “First Draft of a Report on the EDVAC”, a deceptively modest memo that quietly changed the world.

In it, he described an architecture in which data and program instructions would share the same memory, processed by a single control unit and arithmetic logic unit. And he divided the system into the four components we still teach today: memory, control, processing, and input/output.

The simple idea that a program could treat its own code as data, not patch cables plugged into countless photo jacks like Colossus, became the von Neumann architecture, the foundation of nearly every digital computer since.

As a trained mathematician myself, I always found his discussion with Fermi, the physicist who created the first sustained nuclear fission reaction, Chicago Pile 1, in Los Alamos during the Manhattan Project, interesting. John came by, saw what Fermi had on his blackboard in his office, and asked what he was doing. So, Enrico told him, and John von Neumann said, “That’s very interesting.” John then came back about 15 minutes later and gave Enrico the answer to the problem on the board. Fermi leaned against his doorpost and said, “You know that man makes me feel I know no mathematics at all.”

J. Presper Eckert & John Mauchly (14 February 1946) – The Builders Who Made Numbers Dance

If Alan Turing imagined what and how computers could think, and von Neumann showed how they could remember, J. Presper Eckert and John Mauchly built the first one that could act at scale and compute general-purpose problems.

In Wartime Philadelphia at the University of Pennsylvania’s Moore School of Electrical Engineering, the physicist John Mauchly and the engineer J. Eckert led a team to design a machine that could out-calculate any human or mechanical device before it. Their creation, the Electronic Numerical Integrator and Computer (ENIAC), was officially unveiled to the public on 14 February 1946, shocking onlookers with banks of glowing vacuum tubes and whirring panels of switches.

ENIAC contained 17,468 vacuum tubes, weighed 30 tons, and could perform about 5,000 additions per second, hundreds of times faster than anything else on Earth. To put that in comparison, the amazing Colossus had only 2,400 vacuum tubes. Originally commissioned by the U.S. Army to compute artillery firing tables, it quickly proved capable of far more: ballistic trajectories, weather prediction, atomic calculations, and the dawn of digital simulation itself.

Programming ENIAC, however, was an art form: a vast tangle of patch cables and switch panels that had to be rewired for each new task. It was engineering on an epic, cinematic scale and took days to do. And yet, it worked.

At its first demonstration in 1946, ENIAC was fed the problem of calculating the trajectory of a shell that would have taken human “computers” forty hours. It produced the answer in 20 seconds. Reporters gasped; the Army declared the machine a secret weapon of mathematics. And so it was.

Eckert, the meticulous electrical engineer, made ENIAC reliable. He realized that vacuum tubes didn’t fail constantly when left powered on. The same realization across the Atlantic that Tommy Flowers had discovered, but secrecy prohibited anyone from knowing. Mauchly, the visionary physicist, imagined how electronic speed could transform science. Together they balanced precision with imagination, forming one of computing’s great creative duos.

After the war, they founded the Eckert-Mauchly Computer Corporation, where they built the UNIVAC I, the first commercial computer sold in the United States (1951).

Eckert and Mauchly’s genius was to turn electronic calculation from an experiment into an industry; my industry. And I am damn thankful they did.

Grace Murray Hopper (9 September 1947) – The Mother of Modern Programming

Should you visit the Smithsonian Museum of American History, and it is on display, you might see something quite curious: an engineering logbook from 1947 with, of all things, a moth taped to the page. Under the taped-in moth is a note written by Grace Hopper: “First actual case of bug being found.”

This happened while debugging, and yes, this is where the term comes from, a literal bug, on the Harvard Mark II computer, where the poor moth in question was found trapped in one of the computer’s relays.

Born in New York City in 1906, she was a brilliant mathematician who earned her Ph.D. from Yale in 1934. When World War II broke out, Hopper joined the U.S. Navy Reserve and was assigned to the Bureau of Ordnance Computation Project at Harvard, where she worked on the Mark I, one of the earliest electromechanical computers. Incidentally, one of the first programs to run on the Mark I was initiated on 29 March 1944 by my previous hero, John von Neumann, to determine if an implosion was a viable means to detonate the plutonium-based atomic bomb.

Grace was endlessly curious about how machines could be made to understand humans. To her, programming should be closer to English than to wiring diagrams or raw binary. In 1952, she designed the A-0 Compiler, the first program to translate human-readable instructions into machine code automatically. It was the missing bridge between human intent and silicon precision, language that humans and computers could understand, the ancestor of every modern compiler. A few years later, her work shaped the creation of COBOL (Common Business Oriented Language), which brought computing into business, government, and finance.

She ended her career in the US Navy as a Rear Admiral and was known for carrying an 11.8-inch wire in her pocket to demonstrate to doubters that even abstractions have a physical meaning. “That’s a nanosecond. That’s how far light travels in a billionth of a second.”

Grace Hopper didn’t just write programs; she taught computers to have a common language with humans. And after that, things really took off.

Claude Shannon (July 1948) – Communications can be Math

Claude Shannon was a free spirit, famous for riding his unicycle through Bell Labs’ corridors while juggling or demonstrating a mechanical mouse that learned to navigate a maze. He built a mind-reading machine for fun and wired up a flaming trumpet that played itself. Like many of my heroes, he knew intuitively that fun was a big part of innovation.

Born in 1916 in Gaylord, Michigan, Shannon grew up tinkering with radios, telegraph lines, and homemade gadgets. After studying electrical engineering and mathematics at the University of Michigan, he went to MIT, where his 1937 master’s thesis became one of the most influential documents in the history of engineering. Titled, A Symbolic Analysis of Relay and Switching Circuits, the thesis proved that Boolean algebra, the logic of true and false, could describe any electronic circuit. Certainly a far more impactful master’s thesis than mine! With that single insight, he turned logic into hardware, making digital computing possible.

But where Claude shocked the world was in a two-part paper published in July and October 1948 titled “A Mathematical Theory of Communication.” It was the birth of information theory. Shannon proposed that messages, no matter their form, letters, sounds, images, or even video, could be represented as sequences of bits, and that information could be measured in units he called “the bit” (which I do believe has managed to pass the test of time).

I have read A Mathematical Theory of Communication several times. It is a revolutionary idea: communication was no longer about words and meanings but about probability and entropy. Claude derived the limits of how much information could be transmitted reliably through any noisy channel and proved that with the right coding, you could get arbitrarily close to perfect accuracy. Every modern technology that compresses, encrypts, or transmits data, ZIP files, Wi-Fi, fiber optics, and streaming video rests on those equations.

Claude Shannon didn’t just explain how to send a message; he revealed what information really is.

John Backus (20 September 1954) — Turning Math into Code

My first programming language was FORTRAN IV, which I learned from my mother, who was a computer scientist, teacher, cook, and mom, all tough jobs she managed to do simultaneously. She would take me to the local community college in Avon Park, Florida, where there was a brand-new IBM Series 1 computer, and we would program together for fun in the evenings. The joy I feel coding and in creating things in computer science all started from these twilight trips to work on the IBM Series 1 and code in FORTRAN IV. And all of that is because of John Backus.

A mathematician turned reluctant programmer, somewhat like me but way smarter, Backus joined IBM in the late 1940s after earning his master’s degree in mathematics from Columbia University. He never meant to become a computer scientist; he was opposed to it. He had built a hi-fi amplifier and impressed an IBM recruiter with his knack for circuitry. Yet within a decade, he would lead the team that created FORTRAN (short for Formula Translation), the first high-level programming language, released in 1957 but running internally in IBM starting on 20 September 1954.

Before FORTRAN, programming a computer meant writing in raw machine code, long sequences of 1s and 0s, or in cryptic assembly instructions; fun for a hardcore programmer but incomprehensible to 99.999% of the human population. Debugging even simple arithmetic operations could take days. Backus hated it. “I didn’t like writing programs,” he later admitted, “and so I started work on a program to help me avoid having to write them.” His distaste for tedium became the spark for one of the greatest breakthroughs in computer history, FORTRAN.

Under Backus’s direction, IBM’s small team of mathematicians and engineers set out to create a system that could translate human-readable mathematical expressions, such as A = B + C * D, into efficient machine code automatically. It was a radical idea: letting the machine write its own machine language. Many skeptics in the scientific community, let alone inside IBM, dismissed it outright. They didn’t believe a compiler could generate code as fast as hand-written assembly. When FORTRAN proved them wrong, running nearly as efficiently as expert-crafted code, it revolutionized programming.

It is a testament to my former employer that they allowed a wild duck like John to pursue such an effort, funded it, protected it, and invested more when they saw the results.

FORTRAN didn’t just make coding easier; it made computing scalable. For the first time, scientists and engineers could express problems symbolically rather than mechanically. It became the language of physics simulations, engineering calculations, and the emerging world of computer-aided design. Even today, nearly seven decades later, FORTRAN quietly powers weather models, nuclear research, and financial systems.

In 1959, when journalists asked Backus what he thought he had really invented, he replied, “Freedom.” But as for me, John gave me my career and some very precious moments with my Mom.

Ivan Sutherland (7 January 1963) – The Man Who Taught Computers to Draw

Imagine being back in the beginning of 1963, John Kennedy is President of the United States, and the Beatles’ second single, Please Please Me, was about to be released in the UK. But no one had ever seen anything like what they were about to see, an interactive computer graphics program that let you draw shapes, doodles, whatever you liked, on a screen. And it all came together in a doctoral thesis on the 7th of January, 1963.

Born in 1938 in Nebraska, Ivan Sutherland grew up with a mechanical curiosity. After earning his bachelor’s degree from Carnegie Tech and a master’s from Caltech, he pursued his Ph.D. at MIT under Claude Shannon, another hero on this list. It was at MIT that Sutherland produced one of the most influential dissertations in computer history, and he called it Sketchpad.

Lest you think that this was a simple drawing program, Sketchpad was a revelation. For the first time, a computer responded to human gestures, your digits could provide digital input, and you could see it all in real-time. Running on MIT’s TX-2 computer, a computer with all of 64 kilobytes of memory, SketchPad allowed users to draw directly on a screen using a light pen. You could even define constraints, such as “this line must remain vertical”, that the program would enforce automatically.

During his doctoral defense, one examiner reportedly asked Sutherland what Sketchpad was really for, and he replied, “It’s for making drawings of anything.” That “anything” concept became everything: CAD systems, graphical user interfaces, games, computer animation, and virtual reality, all of them can trace their lineage to Sketchpad.

Sutherland didn’t stop there. He co-founded Evans & Sutherland, which pioneered real-time 3D graphics, flight simulators, and later developed the first head-mounted display, the ancestor of today’s VR headsets.

Ivan Sutherland didn’t merely invent computer graphics; he invented the idea that computers could be visual partners in human imagination. I doubt even Ivan could have imagined where that would go.

Donald Knuth (1 February 1968) — The Philosopher

Alan’s immortal work, “On Computable Numbers, with an Application to the Entscheidungsproblem” is the genesis of Computer Science. But The Art of Computer Programming (TAOCP) by Donald (Don) Knuth made Computer Science into that most unique of sciences, one that it has had since the publication of TAOCP: science with a splash of art.

Of all my heroes, Don is the first on this list that I have met. And he is all that mixture of science and philosophy that you can imagine. I told him I wrote a linear sorting algorithm based on his work and showed it to him, and he commented not on the result but on the elegance of my implementation. That is Don.

Born in Milwaukee in 1938, Knuth combines a mathematician’s logic, a writer’s obsession for precision, and a philosopher’s instincts of looking at greater meaning. By the late 1950s, computers were fast enough to do remarkable things, but the programs running on them were often crude, inefficient, and undocumented. Knuth saw programming not just as engineering but as a form of art, a craft of clarity and structure.

While teaching at Stanford, Knuth began writing lecture notes to explain the principles of efficient computation. Those notes grew into what became his life’s magnum opus: The Art of Computer Programming (TAOCP), the first volume published in 1968. His goal was audacious and unprecedented: to catalog the entire field of algorithms, analyze them mathematically, and make that analysis readable and understandable - and most importantly, learnable.

In TAOCP, Don created MIX, a virtual and hypothetical computer, along with its own respective assembly language, MIXAL. This allowed him to be completely agnostic to device or manufacturer, letting the reader of his work focus on the code itself and how algorithms work at the machine level.

While finishing the first volume of TAOCP, Don’s typesetter mangled the manuscript’s mathematical equations. And of course, Don didn’t complain; he built a new system to fix it. That project became TeX, a typesetting language so precise that it remains the standard for mathematical and scientific publishing worldwide. And to this day, he offers anyone who finds a typo in his books a reward check for $2.56, that’s one hexadecimal dollar. Thousands have received them; most never cash them. I certainly didn’t cash mine.

John Kemeny & Thomas Kurtz (1 May 1964) – Anyone Can Code

I got my first computer in 1981, a brand new Commodore VIC-20 running at a blazing 1.02 MHz with five kilobytes of RAM. I got it on Christmas Day 1981, connected it up, and was confronted with something I had never seen before, even though I had been programming with my Mom in FORTRAN for years, a prompt that said “CBM BASIC V2” and “READY”. READY? Ready for what? I was used to classic business mini-computers of the era, not something that was just saying READY to me. And then I realized that BASIC was a programming language of some kind, and the new VIC-20 was READY for me to type a program.

In the early 1960s, computers were rare, expensive, and intimidating. Programming was reserved for specialists who spoke the language of punch cards and assembly code. But at Dartmouth College in Hanover, New Hampshire, two professors believed that computing should be as universal as mathematics, that students in every discipline should be able to harness the power of a computer without needing to be engineers. They were the pioneers of what would eventually be called the citizen developer movement.

Kemeny, a mathematician who had served as Albert Einstein’s research assistant at Princeton, and Kurtz, a physicist and systems thinker, set out to democratize computing. Their goal was to build a time-sharing system that allowed multiple users to work simultaneously, and design a simple programming language to leverage that multiple-user system, which anyone could learn in an afternoon.

On the morning of 1 May 1964, at 4:00 a.m. (and as a computer scientist, I can appreciate that they were working all night, some things never change), they succeeded. In a small lab at Dartmouth, a student typed a few lines of code into a teletype terminal and entered a single command: RUN. For the first time, two programs executed simultaneously on the same mainframe using code that anyone could understand. That language the two of them created is called BASIC, or Beginner’s All-purpose Symbolic Instruction Code, and it democratized programming.

That first BASIC program, running on a GE 255 computer, printed a simple arithmetic result. John watched as the teletype clattered out the correct answer, then turned to his team and said, “It worked.” That understated moment marked a revolution. Within a decade, BASIC would spread from college labs to the first generation of microcomputers, inspiring young programmers like Bill Gates, Microsoft’s first program was BASIC for the Altair 8800 computer, Steve Wozniak, and little me, on my Commodore VIC-20.

BASIC’s power was in its simplicity. Commands like PRINT, INPUT, and IF/THEN mirrored natural language, and the syntax was forgiving enough for beginners to explore and understand. Combined with Dartmouth’s pioneering Dartmouth Time-Sharing System (DTSS), students from any college major could now write and run programs instantly, artists, sociologists, and poets right alongside engineers and physicists.

Kemeny and Kurtz were building a future where computers were partners in learning and innovation. Kemeny later became president of Dartmouth and continued to advocate for computer literacy as a civic right. Thomas led efforts in computing education, ethics, and open access, ensuring that the pair’s vision endured beyond the mainframe era, and so it did.

When we talk about the personal computer revolution, we often begin with garages in Silicon Valley, or the windswept desert of New Mexico, perhaps even in the rolling hills of Valley Forge, Pennsylvania, but it really began in a quiet New Hampshire lab at four in the morning. This will not be the last time in this series that New Hampshire comes up.

Douglas Engelbart (9 December 1968) – The Man Who Showed Us the Future

It was literally the “Mother of all Demos”, 9 December 1968, at the Fall Joint Computer Conference in San Francisco. In front of a stunned audience of over 1,000 engineers, Douglas Engelbart sat at a custom-built console connected by a 30-mile link to Stanford Research Institute (SRI)’s mainframe.

On a large projection screen, he moved a small device he called a mouse, which was nothing more than a wooden block with two perpendicular wheels, to control a cursor. He opened and rearranged text in multiple windows, clicked hyperlinks, edited documents collaboratively with a colleague on another terminal, and even conducted an early form of video call. In 1968! He left the audience stunned to the point of utter silence in the room when he was done. I cannot think of any other computer science demo in history that has its own Wikipedia Page and inspired a musical.

Born in 1925 in Portland, Oregon, Engelbart served as a radar technician in World War II, serving in the Philippines, before earning an engineering degree from Oregon State and a Ph.D. from Berkeley. Like most of my heroes, he was inspired by a simple idea, and Doug’s was that computers should not just compute, they should help people think better together.

Doug envisioned something radical: an interactive workspace where people could collaborate in real time, share information, and navigate knowledge as fluidly as thinking. Working at SRI in Menlo Park through the 1960s, he and his team at the Augmentation Research Center quietly built prototypes of nearly every modern computing concept, the mouse, hypertext, windows, video conferencing, real-time editing, and networked collaboration.

Doug’s ideas didn’t immediately take off. For years, many dismissed them as impractical or utopian. Yet the young researchers who saw that demo, many of whom later joined Xerox PARC, Apple, and Microsoft, and will be in future articles in my list of heroes, took his concepts into the age of personal computing. It turns out, “The Mother of all Demos” was actually the future.

Douglas Engelbart didn’t just predict the future of computing or write about some processing utopia; he demoed it, live. A lesson I learned well in my career, seeing is believing.

If you think this is hyperbole, it isn’t. Last week, I created, in a day, a fully implemented server-side reverse proxy that applies user scripts to websites on the fly; in 11 hours—eleven hours of just me, my MacBook, and ChatGPT, Claude, Kilo, and Codex. This would have taken me in the past, and I know this as I have written a similar piece of software before, more than a month.

I used to think that I loved to code, and perhaps that is still true, but what this has shown me is that my true love is to create.

But like everything else in Computer Science, when a new innovation comes, there are many downstream consequences. Many of which I have not seen mentioned in any of the usual suspects blogs, videos, or articles.

Programming Languages

Programming languages for the back-end are dead, put a fork in them. I’m serious, “They’re dead, Jim.” Why? Think about it: languages like FORTRAN were created in the 1950s. OK, yes, Plankalkül was technically created in the 1940s, but does anyone really remember it? And why were they created? To make machine code readable to software engineers, as tools to make programming easier. And these languages, tools, that we have created from FORTRAN to Rust to Java and everything in between, slow down the processing device they run on as they become more and more abstracted above the actual hardware that is doing that work. You are not going to get anywhere near the performance in some higher-level language than if you just have the code all in assembly, doing individual processor instructions like MOV R0, R2.

Keep in mind assembly isn’t compiled, it’s assembled into pure machine code.

So, do we really need programming languages? I just spent an hour vibing and having all the output in ARM assembly. You want to talk about fast code, it’s mind-blowing. I can hear the language lovers saying, “But Jason, you can’t really read assembly, it’s so complicated and difficult.” First, I can read assembly, but why do I need to read it? I can just ask, pick your vibe engine with inference, what does this code mean? Some might argue that a professional developer then needs to make tweaks that the vibe coding tool missed, and my answer is, “Learn a little assembly or have the tool teach you, it isn’t hard.”

But, but, but libraries, modules, includes, package managers... seriously, why do you need them? Your vibing tool can assemble everything you need, all together. All of these mechanisms, dragging in libraries, OOP, you don’t need any of it anymore. Use the vibe tool and then your professional developer skills to make amazing, incredibly performant, far lower memory use services.

What about web programming? Vibe programming is going to take us back to HTML, CSS, and JavaScript, the end. No libraries, frameworks, none of it. React.js, done. And all for the same reasons, the server-side code is going back to its roots with vibing, these languages and frameworks were all created, from Dojo (I get a little sick every time I even think of Dojo) to jQuery to Angular to React, for the explicit purpose of making web software engineering faster and easier; as tools for the developer. With vibe coding, why in the world would you need them? And don’t forget all those tools make the browser slower, bloated, and continually lead to my blessed tabs in Chrome using more memory than the first computer I had that could open a webpage.

Server Operating Systems

Operating Systems for servers; they are going to be like Old Marley, dead as a doornail. I can hear it now, but we need operating systems for drivers to talk to keyboards, and video cards, accessing memory and I/O, scheduling, multitasking, file system access... and I would counter with, why? Operating Systems create tremendous overhead for servers. If I can build a piece of software that is designed to run a specific workload, mostly using vibe tooling, then why do I need a general-purpose operating system to do all of these things, of which I might need, for a specific workload, maybe 10%?

Let me give you an example. Remember that reverse proxy server I wrote using Vibe coding? I have it running, right now, on a single-board ARM64 computer. It is not running any operating system at all, just a bootloader and my proxy code, both of which were 80-90% created with Vibe coding. I don’t need to connect to the keyboard, mouse, I/O, GPU, or, for that matter, much of anything. I just need for the reverse proxy application, access to the network card, done with Vibing, memory management, Vibing, file system, Vibing, and that’s it. I wrote my own threading and scheduling, AArch64, with Vibing, that is tailor-made to proxy REST payloads.

And I did this in hours, and it screams. It is using all of the hardware available, custom fit specifically for the purpose. Low cost, low power consumption, and I have not been able to with my various workstations scattered about, running workload simulations, to break it. It just keeps performing.

Think about what this means. Viruses on the server, they are over, this application is running directly on the hardware; you literally can’t install anything else. It only knows how to run my proxy program. Patching and managing operating systems, a herculean task that automation and DevOps professionals have to engage in, ummm, patch what? Crash, the program will just restart; it’s running in a loop. There is no operating system, only Zuul. OK, I know, but I had to have a Ghostbusters reference in this article.

Software and Software Companies

This is going to sound like heresy, since I am the CTO of a division of a software company. But software companies, as they are currently constituted, are going the way of the dodo. Not because anyone now can make super complicated applications like ERPs just by Vibing, you are going to need lots of highly skilled software engineers to work with the Vibing toolchain, but because the speed at which software can be created with Vibing is so fast that end-users and companies will not need or want general-purpose software.

As a company, why do I need an SAP, as an example, which, while a great ERP system, and more, does probably 80% more than what I need; and isn’t exactly inexpensive? With Vibing, I can get a perfectly custom ERP system that does literally exactly what I want and need, at a fraction of the cost, running bare metal on less expensive to buy and operate hardware. Why in the world would I buy a general-purpose ERP system, or a CRM, or SCM, HRMS, and more when I can have all of those perfectly tailored to my needs for less money?

With Vibing, the future of software companies is going to be, in the words of one of my bosses (look, if you are going to be the CTO of a large software division, you are going to end up like Paul Wilson in Office Space, with lots of bosses), Services as Software. Companies are going to contract with these new-age software companies for specific solutions to their exact needs. And these new-age software companies are going to use highly skilled software engineers with Vibing to create, support, and evolve these curated, individual applications for the customer. No company in its right mind five years from now, is going to be buying general-purpose enterprise software. And software companies today that don’t rapidly evolve in this direction, providing services as software, are going to be dinosaurs.

This all may sound scary, or crazy . . . perhaps even both. But to me, it is exciting. Heck, it is thrilling. Change is a universal constant in Computer Science. And every time there has been a change in my tenure on this globe, there has been opportunity. This is the time to grab on with both hands and get Vibing.

Why do they do this? There are many reasons why they may actively try to deceive you. They may think the requirement, project, product, or service effort is stupid, wrongheaded, and misguided, and that they know better than the company. They may receive a directive on how to accomplish something, but they don’t like the specificity of the “how,” whether it involves a specific tool, an open-source project, or a component. The engineer(s) might just want to work on something else, and this is getting in the way of them working on that far more desirable, in their minds, product or project. However, my personal favorite is that they become so entrenched in their ways that, regardless of what you, product management, or even their peers on other products might think, they believe they know best how and what to accomplish.

Let me give you some examples of what I’ll call Deceptive Engineering.

I’ll start with a classic, “I have concerns.” My blood almost, but not quite, boils when an engineer or engineering director tells me they have concerns. If any of my engineers wants me to instantly get angry and reach for the Clonidine, it is telling me they have concerns. Why? Because I know after 31 years in this industry that they don’t have concerns, they just don’t want to do it. I don’t even care why they don’t want to do it; they really don’t want to. Usually, after telling you they have concerns, they will rattle off a list of things they have concerns about. You might think they are being deep thinkers or that they have truly considered the problem, but no, they are just listing things off that they hope might undermine what is being presented as work to them, or it will be slowed down while these concerns are investigated.

Fun fact, IBM once had an entire system for “Concerns” called the Nonconcur system. Basically, anyone could raise a concern, and the entire effort had to be paused while that concern was evaluated and mitigated. It was paralyzing to the company.

So, how do you handle “Concern” based Deceptive Engineering? It is actually pretty easy once you recognize the characteristics. You simply tell the engineer or engineering leader, “You have concerns, that’s great, congratulations, you now own creating a solution for all of them, I look forward to weekly updates on your progress.” Do that two or three times with your organization, and you will never hear the word “concerns” again.

Security Reviews, this is a somewhat newer one, but it has gained enormously in popularity. I once, without me knowing it was happening, had a team with a successful shipping product that was going to be integrated with a new product, attempt to out-and-out sabotage the proposed integration by using the tool of Security Reviews. How? The existing successful product engineering team went out and spent two weeks devising a brand new Security Review process that, no lie, required the other, new product team to write a 40-page document. Then they conducted a day-long review of the document. And since the new product team was in a distant time zone, the shipping product team scheduled the day-long review at a time that was the middle of the night for the new product engineering team. I mean, I give them an “A” for creativity in shutting down work.

The Deceptive Engineering via Security Reviews is highly effective because security has become a boogeyman in software engineering. It is so very easy for software engineers to say they discovered a security issue or flaw, and so hard for senior leaders to validate them. And let’s be completely honest, no piece of software is ever perfectly free of security flaws. When you have forty blessed pages to pick and choose from (in the example), you are going to find something. In my above example, the security review, though it really found nothing wrong that mattered, was reported up to my boss, along with those forty pages of meaningless material that he couldn’t understand anyway, and the effort was delayed by TWO YEARS over my strenuous objection. When we finally returned to the integration project, it turned out that there was nothing wrong with it to begin with. Shocker!

Lesson learned: Do not let your product engineering teams conduct security reviews. Have a separate team or security leader who has no axe to grind and whom you trust, handle security reviews. Whenever a security problem is identified by one of your engineers, it must be referred to the security team for evaluation. Nothing can stop until that evaluation is complete; coding must continue. I have even implemented a checksum such that if an engineer raises more than five security issues in a year, all of which are determined to be unfounded and frivolous, it will be grounds for being placed on a Performance Improvement Plan (PIP).

As an aside, I recently saw an engineer in a chat raise both concerns and state in the same paragraph that a specific programming language was “known to be insecure.” That's trying really hard to stop or delay something. It’s impressive.

Sizing, are you kidding me? Really, it will take that long to do this proposed component, project, or effort. Engineers have been using Deceptive Engineering via sizing since the ENIAC. They know how long it will really take, but they report something much longer to discourage whatever it is. And it works. How would a project manager or business owner know how long it will take to code something? They aren’t engineers. They are trusting the engineer or the engineering team leader as the expert.

Engineers have even created a whole system within the Agile development methodology (capital A) where they don’t provide time estimates. They have, wait for it, story-points. What is a story-point? That’s the genius of it; it is whatever they want it to be. Story-points even inflate in an engineering organization over time. It is like the engineers have this built-in way to conflate and confuse the business. And all they say over and over again is, “We are just following the Agile Process.”

As the CTO or senior technical executive, how do you stop this “sizing” fraud? I use three methods. The first is to have sizing reviews. All major sizings in my organization are reviewed by another engineer or architect who is from another team and/or product. I don’t expect the reviewing engineer to actually do a new sizing, they just report back if the sizing is reasonable or not. Second, we never expose story-points to the business. If the engineering team is using virtual currency like story-points for measuring work, that’s fine. But we report to the business, dates and effort in person months. Lastly, and I know this is a hard thing to do for a senior executive, I stay current in technology and I can still code. If I see a sizing and it seems off to me, I try to do it myself. Not all of it, just a small segment to get a feel for how hard it really is. Woe be unto the engineer, and colluding review engineer, that tries to slip something past me.

Gobbledygook. In Inside Star Trek: The Real Story, authors Herb Solow and Robert Justman tell a story of how they once when horribly late in delivering the next episode of Star Trek to the network, NBC, used Gobbledygook to provide an excuse. They told an NBC executive who was smart but not well-versed in the making of the films, that they were late because the sprocket holes and the associated machine were broken. The episode was done, and they were just waiting for the machine to be repaired. Now, if you know anything about the making of television and film, Solow and Justman just changed motion-picture technology in the lie they told to the executive. They used their knowledge of technology and some creativity to their advantage.

Software engineers do the same thing. They use their expertise to deceive product managers, engineering leaders, and the business. And boy, are they creative and good at it. They will tell some whoppers like, “Oh, we can’t use open source here because the project you want us to use is written in a programming language that can’t run on our servers.” Or “My repository server is down, can’t get this to you until IT fixes it.”

The easiest way to combat Gobbledygook is knowledge. To be a successful senior technical executive, you have to know your products and their code, know the technical trends, and understand how your pipelines and infrastructure can impact your current efforts. It is hard, for sure. But no one has ever said this industry is for the weak.

Training, seriously, are you kidding me? I was once given a new engineering team from a recent acquisition that needed to create a client-side integration with our existing products. The five senior engineers and architects from this new team met with me in a conference room where they told me, to my face, that they needed the company to give them three months of training because they, some really good and talented Java programmers, did not know and understand JavaScript. Okay, I’ll admit it; I couldn't help but start laughing. For those of you who are not very technical, this is hugely amusing because JavaScript was derived from Java by Brendan Eich over a weekend as a hack.

Engineers will tell you they can’t do something because they don’t know how, that they are experts in another programming language and don’t know X, Y, or Z. It’s just not true. Sure, taking a Java programmer and telling them something has to be implemented in, for example, the Rust programming language, is going to take longer while they get up to speed. But if an engineer tells you they can’t do something in another programming language or with another technology and they require some kind of formal training to do so, you should seriously consider whether they are really an engineer.

This one is the easiest to manage, though it does require you, as a senior leader, to be a bit harsh. Mock them. Publicly. It works, and though it is a bit crass to do it, an engineer who can’t learn and grow probably should not be working for you.

There are more, so many more ways in which Deceptive Engineering manifests. I had an engineer once argue with a lawyer over his legal interpretation of a license so that the engineer could get out of using a specific open-source repository for the basis of a project. All because he wanted to write it himself. Hey, they are certainly creative.

Deceptive Engineering, at its core, is a culture problem. And it will always be in your engineering organization, lurking beneath the surface. However, if you can establish a culture that despises its tendencies and calls them out, even before they manifest, you can keep them at bay and avoid the stories above.

Authoritarian edicts are non-negotiable and absolute. They barrel through the organization like a freight train, flattening context, data, and dissent in their path. Even as a senior leader, you can’t tweak, debate, or, most importantly, align them with the real-world nuances of your part of the business.

Personal Story of Authoritarian Edicts Run Amok

Years ago, I was running the IT services arm of a multinational across the Asia–Pacific region. We were a healthy business, high utilization, 32 percent margin, happy customers, the very definition of “don’t mess with success.”

Then HQ issued an authoritarian order: “Every” division would cut headcount by 20 percent. Full stop. No Exceptions, no negotiations.

I argued that in a services business, our “product” is our people; trimming billable consultants would kneecap revenue. Finance shrugged. HR sympathized but refused to budge. The directive was the directive.

The fallout was exactly what you’d expect, except worse. Two clients sued us for non-delivery because we no longer had enough engineers to fulfill the contracts. We paid eight figures in settlements and lost both accounts to competitors. Any theoretical savings from payroll vanished before the ink dried on the legal paperwork.

Lesson learned: When you apply a blanket mandate to a heterogeneous organization, you risk creating damage that undermines the stated goal and can also be permanent.

Why Smart Leaders Still Reach for Authoritarian Edicts

It’s tempting to assume these heavy-handed moves stem from malice or incompetence. The explanation is much simpler: “They’re easy.”

Need to hit an EBITDA target this quarter? Freeze travel, no exceptions.

Want to impress the board with headcount discipline? Announce a hiring freeze, effective immediately (and I’ll have a whole entry on hiring freezes and their impact on an organization).

With a single stroke, the C-suite feels they have pulled a measurable lever. Exceptions are denied (or never even considered), so the ledger shows savings. The hidden costs, lost deals, cratered morale, and reputational damage rarely appear in the same spreadsheet, so they’re conveniently invisible.

Nuanced Edicts: Guidelines That Invite Leadership

Nuanced edicts start with a clear goal but leave room for intelligence, creativity, and negotiation down the chain of command. They respect the fact that different teams face different realities.

Instead of “Cut 20 percent of staff,” a nuanced leader might say, “We need a 5 percent reduction in operating expenses this quarter. Show me your plan.”

The difference between these approaches is profound:

• Context is shared. People understand *why* the change is needed.

• Expertise is leveraged. Local leaders, who know their business better than anyone, craft solutions that protect revenue while meeting the objective.

• Innovation appears. One team postpones a non-critical software upgrade; another renegotiates vendor contracts; a third consolidates overlapping support roles through attrition rather than layoffs.

General George S. Patton nailed it: “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”

Yes, Nuance Is Harder—But the Payoff Is Bigger

Granting exceptions, weighing trade-offs, and trusting your leaders takes time and courage. The accounting isn’t as clean; the results aren’t as immediate. Yet time and again, organizations that embrace nuance:

• Preserve customer relationships

• Maintain employee engagement

• Achieve sustainable cost savings rather than one-off dips that rebound next quarter

• In short, they avoid the lawsuit-inducing, morale-crushing disasters that often trail behind authoritarian edicts.

Authoritarian edicts promise simplicity and speed, but they do so by ignoring complexity, and that ignorance carries a steep price. Nuanced edicts demand more work upfront, yet they harness the collective intelligence of the organization and lead to smarter, longer-lasting outcomes.

So, the next time you feel the urge to issue a freeze from “on high,” pause. Share the goal instead of the rule, invite your leaders into the problem-solving process, and let them surprise you with their results. Your customers, your balance sheet, and your people will thank you for the warmth of that leadership style, no parkas required.

Software engineers, those most mercurial of employees, are a wonderful mix of technologists and frustrated artists. They long to build things but simultaneously create something magical, new, and inspiring. Wrote George Sand in the 19^th century, “Art for art's sake is an empty phrase. Art for the sake of truth, art for the sake of the good and the beautiful, that is the faith I am searching for.” Nothing better sums up the software engineer of the 21^st century.

But, but . . . how are those talented, frustrated artists with incredible technical acumen used today? They are given lists created by people who are, at best, no more creative than they are and forced to provide those lists with “story points” and thence work on them one-by-one just like an assembly line worker doing the trade in a line. Engineers are told that product management decides the “what,” and they just do the “how,” and so they are forced, these incredibly expensive and creative people, to work their line items decided upon others.

To consider how wasteful this is, I must give an aside to the reader of my past. When I was a young man, I got my first real job at Walt Disney World, working at the world-famous Jungle Cruise. The Jungle Cruise is famous not just because of Walt Disney’s personal involvement in it or its iconic river cruise down the great rivers of the planet but because it is, effectively, the only place in any Disney Park from Paris to Hong Kong, where the Disney cast member gets to be a stand-up comic for 10 mins, over and over again, with a script that at the time was hmmmm, like traffic laws in Jakarta, mere suggestions.

The list of people who were Jungle Skippers like myself is legendary, including Robin Williams, Kevin Costner, and John Lasseter. And let me tell you, the selection process and training were quite the challenge. Brutal even. But at the end of that process, if you made it and became a skipper, and the wash-out rate was quite high back in the 80s, then you were alone, without any monitoring, with thirty Disney guests, for ten minutes, in a boat. Was I told at the tender age of 18 to be careful and stick to the guidelines and guardrails of what I could and could not say? Sure. But the biggest mandate I was given was to make sure the guests have fun and be funny. Use my creativity and inventiveness to make every experience great.

We, the software industry, are doing the opposite of how Disney treated a young creative innovator many years ago. We are stifling our expensive engineers and turning them into widget makers.

So, what is the answer to the original question? Well, hackathons have no product or release management, standups, process, formal security reviews, PR/CRs, and none of the expected lore of Agile (capital “A”).  All these things still happen in the flow of the hackathon, but they aren’t the formal “ceremonies” that crush innovation. The code that is created out of a hackathon is as good or better than what comes out of “the process,” but it is created faster, with more creativity; whole new ideas for things are thought of, built, and ready to ship in a week or two, all when you take away the things that stop the frustrated engineering artists from doing great things in the first place.

It isn’t that agile is bad, or that all agile practices are bad. It is that Agile (capital “A”) is strangling the creativity out of our engineers.

Disney wanted me to be funny, so they chose me and trained me so that I could delight their guests with my imagination and creativity. We want more velocity and features in our software; stop the madness of making engineers line-item processors and let them make magic for you.

And yes, I would love to go around that river one more time and tell those jokes that I can still recite, “Rise like bread, it’s the yeast you can do for me . . . I’m on a roll.”

I wholeheartedly agree with Roone. In the age of generative AI, organizations do not need these seemingly massive software engineering teams, most of which are hired in bulk based on salary bands, ranges, and geo-locations, decided on by people who have never built software. What is needed in a software engineering team is the best and most talented engineers of all kinds of experiences who can innovate, architect, design, and lace together the pieces and parts generated by AI.

Today, the trend is large software engineering teams with a blend of high-cost engineers in the developed world and low-cost ones in India, Manila, Eastern Europe, or another developing region of the world. This is usually enforced by Finance demanding a “blend” of salary costs because, obviously, they know all about how to build a successful engineering team, and yes, I’m dripping with sarcasm. Or perhaps you, as an engineering leader, get “advice” from HR that your company needs to lower overall engineering salaries for some reason, even though the budget for the product or project stays the same, or you have to have a specific ratio of offshore to onshore.

Ignore them and use the “Star System”.

So, what should you consider when assembling this software engineering team based on the “Star System”? Let’s work backward with what you should NOT consider, or better, flat ignore. First, ignore the location of the engineer; it doesn’t matter. I have an engineer who works for me today, and from day to day, I have no idea where he might be. And I don’t care if he is in a hot tub in Antarctica. He codes solutions overnight, in his sleep, and all of his work is stellar. You want talent; the location is irrelevant. Second, salary, who cares? Do you want the best or not? If you have a budget of $5 million USD and pay all of your developers $300k and end up with 16 software engineers instead of the 90 or so you can get using the older model, don’t worry. As long as you pick the best, most passionate engineers you can find, those 16 engineers will code circles around a team built on the traditional blended salary and location model. The experience level doesn’t matter. If you pick the right engineers, you will end up with some entry, some mid-career, and some late-career engineers, but the important thing is that they will be passionate, know they are well cared for, and, as a result, will code like the wind; their code will be beyond reproach, and they know they will be treated well if they overachieve.

I can hear the naysayers now; what about bonding, Agile (I’ll have another post on Agile, capital “A” at some point), team interaction face-to-face, blah blah blah? Well, naysayers, you are flat wrong. Interactions? Are you serious? Have you ever met a non-socially awkward 10X software developer? No, neither have I. I once saw an Agile scrum team stare at each other for the entire stand-up with only a few halting words and the soft sound of shuffling of feet. Sure, getting people together in the same room for kickoffs of major efforts and the like can be highly useful, but a bunch of really talented engineers not only do not need the social interaction that comes with putting time in the office, they hate it. Don’t waste your time.

When staffing this mythical team, be on the lookout for creativity. Great engineers who are also creative can be found, and they are worth whatever you pay them. I once had a young engineer just out of college who was a fantastic software engineer and an art history major. She was amazing, not just with her code but her ability to take a few requirements on a whiteboard and a sketch or two and build it; and drag others to help her make it. These are the people you should prize.

Flexibility is a rare trait that can bring great dividends to your team. Engineers, at least most of them, get stuck . . . and they like it that way. They like staying in the same area of code; it’s comfortable, and they feel like they are THE expert. These inflexible engineers are the engineers that, over time, cause development inertia. They don’t want anything to change; they will resist anything new. While you can turn inflexible engineers around if you are starting new, what you wish for is flexible engineers who love a challenge and don’t care if you will break their Agile sprint and have them do something completely different. Flexible engineers don’t mind learning new skills; when you ask them to code something in a new language, they leap at the opportunity, not run away.

Passion is indispensable. When recruiting engineering resources, it is the first thing I look for. Passion manifests in many ways, including a determination to finish and finish well, a hunger for the impossible, and a willingness to do whatever it takes. The best-skilled engineer lacking passion isn’t a good candidate. You need that passion in your organization.

The Star System is not an easy internal sell, and as a senior engineering leader or CTO, you will find that there will be a great deal of opposition from support services that think they know better how to staff and hire. But it is worth the effort as your team will be far more productive, and you will exceed your company or organization’s expectations.

My new team seemed to me to be strong and highly competent, though my Chinese was pretty rough (it did get better). I got into the office every morning early, 7 am or even earlier, and left late into the evening, walking home after dark some days, putting in the hours needed to learn my new team members, my job, the marketplace we were competing in, and how I could improve upon the track record of my predecessor.

After a week or so of starting my job, I walked every day to the office and back, not because I wanted to be healthy but because before I could speak Chinese reasonably well, I had this bad habit of getting into a taxi and not being able to convey accurately to the driver where I wanted to go, ending up in a lot of random places all over Beijing, I started to notice something odd about my team. They never left the office. Like, really, ever.  It was super weird.

This went on for at least two weeks until I asked one of the engineers about her family and children, just making small talk. What she told me about her family, while interesting, was not the most potent part of the conversation. She very directly told me she had not really seen her son in weeks as she had been in the office working. This was pretty confusing to me, so I asked her if she needed me to reduce her workload so she could get home at a reasonable time. She was shocked at the suggestion.

She and my entire team were arriving early and waiting to leave until I left the building, even if they had no work to do, so that I would not be upset with them for not being willing to work as hard as the boss.

Obviously, I scheduled a meeting and explained to the team that my expectation was not that they work as insane hours as I was willing to work and that I was far more interested in them doing a good job with their tasks rather than their appearing to work by being in the building. But far more importantly, I learned a key lesson. Culture, as Lou Gerstner said in his book Who Says Elephants Can’t Dance, isn’t a component of organizational leadership; culture is the whole game itself. Culture dictated in the early 2000s that my new Chinese team stay until the boss left. To gain the loyalty and mold my team into the organization I desired, I needed to invest much in learning their culture and applying some of my own.

And, most importantly, I learned to let my team go home.

I’m Jason, a CTO and VP of Software Engineering at a major enterprise software company, father of three, a good husband (so my wife says), and an all-around good guy. 2024 marks my 30^th year in the software industry. It has been a wild ride. After years of considering creating a place where I can share all that I have learned, I have finally decided that it would be fun to share the lessons, stories, failures, and minutia of a long and entertaining career. The content here is my own as well as my sometimes-pointed opinions and is not in any way associated with my current or any of my past employers. I also reserve the right to change anything I like, anytime I want, for good or even pointless reasons.

So, let me tell you a little about myself. I love to code and have all my life. My Mom is the one who taught me how to code, having learned herself in the 1960s. Fortran 4 was my first computer language, and I used it to code a baseball game on a PDP-11 at the local community college at the age of 5. My first computer was a Commodore VIC-20 which I spent countless hours playing with while learning 6502 assembly. For those that remember, the VIC-20 only had 4k of RAM, and I didn’t have the money to buy a RAM expander. So, to do primitive word processing, I had to write a memory swap to my cassette drive.

I’ve been in core software engineering, support, services, strategy and leadership during my lengthy career. I was fortunate enough to do so while living around the world in China, Malaysia, Singapore, Germany, and many States in the USA. I have been recognized as an IBM Distinguished Engineer along with many industry lauds for being innovative, passionate, flexible, and perhaps crazy enough to take on just about any challenge.

As I write more here in my new destination, I’m sure you, the reader, will learn more about me, but at my core, I like improving, learning, helping others improve, and being the best I possibly can be each and every day. A young Winston Churchill, on his first speaking engagement to the United States after his involvement in the Boer War, met an aging but resplendent Mark Twain in New York. After the speech, Winston asked Twain to sign his collection of books for him. Twain added the following to his signature, “To do good is noble; to teach others to do good is nobler, and no trouble.” This quote is something I remind myself of each and every day.