The Art of Doing Science and Engineering: Learning to Learn

1. 1Master the fundamentals of your field first — Hamming builds the entire course on 'a good review of the fundamentals you have learned' because recognition of significance requires deep prior knowledge to compare against.
2. 2Read broadly across fields so 'anything and everything you know might be useful.' The prepared mind fails when 'you believe the problem is in one area' and won't pull relevant information from another course.
3. 3Study the initial part of discoveries, not just the finished result — Hamming deliberately uses the 'story approach, often emphasizing the initial part of the discovery' to show how preparation precedes recognition.
4. 4Aim your preparation at the future, not the past: 'prepare the student for the student's future, not for the teacher's past.' Estimate the state of your field 'at the time of your greatest contributions' and stock your mind for that.
5. 5Accept the constant need to relearn: knowledge doubles roughly every 17 years, so build the habit of continually learning new things rather than treating preparation as a one-time event.
6. 6When an unexpected observation appears, run it through your fundamentals to recognize, formulate, and solve — the sequence Hamming names as the payoff of preparation.
7. 7Reframe apparent luck as psychological, not logical, novelty: examine your own past experiences that 'led you to finding the result,' because circumstances lead the prepared to success.

Hamming was frightened of giving public talks despite years of college teaching, and reasoned he 'could not afford to be crippled that way and still become a great scientist' — a scientist must communicate through papers, prepared talks, and impromptu talks. Shortly after deciding practice was the necessary fix, he was asked to give an evening talk to IBM customers. Because his mind was already prepared with this self-diagnosed need, he 'immediately accepted the offer' — recognizing an ordinary invitation as the exact opportunity he required. He then went further: he resolved to give a talk 'so good I would be asked to give other talks and hence get more practice,' and realized he must give the talk the audience wanted, not the one 'dear to my heart.' The prepared mind converted a routine speaking slot into a compounding chain of practice. Note the sequence: preparation (the decision) preceded the observation (the invitation) which enabled recognition and capitalizing — 'luck favors the prepared mind' in action.

• If an unexpected opportunity arrives and it matches a need you've already articulated, accept immediately — don't wait for a better one.
• If you're choosing what to prepare, weight toward the future state of your field over its past, since your greatest contributions lie ahead.
• If a problem seems confined to one area, deliberately search your knowledge of other fields, because relevant information usually lives outside the obvious box.
• If a result looks like pure luck but keeps 'bunching' in the same people, treat it as evidence of preparation, not randomness, and reverse-engineer the preparation.
• If mathematics or fundamentals feel hard, still forgo skipping them where possible, since they give the 'deep insights' that let you see the weaknesses in current beliefs and spot openings.

• Preparing for the teacher's past instead of the student's future — the tell is a curriculum that reviews only settled material and never discusses 'the future of the field.'
• Treating success as random luck — the tell is dismissing great results despite them being 'bunched in the same person too often' to be chance.
• Compartmentalized knowledge — the tell is not applying relevant information because it 'occurred in another course.'
• Preparing once and stopping — the tell is ignoring the 17-year doubling of knowledge and the 'constant need to learn new things.'
• Chasing the opportunity you love rather than the one that serves the goal — the tell is giving 'a talk on a topic dear to my heart' instead of what the situation actually rewards.

• ▸Fundamentals inventory: list core fundamentals you can recognize deviations from on sight.
• ▸Adjacent fields scanned: name fields outside your own you actively read.
• ▸Future-state forecast: describe your field at the time of your expected greatest contribution.
• ▸Articulated needs: state the capabilities/gaps you've consciously named (like Hamming naming 'practice talks').
• ▸Opportunity match test: for a current opening, note which named need it satisfies.
• ▸Recognition note: write what fundamentals told you this observation is significant.
• ▸Relearning cadence: set what new thing you're learning this cycle to stay ahead of the 17-year doubling.
• ▸Luck audit: record a past 'lucky' win and the preparation that actually caused it.

1. 1Take the hardest problem in your area first, deliberately, to prove the new method can cope before anyone will let it near the routine work. Hamming did integration, then function evaluation, then how numbers combine — 'the hardest problems on the most primitive equipment' — precisely because 'it was necessary to do this in order to prove machines could do things which could not be done otherwise.'
2. 2Expect and pre-budget for resistance. Assume any real innovation is 'stoutly, and perhaps foolishly, resisted' by 'the forces of inertia and stupidity,' and treat that resistance as a fixed barrier, not a personal verdict.
3. 3Manufacture pressure to force output. Promise a result by a fixed date so that, 'like a cornered rat,' you must 'at the last minute find something' — Hamming reports being 'surprised at how often this simple trick of managing myself has worked.'
4. 4Build the self-confidence that makes creation possible by acting on it repeatedly: 'without self-confidence you are not likely to create great new things.' Confidence is a habit you rehearse, not a mood you wait for.
5. 5Guard the thin line between confidence and overconfidence by watching results: 'when you win you are strong-willed, and when you lose you are stubborn.' Let outcomes, not self-image, arbitrate.
6. 6Learn to drop a wrong problem. 'If you cannot drop a wrong problem, then the first time you meet one you will be stuck with it for the rest of your career' — so persistence must be paired with the discipline to quit a dead line of attack.
7. 7Measure the size of the barrier before committing. 'By realizing the magnitude of the actual task you can then decide if it is worth your efforts to continue, or if you should go do something else you can accomplish.'
8. 8Start now, not at the 'proper moment.' Hamming's advice: 'if you want to do significant things, now is the time to start thinking and not wait until it is the proper moment—which may never arrive.'

Hamming's own progression on early computers is the model. He deliberately attacked the hardest problems — integration, then function evaluation, then a paper on how numbers combine — on the most primitive equipment available. He did this not because it was efficient but because a new device must 'prove beyond any doubt' it can 'cope with heroic tasks before it can get into the system to do the more routine, and, in the long run, more useful tasks.' Only after that proof could he turn to 'the economical solutions of problems which could be done only laboriously by hand,' which required developing the basic theories of numerical analysis for machines. The courage here is enduring a hard, unglamorous heroic task specifically to break through inertia. The payoff was not the hard problems themselves but the door they opened: the mass production of a variable product on machines.

• If your new idea meets stiff, even foolish, resistance, then treat it as the expected barrier every innovation faces — not as evidence you are wrong.
• If you keep waiting for ideal conditions to create, then stop; 'the constant impinging of reality is often a great help,' so impose a deadline instead.
• If a problem has resisted you far past its apparent magnitude and you can no longer see a path, then drop it and 'go do something else you can accomplish' rather than 'fritter away your efforts.'
• If your past successes are convincing you that you can solve any problem, then treat that as a warning sign of overconfidence — the trap that cost Einstein his midlife decades on a unified theory 'with about nothing to show.'
• If you must choose between proving a method on a heroic task and applying it to routine work, then prove the heroic task first — routine acceptance only comes after.

• Persisting on a wrong problem out of pride. Einstein 'spent the rest of his life' on a unified theory 'with about nothing to show' — the tell is that your motivation is defending past success rather than the problem's promise.
• Waiting for the 'proper moment' or ideal creative atmosphere. The tell is you talk about needing the right surrounding conditions; Hamming has 'seen the creative act done under the most trying circumstances.'
• Mistaking stubbornness for strong will. The tell is the outcome: 'when you win you are strong-willed, and when you lose you are stubborn' — if you're losing and still doubling down, you've crossed the line.
• Getting discouraged the first time a new idea is resisted, and abandoning it before measuring the barrier. The tell is you quit on emotional rejection rather than a reasoned judgment that the task isn't worth it.
• Attempting 'heroic reformations' of yourself that are 'almost certain to fail.' The tell is grand all-at-once change without knowing which habits to change or your own limits — like a crash diet that collapses.

• ▸Hard problem I am attacking: state the single most important, difficult problem in your area.
• ▸Why it must be proven heroic first: what routine acceptance does this heroic result unlock?
• ▸Deadline I am promising: fix a date and a person to whom you promise the result.
• ▸Magnitude of the barrier: estimate the size of the actual task and the resistance expected.
• ▸Continue-or-quit judgment: given that magnitude, is it worth my efforts or should I do something I can accomplish?
• ▸Confidence-vs-stubbornness check: am I persisting on the problem's merit or defending past success?
• ▸Drop trigger: the specific condition (no path visible after X) at which I will drop this problem.
• ▸One habit I am changing: name the single realistic habit shift (no heroic reformation) to become more creative.
• ▸Start-now action today: the concrete first step taken before the 'proper moment.'

1. 1Before writing anything, think through the whole problem: define what your acceptance test for correctness will be and how later maintenance will be done. Getting it right the first time beats fixing it later.
2. 2Treat the work as closer to novel writing than to classical engineering — accept that two competent people given the same problem produce different valid solutions, so pursue your own imaginative formulation rather than a single 'engineered' answer.
3. 3Measure the initial psychological distance between the fields or tools you are combining; deliberately reach for a tool far from the problem's home domain (the greater the perceived distance, the greater the potential creative payoff).
4. 4Question foundational assumptions constantly — pick up each choice (basis functions, a metric, a method) and turn it over, searching for fundamentals rather than accepting the standard by default.
5. 5Shift scale on purpose: examine the micro detail closely, then zoom out to place the problem against the broad landscape and the long chain of history to see connections others miss.
6. 6Prepare the mind before encountering problems ('luck favors the prepared mind'), so that when a problem arrives you can recognize, formulate, and solve it — build the general tools in advance.
7. 7When you find a very general formulation (like a simulated neural net program written once), write it broadly so a whole class of problems is solved with only a calling sequence — reuse generality instead of re-solving details.

Hamming applied the well-known method of least squares to a problem in magnetics, and a colleague wrote it up with him as joint author. He balked, saying he could not publish a paper that 'merely applied least squares.' A shrewd physicist friend pointed out that his own most-requested reprint was a solid-state physics paper that applied standard circuit analysis — a routine tool moved into a new area — and since Hamming's paper was new in its area, he should publish. The lesson: creativity is 'usefully putting together things which were not perceived to be related before,' and the difficulty of the act matters less than the initial distance between the combined things. He makes the same point with his own discarding of L2 for L1 when measuring the distance between two strings of bits — it had apparently not been done before and it advanced the field, even though the act itself was not hard.

• If two capable people would produce genuinely different valid solutions to the problem, then treat it as creative writing (imagination-bound), not engineering — don't force premature 'engineering control.'
• If a tool from a distant field can be usefully applied to your problem for the first time, then publish/pursue it even if the act is technically routine — novelty in that area is the value.
• If something has merely 'not been done before' but carries no value to anyone, then it is novel but not creative — discard it.
• If you are about to start writing/building, then first fix the acceptance test and maintenance plan; if you can't state them, you aren't ready to begin.
• If you catch yourself accepting a foundational choice (metric, basis, method) unexamined, then stop and turn it over for fundamentals before proceeding.

• Believing years of experience automatically improve you — the tell: repeating habitual patterns (like bureaucrats' 'governmentese' seeping in) and mistaking accumulated reps for growing skill.
• Chasing 'not done before' as a proxy for originality — the tell: producing work that is new and novel (a picture anyone could paint) but valued by no one.
• Waiting for 'engineering control' to make the creative work orderly — the tell: absorbing propaganda and wishful thinking about method (top-down, waterfall, etc.) instead of thinking before you write.
• Mistaking unappreciation for greatness by inverted logic — the tell: 'because I am unappreciated I must be great,' ignoring that value (to someone) is what makes creativity real.
• Working with myopia, jammed against passing trends — the tell: you cannot see beyond or beneath current fashions, so you never shift scale or place the problem in historical context.

• ▸Problem restated in my own words: capture the formulation that is uniquely yours, not the standard one.
• ▸Foundational assumptions I am questioning: list each default choice and why it might not hold.
• ▸Distant field/tool to import: name a tool from a domain far from this problem's home.
• ▸Initial psychological distance rating: how unrelated do these combined things seem now (low/med/high)?
• ▸Value-to-whom check: state who benefits and why this is more than 'not done before.'
• ▸Acceptance test: the concrete test that proves it is right.
• ▸Maintenance/field plan: how this will be supported later.
• ▸Micro/macro note: one close detail examined + one wide-shot historical or landscape connection.

1. 1Treat your work as investment, not expenditure: choose the problems and habits that compound rather than the ones that merely feel productive today. Hamming's celebrated inventions grew from problems he solved for others—pick a base workload that keeps you touching 'harsh reality.'
2. 2Keep the door open. Hamming insisted on an open door, lunched with anyone he could learn from or argue with, and stormed in and out of colleagues' offices. Structure your day so useful problems find you.
3. 3Convert routine consulting into 'micro-Nobel Prizes': take each mundane problem you are handed and ask what general, reusable result it can yield, so effort accumulates instead of dissipating.
4. 4Concentrate effort on fundamentals—things that have lasted a long time, and from which the rest of the field can be derived by standard methods—so the intellectual capital you build does not obsolete when fields shift.
5. 5Build the capacity to learn new fields on the fly while still carrying your operational load; Hamming learned numerical analysis, the physical sciences, and social sciences while developing and running a computing center.
6. 6Run the mile yourself. A coach can only discuss style and criticize yours—you get out only as much as you put in, so mull, compare against your own experience, argue with others, and make points part of your practice.
7. 7Study successes over failures: there are many ways to be wrong and few to be right, so investing effort in what works is more efficient and leaves you knowing how to succeed when your turn comes.

Jack Kane had the 'wild idea' of attaching a small SDS 910 computer to the Brookhaven cyclotron. Hamming's VP asked whether Jack could do it; Hamming examined both the question and Jack closely before saying yes, and further asked whether the manufacturer would stay in business—'that cost me much more effort in other directions.' The payoff compounded: the cheap machine at least doubled the effective productivity of the huge, expensive cyclotron by gathering, reducing, and displaying data on an oscilloscope Jack built in a few days, letting them abort bad runs mid-experiment. That single effort seeded a larger arc—Bell Labs began putting small computers in laboratories, first to gather data and soon to drive experiments, enormously increasing the range of possible work. The lesson: sustained, focused effort on one concrete problem changed both the problem and what computers were used for. Effort invested well returned an equivalent, larger job—not the same old one.

• If a problem is routine consulting but can yield a general, reusable result, then invest the extra effort to extract the reusable result—that is where compounding happens.
• If a topic has lasted a long time and the rest of the field can be derived from it, then it is a fundamental and deserves your concentrated effort.
• If you are only sitting in the class or reading the book without mulling, comparing, and arguing, then you are wasting your time—put in more or stop.
• If you must choose between studying a success and a failure, then study the success, because it is more efficient and teaches you how to succeed.
• If a piece of work keeps your head out of the clouds by contact with harsh reality, then protect it rather than begrudge it—it feeds the great work.

• Treating effort as expenditure to minimize rather than investment to compound; the tell is you optimize for comfort—'just get along through life comfortably'—instead of significant contribution.
• Closing your door to protect focus; the tell is that no new problems arrive and your work stops touching harsh reality, so you drift into the clouds.
• Chasing prestige-shaped 'great work' while disdaining mundane consulting; the tell is that you have no stream of real problems, which is exactly what Hamming's inventions grew out of.
• Devoting all effort to learning new topics and thereby not contributing your share to the organization—or the reverse, never learning and being left behind like 'so many good engineers' in the long run.
• Being a passive passenger: adopting a master's style wholesale by copying the past instead of selecting, adapting, and forging your own; the tell is that merely copying the past will not carry you to future greatness.

• ▸Problem in hand: the concrete, possibly mundane problem you are working
• ▸Harsh-reality check: what real constraint keeps this grounded
• ▸Reusable result: the general 'micro-Nobel Prize' you can extract from it
• ▸Fundamental touched: which long-lasting principle this builds capital in
• ▸New field to learn: what you must pick up on the fly to finish
• ▸Effort put in this week: hours of real mulling/arguing, not just attendance
• ▸Success studied: one worked success you analyzed and why it worked
• ▸Own-style adaptation: which observed trait you selected and made yours

1. 1Aim at your period of greatest contribution, not the present: estimate the state of science and engineering at the point in your career where impact peaks (Hamming notes many are near the high point ~34 years out), and pick problems that will still matter then.
2. 2Get positioned near hard, real problems. Hamming's celebrated inventions all 'grew directly out of' problems he solved for other people; treat mundane consulting work as 'interaction with harsh reality' that keeps ideas grounded and produces 'micro-Nobel Prizes.'
3. 3Keep the door open and eat with people you can learn from or argue with. Hamming shared offices and lunches with Shannon, Tukey, Bardeen, Brattain, Bode; deliberately place yourself among people whose work has a 'discontinuous effect.'
4. 4Model claims on the back of the envelope before acting. When you hear a quantitative statement, set up a quick model to check it—this keeps modeling skill fresh for 'more important applications' and clears misconceptions 'at the time they are being formed.'
5. 5Develop and adapt a personal style rather than copying a predecessor's. Hamming and 'the four young Turks' found their own styles and transformed a whole department; select traits, adapt them, and make them your own because a style that works in one age may not fit the next.
6. 6When you conclude something can't be done, record the exact reason why, so when circumstances change you don't repeat 'it can't be done.' Guard against obsolescence (half-life of technical knowledge ~15 years) by continually learning new things.
7. 7Choose a goal of excellence and commit; the gain 'is in the struggle and not in the achievement.' Pursue significant contribution deliberately rather than 'just getting along comfortably.'

Tukey suggested to Hamming, 'sort of,' the basic ideas of the fast Fourier transform. At the time Hamming had only an IBM Card Programmed Calculator, on which the 'butterfly' operation was completely impracticable, so he correctly judged it a bad idea for his equipment. Years later he had an internally programmed IBM 650 and Tukey mentioned it again, but Hamming remembered only that it 'was one of Tukey's few bad ideas'—he had forgotten the reason (the equipment) that made it bad. So he did not do the FFT, even though a book he had already published in 1961 shows he knew every fact needed and could have done it easily. The FFT reduced computation from about (2N)² operations to roughly N log N, transforming whole areas of science and engineering. The moral: he missed founding a field because he retained the conclusion but discarded the reason behind it.

• If a problem comes from someone else's harsh, practical need, then take it seriously—Hamming's great work grew out of exactly such problems.
• If you previously judged something impossible, then before repeating that judgment recheck the original reason, because changed circumstances (better equipment, new tools) may have removed it.
• If you can plausibly work near or argue with people whose work is discontinuously important, then arrange it—keep an open door and share meals.
• If a quantitative claim can't be turned into a model, or the model contradicts it, then treat the claim as probably nonsense.
• If a trait works for your predecessor's age but not the coming one, then discard or adapt it rather than adopt it wholesale.

• Retaining a conclusion but forgetting its reason—Hamming's FFT miss; the tell is saying 'it can't be done' without being able to state why.
• Copying a successful predecessor's style verbatim; the tell is doing what worked in a prior age and finding it no longer produces impact.
• Treating consulting or 'mundane' service work as beneath you; the tell is a head 'in the clouds' with no interaction with harsh reality feeding real problems.
• Optimizing for present-day problems instead of the state of the field at your peak contribution; the tell is expertise going obsolete (~15-year half-life) mid-career.
• Choosing comfort over a goal of excellence; the tell, in Hamming's terms, is 'merely existing' rather than living—no struggle you set for yourself.

• ▸Target horizon: years until your estimated peak contribution.
• ▸Field state at peak: what will likely be true then (more mathematical? new tools?).
• ▸Source problem: the real, practical problem (whose need) you are working from.
• ▸Adjacent people: names you can learn from or argue with, and how you'll reach them.
• ▸Personal style: which observed traits you keep, adapt, or reject—and why.
• ▸Impossibility log: things you judged 'can't be done' + the exact reason each.
• ▸Obsolescence watch: knowledge likely stale within 15 years + what to learn next.
• ▸Model check: one recent claim you tested on the back of the envelope + result.
• ▸Excellence goal: the specific struggle you are committing to pursue.

1. 1Compute your obsolescence horizon: pick your years to retirement, use Hamming's doubling table (knowledge doubles roughly every 17 years), and read the left-hand factor. At 34 years, technical knowledge quadruples; assume most of what you now know will be superseded before you retire.
2. 2Separate fundamentals from perishable technique. Apply Hamming's test: fundamentals are the ideas that keep recurring and let you derive the specifics — concentrate learning there, treat the rest as illustrative material you can relearn later.
3. 3Build a standing learning capacity, not a fixed knowledge stock. Deliberately learn 'enough to get along' in adjacent fields as problems arise, without stopping your actual contribution — the way Hamming learned numerical analysis, physical sciences, and some biology while running a computing center.
4. 4Position yourself against real problems supplied by others. Take an 'internal consultant' posture: solve practical problems for colleagues so your great work grows directly out of that 'interaction with harsh reality' rather than clouds.
5. 5Adopt new tools early against professional resistance. When a superior method appears (symbolic programming, FORTRAN), switch before your peers do; expect the objection 'it can't be done / it's wasteful / it's for sissies' and route around it.
6. 6Practice dropping wrong problems. Set a rule for abandoning a line of work so one bad problem doesn't consume your career; watch especially for the overconfidence that follows past success.
7. 7Project your field forward using your own imagination and history, then aim decisions at that future — a random walk of choices gets you far less far than choices steered by a vision.
8. 8Prefer forms of work with broad, durable applicability and free distribution — knowledge others can learn and internalize — over work whose value is locked behind an API or acquisition.

Hamming arrived at Bell Labs having just learned his field, then found himself computing for the development of transistors — work that 'obsoleted my just-learned knowledge.' Rather than treating this as a loss, he treated it as the doubling of knowledge made personal: whatever he had mastered was already being overtaken. He responded by concentrating on fundamentals and building the ability to learn new fields as they arose, forcing himself to learn numerical analysis, computers, and enough of the physical, social, and biological sciences to serve the many computing problems that came to him. He did all this while simultaneously developing and running the computing center, so learning never displaced contribution. The result over decades was sustained relevance: his celebrated work, including error-correcting codes, grew directly out of the practical problems he was solving for others. He avoided the fate he named explicitly — good engineers who are 'left behind in the long run.'

• If a piece of knowledge recurs across problems and lets you derive specifics, then it's a fundamental — invest there; if it's a polished result you can relearn, treat it as illustrative.
• If your just-learned expertise is being obsoleted by the very work you're doing, then respond by expanding learning capacity, not by defending the old knowledge.
• If a problem's errors pass through a feedback situation that compensates them, then don't over-invest in accuracy there; if a quantity is 'vitally out in the open' with no feedback protection, then get it exactly right — understand the computation as a whole.
• If a new tool is opposed by 'it can't be done, it's wasteful, real professionals won't use it,' then that resistance is a signal to adopt it early and gain the 10x advantage.
• If a problem has consumed you past its productivity and past successes are fueling your confidence more than results, then drop it — sterility with age is real, especially in high-raw-creativity fields.

• Defending just-learned expertise instead of relearning — the tell: you resent that new work is making your knowledge obsolete rather than treating it as normal doubling.
• Being the shoemaker whose children go without shoes — refusing to use your own best methods on your own work; the tell is insisting on the harder legacy approach (absolute binary addresses over the symbolic system) out of professional pride.
• Riding one problem to sterility — like Einstein spending midlife-onward on a unified theory with 'about nothing to show'; the tell is inability to drop a problem plus a track record of successes convincing you that you can solve anything.
• Mistaking the illustrative content for the point — cramming perishable technique while skipping the style of thinking and the fundamentals; the tell is that you can perform methods but can't derive or adapt them when the field shifts.
• Chasing the fashionable brass ring — assuming the entrepreneurial 'inevitable-seeming path' (encoding-as-a-service behind an API, acquisition) is the only form of impact; the tell is measuring worth by acquisition size rather than durable, teachable contribution.

• ▸Years to retirement: number you enter, then read the knowledge-increase factor from the doubling table
• ▸Knowledge factor at that horizon: e.g. ~4x at 34 years — what fraction of today's expertise likely survives
• ▸Fundamentals list: 3-5 recurring ideas that let you derive specifics, passing the 'keeps coming back' test
• ▸Perishable techniques: current tools/results you accept you'll relearn or discard later
• ▸Adjacent fields to learn 'enough to get along': domains your problems keep touching
• ▸Real problems from others: 2-3 practical problems you're solving that could seed durable work
• ▸New tool to adopt against resistance: the method peers reject that you'll switch to now
• ▸Problem to drop: the line of work past its productivity that you're holding out of overconfidence
• ▸Your future vision: one sentence on the future you're steering decisions toward, not a random walk

1. 1Fix a horizon far enough out that today's technical knowledge is largely obsolete — Hamming centers on the year 2020, a '20/20 foresight' about 15-30 years ahead. Use the knowledge-doubling table (a factor of 4 in ~34 years) to estimate how different that world will be.
2. 2Separate three questions before committing: What is possible (science)? What is likely (engineering/human factors)? What is desirable (ethics)? Answer each independently for your field.
3. 3Compare the 'likely' against the 'desirable'; where they diverge, that gap is exactly where you can steer events toward the future you want instead of suffering the inevitable.
4. 4Draw on the two tools Hamming names: history (one of the few guides you have) and active imagination in trying to picture the future you'll actually face.
5. 5Write the vision 'in some detail' — not a vague slogan but a specific direction concrete enough to bias thousands of small and large choices toward it.
6. 6Accept the vision will likely be wrong and commit anyway; then use every subsequent choice, however minor, as a step in that direction rather than a reaction to current events.
7. 7Anchor the vision in fundamentals plus a learned ability to keep learning, since the specifics will obsolesce (recall vacuum-tube expertise obsoleted by transistors within a career).

Hamming's clearest case is his own simulation vision. At Los Alamos, designing the atomic bomb, there could be no small-scale experiment — either you have a critical mass or you don't — so computing on primitive IBM accounting machines was the only practical way to test proposed designs down to the one tested at Alamogordo. From that single experience, thinking it over carefully, he extracted a general vision: computers would let you simulate many kinds of experiments. He carried that vision to Bell Telephone Laboratories and, in the mid-to-late 1950s, told the President and VPs, 'At present we are doing one out of ten experiments on the computers and nine in the labs, but before I leave it will be nine out of ten on the machines.' They dismissed him as a wild theoretician from the math department. He was right — the ratio is now 90-99% on machines — because he had answered 'what is possible' (simulation), judged 'what is likely' (it is cheaper and more flexible, so inevitable), and steered his own effort accordingly rather than reacting year to year.

• If you find yourself only reacting to current events as they happen, then you have no vision — install one, because reaction gets you distance √n, not n.
• If your vision might be wrong, then keep it anyway; accuracy matters less than you suppose, and getting anywhere beats drifting.
• If 'what is likely' differs from 'what is desirable,' then act on the difference to bias events toward the desirable future.
• If a plan depends on today's specific technical knowledge, then re-anchor it on fundamentals, since half your technical knowledge is obsolete in ~15 years.
• If someone else prescribes which path to greatness you must take, then ignore the prescription — the path is your business, only that it leads somewhere great matters.

• Drifting like the drunken sailor — staggering left or right on independent random steps, ending up only √n from the origin; the tell is that your choices trace back to whatever event was in front of you, not a direction.
• Refusing to form a vision because it might be wrong — the tell is that you keep waiting for certainty that never comes, mistaking predicting the future perfectly for the actual task of foreseeing it.
• Fixing on a specific technology instead of a direction — the tell is that your goal obsolesces with the tool (vacuum tubes to transistors) and you have nothing left to steer by.
• Optimizing only 'what is possible' while ignoring the human factors that select the one future that happens — the tell is a technically brilliant plan that the slow evolution of laws, institutions, and organizations quietly defeats.
• Letting the inevitable happen and suffering the consequences — the tell is that you can describe the future clearly but never asked whether it was desirable or how you'd alter it.

• ▸Horizon year: the far date you're preparing for (e.g., ~15-30 years out)
• ▸Knowledge factor: expected increase in relevant knowledge by then (use the doubling table)
• ▸Possible: what your field will be technically capable of by the horizon
• ▸Likely: which of those possibilities the human factors will actually select
• ▸Desirable: which future you want to see happen
• ▸Steering gap: where Likely differs from Desirable — your point of leverage
• ▸Fundamentals to hold: the durable basics your vision rests on as specifics obsolesce
• ▸Next choice test: the concrete decision in front of you, scored by whether it moves toward the vision

1. 1Reserve a fixed block for problem-scanning the way Hamming devoted Friday afternoons (about 10% of his time) to asking what would happen in the future of his field — treat this as a standing appointment, not a leftover.
2. 2For each candidate problem, run the three-question filter: what is possible (science), what is likely to happen (engineering/human factors), and what is desirable (ethics/values). Only problems where the desirable and likely futures diverge are ones where your effort can change the outcome.
3. 3Concentrate on fundamentals, not conveniences: given that half of technical knowledge obsoletes in ~15 years, ask whether solving this problem builds durable understanding or just clears a transient task.
4. 4Mine the mundane problems others bring you for their fundamental core — Hamming was an internal consultant whose 'great' inventions grew directly out of practical problems he solved for other people. Take the assigned problem, then ask what general problem it is a special case of.
5. 5Keep an open door and eat lunch with people you can learn from or argue with; use those conversations to surface which problems in the field are actually important versus merely fashionable.
6. 6Run a back-of-the-envelope model on any claim about a problem's size or urgency before committing — if you can't set up a model, or the model contradicts the claim, downgrade the problem.
7. 7Formulate the problem so its solution is a gift of knowledge — something teachable, learnable, internalizable — rather than something hidden behind an API or a business. That test forces you toward problems with broad, lasting applicability.

Hamming was asked to help chemists run reaction simulations, and he could have just accepted the assigned, convenient task: get their equations into the machine. Instead he located the fundamental problem — reliability and correctness of the simulation — and reframed it. He wrote a program that went from a punched card describing each reaction, with its interaction constants, straight to the equations, so no coefficient could differ between equations for the same reaction. This kept the chemists focused on chemistry, the thing they were best able to do, while automating the bookkeeping and step-spacing they were not expert in. Critically, he refused to relieve them of the thinking part and left them in charge of the actual computing. The important problem was not 'run this simulation' but 'make simulations trustworthy,' and by solving that he produced a reusable, teachable method rather than a one-off answer.

• If a problem is merely assigned or convenient but has no fundamental core, then extract the general case it illustrates before spending real effort on it.
• If the likely future and the desirable future coincide, then the problem needs watching, not your labor; if they diverge, then that gap is where your work can alter the outcome.
• If solving the problem produces something teachable and freely usable, then it clears Hamming's 'gift of knowledge' bar; if it only produces something hidden behind a service or acquisition, then reconsider whether it is 'great' work.
• If a quantitative claim about a problem's importance survives a back-of-the-envelope model, then treat it as real; if it doesn't, then discard it as public-media nonsense.
• If you believe a tool or machine can simply relieve you of the thinking part, then stop — you remain responsible for the decision and cannot blame the simulation.

• Working the problem you were handed rather than the fundamental problem behind it. Tell: you can describe the task but not the general class of problem it belongs to.
• Chasing the culturally rewarded path — the billion-dollar acquisition, the startup on the side — instead of the fundamental problem. Tell: your criterion for 'important' has quietly become 'fundable' or 'inevitable-seeming.'
• Optimizing within a single course, department, or specialty and skipping problems that fall between the fragments. Tell: you never touch topics that don't obviously belong to your assigned area.
• Trusting a simulation because it prints nice sheets or colorful pictures. Tell: you'd accept the output without being able to model or check its reliability yourself.
• Betting your effort on transient, obsolescence-prone knowledge instead of fundamentals. Tell: everything you're working on will be half-obsolete in about 15 years and builds no durable understanding.
• Believing (or disbelieving) a sweeping premise — 'computers can think' — instead of coming to your own terms with it, leading to a first-class failure.

• ▸Problem as handed to me: state the task exactly as assigned or as it arrived.
• ▸Fundamental problem behind it: the general class this is a special case of.
• ▸Possible / Likely / Desirable: fill each; note where likely and desirable diverge.
• ▸Fundamentals test: does solving this build durable understanding or just clear a transient task?
• ▸Gift-of-knowledge test: is the result teachable and freely usable, or hidden behind a service?
• ▸Back-of-the-envelope check: model any size/urgency claim; record whether it survives.
• ▸Who to argue with: name one person to lunch with or storm in on about this problem.
• ▸Time committed: which recurring block (my 10% / Friday afternoon) I assign to it.

1. 1Separate the fundamentals from the illustrative material in whatever you're studying. Hamming's own test: his chapters on 'Digital Filters' and 'Error-Correcting Codes' do not teach those things — they teach the style of thinking by which the ideas were conceived. Ask of any lesson: is this the content, or the illustration?
2. 2Pick foundations that last. Choose principles taught, learned, internalized, and performed with your own hands (like Shannon's information theory or the Nyquist sampling theorem) over transient techniques and passing trends.
3. 3Study fundamentals through the initial part of a discovery, not the polished result. Hamming uses the 'story' approach — emphasizing preparation before the problem was encountered — because 'Luck favors the prepared mind' (Pasteur).
4. 4Practice range of scale deliberately. Zoom in on micro decisions (why complex exponentials as basis functions) and out to the broad landscape and long chain of history — in the same analysis. Nothing taken for granted, nothing taken in isolation.
5. 5Learn style the way arts are taught: once fundamentals are learned, attempt many approaches that 'surround the subject,' then get suggestions on what else might be tried. Expect repetition and approaching from many sides.
6. 6Keep your mind focused on the thinking part and automate the mechanical part — but never let automation relieve you of judgment. Hamming automated the chemists' bookkeeping while refusing to relieve them of the chemistry.
7. 7Treat the future, not the past, as the target. 'Teachers should prepare the student for the student's future, not for the teacher's past.' Center your preparation on where the field is heading.

When Hamming helped a group of chemists run reaction simulations, he did not trust that they could type each set of equations into the machine correctly every time. Instead of drilling them on data entry (transient technique), he built a program that took one punched card per reaction — with all its interaction constants — and generated the equations themselves, guaranteeing all terms were present and coefficients matched across equations. The chemists then only selected the cards they wanted, and the machine handled the rest, including the integration step spacing. His stated aim was to keep their minds focused on what they were best able to do — chemistry — and not fuss with a machine they weren't expert in. Yet he pointedly refused to relieve them of the thinking; they remained in charge of the actual computing. The fundamental here is not the card format (a detail) but the principle: automate the mechanics, protect the judgment. That principle transfers to any simulation, whose reliability, Hamming warns, 'is not something you can take for granted just because a big machine gives out nicely printed sheets.'

• If a piece of knowledge is 'taught' — learnable, internalizable, performable with your own hands — then treat it as a fundamental worth mastering; if it's a hidden technique behind an interface, treat it as transient.
• If you can only see the trends jammed against your day-to-day work, then force a shift in viewpoint (zoom out to history, zoom in to first principles) — information is abundant, wisdom is rare.
• If a subject is genuinely an art (style, thinking), then don't expect to learn it in words alone; approach it from many sides, repeatedly, by attempting it yourself.
• If a technical choice is a detail rather than a fundamental feature — like multi-mode vs. single-mode fiber signaling — then don't burn effort resolving it; back the simpler option (as Hamming backed single mode, on the same grounds he backed binary) and move on.
• If a claimed improvement involves humans perceiving special care, then suspect the Hawthorne effect and demand controls before you believe the fundamental was actually responsible.

• Mistaking the illustrative material for the course. Tell: you can recite the technique but can't reconstruct how it was conceived, so a new context defeats you.
• Preparing for the teacher's past instead of the student's future. Tell: your curriculum reviews settled tools but never discusses where the field is going (Hamming centers on a future date for '20/20 foresight').
• Automating away the thinking, not just the mechanics. Tell: you accept a simulation's output because the machine printed nice colorful pictures, and you can't defend the decision as your own.
• Believing an educational or productivity 'improvement' at face value. Tell: like the PLATO advocate, you cite a 10% gain but can't say whether it's a one-time shift or compounds per course, and you did nothing about the Hawthorne effect.
• Getting lost in technical details that aren't fundamental. Tell: you're deep in detectors, emitters, and splicing arguments before establishing whether the feature is even a fundamental of the problem.

• ▸Subject under study: name the topic or lesson in one line.
• ▸Candidate fundamental: the principle that is taught, internalized, and performed by hand.
• ▸Illustrative material: the specific example/technique used only to demonstrate the fundamental.
• ▸Longevity check: will this still hold as the field changes, or is it a passing trend?
• ▸Range-of-scale note: one micro observation + one wide-shot / historical context.
• ▸Mechanics to automate: the bookkeeping you can offload without losing judgment.
• ▸Thinking to protect: the decision you must own and never delegate.
• ▸Future-target date: the horizon you're preparing for, not the past you were trained on.
• ▸Human-effect flag: does any claimed benefit here depend on perceived special care (Hawthorne)? yes/no + control needed.

1. 1Keep an open door literally: make yourself interruptible so colleagues bring you their problems instead of routing around you. Hamming did this deliberately as a mathematical consultant.
2. 2Take on other people's practical, mundane problems rather than begrudging them — treat them as your 'interaction with harsh reality' that keeps your head out of the clouds.
3. 3Lunch with anyone you can learn from or argue with. Choose the table by who will stretch or challenge you, not by comfort.
4. 4Storm in and out of colleagues' offices — pursue discussion actively across fields rather than waiting for ideas to arrive. Hamming did this with people in error-correcting codes, information theory, and filters.
5. 5Mine the problems people bring you for the general case: Hamming's celebrated inventions (error-correcting codes) grew directly out of solving specific problems for other people.
6. 6Study the lives and work of people outside your immediate task — Newton, Einstein, Shannon, Tukey — to import their style of thinking, not just their results.
7. 7Shift scale deliberately: examine the micro (why complex exponentials as basis functions) and then zoom out to place the problem in the broad landscape and long chain of history.

Hamming was employed essentially as an internal mathematical consultant, spending his days helping other people solve practical, mundane problems. Rather than resenting this service work, he framed it as necessary 'interaction with harsh reality.' Because his door stayed open and he lunched and argued with anyone he could learn from, a steady stream of real problems flowed to him. His error-correcting codes — one of his 'great' inventions — grew directly out of one of these problems he was solving for someone else. He also positioned himself socially near extraordinary people: sharing an office with Claude Shannon, eating lunch with Bardeen and Brattain, being bossed by Bethe and Bode, hanging out with Feynman. The receptivity and the proximity were not incidental to the great work; they were its source.

• If someone brings you a mundane practical problem, then take it — it is a candidate 'micro-Nobel Prize' and possibly the seed of a general result.
• If you can lunch with someone you'll either learn from or argue with, then choose them over an easy conversation.
• If an idea can be taught, learned, and performed with someone's own hands, then it is the kind of work worth aiming at — great achievements are gifts of knowledge to any open mind.
• If you find yourself myopic and jammed against passing trends, then deliberately zoom out to the historical and cross-field context to regain wisdom.
• If you're tempted to close your door to protect focus, then weigh what you lose: Hamming's inventions came through the open door, not despite it.

• Begrudging service work as beneath you — the tell: you route practical problems away and never notice they were the raw material of great work.
• Working in isolation because you believe great figures were lone geniuses — the tell: you admire heroes rather than intermingling with peers, ignoring that science is a fundamentally social enterprise.
• Confusing an open door with passive availability — the tell: you wait to be found instead of storming in and out of offices and actively seeking argument.
• Staying inside one field's myopia, so jammed against swaggering passing trends you can't see beneath them — the tell: information feels abundant but you produce no wisdom.
• Keeping your head in the clouds with no 'interaction with harsh reality' — the tell: your ideas never get corrected by a concrete, mundane problem someone actually has.

• ▸Who came / whom I sought: name and their field
• ▸Problem they brought: the specific, practical question
• ▸Harsh-reality check: how this grounds an idea I've been floating
• ▸General case: the broader result hiding inside this specific problem
• ▸Cross-field link: which other discipline or historical figure this connects to
• ▸Learn-or-argue value: what I gained by engaging (1 line)
• ▸Teachable form: could the outcome be taught to any open mind? y/n
• ▸Follow-up: office to storm into or lunch to schedule next

1. 1Block a fixed, recurring time — Hamming used Friday afternoons — and protect it from operational work like running the computing center. The point is deliberately stepping back from daily execution, not squeezing thought into gaps.
2. 2Aim the reflection above the task: think about future directions of your field, the underlying principles, and 'what do we want to do' rather than 'what can we do.' Ask the three questions — what future is possible, what human factors select the one future that happens, and what value judgments should shape it.
3. 3Identify the fundamentals of your field using two tests: it has lasted a long time, and the rest of the field can be derived from it by standard methods. Reflect on these because in your future the science and engineering you need will be created after you leave school, so you must actively master emerging fields on your own.
4. 4Base your projections on understanding the fundamental forces involved rather than on linear extrapolation of current rates. Remember human-made laws, habits, egos, and organizational inertia often dominate the evolution to the future more than physical limits.
5. 5After any discovery or event of great or small importance, go back and trace the steps by which it apparently happened — but do this afterward, not during the work itself, the way athletes practice style until it is automatic rather than thinking about it mid-play.
6. 6Habitually review your past successes so the style becomes automatic; Hamming did this on his morning ride through north Jersey, using the absence of distraction to keep turning a problem over.
7. 7Write the reflection down as a personal story, including your spectacular failures as examples of what to avoid — the personal account is far more effective than the impersonal survey.

Riding the company mail car from Murray Hill to New York City through the plain north Jersey scenery, Hamming had nothing to look at, so he did what he habitually did: reviewed his successes to keep the style in hand. He was turning over his rectangular error-correcting codes when, for no reason he could give, he realized a triangle with parity checks along the diagonal gave a more favorable redundancy. His smugness vanished — was it the best? A few miles later he saw a cube of information bits with parity planes worked better; then a four-dimensional cube; then, within about five miles, a 2×2×...×2 cube with n+1 parity checks seemed best. Having burnt his fingers before by settling for what merely looked good, he refused to stop at 'apparently' and pushed to prove it. The reflective habit — reviewing successes in undistracted time — is what surfaced each successive improvement.

• If you are choosing what to treat as fundamental, then keep only what has lasted a long time and from which the rest of the field can be derived by standard methods.
• If a prediction rests only on extrapolating current rates of change, then distrust it for the long term and re-anchor it on the fundamental forces involved.
• If you are inside the act of research or discovery, then do not analyze your own process; trace the steps only afterward, like practicing style outside the game.
• If something 'looks good' or 'apparently best,' then treat that as a warning to push for proof, because settling for what looks good is a repeatable mistake.
• If a topic falls between your organized courses or departments, then deliberately reflect on it, since optimization by department conceals the homogeneity of knowledge and skips what matters in practice.

• Letting daily operations consume the reflection time — Hamming had to learn while developing and running a computing center, and problems that 'seem to overwhelm you' crowd out the great thoughts. Tell: your calendar has no protected block and you only think big when nothing is due.
• Reflecting only on successes and forgetting the failures. Tell: your account has an aura of bragging with no spectacular failures recorded as examples of what to avoid.
• Predicting by linear extrapolation and missing geometric growth. Tell: your long-term forecasts run pessimistic because compounding is hard to grasp, or optimistic in the short term.
• Mistaking accumulated experience for improvement. Tell: you assume years of programming or writing reports made you better, when habitual 'governmentese' may have made you worse.
• Stopping at 'apparently best.' Tell: you accept the first elegant answer without asking whether it can be proven, repeating a mistake you've already been burnt by.

• ▸Protected time block: name the fixed recurring hours you will guard from operational work.
• ▸Field's future direction: where is this field heading over the next years, based on fundamental forces (not current rates)?
• ▸Fundamental under review: state one principle that has lasted long and from which the rest derives.
• ▸Success traced: pick one recent success and write the apparent steps by which it happened.
• ▸Failure logged: one recent failure and the avoidable lesson it teaches.
• ▸'What do we want to do?': the choice/value question behind current work, distinct from 'what can we do.'
• ▸Between-the-courses topic: one relevant thing that falls outside your usual categories.
• ▸'Looks good' check: name any answer you're tempted to accept, and the proof still owed.
• ▸Prediction basis: state which fundamental force (not extrapolation) supports your outlook.