Tag Archives: Learning

Think First, AI Second

Here’s a cool new study on learning using AI:

Think First, ChatGPT Later: Guiding Human–AI Collaboration for Learning Gains in Independent Human Creativity (April 2026)

The authors, Sarah Shi Hui Wong and Sophia Xuefei Qiu, ran a simple experiment with 196 university students and published the paper earlier this year in Educational Psychology Review. What struck me about the study was that the results seemed so obvious. I must be missing something. But maybe I came to that same conclusion after using various AI tools and just figured out on my own what they do best and what they don’t do very well at all. For me, I found that if I engaged the AI with something already in mind I was far more productive and the experience was more satisfying, whereas if I just randomly poked around with the AI with an empty mind then we both just ended up running around in circles and I learned nothing.

From the abstract:

“Thinking of one’s own ideas first, then collaborating with ChatGPT to improve them, promotes learning gains in independent human creativity.”

And with that, I knew I was on the right track and read the rest of the paper.

Wong and Qiu are researchers working in cognitive and educational psychology, and their study draws heavily on the memory and learning research that those fields have built up over the past several decades. The tradition also traces back to people like Robert Bjork, whose PhD is in mathematical psychology, and other researchers studying how the human brain encodes and retrieves information. These questions predate generative AI, but now they can be studied in the context of AI to explore new possibilities to use the technology. The findings of the ChatGPT study support my own experience since I’ve been using AI specifically for learning from the beginning. It’s the best teaching tutor I’ve ever had by far. The possibilities for education are endless. I wish I had these tools when I was a kid in school.

Here’s what they did with ChatGPT, but it works with any chat-based AI tool. They split students into three groups. The first group solved a creative task alone. The second group used ChatGPT however they liked. The third group followed what the authors called a “think first, ChatGPT later” method. So that third group of students had to think of their own ideas first and then iterate with the AI to improve those ideas. And then they’d submit a final answer on their own like the other groups.

On the first task, the group that used ChatGPT freely did the best. And if you’ve used AI at all, it should be obvious that the first group came out ahead initially. They seemed more productive. But they outsourced their own thinking entirely. Why does that matter? Well, from a longer term learning perspective, this is where it gets most interesting when you look more carefully.

Next, all three groups did a second and harder creative task with no AI access at all. At that point, the free-use group’s advantage vanished. Their scores dropped back to the level of students who never touched AI. But the guided group using AI was different. They hadn’t looked especially strong on the first task, but on the second task working alone they ended up beating the other groups. The researchers then read the chat transcripts and found a possible reason. Students using ChatGPT freely mostly just asked it for external ideas outright, just like I did when I was aimlessly messing around with AI. The guided group, however, mostly brought their own ideas to the chat conversation and asked ChatGPT to push on them. In other words, they iterated. That difference in human behavior, not the AI itself, predicted who actually learned something that resonated over time.

So why is this important? Use AI to help you learn! Simple. And we now have some data in a controlled study to substantiate that AI is a useful tool for learning beyond just anecdotal experience. Sure, AI can make you more productive really quickly, and I use it for that purpose all the time. But to actually leverage the tool it makes more sense to go in with a plan in mind so you can be both more productive and learn something valuable in the process. Then you can take what you’ve learned to focus your prompts to the AI so that you can move even more deeply into the subject. Again, this process is obvious if you’ve spent any time poking around with AI.

Others have also discovered this phenomenon as well. Tamara Tate published a piece called Think First: Why the First Idea Shouldn’t Come from AI in March 2026 before the ChatGPT study, and she made a similar argument about generative AI and writing.

As I read both pieces I found the concepts familiar because they reminded me of a book on learning I read years ago: Make It Stick: The Science of Successful Learning. Make it Stick is probably the best book on leaning I’ve ever read. Every page is pure gold for people who are motivated to learn on their own. The book is based on the same body of cognitive psychology research as the ChatGPT study, particularly the work of Robert and Elizabeth Bjork on what they called “desirable difficulties.” Wong and Qiu cite that same research to help explain why the AI guided group may have performed weaker initially but excelled later. The key is that the students were doing more work up front. Attempting retrieval on your own (thinking first) before instruction beats instruction alone followed by retrieval (testing) afterwards. That’s not a new idea. It’s just being tested on a chatbot now. We now have a new tool at our fingertips to implement an old principle.

Aside from going into an AI conversation with at least a rough plan up front, it also makes sense to spend some significant time iterating with the AI at length. The ChatGPT study only covered a 12 minute timeframe before answers were submitted. But try going longer. I can talk to the damn thing for hours just going back and forth asking and answering questions, brainstorming ideas, taking quizzes, working thorough tutorials, and anything else I can think of. I tend to have hand-written notes to the side, though, to track things that are important and need more probing. I learned this from an engineering manager I worked for at Sun in Solaris engineering where I observed her managing meetings of engineers. She asked one question after another until they solved the problem. I was surprised how deep she could go to get the engineers to think differently about the issue. She always had another question to ask, which led to additional questions the engineers would ask each each other as well. Those meeting sessions would also often lead to further conversations on the team’s mailing list. It works. And AI has infinite patience for this iteration. I guess Socrates was right.

Here’s the final sentence in the ChatGPT study:

“Generative AI is not to be a substitute for human creativity but, when strategically harnessed, a powerful tool for enhancing it.”

Makes sense to me. Working it every day.

AI’s Perpetual Present

I’ve been reading “Why We Need Continual Learning: The Memento and the Machine” by Malika Aubakirova and Matt Bornstein recently. I also listened to a podcast interview from Malika on a16z . Now, I’m no AI researcher or developer. But I do like exploring the scientific foundations on which advanced software tools are built, especially since I use these applications every day and hope to leverage them more in the future. I’m not afraid of AI, and I don’t believe any of the dumb doom slop about AI either.

So although I don’t fully understand what’s actually happening underneath the user interface, poking around a bit is an interesting exercise. What follows below is what I’ve learned from the article. Consider it a work in progress. If you want the expert version from Malika and Matt, go read their original piece for a deep dive and follow them on social media. This text here is just me working through things as best as I can at my level. At the end of this post, I include a long list of terms and definitions. I’ll make that a standard feature in similar upcoming posts for my own short-term recall practice and also for long term memory consolidation. Memory practice (the human kind) is a hobby of mine.

Anyway, here we go. The authors open their article on continual learning by referring back to Christopher Nolan’s “Memento,” which is a film about a man named Leonard Shelby who suffers from anterograde amnesia that prevents him from forming new memories. Every few minutes his world resets and he wakes up in the same perpetual present with no idea what just happened in the past. He tattoos notes on his body and carries Polaroids as memory aids just to function throughout the day. It turns out that he’s very resourceful because he uses whatever he can in his environment to get by. He even appears pretty capable within any given scene in the movie. But, as the authors put it, his tragedy is that “he can never compound. Every experience remains external.” So, I guess that means he can’t learn based on his present moment to prepare for the future like most of us who have normal human memories.

That seems to be a good general description of where AI models are right now. Back before I knew about this issue, I actually inadvertently tripped over it when I first used ChatGPT and Grok a few years ago. It was clear from my chats at the time that the models were not “learning” from our conversations at all. I kept spinning around in circles explaining myself over and over again. And, in fact, some of those earlier models didn’t know even basic facts from current events, which was surprising since AI was sold to us as being so super smart. That’s when I realized that the “learning” for LLMs took place at some point in the past and then they were locked shut while life continued on. That experience of an AI not knowing simple bits in the news rarely happens now so the user experience has improved significantly. However, there’s a lot more to it that I didn’t realize from those first few frustrating conversations.

What Actually Happens When You Type Into That Text Box

When you type some text into an AI chat window the frontend application sends the message to the backend LLM, which sends back a response. That’s it. There’s no learning from the exchange. When the conversation ends, the model does not carry that conversation forward in its memory. The next conversation starts from exactly the same place as every other new conversation. Initially, that felt unnerving so I had to figure out ways to leverage the knowledge from the LLM without all that forgetting going on.

The text box we type into is just a door into the system. What matters is the context window behind the door, which is everything the model can see at once in real time. So, your message, the whole conversation history, any documents you shared, and any background instructions — all of these things represent what the model is working with when it responds. And it has a size limit. When it fills up, older content gets dropped to make room for new content. So if you spend an hour explaining your company’s internal processes to an AI bot and then start a fresh conversation the next day in a new text box, the AI has no memory of the previous conversation. You have to start over.

There’s a name for this phenomenon. The article calls it in-context learning, which is really just the model making smart use of whatever sits in front of it right now. It’s temporary by design. The model reads, responds, and moves on. It’s similar to glancing at your notes before a meeting rather than actually deeply studying, internalizing, and using the material beforehand. When the meeting ends, those casual notes go back in the drawer and are forgotten.

The Frozen Model Problem

To understand why this matters, you need to know a little about what’s inside these models. During training, a model reads an insane amount of text from the Internet and gradually adjusts billions of numerical values called parameters or weights. You can think of each weight as a dial on a pipe connecting two nodes in the network controlling how much signal flows through. The model trains by turning billions of those dials very slightly over and over again until it gets good at predicting language. That bit right there is really impressive to me given the scale of information these models are working with. But when the training process ends all those dials get locked. That stage represents deployment. The model then goes out into the world with its knowledge frozen in place.

Training works because it’s a compression process. The model can’t store everything it reads verbatim. It has to find the underlying patterns, generalize the data, and build something compact that transfers to new situations it’s never seen before. The authors describe this as lossy compression, and that lossiness is actually what produces what seems like intelligence to us when we talk to an AI. When I first read that I thought of a camera compressing a RAW file to a JPEG file. In photography, a RAW image contains all the available data but it’s a massive size and requires editing in post production to produce a beautiful image. The JPEG, however, is much smaller because it’s been compressed by the camera to just what’s needed to display a good quality image at a certain specified size. I’ve always understood that process in photo imaging, but I didn’t realize that LLMs are going through a similar process.

Here’s another way to think about it. Remember when you first learned how to ride a bike? You didn’t read the entire manual every time. You just got some guidance from a friend or a parent and you practiced. You fell down a few times and adjusted your technique, and then eventually your brain distilled your experience into something automatic and compact. That’s compression in computer terms. You still remember falling down, but that falling down process is no longer helpful for riding once learning has taken place. What remains is the final skill of balancing so you can ride. An AI model that memorizes every training sentence perfectly wouldn’t be that useful to us because although it could retrieve it can’t generalize. It would behave more like a simple retrieval system than a sophisticated learner. So, the AI still has a long way to go before getting to human learning capabilities.

The painful irony the authors identify is this. The very mechanism that makes these models powerful during training is exactly what we stop them from doing once they’ve been deployed. We freeze the compression at the moment of release and replace it with what’s called external memory. That clarified the argument for me. The system is layered, and each layer is essentially a workaround for the fact that the compression stopped. Understanding that made the next part of the article click.

The Filing Cabinet

To compensate for frozen models, developers have built elaborate scaffolding systems, such as chat histories, retrieval databases, system prompts, external document stores, and more. All of these things make up what the article calls external memory. Those systems, unlike the LLMs, are flexible and they live outside the model’s internal, frozen weights. When you need information, the system retrieves it and feeds it into the context window. Then the model reads it and responds.

This architecture works as is and the authors are honest about that. However, they make a point I hadn’t considered before. “A bigger filing cabinet is still a filing cabinet.” Retrieval is not learning. The model is looking things up, not actually knowing them or learning from the retrieval process. It just does it very quickly and uses natural language so we get the impression we’re are talking to someone who is intelligent. Note that the term retrieval used here is opposite to how it’s used when considering human memory. With people, the act of retrieving something from your memory is very much involved in learning. The more you retrieve a memory, the more you know it. In fact, it’s a core part of memory training for people. Computers don’t work that way, though.

Here’s another practical example. Say a hospital deploys an AI assistant to help with real world clinical decisions. That model was trained on medical literature through some cutoff date. Then a major new clinical trial or medical policy comes out afterward that changes how doctors treat a particular condition. The hospital can then feed that paper into a retrieval database so the AI can surface it when it’s relevant. But the model doesn’t internalize that new research the way doctors would after reading it, learning it, applying it to patients, observing the outcomes, and revising their practice accordingly. The AI can just retrieve the content. But it can’t reason from the new finding the way someone who has truly learned it can in practice. That’s the limitation these researchers are trying to fix.

The same problem exists in cybersecurity with threats evolving constantly. A frozen model can be given descriptions of new attack patterns through retrieval, but it can’t compress and generalize from those patterns the way an analyst does who has spent months chasing a specific class of threat. The knowledge stays external. It never becomes part of what the model actually knows unless the model is updated with a new learning process, which is time consuming and insanely expensive.

What Real Learning Requires

So what’s the alternative? The article introduces a concept called continual learning, which is the field of research aimed at letting models actually update their weights based on new experiences after deployment. Not just reading external notes. Actually learning live like humans do.

And here’s where the Memento metaphor really makes sense. The authors say that today’s AI is stuck in Leonard Shelby’s perpetual present. The scaffolding, the Polaroids and tattoos, and other memory aids work well enough within any given scene. But the model can never compound in real time. Every new thing it encounters stays external.

Think about the difference between a doctor who simply retrieves a recent study and a doctor who has spent years treating patients with that knowledge fully and personally internalized. Or consider the difference between someone who has your email history in front of them and someone who actually knows how you think over time. The article frames this cleanly. “The difference between ‘Here is what you responded to this email before’ versus ‘I understand how you think well enough to anticipate what you need’ is the difference between retrieval and learning.” Even in normal human memory, immediate retrieval is necessary to manage your present experience. However, it’s also required that your present experience be embedded into long term memory for continual learning.

The authors bring up Fermat’s Last Theorem as one powerful example of the kind of hard discovery problem they have in mind. Mathematicians worked on the issue for 350 years. Eventually the problem was solved by Andrew Wiles. But he didn’t crack it by retrieving the right papers like an LLM. He solved it by working in near total isolation for seven years and inventing entirely new mathematical techniques to bridge two previously disconnected fields. That kind of discovery required genuine compression, generalization, and creative combination — all processes humans do well. Jet fast retrieval may be impressive, but it’s not close to the comprehensive compounding process the human brain does by nature. And the article asks directly whether a model that can’t compound from experience could ever do anything like that in the future. The honest answer is they don’t know yet.

Why Updating Weights is so Hard

At this point I had to ask myself if real time continual learning is so important, why can’t the LLM models do it now? The short answer is that updating a model’s weights after deployment is genuinely dangerous and technically unsolved at scale at present.

The most obvious problem is called catastrophic forgetting. When you update a model’s weights to learn something new, it tends to overwrite what it already knew. New learning crowds out old learning. If you fine tune a general model specifically on medical records, it might get better at clinical language while getting noticeably worse at everything else because the new training has nudged weights that were also doing other jobs. The model gets better at one thing and potentially worse at everything it was already good at. When you understand this you can really appreciate how humans have benefited from millions of years of painful evolution. The AI machines seem rather clunky by comparison, don’t they? When humans learn, new neural connections are made in the brain that stick for a long time as new learning is layered on top. But even in humans, old learning and memory does actually fade gradually over time if a specific neural pathway isn’t continually or at least occasionally reinforced by retrieval and use. It just takes a very long period of time. With AI systems, however, new learning can wipe out old learning completely and immediately. The authors didn’t address this issue directly in humans, but the example seems similar enough to me when you study biology and cognitive science.

There’s also the problem of data poisoning. If a model’s weights can be updated through interactions after deployment, bad actors could gradually manipulate its behavior through carefully crafted inputs over time. Unlike a one-time attack, poisoned weights persist across every future conversation. The damage would live in the model itself so safety alignment would degrade unpredictably and immediately or some unknown time in the future. The article notes that “even narrow fine-tuning on benign data can produce broadly misaligned behavior,” which is a sobering thought to sit with. Yet we all know this would happen right away based on our own experience being online every day fighting bots and hackers.

These aren’t hypothetical concerns. They’re real problems without clean technical solutions yet.

Where Things Are Heading

The article maps out several approaches to continual learning that are organized around a question I found clarifying — where does the compaction actually happen? It seems that there’s a stack of technologies managing the process right now.

On one end you have pure retrieval, which is no compaction. The model just reads notes. That’s most of what exists today. In the middle there are modules, which are attachable and specialized components that let a model develop some expertise in a specific domain without retraining the entire LLM from scratch. A hospital might attach a medical module to a general model so it performs at a specialist level on clinical questions, while the same base model with a different module handles legal contracts. Each module is swappable independently. That’s a practical and reasonable middle ground for now.

On the far end you have full parametric learning, where the model’s weights actually update from new experience after deployment. That’s the goal. But it remains largely unsolved at scale with the current technologies. But there are serious research efforts moving in this direction with things like test-time training where the model runs brief learning cycles before it generates a response. Also there are self-improvement approaches where models like AlphaEvolve have generated their own training data and genuinely improved from it, at least within constrained problem domains like mathematics.

The authors frame the path forward as layered, which is common throughout the entire software industry. In-context learning represents the first line of adaptation because it works now and keeps getting better. Modules offer some personalization and domain specialization. But for genuinely novel problems, adversarial scenarios, and knowledge too tacit to put into words, models may eventually need to compress new experience directly into their parameters after training. Otherwise, as the authors put it, we stay stuck in Memento’s perpetual present.

What I Took Away

I started reading this article as someone who uses AI tools every day without really thinking much about what’s happening underneath. What I came away with is a better sense of the gap between what these systems appear to do, what they’re actually doing, and what they’ll potentially do in the future. Right now they can respond to new information and adapt to what you give them really fast. And most times they feel like they understand us. But the reality is that they don’t compound. They don’t learn. They don’t internalize new experience the way continual learning systems or humans would. Their dials are locked. And until engineers figure out how to update those dials safely and continuously after deployment, the models we’re using now are doing something more like reading notes than actually learning from the experience. That’s a distinction with a very big difference.

Check out the original article and Malika’s podcast for the technical details. Below is a list of related terms and definitions.


Continual Learning: Vocabulary List

This list of terms below is based on the a16z article “Why We Need Continual Learning” by Malika Aubakirova and Matt Bornstein and also the podcast with Malika discussing the article. Some definitions closely reflect the article itself, but others expand into broader concepts from the field for additional context. I error checked the terms and definitions with Grok, ChatGPT, Gemini, Perplexity, and DeepSeek. They mostly agree. The list isn’t complete, though, because with AI things change pretty much weekly at this point.

Agentic Loops

A mode of operation where the model works autonomously step by step toward a goal without you typing each instruction. Each step produces output that feeds into the next. This process can go on for many cycles. The article identifies two related problems as steps accumulate: (1) the immediate symptom is coherence degradation, where the agent loses the thread and starts making poor decisions, and (2) the underlying cause is that maintaining a growing context becomes increasingly expensive and inefficient. Both concerns together represent why the article frames agentic loops as one of the pressure points on the current in-context learning paradigm. For example, an agent tasked with researching a topic, drafting a report, checking sources, and revising the draft might handle the first twenty steps cleanly. But by step eighty the accumulating context has grown so large and costly that the agent starts losing track of earlier decisions and repeating work it already did.

Attention Heads

A key mechanism inside transformers that allows the model to weigh how relevant each part of the context is to every other part when generating a response. Multiple attention heads run in parallel with each one learning to focus on different kinds of relationships in the text. One head might learn to track grammatical agreement between subject and verb across a long sentence, while another tracks thematic connections between paragraphs. Together they allow transformers to handle complex, long range dependencies in language that earlier architectures struggled with. For example, in the sentence “The lawyer who argued the case, despite the objections raised by her colleagues, ultimately won,” an attention head helps the model correctly connect “won” back to “lawyer” across all the intervening words. Hopefully, the LLM would suggest a better sentence entirely because putting the main verb at the end like that is crap English.

Catastrophic Forgetting

When a model updates its weights to learn something new, it tends to overwrite what it already knew. In other words, new learning crowds out old learning and sometimes dramatically. This is one of the central unsolved problems in continual learning, and it’s one of the main reasons models are not updated continuously after deployment. Think of it somewhat like overwriting parts of a hard drive. The new files go in, but the old ones can be partially or fully lost. For example, if you fine-tune a general purpose model specifically on a medical records archive, the model will get better at clinical language but noticeably worse at writing poetry or explaining history because the new training has nudged weights that were doing other jobs.

Compression / Compaction

The process of taking a vast amount of raw information and distilling it into something compact and generalized. During training, a model compresses an enormous amount of human writing into its parameters and finds the underlying patterns rather than storing things verbatim. The article uses “compaction” as a broad organizing term for how deeply new information gets digested, which ranges from not at all (pure retrieval, where facts just sit in a database) to fully (weight-level learning, where the model actually internalizes new knowledge). For example, rather than memorizing every recipe ever written, a well-trained model compresses the underlying logic of cooking: how heat transforms food, how flavors balance, how techniques generalize across different cuisines.

Continual Learning

The broader field of research aimed at letting models learn from new experience after deployment, ideally by updating their weights rather than relying on external software systems. It’s the opposite of the current norm, where training and deployment are completely separate and weights are frozen the moment a model is released. The goal is something closer to how humans learn continuously from experience without needing to be retrained from scratch every time the world changes. For example, a customer service model using continual learning could gradually internalize patterns from thousands of resolved support tickets over time and get genuinely better at its job rather than just retrieving past examples.

Context Window

The full body of text the model can see at once when generating a response. It includes your message, the full conversation history, any documents you shared, and any background instructions passed to the model. It has a size limit measured in tokens. When it fills up, older content must be dropped to make space for new content. For example, if you have a long conversation with an AI assistant and then ask it to recall something you mentioned earlier, it may not be able to answer because that part of the conversation has already been pushed out of the window.

Data Poisoning

One of several serious governance and security risks the article raises around continuous weight updates. If a model’s weights can be updated after deployment interactions, bad actors could gradually manipulate its behavior through carefully crafted inputs over time, which is a slow and hard-to-detect form of corruption that lives in the weights rather than just in the context. Unlike a one-time prompt injection attack, poisoned weights persist across every future conversation. The article groups this alongside other unsolved challenges: alignment degradation, the impossibility of unlearning toxic knowledge, auditability failures, and privacy risks from user interactions being compressed into parameters. For example, an adversary could repeatedly feed a customer-facing AI subtly misleading information about a competitor’s product until the model begins reproducing those inaccuracies on its own with no obvious sign of tampering.

Distillation

A process involving two models: (1) a large, capable, frozen teacher and (2) a smaller student. The student is trained to match the teacher’s outputs as closely as possible and absorb its knowledge in a more compact form. The result is a smaller, more efficient model that performs nearly as well as the larger model on the tasks it was trained for. It’s like an apprentice learning by closely watching and mimicking a master until the skill becomes their own. For example, a large hospital system might use a massive general-purpose model as the teacher and distill its medical reasoning capabilities into a smaller model that can run efficiently on local hospital hardware without requiring an expensive cloud connection.

External Memory

Anything outside the model’s weights used to store and retrieve information. Chat history, databases, document stores, and agent notes are all examples of external memory. Information gets fed back into the context window when necessary. In current deployment architectures, the model typically does not update its weights from that information during inference. The key limitation is that external memory requires retrieval. The model has to be given the right information at the right moment, and if it isn’t, the knowledge may as well not exist. For example, a legal AI might have a database of ten thousand case summaries it can search, but if the retrieval system surfaces the wrong cases, the model has no way to compensate from its own knowledge.

Few-Shot Learning

The ability of a model to perform well on a new task after seeing only a handful of examples, rather than requiring thousands of training samples. Transformers are surprisingly good at this when examples are provided in the context window. Meta-learning approaches aim to make weight-level, few-shot learning just as effective, so the model can internalize new tasks from just a few examples even without them being available in the context. For example, if you show a model three examples of how you want your emails formatted and then ask it to format a fourth, it adapts immediately without any retraining.

Fine-Tuning

A more targeted form of additional training done after the initial training run. Instead of training from scratch on everything that’s known, you take an already-trained model and update it on a smaller or specific dataset. The new information shapes the model’s behavior for a particular use case without rebuilding it from the ground up, but the process still risks catastrophic forgetting if pushed too hard. For example, a company might take a general-purpose language model and fine-tune it on thousands of their internal support conversations, so the model learns the company’s terminology, tone, and common issue patterns without losing its broader language capabilities.

Gradient Descent

The mathematical process by which a model adjusts its weights during training. It measures how wrong the model’s predictions are on a given example and then calculates which direction to nudge each weight to reduce that error slightly. It’s called “descent” because the process is navigating downhill on a mathematical landscape, always moving toward lower error rates. Repeat this across billions of examples and the model gradually gets better. For example, if the model predicts “cat” when the correct answer is “dog,” gradient descent works backward through the network to figure out which weights contributed to that wrong answer and adjusts them a tiny amount. Do that enough times and the model learns to tell cats from dogs reliably.

In-Context Learning (ICL)

Everything the model reads and uses during a single conversation without updating its underlying knowledge. You paste in a document, the model reads it and responds. You describe a task, it follows your instructions. But when the conversation ends, none of that experience changes the model itself. The next conversation starts with the same frozen weights as always. This is a smart use of temporary information, but it’s not genuine learning at all. For example, if you spend an hour teaching an AI assistant about your company’s internal processes and then start a new conversation the next day, the model will have no memory of the previous conversation. You would need to paste in that information all over again.

Inference

The act of a model generating a response from input. It’s the opposite of training. Training occurs when the model learns by adjusting its weights. Inference occurs when the frozen model performs and takes what it knows and produces an output. Any time you send a message and get a reply, that’s inference. The term “inference-time compute” (below) builds on this and refers specifically to spending extra computational effort during inference to get a better result. But plain inference just means the model is running, not learning. For example, asking a model what the capital of France is and getting back “Paris” in a fraction of a second is inference in its simplest form. No learning took place. The model generated an output from its existing weights without updating them.

Inference-Time Compute

The current dominant paradigm for improving model performance by spending more computational effort at the moment of response rather than updating weights. This includes chain-of-thought reasoning, tool use, search, and iterative problem-solving, all of which cost more compute at response time but produce better results. The article positions this process as a workaround or a scaling of what already works rather than a true solution to the learning problem. Test-time training is the most aggressive form of this learning because it actually runs gradient updates on new information during inference, which begins to compress it into weights in real time. This process runs at the boundary between the current paradigm and genuine parametric learning. For example, when you ask a model a complex math problem and it works through each step before giving a final answer rather than just guessing immediately, that is inference-time compute. The model is using more processing in the moment to arrive at a better result.

Instruction Tuning

A form of fine-tuning where the model is trained specifically on examples of instructions paired with ideal responses. It’s one of the main reasons modern models are so much better at following directions than earlier versions, which tended to just complete text rather than actually do what you asked. The model learns not just facts but the shape of helpful behavior, including how to interpret requests, how to structure answers, and when to ask for clarification. For example, an early language model asked to “summarize this article” might just continue writing in the same style as the article. An instruction-tuned model understands that the request calls for a concise, distinct summary and produces one.

KV Cache

Short for key-value cache, which is a technical mechanism that stores intermediate computations during inference so the model does not have to redo them from scratch for every token it generates. The article discusses this specifically in the context of KV cache compaction where the cache functions as a form of non-parametric memory but grows substantially as conversations and agent loops get longer. The authors argue that learning to compress this cache more efficiently is one of the meaningful challenges in moving from pure retrieval toward more durable knowledge storage. For example, in a long agentic task, the KV cache holds the computed representations of everything the model has processed so far. Without it, each new token would require reprocessing the entire history from scratch, which would be prohibitively slow.

Lossy Compression

Compression where some information is permanently lost in the process, as opposed to lossless compression where everything can be recovered exactly. For LLMs, the inability to store everything verbatim during training forces the model to find patterns, generalize, and abstract. That forced abstraction is precisely what makes the model seem intelligent and useful in new situations it has never seen before. A JPEG image is the familiar everyday example. Save a photo as a JPEG and the file shrinks dramatically because fine detail is discarded. But if you zoom in close enough you can see the degradation. For most purposes, though, the image is perfectly usable. The tradeoff is the point. For a language model, the equivalent is that it cannot recite every sentence it ever trained on, but it can write a new sentence in any style on any topic because it extracted the underlying structure rather than memorizing the surface.

Meta-Learning

Teaching a model how to learn rather than what to learn. The model is pre-trained in a way that positions it to update quickly and effectively with just a few new examples, rather than requiring extensive retraining. It’s the difference between educating someone to be a quick study versus simply giving them a lot of facts to memorize. A quick study can walk into an unfamiliar subject and get up to speed fast, whereas someone who only memorized facts cannot. For example, a meta-learned model shown three examples of a new classification task, say sorting customer complaints into categories it has never seen before, should be able to generalize accurately to new complaints after just those three examples rather than needing hundreds.

Modules

The article uses this as a broad middle-ground category on the compaction spectrum placed between pure retrieval and full weight-level learning. In practice, modules can take several forms: adapter layers, LoRA-style weight updates, memory components, or cached representations. What they share is the ability to specialize a general-purpose model for a specific domain without retraining the entire model from scratch. They offer more than retrieval in that some digestion of information happens but less than full parametric learning in that the core model is typically left unchanged. For example, a hospital might attach a medical module to a general-purpose model so it performs at a specialist level on clinical questions, while the same base model with a legal module performs at a specialist level on contract review, with each module being swappable independently.

Multi-Agent Architectures

Systems where multiple AI models work in parallel with each one handling a slice of a larger task and communicating results to each other or to an orchestrating layer. If a single model is limited by its context window, a coordinated group of agents can collectively handle far more. But this shifts the problem rather than eliminating it. Each agent still faces its own context limit, and coordinating many smaller contexts introduces its own complexity for the system to manage. It’s a non-parametric workaround for scale, not a solution to the underlying constraint. For example, a research task that would overflow one model’s context window might be split across ten agents, each reading a different section of source material with a coordinating agent assembling their summaries into a final report.

Neural Network

The underlying computational structure of an LLM. It’s a network of interconnected nodes organized in layers, loosely inspired by neurons in the human brain. But the analogy should not be pushed too far. Each connection between nodes has a weight that determines how strongly one node influences another. During inference, information flows forward through the layers, gets transformed at each step, and eventually produces an output. The network learns by adjusting those weights during training until it gets good at its task. For example, in an image recognition network, early layers might learn to detect simple edges and colors, middle layers might learn to recognize shapes, and later layers might learn to identify objects. Language models work on the same principle but applied to sequences of text.

Parameters / Weights

The billions of numerical values inside a model that encode everything it learned during training. Each value represents the strength of a connection between two nodes in the neural network. During training, these values get adjusted gradually until the model becomes good at predicting language. After training they get frozen, and the model’s knowledge and capabilities are entirely determined by those fixed numbers. “Parameters” and “weights” refer to the same thing and are used interchangeably throughout the article. For example, large frontier models contain billions or even trillions of parameters. Each one is a small dial that was tuned during training and now stays locked in place, collectively encoding an enormous amount of compressed knowledge about language, facts, and reasoning patterns.

Parametric Learning

Learning that actually updates the model’s weights based on new experiences, as opposed to in-context learning that uses information temporarily without changing anything permanent. It’s the deeper form of learning the article is ultimately arguing we need more of. When a model learns parametrically, new knowledge gets compressed into its weights the same way training data did and becomes a durable part of what it knows rather than a note it holds briefly and then discards. For example, a parametric update after a model encounters thousands of conversations about a new programming language would leave it genuinely better at that language going forward across all future conversations, not just within the session where it learned.

Regularization

A cautious approach to weight updates that penalizes changes to parameters deemed important to existing knowledge. Before updating a weight, the system estimates how critical that weight is to the model’s current capabilities. If it’s very important, the update is constrained or slowed down. This is one of the older approaches to continual learning and helps manage the stability-plasticity dilemma. But it tends to be brittle at scale. Think of it like a renovation rule that protects load-bearing walls in construction. You can still remodel, but certain structures are off-limits because removing them would collapse the building. For example, EWC (Elastic Weight Consolidation), one of the most cited regularization methods, computes an importance score for each weight after training on a task and uses that score to resist changes when training on subsequent tasks.

Reinforcement Learning (RL)

A training approach where a model learns from feedback signals rather than from labeled examples. It tries things, receives a reward or penalty based on how well it did, and adjusts its behavior accordingly over many iterations. The article mentions RL-based feedback loops as one direction in continual learning research where models could improve from real-world deployment signals like user corrections or task outcomes. However, it’s not the central mechanism the authors emphasize. The core focus of the article is on compaction, weight updates, and memory structures. For example, the systems that learned to play chess and Go at superhuman levels used reinforcement learning by playing millions of games against themselves and adjusting strategies based on wins and losses rather than being taught explicit strategies.

Retrieval-Augmented Generation (RAG)

A common approach to giving models access to current or specialized information without retraining. Instead of baking knowledge into weights, you build a searchable database the model can query at response time. The retrieved content gets injected into the context window and the model uses it to generate its answer. It’s purely non-parametric. The model retrieves information but never internalizes it. The limitation is that retrieval only works if the right information gets surfaced at the right time, and no amount of retrieval can substitute for knowledge the model needs to reason with flexibly. For example, a financial AI might use RAG to pull in the latest earnings reports before answering questions about a company’s performance because that information changes constantly and cannot be baked into training data.

Safety Alignment

The work done during training to make a model helpful, honest, and safe to use. It involves carefully curated training data, human feedback on model outputs, and specific training objectives designed to shape the model’s values and behavior. One of the serious risks of continuous weight updates after deployment is that alignment can degrade unpredictably even from adding seemingly benign new data. It seems that fine-tuning on almost anything can shift the weights that govern behavior, not just the ones governing the specific knowledge update. For example, researchers have shown that even brief fine-tuning on ordinary instructional text can weaken safety guardrails in ways that are not obvious until the model is probed specifically for harmful outputs.

Self-Improvement

An approach where the model generates its own training data, filters out low-quality results, trains on the high-quality results, and repeats the cycle. It learns from its own work rather than from human-provided data and can improve capability over repeated iterations in constrained settings. The article cites AlphaEvolve and AlphaProof as examples of this kind of closed-loop improvement. But these systems operate in constrained domains like mathematics and algorithm optimization, not open-ended real-world learning. The article uses these examples to illustrate iterative self-training loops, and what qualifies as a genuinely new discovery in this context remains debated. For example, AlphaEvolve used self-generated solutions and automated evaluation to discover improvements to algorithms that human programmers could not find because it worked within a well-defined problem space where correctness could be verified automatically.

Stability-Plasticity Dilemma

The fundamental tension in any learning system between staying stable, meaning not forgetting what it already knows, and staying plastic, meaning remaining able to learn new things. Push too hard toward plasticity and you get catastrophic forgetting. Push too hard toward stability and the model cannot adapt to anything new. Solving this dilemma is one of the core engineering challenges in continual learning, and no approach has fully solved the problem at scale. The dilemma exists in biological brains too. From what I understand about biology, human memory consolidation is strongly associated with sleep and offline processing, which suggests the brain has its own version of this stability-plasticity problem built right in. For example, a model trained to be highly stable might refuse to update its belief that a particular drug is safe even after being shown new clinical evidence, while a model trained to be highly plastic might update so aggressively that it forgets basic grammar rules after a week of medical fine-tuning.

State Space Models (SSMs)

An alternative to traditional transformer architecture that the article highlights for offering a fundamentally better scaling profile for long contexts. The article describes them as using fixed memory layers interspersed with normal attention, which unlike transformers does not grow unboundedly with every token added to the context. Traditional transformers scale quadratically with context length, while SSMs aim for near-linear scaling. However, this remains an active area of research rather than a fully settled property. The article treats SSMs as a promising architectural direction for enabling much longer agentic loops rather than a definitive solution to the broader continual learning problem. For example, a transformer handling a 100,000-token conversation requires vastly more compute than handling a 10,000-token request. But an SSM handling the same expansion would ideally require only proportionally more, which could make very long agentic tasks far more practical.

Temporal Disentanglement

A core limitation of parametric memory since a model’s weights do not separate timeless facts from information that changes over time. Both get compressed into the same parameters and are tangled together with no internal label distinguishing what’s permanent from what’s mutable. This makes continual weight updates risky because changing a time-sensitive piece of knowledge can corrupt stable knowledge stored in nearby weights. The article frames this as one of the fundamental unsolved problems standing between today’s frozen models and genuinely adaptive ones. For example, the fact that two plus two equals four and the fact that a particular person holds a particular job title are both encoded somewhere in the weights. Updating the job title risks disturbing the arithmetic because the model has no mechanism for knowing which facts are stable laws and which are contingent facts about the world.

Test-Time Training

An approach that blurs the line between training and responding by letting the model do a small amount of learning before it generates a final answer. Rather than relying entirely on what it learned during the original training run, the model runs brief gradient updates based on what it’s currently seeing and then responds. The article describes this as running gradient descent on test-time data, which means compressing new information into parameters at the moment it matters. The article treats this as one of the more substantive moves toward genuine continual learning because it actually changes weights at inference time. For example, if a model is asked to analyze a long, unusually technical document, test-time training would let it briefly train on that document before responding and compress its key patterns into the weights rather than just reading it as context. This method potentially produces a much more accurate analysis as a result.

The Bitter Lesson

A well-known observation in AI research. It holds that given more compute and data, general methods that let models figure things out at scale consistently outperform clever human-engineered solutions over time. Every time researchers have tried to hardcode structure and shortcuts into AI systems, the simpler but more scalable approaches have eventually won. The article invokes this phenomenon to question why we still hand-engineer memory and compression pipelines rather than letting models learn to do it themselves. For example, early chess programs used elaborate human-crafted rules about piece values and board positions. They were eventually crushed by systems that simply learned from millions of games with minimal human guidance and relied on scale rather than cleverness. The same pattern has repeated across nearly every domain in AI.

Token

The basic unit of text that a large language model processes. A token is roughly a word, though it can also be a fragment of a word, a punctuation mark, or a short common sequence like “ing” or “un.” Models do not read text the way humans do, character by character or word by word. Instead, they break input into tokens first and then process the sequence. The size of a context window is measured in tokens, not words or characters. For example, the sentence “The cat sat on the mat” would be broken into something like seven tokens, roughly one per word. But a word like “unbelievable” might be broken into two or three tokens: “un,” “believ,” “able,” because it’s less common and gets split into recognizable subunits the model has seen frequently.

Training Run

The large-scale and expensive process of building a model’s knowledge by exposing it to massive amounts of data and adjusting its weights. Training involves feeding these huge datasets through the network repeatedly and using gradient descent to nudge weights toward better predictions. The process runs on clusters of specialized hardware for weeks at a time and consumes substantial amounts of electricity. It’s all carefully controlled, occurs before deployment, and produces a fixed set of weights that define everything the model knows. Once training ends, the weights are frozen and the model goes out into the world as-is. For example, training a frontier model is estimated to cost tens or hundreds of millions of dollars and requires specialized data centers. This is precisely why continuous post-deployment learning is so appealing because rerunning a full training process every time the world changes isn’t practical.

Transformer

The dominant architecture underlying most major AI models today. At its core, a transformer predicts the next token in a sequence of text based on everything that came before it. It generates outputs token by token at very high speed. That sounds simple but at scale it’s not. The architecture was trained on so much human-generated text that it models statistical relationships in language and attempts to produce behavior consistent with understanding context, logic, and meaning. For example, when you ask a transformer-based model to explain a complex idea, it makes predictions about what a good explanation would look like given your question based on patterns it absorbed from vast amounts of human writing on similar topics. That’s why it seems smart. It’s familiar. Whether the final output constitutes genuine understanding is a separate philosophical debate that the article doesn’t address.

Chris Hermansen: Don’t be Afraid to Create

Duke’s Corner Java Podcast — Chris Hermansen: Don’t be Afraid to Create

Summary

Jim Grisanzio from Java Developer Relations talks with Chris Hermansen, a Java developer, consultant, and data analyst from Canada. Chris discovered Java in the 1990s and was drawn to its free accessibility and object-oriented design. He particularly appreciated Java’s straightforward single inheritance model over C++’s complexity. But Chris’s path to technology came through mathematics rather than computer science. He identifies streams as Java’s most transformative feature for data analysis work and praises how it improved code readability and maintainability. On consulting, Chris cautions against Silicon Valley mantras like “fail often” when applied outside prototyping contexts, and he observes cultural differences in how engineers approach problem-solving with some preferring abstract discussion while others focusing on concrete data. Chris emphasizes that technology work remains fundamentally human and stresses the importance of listening, maintaining humanity in professional life, and avoiding corporate stereotypes. For students, he notes the differences between learning with modern IDEs versus the command line tools of his era when he learned to code, so he advises that new learners to try multiple approaches to deepen their understanding. His core message, which became the episode’s title, is simple: “Don’t be afraid to create.”

Discovering Java in the 1990s

Chris discovered Java in the mid-1990 when Java was announced while working as a data analyst. “Java came along and it was free to use. It wasn’t open source at that point, but it was free to use,” he says. “And it really intrigued me because of its object-oriented approach to things, which was something that didn’t come with the platform we were working on.” Unlike the purchased software products he was using at the time, Java offered a free and accessible alternative that promised serious long-term value.

He also appreciated how Java’s design avoided the complexities of C++, especially the problems with multiple inheritance. He and a colleague had been discussing moving from Pascal to either C or C++, but his colleague had concerns about C++’s complexity, particularly around multiple inheritance. “The first thing that really jumped out to me was the straightforward single inheritance pathway and the use of interfaces to define contractual relations between code,” Chris says. Java’s approach to inheritance immediately stood out as cleaner and more maintainable.

Features like array bounds checking and interfaces for defining contractual relationships between code further convinced him he was learning something that would age well. “I felt that I was learning something that would wear well over time. I wouldn’t turn around and look at what I’d done 10 or 15 or 20 years later and say, yuck, what was I thinking?” After committing to Java and sticking with it through the learning process, he found it repaid his effort many times over. “I liked it and I stuck with it, and I found it paid me back enormously for my investment in learning.”

Career Path Through Mathematics

Chris’s path to technology came through math rather than traditional computer science. He actually stumbled into science during the registration process at school in the 1970s and eventually pursued math after deciding against engineering. His career took him through various mathematical applications, including consulting and data analysis positions in forestry.

Java’s Evolution: Streams and Beyond

Regarding Java’s evolution, Chris identified streams as the biggest feature improvement for his work. When asked about new features that have been useful in his applications, he immediately identifies streams as transformative. “I mean, streams was the big one. Streams just made a whole difference to the way you would handle data,” he says.

He contrasts the old approach of writing hundreds of lines of nested for loops with the more elegant stream-based approach: “And so streams has just made that a whole lot easier. And the code is so much more readable and maintainable than the old 500 line do loops that we used to have in Fortran that turned into the 375 line for loops in Java. Anyway, so streams is a big one, a really big one for me. The biggest, I would say.”

He also valued the introduction of templates (generics) in Java 5 or 6, which represented a significant evolution in the language and allowed applying libraries to custom classes. He praised the Java community for keeping the platform and ecosystem viable, noting that the combination of an active developer community and a satisfied user base creates a virtuous cycle that keeps the platform evolving and improving: “There’s enough Java programmers out there, enough people interested in the continuing viability of Java that they keep it going, that they modernize it, that they solve new problems with it, that they make it perform better than it ever has before.” He added a “big shout out to the garbage collection people that do that amazing stuff,” acknowledging the often-invisible work that performance engineers at Oracle do to make Java faster and more efficient for developers. 

Throughout the discussion, Chris talked at length about developers, the user community, and the technology. He has a nice habit of mixing the issues seamlessly. Check out this gem below where he beautifully concluded that Java is far more than a language because it’s really a movement.

“The user community is, generally speaking, pretty satisfied with [Java]. And it’s a broad enough user community. It’s got people like me. It’s got people still doing desktop Java. It’s got people using it on servers. And there’s a whole tool ecosystem out there. Personally, I prefer working right at the command line. I always have. But the application that I mentioned we built using NetBeans, which came out of Sun originally. And it’s quite a nice IDE. I don’t think it’s the most popular one. It doesn’t really matter. It’s still a very nice one. And it gave us a big part of that long-term support. And lately, I find myself using other JVM languages. So it’s not just Java. It’s the JVM that underpins it, that has permitted a flowering of alternative approaches to things that, generally speaking, work very well together with Java. So, it’s a pretty cool thing. It’s a movement. It’s not just a programming language.”

Consulting, Professionalism, and Cultural Differences

On consulting and professionalism, Chris stresses the importance of contributing to the team to best serve customers. He cautions against embracing some Silicon Valley software mantras — such as “fail early, fail often” — when applied outside their intended prototyping context. “And I know failure is a thing that people talk about in software development. Fail early, fail often. But you don’t hear consultants saying fail often. It’s not a good look for a consulting company,” he says.

Instead, Chris focuses on engineering being technically excellent and using open communications to help ensure the team’s success. “In a consulting organization, you really have to be a team player,” he says. He clarifies that getting prototypes out for feedback certainly has merit: “Get something out there and [letting] people throw rocks at it and [recording] what they say [that’s] false and recognize that, okay, you failed, but at least you moved the ball down the field. I’m a huge fan of prototyping.”

Throughout the years in his career Chris also observed cultural differences in problem-solving approaches around the world. He says that some cultures prefer abstract discussion while others focus on concrete data. “Never mind all these grand theories. Let’s actually look what we have. And really, you know, like don’t go down that rabbit hole either. Look at what you have and base things on the reality that you know about,” he advises. He warns against getting lost in theoretical discussions: “Resist the old, you know, the medieval concept of how many angels on the head of a pin kind of thing. Just don’t go there.”

The Human Side of Technology Work

Chris emphasizes that technology work remains fundamentally human. Near the end of the conversation, Chris focuses what he sees as most important: “I would just emphasize maybe that we’re human beings here and we’re driven by our human desires and wills. And as you rightly pointed out, cultural things roll into that,” he says. Despite all the technical discussion about tools, languages, methods, and preferences, the work is ultimately done by human beings with human needs and motivations.

Cultural factors, listening skills, and collaborative team approaches matter as much as technical competence. “Remember, you spend a long time of your life at your job. And so, it’s important that that contributes to your humanity and that your humanity contributes back.” He encourages developers to remember their humanity throughout their careers, to contribute meaningfully to their teams and communities, and to avoid becoming caricatures of the latest corporate culture. “It’s really important to remember that you’re part of a group of human beings here. You don’t want to be a Dilbert comic,” he says, using the comic strip as a reference point for the dehumanized corporate worker trapped in absurd bureaucracy.

On the importance of listening, Chris shares wisdom from a sign he saw years ago: “If God had intended man to speak more than he listened, he would have given him two mouths and one ear. Listen more, say less.” When discussing custom solutions versus off-the-shelf tools, and after discussing how being familiar with algorithms allows you to blend approaches for better solutions, Chris delivers what became the title of the episode: “Basically, you know, if there’s not something off the shelf that —  Don’t be afraid to create!” This is a message that Chris encourages all developers to embrace because they have such advanced skills right at their fingertips.

Advice for Students: Learning Then and Now

That creation framework extends to Chris’s advice to students learning software development. Students today face different challenges than he did decades ago. Chris compared his learning experience years ago with his daughter’s more recent computer science education. Modern students learn differently through sophisticated IDEs that suggest improvements and refactor code automatically, while Chris and his colleagues back in the day learned using only a command line, a text editor, and a compiler.

“The difference is really striking between the two because the only tool we had was the command line, the text editor, and the compiler,” he says. Modern IDEs provide capabilities like automatic refactoring and code suggestions that fundamentally change what students focus on during their education. He notes that learning with modern tools creates almost a different world than learning in his era: “And so it was really almost learning a different discipline for her than it was for me.”

He advises students to try multiple approaches to problem-solving and to explore all their options to apply their technical skills in many diverse fields. “And I think if there’s a lesson to be taken from that, sometimes it might be fun once you’ve learned how to do something in the IDEs to try and do it the old way and see what it’s like just creating from nothing, you know, and starting out that way. And vice versa, guys like me that always insist on using VI at the command line, we should learn an IDE. It’s time.”

Finally, Chris reflects on the value of learning multiple approaches to solving problems. This goes beyond just technical skills to understanding the problem itself more deeply: “I think learning several different ways to solve a problem ultimately teaches you more about the problem. And learning more about the problem, I think, teaches you a bit about yourself and how you go about solving things and your value to your organization.” During the entire conversation on technology, Chris consistently wove in the human element. We are people, after all. We’re just using digital tools to create. 

Duke's Corner Java Podcast

Six Strategies for Better Learning

The pace of change today demands constant learning, whether for career advancement, upskilling in fast-moving fields, or mastering new personal interests. Many of us wonder if there is a right way to learn so knowledge truly sticks. Recent research points to clear answers.

A interesting paper called Teaching the Science of Learning by Yana Weinstein, Christopher Madan, and Megan Sumeracki, published in Cognitive Research: Principles and Implications, offers a science-based roadmap for effective lifelong learning. Decades of cognitive science and educational research support the strategies they recommend, and their guidance extends well beyond the classroom.

Why Evidence-Based Learning Strategies Matter

Traditional methods like cramming, rote memorization, or repeated review provide an illusion of mastery, but often result in rapid forgetting. Real learning means building a durable, flexible knowledge base that can be called upon in real situations, whether at work or in life.

Weinstein and colleagues highlight six strategies that consistently improve retention and transfer: spaced practice, interleaving, retrieval practice, elaboration, using concrete examples, and dual coding. Below, you’ll find each described along with actions any professional or self-directed learner can apply.

1. Spaced Practice: Distribute Review Over Time

Spaced practice involves spreading study or review sessions over time, rather than massing them together. Research shows knowledge reviewed at intervals is remembered longer with less total effort.

Why it works:

Spaced practice allows memory “retrieval strength” to wane before boosting it again, which leads to better storage in long-term memory.

Actions:

  • Build recurring review into your workflow. Use calendar reminders to revisit topics or skills (e.g., first after one day, then three, then a week).
  • Mark when you learn something new, and schedule check-ins to revisit it later.
  • Use tracking tools (digital or print) to log what you’ve reviewed and when.
  • Leverage digital flashcard systems with spaced repetition (e.g., Anki, SuperMemo) for knowledge that builds on itself, but verify compliance with your organization’s security and privacy policies if using external apps.
  • Blend current tasks or cases with samples from prior projects to reinforce older knowledge.

2. Interleaving: Mix Related Skills and Concepts

Interleaving means alternating practice or review between related skills, concepts, or problem types instead of focusing on one at a time.

Why it works:

Switching between related topics sharpens your ability to discriminate between them and select the proper approach for each, boosting adaptable expertise.

Actions:

  • Alternate work tasks that use related skills (e.g., switch between the analysis and writing phases of a report instead of batching all analysis first).
  • If practicing technical skills, intermingle exercises on different but related techniques in one session.
  • In training, mix case studies or scenarios from multiple categories rather than working through each category in sequence.
  • For language or communication, alternate between different types of correspondence or customer scenarios.
  • Use professional e-learning platforms or in-house tools that automatically vary topics or assessment items across reviews.

3. Retrieval Practice: Actively Recall Information

Retrieval practice is the act of recalling information from memory, not just rereading or reviewing it passively. This dramatically boosts retention.

Why it works:

Retrieval strengthens neural pathways and makes the information more accessible in the future. Low-pressure recall exercises reduce stress and encourage active engagement.

Actions:

  • After a meeting or training, jot down key points and action items from memory before referencing any notes.
  • Create end-of-week or end-of-project knowledge checks, summarizing recent learnings without your materials in front of you.
  • Use flashcards or “quiz yourself” routines as part of continuing professional development.
  • Practice describing complex procedures, explaining them as if to a colleague, without referring to a manual.
  • Set up peer Q&A sessions where team members challenge each other to recall key facts or principles relevant to your organization.
  • Experiment with AI tools to generate personalized quizzes.

4. Elaboration: Link New Knowledge with What You Know

Elaboration refers to the process of connecting new information to prior knowledge and making it personally meaningful.

Why it works:

By asking yourself “how” and “why” questions and drawing analogies to familiar concepts or real scenarios, you deepen your understanding, making it easier to retrieve and apply knowledge later.

Actions:

  • After learning a new tool or concept, write or speak out loud about how it integrates with what you already know.
  • When presented with a new procedure, compare it to previous processes and note similarities or differences.
  • Keep a reflective learning journal: After completing new coursework or reading, sum up the day’s biggest learning in your own words and relate it to past experience.
  • In project debriefs, explicitly link lessons learned to prior projects.
  • When facing a challenging problem, articulate the potential causes and solutions aloud or in writing, referencing knowledge from other fields or prior roles.

5. Concrete Examples: Anchor Ideas in Real Situations

Using concrete examples — specific, real-world cases or analogies — makes abstract concepts memorable and easier to understand.

Why it works:

Concrete information is more readily assimilated and retained. Comparing multiple examples enhances the ability to apply an idea in new situations.

Actions:

  • Illustrate complex principles or models by referencing actual projects, known workplace situations, or well-defined industry scenarios.
  • When learning new regulations or policies, anchor them in relevant, concrete events from your organization’s history.
  • Create job aids or reference sheets using one or more vivid, context-appropriate examples for each key concept.
  • During presentations or training, pair abstract slides with brief case summaries to reinforce understanding.
  • Whenever possible, develop alternate examples that differ on the surface but share the same underlying structure.

6. Dual Coding: Combine Verbal and Visual Information

Dual coding is about presenting material using both words and visuals (charts, diagrams, infographics, sketches) to reinforce learning.

Why it works:

Engaging both verbal and visual channels supports deeper learning and increases recall, provided both representations are clear and meaningfully related.

Actions:

  • Supplement written reports with diagrams, flowcharts, or annotated screenshots to illustrate key points.
  • During meetings or presentations, support spoken points with slide visuals — charts, figures, or concept maps.
  • Capture processes or workflows visually (e.g., draw swimlane diagrams, mind maps) while also describing them in text or speech.
  • After reading a policy or technical manual, attempt to sketch the process or concept with labels and brief annotations.
  • When reviewing digital training, pause to create your own diagrams depicting major processes or relationships.

Combining Strategies for Maximum Effect

Research shows these strategies interact synergistically, so use them together to leverage results. Retrieval practice spaced over time solidifies knowledge. Interleaving concepts keeps skills flexible. Concrete examples and dual coding together make complex information more accessible and memorable. Elaboration will help you transfer abstract theories into daily practice.

Experiment with integrating these techniques in your study sessions, work meetings, or professional development routines. Share your approaches with peers and teams or even online. Evidence-based learning is for everyone. And as these principles spread, organizations and individuals will find it easier to learn, adapt, and excel in an ever changing world.

UnVoxxed Hawaii (LavaOne) January 2019.
UnVoxxed Hawaii (LavaOne) January 2019.

Redefining Aging: Wisdom Wins

The Myth of Cognitive Decline: Non-Linear Dynamics of Lifelong Learning
Michael Ramscar, Peter Hendrix, Cyrus Shaoul, Petar Milin, Harald Baayen

I’ve always had a hunch about this. Back in my 20s, I remember being quick. Conversations, thinking, decisions, reactions, movements. All fast. Now, though, things are obviously much slower. It’s also, obvious that my brain is juggling a ton more info. Massively more! I never had that feeling when I was a kid. And my memory is so much more comprehensive now, whereas when I was young I never even thought about memory. I also notice I’m not just reacting these days. Instead, I’m actively sifting through years of experience, global connections, interesting new ideas, and some really painful lessons learned since birth. And, apparently, all that processing that takes some time.

I see this phenomenon everywhere now. Kids fly through problems with fresh, uncluttered minds. Then young adults start layering on some complexity and slow down just a bit. Older people, though, like my parents or my older mentors, pause much longer — but they then drop insights that blow me away with their depth. How do they know that? Where did that come from? These patterns are obvious when you watch people wrestle with intellectual challenges, whether coding a complex algorithm, debating politics, arguing over sports teams, or solving intractable real world geopolitical problems. It’s not a hard and fast rule, bit the pattern is observable is you pay attention long enough.

I stumbled on the article above while digging into learning techniques for some projects on training, networking, and memory. It confirms what I’ve felt for years but I rarely hear people talking about it in casual conversation. Even when I bring it up, most people just dismiss the issue.

A New Spin on Aging

The article flips the script on how we think about our aging brains. Everyone seems to assume we just fall apart mentally as we get older, right? Wrong. The authors tackle the “aging as decline” myth head on, pulling from the Greek story of Tithonus, who was immortal but stuck without youth, to slam the idea that growing older means mentally breaking down. And they’re not messing around:

“Many of the assumptions scientists currently make about ‘cognitive decline’ are seriously flawed and, for the most part, formally invalid.”

They say slower reaction times or shaky test scores don’t necessarily mean your brain’s failing, and it’s just natural decline due to aging. Instead, it’s the natural result of continually laying knowledge over a lifetime. It’s just your brain working overtime parsing all that wisdom.

With 72 million Americans hitting 65 by 2030, we need to get this right. The authors say buying into the decline myth wastes human potential:

“The myth of cognitive decline is leading to an absurd waste of human potential and human capital.”

I love that assertion in the face of never-ending media propaganda telling us that our brains are doomed. The authors push back hard and say we need to rethink how we support older people. Aging isn’t the problem. Our misconceptions are.

Breaking the Decline Myth

The core idea here is that your brain doesn’t just stay the same forever. Psychometric tests, those standard measures of cognitive ability, miss the mark because they ignore how experience shapes us over time. Learning tunes out useless noise and crams your head with more info, which naturally takes longer to parse. Language is a big deal here as well. Words follow a long tail pattern, where common ones rule in the present moment but rare ones pile up over time. Traditional tests miss this growth, so older people seem slower. Of course the are. They’re processing more!

Could it be that simple? The authors point out that current tests miss how our knowledge grows over time, and that mainstream aging researchers haven’t controlled for the sheer amount of information an older brain has to search through. That gap is what’s kept the science off for so long.

And the authors clearly nail the paradox of this experience:

“Learning is a discriminative process that serves to locally reduce the information processing demands associated with specific forms of knowledge and skill… [but] age and experience will inevitably increase the overall range of knowledge and skills any individual possesses, increasing the amount information in (and complexity of) his or her cognitive systems.”

Translation? Your brain’s sharper as a result of education but much busier. They sum it up late in the paper:

“The results reported here indicate that older and younger adults’ performance in psychometric testing are the product of the same cognitive mechanisms processing different quantities of information: Older adults’ performance reflects increased knowledge, not cognitive decline.”

To me that’s a nice big fat middle finger to decades of so-called settled science. No. The science is never settled. You gotta question it, like these authors do with some serious attitude.

Simulations and Real Life

The authors use an interesting data collection tool, the Naive Discriminative Reader, to simulate how brains handle tasks like picking out words. Models with more data, mimicking a lifetime of experience, get pickier with rare words and vary more, just like older people in studies. Same deal with non lexical tasks like letter classification. Slower times come from bigger mental databases, not a broken brain. Paired associate learning, where you link words like baby and cries, shows older adults deeper knowledge makes hard pairs trickier, not memory loss.

Name recall? That’s a mess because names got crazier since the 1880s. American first name complexity jumped from 100 to over 2,000 options. Simulations say it takes half a second longer to recognize names over a lifetime. The authors throw a curveball:

“Confounding name recall problems with cognitive decline is akin to asking older adults to accept personal responsibility for a social problem.”

Ouch! Even tasks like the COWAT FAS test, where older people often shine, support the point. Experience helps you nail word retrieval despite proper noun chaos.

On brain science, the authors are bold:

“Except in the case of neurological diseases where there is evidence of pathology, there is no neurobiological evidence for any declines in the processing capacities of healthy older adults.”

So, without models tying brain changes to behavior, those decline claims seem shaky.

Why This Matters

There’s one more bit worth knowing about because it answers the obvious skeptical question. If cognitive decline isn’t real, why does it show up in study after study? The authors dug into a meta-analysis of 134 studies using the FAS fluency test and found something they hadn’t expected. The size of the study mattered more than anyone realized. In small samples, the kind they call “artisanal,” performance barely changed with age at all. Thirty-five-year-olds and sixty-five-year-olds scored about the same. It was only in the larger studies that the familiar decline showed up, and it grew steadily as the samples got bigger. That’s a strange thing for a real biological decline to do. It suggests some of what we call cognitive decline might be an artifact of how psychology studies are run, not a fact about how brains age normally.

Same deal with retirement: less variety in daily life can jumble memory, not because your brain’s failing, but because learning and memory thrive on context. The authors want us to dump the myths that waste talent and build models to tap lifelong intelligence. Remember this blunt statement from earlier in the article:

“The myth of cognitive decline is leading to an absurd waste of human potential and human capital.”

That’s a paradigm shift, not just for better science, but for creating spaces where wisdom shines. Understanding learning’s ups and downs can help people manage memories better. So, next time someone says aging means decline, tell ’em to read this research from the authors above. Knowledge acquired from years of experience isn’t the problem. It’s the superpower.

And always question science. Question everything. Even this research that questions the previous research should be questioned. The science is never settled.

Jim Grisanzio at Jfokus in Stockholm in April 2022.
Jim Grisanzio at Jfokus in Stockholm in April 2022.

Memorize

In recent years I’ve been rebuilding my memory. I’m determined to master raw, blatant, repetitive memorization — which is the very thing I was told when I was young to not do as a part of learning. You know, because “you can always look it up,” right? And now we have AI, so we’re good. Big mistake. As always, it’s all a lie. Memorize daily. Anki is a great little algorithm to help train your brain.

Jim Grisanzio at OCYatra 2022. Six city tour of India: Chennai, Bengaluru, Mumbai, Pune, Delhi, Hyderabad. Here I’m talking about Anki and the book Make it Stick as two excellent learning aids you’ll never get in school. Photo by AIOUG.

Venkat Subramaniam: I Teach Because I Learn

Duke’s Corner Java Podcast: Venkat Subramaniam: I Teach Because I Learn

Jim Grisanzio from Oracle Java Developer Relations talks with Venkat Subramaniam who was recognized with the Java Community Lifetime Achievement honors by Oracle’s Sharat Chander at Devoxx UK in May 2024. Venkat is a Java Champion, author, speaker, founder of Agile Developer, co-founder of the dev2next conference, and teacher at the University of Houston.

In this conversation, which is part of an ongoing series honoring Java pioneers, Venkat expresses profound humility about his accomplishments and credits industry giants and his passion for learning and sharing technical knowledge. He reflects on leaving his own company years ago to focus on teaching and technology, writing books like Cruising Along with Java, and speaking at over 45 conferences and 30 Java User Groups — every single year! Venkat has one of the most impressive global speaking schedules of anyone in the Java community.

Venkat praises Java User Group leaders as “unsung heroes” for their organizational efforts and highlights Java 25’s evolving features like structured concurrency, scoped values, pattern matching, and the instance main method, which helps simplify the learning process for new developers. Venkat also cites Java’s agile six-month release cycle, which helps improve the smooth evolution of Java, increases developer engagement, and makes Java more suitable for today’s rapidly expanding technology markets. Emphasizing teaching as reciprocal learning, Venkat advises students to engage mentors and senior developers to collaborate with juniors to help welcome into the community. He stresses that knowledge grows when shared. His mantra? Teaching fuels learning and he lives that ethic every day as he interacts with thousands of developers around the world.

Here are some links on the web where this interview can be found: Apple | LinkedIn | Substack | WordPress | WordPress

Also, below are some quotes and the specific context of the quotes from the conversation split into sections.

Community Recognition and Humility

Unexpected Award Shock
Timestamp: 00:01:16
Context: During the conversation, Venkat recalls the moment he was awarded the Java Community Lifetime Achievement honors at Devoxx UK in May 2024, an initiative led by Sharat Chander of Oracle’s Java Developer Relations to recognize community contributions. He describes being caught off guard right before a keynote when Shar made the announcement, emphasizing the vital role of community members in the Java ecosystem. Venkat shares his nervousness and surprise, feeling unprepared for such recognition amidst esteemed industry figures.
Quote: “I was truly shocked, honestly. If you want me to truly explain the feeling, I was very nervous being there and did not see this coming. I don’t think I consider myself as worthy of being received compared to the giants I mentioned in the industry today.”

Humbled by Giants
Timestamp: 00:00:49
Context: Early in the interview, Venkat expresses profound gratitude for the award, emphasizing his humility in being recognized alongside prominent Java contributors. He references Newton’s quote to highlight that his achievements build on the foundational work of others, acknowledging the mentors and peers who have shaped his career and strengthened the Java community through their contributions.
Quote: “I look up so many giants that are in the field and I’m truly humbled for having been recognized. I want to channel in the words of Newton. He said, I see the farthest because I am standing on the shoulders of the giants. I’m very humbled and thankful for the giants that brought me up to here and I couldn’t be here without it.”

Undeserving Yet Grateful
Timestamp: 00:02:37
Context: After receiving the award, Venkat reflects on feeling unworthy compared to other Java luminaries, many of whom he believes have made more significant contributions. Venkat shares his emotional response to the unexpected honor from Shar. Venkat values diverse community efforts like coding, blogging, and event organization, which underscores his gratitude despite his self-perceived inadequacy.
Quote: “I don’t think I was expecting or even feel that I was deserving of it. So I’m very grateful. I don’t think I consider myself as worthy of being recognized compared to the giants I mentioned in the industry today. So I’m very grateful and it was an interesting moment.”

Contributions to User Groups and Conferences

Unsung Heroes of User Groups
Timestamp: 00:07:44
Context: Venkat passionately praises Java User Group (JUG) leaders as the backbone of the Java community, recognizing their tireless, often thankless efforts in organizing monthly meetings for years. He details their work in securing speakers, arranging venues, providing food, cleaning up, and more — all done voluntarily to foster learning and networking and community building. These leaders, often unknown beyond their local communities, embody true service and significantly contribute to Java’s vibrant ecosystem.
Quote: “These are to me, the unsung heroes of our field. These are the user group leaders. Most people wouldn’t know their names outside of their local community, but these are the people doing hard work every single day. Imagine the effort it takes to organize a user group meeting month after month after month, having a speaker come over, having the attendees show up, having the food for them available, having the facility to clean up after the meeting is over.”

Giving Back Through User Groups
Timestamp: 00:17:47
Context: Venkat shares how a scheduling mistake 25 years ago at a Houston Java user group gave him his first speaking opportunity, a pivotal moment that launched his community engagement. Grateful for this serendipitous break, he commits to speaking at around 30 user groups annually, as listed on his website (agiledeveloper.com). He views it as a way to repay the community that elevated his career.
Quote: “This is one of the reasons, in all honesty, 25 years later that I speak in approximately 30 or more user groups every single year. If you go to my website, agiledeveloper.com, and you look in the events section, you will see the number of user groups I talk to every single year because that’s, to me, a way to give back to the user groups because that’s what I started.”

Conferences and Broad Reach
Timestamp: 00:18:25
Context: Venkat attributes part of his recognition to his extensive speaking at approximately 45 conferences yearly, reaching diverse audiences from aspiring developers to seasoned experts. His talks cover deep technical details, career advice, and Java innovations — all of which creates creating a broad “surface area” of impact. This prolific engagement, driven by his enthusiasm, likely contributed to his award, connecting him with developers worldwide.
Quote: “I speak in roughly about, I don’t even count, but I’m going to say maybe 45 or more conferences a year. So I think that’s part of the reason for the recognition is the amount of… the surface area that I can touch. I can touch the surface area of young developers, aspiring programmers, seasoned professionals, all the way to experts with my interaction in the industry by way of conferences, user groups, university, consulting, writing books.”

Everyone Needs a Break
Timestamp: 00:14:00
Context: Venkat recalls a defining moment 25 years ago when a calendar error by a Houston Java user group organizer allowed him to speak on a non-teaching night. This led to an invitation to the No Fluff, Just Stuff conference, connecting him with industry giants like Jason Hunter and James Duncan Davidson, marking a turning point in his career through serendipity.
Quote: “Everybody needs a break. If you don’t get a break, you could have the potential, but you need that first break, right? It’s like the actors who always tell you, well, I was in acting school and I was interested in acting, but here’s where I got a first break. Well, I got my first break in the Java User Group.”

Teaching and Sharing Knowledge

Teaching as Learning
Timestamp: 00:39:16
Context: Near the end of the interview, Venkat articulates his teaching philosophy, emphasizing its reciprocal nature. As a part-time professor for 34 years, he views himself as the “first student” in his classes, learning from student questions and interactions. This approach fuels his growth and reinforces his commitment to sharing practical knowledge with students, helping them navigate their careers.
Quote: “I teach because I learn. And I always say I’m the first student in my classes. So collaborate, bring other developers because you end up learning by doing [more] so than being in isolation in solving your problems.”

Sharing Excitement
Timestamp: 00:03:16
Context: Early in the discussion, Venkat explains his shift in focus from seeking recognition to prioritizing learning and sharing knowledge. He describes how, in his late twenties, he realized that true reward lies in daily learning and helping others grow, a mindset that drives his prolific contributions to the Java community through technical talks, writing books, and teaching students and professional developers.
Quote: “If our mind is focused on learning, and then sharing what we learn, then we are not focused on where we get the recognition from. The reward is when I wake up in the morning and feel like I have learned something more than I did the day before. And then I go to bed knowing that maybe I helped somebody else along the way to learn something more than they did.”

Venkat’s Company and Solo Path
Timestamp: 00:10:06
Context: Venkat shares his transformative decision to leave his day job and, after four years, fire himself from his own company. He realized that he was a technologist at heart, not a business person. This shift allowed him to focus on learning, tinkering with technologies, and sharing insights through talks and books — all of which aligned with his true passion.
Quote: “I quit working in a day job several decades ago and I started my own company and only to realize after about four or five years running my company to realize that I’m not a business person. I’m a technologist, and I realized that what I truly enjoy is learning about stuff, tinkering with technologies, trying to come up with reasons about why things work and how they should be implemented, and then to turn around and be able to share that and coach people doing it.”

Long-Term Teaching Commitment
Timestamp: 00:13:08
Context: Venkat discusses his 34-year tenure as a part-time university professor, emphasizing that his goal isn’t academic status but instead sharing practical knowledge in the industry. By teaching evenings, he bridges his professional experiences with academia, helping students learn career approaches and professional skills, contributing to their development as future Java developers.
Quote: “I’m into my 34th year of teaching at the university. All these 34 years, part-time, I moonlight. I’ve never been [on the] tenured track or in a position to be tenured. I don’t want to be tenured. My goal is not to be a professor. My goal is to teach students about things they can learn, how to learn, how to approach their careers.”

Venkat’s Book Motivation
Timestamp: 00:11:58
Context: Venkat explains his motivation for writing books like Cruising Along with Java recently. He was initially hesitant but driven by a desire to share stories about technology nuances. Unlike writing for business promotion, he finds excitement in conveying discoveries about languages or design methods, using books and conferences as platforms to educate and inspire developers.
Quote: “The one reason to write a book is to maybe promote yourself and promote your business. But to me, a bigger reason to write a book is I’ve got a story to tell. And that’s what excites me about writing books. Almost every book I’ve written since then, I started writing the book because I have a story to tell. I discover a nuance in a language or in a library or in a method of designing, and I want to speak that.”

Knowledge Grows When Given
Timestamp: 00:38:08
Context: While offering advice, Venkat emphasizes that sharing knowledge benefits both the giver and the receiver. He describes how teaching prompts self-reflection and leads to new questions, often leading him to take notes during conversations to explore topics further. This reinforces his belief that knowledge, unlike money, grows through sharing, enriching all parties involved.
Quote: “I often say that knowledge is a wealth that grows when it’s given. You know, if I give you $10, I’m poorer by $10. But if I share with you a little bit of what I know, I never give you what I know because as I’m talking to you, I’m going to start thinking, do I understand this really well? Or you are asking a question and that immediately triggers in my mind, oh my gosh, I need to really go in and look at that a little bit more because that’s a question I haven’t thought through much.”

Java Evolution and Features

Java 25 Excitements
Timestamp: 00:20:20
Context: When asked about Java 25, set for release in September 2025, Venkat expresses enthusiasm for features like structured concurrency, scoped values, pattern matching, and the instance main method. He is particularly excited about structured concurrency’s foundation on virtual threads for solving divide-and-conquer problems, pattern matching’s evolving syntax for expressive coding, and the instance main method’s role in simplifying Java for newcomers.
Quote: “There are actually a few things that are new and maybe even evolving that I’m truly excited about. There are several features, and I don’t want to lessen any one of them by mentioning a few. But I think one of the things I’ve been keeping my eyes on very closely as it’s going through the development is the structured concurrency and scoped values. The pattern matching syntax as it’s been evolving, I think it’s very interesting to see the instance of, for the primitive types, I think that’s pretty exciting, very useful as well. The other thing that I’m keeping my eyes on pretty nicely evolving is the compact source files and instance main method.”

Structured Concurrency and Virtual Threads
Timestamp: 00:20:39
Context: Venkat elaborates on his excitement for Java 25’s structured concurrency, a feature built on virtual threads introduced in earlier releases. He explains that this feature addresses complex divide-and-conquer problems, making it a significant advancement for experienced developers writing production code. His enthusiasm stems from closely following its development, seeing it as a powerful tool to enhance Java’s concurrency capabilities for robust, scalable applications.
Quote: “Structured concurrency is in a way built on top of virtual threads, which is another exciting feature for me. But structured concurrency is solving a set of problems that are very exciting to solve, divide and conquer problems and so on. So I’ve been keeping an eye on that quite a bit.”

Incremental Changes and 6-Month Cycle
Timestamp: 00:29:02
Context: Venkat praises Java’s six-month release cycle for its agile, incremental approach, allowing developers to benefit from features like pattern matching as they evolve. He contrasts this with long waits for major releases, noting that incremental updates enable faster adoption and adaptation, aligning with agile development principles and benefiting programmers.
Quote: “You are able to come back and keep adding more capabilities to it is much better than saying you wait for eight years to get everything versus you can get them incrementally every six months. I think that’s more beneficial to developers. I feel that’s more agile in a lot of ways as well. So that’s what I mean by evolutionary is you can reap the benefits along the way rather than having to wait a long time to get them all.”

Evolving for Next Generation
Timestamp: 00:21:56
Context: Discussing Java 25’s instance main method, Venkat explains its significance in simplifying the onboarding process for new developers. He contrasts the complexity faced by early Java adopters from C and C++ backgrounds with today’s newcomers, who find Java’s initial learning curve daunting, making features like instance main crucial for accessibility.
Quote: “The instance main method is something I’m really, really super excited about. I’ve been a critique of this for years earlier, that when you start getting introduced to Java, it’s like being hit by a bus. You have to learn about so many things that you don’t need to know right now just to even start with the hello world. I think that main method feature is something I really truly respect as well.”

Pattern Matching Evolution
Timestamp: 00:27:06
Context: Venkat uses an analogy to Captain America to describe the incremental evolution of Java’s pattern matching syntax, from a simple switch statement to a robust feature. He recalls a conversation with Brian Goetz, Java Language Architect at Oracle, who outlined delivering pattern matching in “three installments,” a process that has extended but exemplifies Java’s thoughtful, iterative development.
Quote: “This purely little switch statement, look at how it turned into this powerful pattern matching syntax. So I relate the pattern matching syntax to Captain America’s evolution. I wrote the book recently called Cruising Along with Java. And as you can see that I get excited, I talk about, I’m a person of analogies. So when I started talking about pattern matching in the book, I gave the example of Steve Rogers, who was this puny little guy who didn’t have much strength, failed being in an army. And then they treat him with the serum. And then he turns into this powerful Captain America.”

Advice for Developers

Advice for Students
Timestamp: 00:33:50
Context: Offering advice to students, Venkat stresses the importance of reaching out to mentors and engaging in face-to-face conversations, urging students to keep cameras on during virtual meetings for richer interactions. He shares how he provides Zoom links to students, encouraging them to ask beyond technical questions to learn about careers and conferences, accelerating their growth.
Quote: “If you’re a student, the first thing I would say is reach out to people. Reach out to people and have conversations with them. I can’t tell you how many times I tell my students, here’s my Zoom link. I tell them, here’s a link. You click on it. I pop in like a genie and I’m going to talk to you. Make use of that, I tell my students all the time. The other thing I actually sincerely say that is keep your cameras on. The conversation is very different when you’re able to see the other person.”

Advice for Senior Developers
Timestamp: 00:37:18
Context: Addressing senior developers, Venkat encourages collaboration with junior developers, especially in the context of using AI tools. He sees this as a mutual learning opportunity, where seniors impart critical thinking and fundamentals, while juniors introduce new tools and techniques, fostering a collaborative environment that benefits both parties in today’s rapidly evolving tech landscape.
Quote: “This is an opportunity for you, the senior developer, to engage the junior developers into more collaborative development. And by doing so, I always say it’s got to be a benefit for everybody, otherwise we’re not going to do it. So the young developers begin to learn that proper thinking and critical thinking is important. They’re going to be able to learn that from you, the senior developer. But as a senior developer, you also quickly begin to learn that there are tools and techniques you’re not aware of, but these young developers are able to drag them in because they’re so quick in looking at different things.”

AI as a Tool
Timestamp: 00:36:35
Context: Discussing the role of AI in development, Venkat cautions that while AI is a powerful tool, it cannot replace strong fundamentals. He uses an analogy of misusing a lawnmower to highlight the need for careful application, urging senior developers to guide juniors in balancing AI’s capabilities with critical thinking and foundational knowledge.
Quote: “AI is a powerful tool, but we gotta be careful using it. When you have young developers on your team who feel like they can do anything they want because they have these tools, what they don’t understand is that’s not a substitute for having good fundamentals. This is an opportunity for you, the senior developer, to engage the junior developers into more collaborative development.”

Cay Horstmann: Java Still Vibrant After 30 Years

Duke’s Corner Java Podcast: Cay Horstmann: Java Still Vibrant After 30 Years

Jim Grisanzio from Java Developer Relations talks with Cay Horstmann, a professor, author, and Java Champion. In April 2025 in Cologne, Germany at JCON Cay received the Java Community Lifetime Achievement recognition from Sharat Chander on the Oracle Java Developer Relations Team.

This conversation covers the evolution of Java, the constant polishing of the library, the upcoming Java 25 release, the six-month release cycle, improvements in the Java language to make the technology more beginner friendly, teaching methodologies, conferences vs unconferences, and also timeless task-driven learning methods for students and developers to keep their skills sharp. Also, Cay has been writing books about Java for decades and years ago he was instrumental in initially getting Java integrated into the curriculum for the computer science AP exam in the United States.

“One of the reasons why Java is still so vibrant 30 years in is that there is a constant stream of low-level innovation going on. It’s pretty amazing.”

Links on the web for this conversation: Apple | Substack | LinkedIn | LinkedIn | LinkedIn | LinkedIn | Flickr | Flickr | Flickr | WordPress | X | X | X | X | YouTube | YouTube | YouTube. All of Duke’s Corner Java Podcasts can be found here. Here are more quotes from the conversation below:

Java’s Vibrancy and Evolution


Java’s Continuous Low-Level Innovation
Timestamp: 00:13:45–00:14:12
Context: Cay discusses why Java remains vibrant after 30 years, emphasizing the impact of the Java six-month release cycle and the steady stream of incremental improvements. He contrasts this with how individual features might not seem groundbreaking alone in any given release, but cumulatively they drive significant progress. He also ties this process to the natural competition among programming languages, where Java’s consistent updates help it stay relevant in a fast-evolving field.
Quote: “And I think one of the reasons that Java is so vibrant 30 years in is that it’s doing a really good job. I mean, if you think about it, every six months, there’s a new version that has some features that some are interested in for some people, some for others. And there is a constant stream of low-level innovation going on. Very few of these features seem like momentous on their own, but altogether, it is pretty amazing.”

Polished Java Library Through Continuous Refinement
Timestamp: 00:07:05–00:07:33
Context: Cay highlights how Java’s library has been refined over decades, making it more polished and user-friendly compared to other languages. He explains that this comes from ongoing attention to the API, where small complications are identified and simplified over time, and while each change might seem minor in isolation, the repeated process over 20 to 30 years results in a highly refined system that stands out for its logic and ease of use.
Quote: “There is the evolution, but there’s also the constant polishing of the library. So the API gets attention. You say, this is just a little bit too complicated. And someone says, yeah, sure. And then some small simplification comes. It never looks [like] much of a deal once, but repeat that over 20, 30 years, and you have really a super polished library. You do not have that with other languages.”

Java 25 and Beginner-Friendliness


Simplifying Java for Beginners
Timestamp: 00:08:49–00:09:16
Context: Cay explains how updates in Java 25 will reduce syntactic complexity for beginners by removing the need for a class in simple programs and improving I/O methods. He notes that while beginners have historically managed with templates, this change makes the language less intimidating from the start, and he appreciates its regularity compared to Python’s mix of top-level code and methods, which allows for a smoother introduction to programming concepts without unnecessary distractions.
Quote: “Nevertheless, Java 25 now does make this a lot easier. You now no longer have to have a class for simple programs. You still do need to have a main method, which I think is actually fine because it’s more regular than Python. In Python, you have a slightly confusing mix of top-level code and then methods. And in Java, it’s just methods for simple programs.”

Visual Clarity in Java 25 for Educational Content
Timestamp: 00:09:16–00:09:49
Context: Reflecting on rewriting his textbook, Cay notes how Java 25’s simplified syntax reduces visual clutter, benefiting students and textbook authors. He describes how textbooks often feature numerous small sample programs, unlike larger developer projects, and removing elements like public static void main makes the code less overwhelming visually, allowing developers to focus on core ideas rather than ceremonial syntax that can distract them while learning.
Quote: “At first I thought, you know, big deal, but now I’ve rewritten the first three chapters of Core Java with this and I really, really like it. It just is visually less distracting when you write a textbook. There’s lots and lots of small sample programs… and public static void main, you know, if you even have one in a framework, you would never even have it. But in a textbook, yeah, it’s nice.”

Simplified I/O in Java 25
Timestamp: 00:10:24–00:10:33
Context: Cay discusses how Java 25 introduces simpler I/O methods, making it easier for beginners to learn and use. He says that this eliminates odd constructs like system.out, replacing them with straightforward static methods, which helps beginners master a few key concepts early on and progress smoothly for the first several weeks before transitioning to more advanced object-oriented features. Quote: “To read something now, you no longer need to use system.out, which was always kind of an odd beast. You just say io.printon. It’s a static method.”

Teaching and Learning Methodologies


Task-Driven Learning for Lifelong Skills
Timestamp: 00:19:42–00:20:10
Context: Cay advocates for task-driven learning, where students engage with material through hands-on experimentation, which he believes is more effective than traditional lectures. He stresses that while learning the basics is necessary, the real value comes from applying them in practical ways, which encourages trial and error to build motivation and skills. This approach aligns with how professionals tinker and iterate in real-world work scenarios.
Quote: “You really want the learner to engage with the material by trying things out, by kicking the tires, by failing and then succeeding. There are some times when you need some fundamentals, you can’t build without knowing some basics. So I’m not against teaching those as facts. But then you quickly want to motivate students by putting things to work.”

Teaching Students to Learn How to Learn
Timestamp: 00:18:11–00:18:29
Context: Reflecting on his teaching career, Cay emphasizes that teaching students how to learn is more valuable than pushing specific subject matter, which is especially important given the rapid evolution of technology. He shares how he shifted focus from content delivery to guiding students through vast information landscapes, helping them navigate changes like in Android programming where details quickly become obsolete.
Quote: “I realized that subject matter really does not matter that much because it changes anyway. What really mattered to me is how students could learn to learn better, and how they could find their own way in that morass of materials out there.”

Interactive Learning in Small Classes
Timestamp: 00:18:39–00:18:58
Context: Cay describes the shift from large lectures to small, interactive lab sessions where students collaboratively fix outdated code, promotes practical learning. He explains that by using last year’s notes as a starting point, students learn to adapt to shifts in technology, identifying principles for troubleshooting and using tools like AI or Stack Overflow to aid the process.
Quote: “I really stopped lecturing. We had, like, a lab session every day where I said, here are the lecture notes from last year, none of this stuff works anymore, let’s fix it together. And in fact, none of this stuff did work anymore because this or that shifted. And so then what we really learned is how can you tease out the underlying principles that help you understand where even to look for the failures?”

Challenges of AI Tools in Education
Timestamp: 00:23:46–00:24:07
Context: Cay addresses the challenge of students using AI tools like chatbots to complete homework, emphasizing the importance of learning through personal effort. He observes that while younger students seem to intuitively know when to avoid these tools, older ones struggle, and he compares it to self-practice in other skills, noting that exercises are meant for cognitive development, not just output.
Quote: “What’s the value in that though, right? It’s not that people want to have another program that prints prime numbers. It’s that those exercises are there to make you think and to make you a better programmer. And so at that point, one needs to learn. And for students, this is hard. One needs to learn not to use the chatbot. I mean, it’s just like if you want to learn Italian or to play the piano, you need to do it yourself.”

Contributing to the Java Community


Instrumental Role in Java’s AP Curriculum Integration
Timestamp: 00:04:39–00:05:02
Context: Cay remembers his role in helping integrate Java into the U.S. Advanced Placement Computer Science Curriculum when he was advocating for a minimal subset of Java to focus on fundamentals. He mentions being invited to the committee due to his expertise in Java books and teaching, and how they successfully transitioned from C++ while resisting too many additions that could complicate the course unnecessarily.
Quote: “And so we actually managed to do that. I was very proud that we did not just switch to Java, but we switched to the smallest possible subset of Java that we could. Because I felt that the programming language should not be the key of this course. It is a course in fundamentals of computer science.”

Blogging and Conference Contributions
Timestamp: 00:03:11–00:03:35
Context: Cay reflects on his contributions to the Java ecosystem through writing books, blogging, and speaking at conferences, which he initially underestimated as community work. He describes the effort involved in daily blogging at large events like JavaOne, which included late nights after sessions and parties. He viewed this work as an important responsibility tied to his press pass and a way to share insights widely with developers at the event.
Quote: “I mean, I’ve been writing books, of course, for as long as Java existed. I do a lot of blogging, I speak at conferences, and I guess that’s community work too. For many years, I would go to every JavaOne and I would snag myself a press pass and then I would blog about it. Every day. So it was actually, it was hard work.”

JCrete and Unconferences


Unconferences Foster Dynamic Learning
Timestamp: 00:29:00–00:29:57
Context: Cay praises the informal, interactive format of unconferences like JCrete in Greece. Events like these prioritize participant-driven discussions over the tight schedules and polished presentations of traditional corporate events. He explains that topics emerge from the attendees and their interests, with groups forming naturally around shared ideas, allowing for real-time adjustments like slowing down explanations or skipping known parts. These sessions are far more engaging than standard conference talks and better for deep learning.
Quote: “The interesting part is what goes on in the hallway. And so the unconference kind of says, okay, let’s give us more hallway. Let’s make it so that there is more interaction… That interaction is much more effective because I feel when I’m there, I can stop the speaker and say, that was too fast for me. Or can you dig into this a little bit further? Or we can all tell the speaker, oh, we know this part. Just move on. So you have a much better way to learn.”

JCrete’s Mix of Experts and Novices
Timestamp: 00:30:40–00:31:09
Context: Cay highlights how JCrete’s mix of experts and novices fosters innovation and learning, encouraging young programmers to participate despite feeling intimidated. He says that novices often bring fresh perspectives given their experience from emerging industries, while experts also gain insights into new applications. He urges employers to recognize the value of such networking opportunities.
Quote: “What most of these unconferences purposefully try to do is get a mix of experts and novices. Because for me, it’s also super interesting to know how someone who is just getting started, how they use the technology. Also, sometimes the people who get started, they get started in more innovative industries than what we already know… So we want young people in these events.”

Lifelong Learning Strategies


Setting Aside Time for Learning
Timestamp: 00:17:22–00:17:34
Context: Cay advises developers to dedicate time to learning and make deliberate choices about what to study, which is especially important given the rapid pace of technological change that never seems to stop. He says that this has been a constant in the field for decades, and while it can feel overwhelming, it’s normalized through consistent habits, which is different from some students who may need more guidance to adopt these practices early.
Quote: “You have to absolutely, you have to do two things, right? One is you have to set aside a certain amount of time every week, every month to learn. And secondly, you have to make choices what to learn and what not to learn.”

Task-Driven Learning for Developers
Timestamp: 00:21:16–00:21:54
Context: Cay shares his approach to learning new technologies by setting small, practical tasks, which he believes is an effective way for developers to acquire new skills. He gives examples like when he was starting with basic cloud deployments before advancing, noting that this method avoids the overwhelm of building full apps immediately and mirrors how people naturally learn through motivation and iteration via small tasks.
Quote: “I think this task-driven learning is how people learn. So when I first had to learn like a cloud, AWS and that kind of stuff, you know, I said, okay, I just want to have something running in the cloud. And then I said, okay, now I want to do something with the database. And so I set myself small tasks that were not of the ‘build an app lift’ because I didn’t yet know what app I might want to build.”

Final Advice: Hands-On Learning
Timestamp: 00:32:46–00:32:56
Context: “In his closing remarks, Cay reiterates the importance of hands-on, task-driven learning as a lifelong strategy for developers. He encourages figuring out personal goals and learning incrementally to achieve them, repeating the process to stay current. He ties this back to his own experiences in updating books and adapting to new tech over 30 years.
Quote: “No, really, my advice is to take the time to learn new stuff and do it by some hands-on process. Figure out what you want to do and then learn just enough to do that. Repeat and rinse.”

Nate Schutta: I Just Love to Learn!

Duke’s Corner Java Podcast: Nate Schutta: I Just Love to Learn!

Here’s my interview with Nate Schutta, an author, a teacher, a software architect, and Java Champion. Nate lives in the United States and teaches computer science to university students. He loves teaching and he loves learning, and he specializes in exploring the big picture of complicated systems in his career as a software architect. The conversation covers the Java community, the value for developers if they contribute to Java User Groups (JUGs), the benefits and some possible drawbacks of AI, and the engineering feat that is the Java Virtual Machine (JVM).

Nate has a passion for learning and here’s his advice for young developers and engineering students. “The fundamentals can’t be skipped! And they take time to learn! You just have to put in those hours to understand the basics, and then you can graduate to the more complicated stuff.”

Nate tripped over Java a bit in school and joined his first Java project right in his first job. Once he heard about this new Java project, he said: “Heck, yeah! I want in on that!”

Here’s the full Nate transcript. Here are all the interviews on Duke’s Corner.

Here are some links where the Nate interview appears in full or clipped: Apple | Flickr | Flickr | Substack | LinkedIn | LinkedIn | LinkedIn | WordPress | X | X | X | YouTube | YouTube

Quotes from the Interview

Here is a nice selection of quotes from the interview with Nate. When you talk to someone as articulate as Nate, it’s hard to select specific quotes to print in text. It’s best to just listen to all of the interview! Anyway, a quick scan across some text is nice too! Each quote includes a timestamp and some context on software architecture, learning, education, contributing to the Java community, Oracle’s role, and the use of AI in development.

  1. On the Role of a Software Architect and Trade-offs
    • Quote: “Our job on a software project is to see that bigger picture, to understand what those tradeoffs are, to sort of get out of some of the tribalism and evangelism around real specific technologies and be able to answer, well, why is that something we should use? How is that going to make things better for our business, for our developers, et cetera?”
    • Timestamp: 00:03:00–00:03:16
    • Context: Nate explains the essence of software architecture, emphasizing the need to balance trade-offs and maintain a broad perspective on system design to ensure decisions benefit both the business and developers.
  2. On Teaching Soft Skills for Architects
    • Quote: “A lot of being an architect is people skills and soft skills… I make my grad students read How to Win Friends and Influence People by Dale Carnegie.”
    • Timestamp: 00:06:54–00:07:23
    • Context: Nate highlights the critical role of communication and influence in software architecture, incorporating soft skills into his graduate-level curriculum by recommending a classic self-help book to prepare students for real-world human relations.
  3. On the Engineering Mindset and Curiosity
    • Quote: “The common thread I see through the best engineers that I’ve worked with or that I know, it’s this intense curiosity and it’s this passion to understand what’s going on here. It’s this tinkering mindset.”
    • Timestamp: 00:11:25–00:11:37
    • Context: Nate describes the mindset of great engineers, emphasizing curiosity and a desire to tinker as key drivers of learning, which, for some, can transcend formal education and is essential for mastering complex systems.
  4. On Teaching and the Value of Learning the Hard Way
    • Quote: “I think you maybe appreciate it more when you’ve had to do it the hard way. Like I teach a cloud class to at the [university] and I make my students do things the hard way first to introduce them to why we now have these easier and simpler abstractions.”
    • Timestamp: 00:15:27–00:15:42
    • Context: Nate explains his teaching approach, where he has students perform tasks manually (e.g., bare metal setups) before introducing tools like Docker, to help them appreciate the value of modern abstractions.
  5. On the Importance of Fundamentals
    • Quote: “The fundamentals can’t be skipped and they take time. You know, that’s the other part of this. I think people are in such a hurry to get past. It’s like you just have to put in those hours to understand the basics and then you can graduate to the more complicated stuff.”
    • Timestamp: 00:16:43–00:16:55
    • Context: Nate stresses the necessity of mastering foundational concepts before leveraging advanced tools, using photography as an analogy to illustrate that tools alone can’t replace understanding the basics.
  6. On His Love for Learning
    • Quote: “And I just love to learn stuff. And so for me, that opportunity to just be exposed to brand new things, the web, you know, we’re just starting to play around with that, being able to build an app that you can use on the web and we’re getting a whole new deployment topology and everything is brand new, like, heck yeah!”
    • Timestamp: 00:21:09–00:21:25
    • Context: Nate expresses his passion for learning, describing how his excitement for new technologies, like Java and web development early in his career and how that experience drove his career and continues to motivate him today. You can hear it in his voice, can’t you? :)
  7. On Java’s Evolution and Stewardship
    • Quote: “I think one of the things I find remarkable about Java… It has managed to evolve along with the types of programs that we’re writing and the demands that we place upon that. And I think that’s remarkable and speaks an awful lot to the stewardship. And I don’t think we give enough credit to the people behind that. It’s an incredibly complicated thing.”
    • Timestamp: 00:22:35–00:22:57
    • Context: Nate praises the stewardship of Java’s evolution, implicitly acknowledging the contributions of Oracle’s engineering team and others, for enabling Java to adapt to modern programming demands without breaking legacy systems.
  8. On the JVM as an Engineering Feat
    • Quote: “The JVM is amazing. And just the feat of engineering, what that’s enabled over its entire lifespan… the fact that it’s managed to evolve and grow and adapt to new programming styles and new approaches is amazing.”
    • Timestamp: 00:29:30–00:29:51
    • Context: Nate praises the Java Virtual Machine (JVM) as a remarkable engineering achievement, noting its adaptability over decades, which supports a wide range of applications and programming styles.
  9. On Simple Contributions to Open Source
    • Quote: “One of the simplest things you can do is you find a bug in the docs or in a tutorial and report it. Contribute a pull request for, hey, this isn’t right. It should be this instead… If you’ve ever gone through a tutorial and the steps are wrong or this command got changed and you’re spinning your wheels for two hours, well, you just saved a whole bunch of people a lot of time by fixing the docs.”
    • Timestamp: 00:35:24–00:35:49
    • Context: Nate encourages new developers to contribute to open source projects, even in small ways like fixing documentation. He emphasizes that these contributions are valuable and help others avoid frustration.
  10. On the Collaborative Nature of Software Development
    • Quote: “Me helping you doesn’t diminish me. It’s not a zero sum game. It’s not like I now have less because I’ve helped you. It’s better for both of us.”
    • Timestamp: 00:36:24–00:36:31
    • Context: Nate emphasizes the collaborative ethic of the Java community, where helping others benefits everyone, which reinforces the value of contributing knowledge and support.
  11. On Personal Passion for Teaching
    • Quote: “Oh, for sure… When I was probably in high school, I thought, well, I’ll be a teacher of some sort. I just didn’t know what.”
    • Timestamp: 00:39:42–00:39:53
    • Context: Nate reflects on his lifelong passion for teaching, which began in high school and led to his current role teaching graduate courses and engaging with the community.
  12. On Mentorship and Giving Back
    • Quote: “So many people helped me. So many people reached out a hand and helped me up. So my job is to turn around and help somebody else to and help them understand something or put them in a position to succeed.”
    • Timestamp: 00:41:56–00:42:16
    • Context: Nate reflects on his duty to mentor others, inspired by the support he received, emphasizing the importance of helping the next generation of developers succeed.
  13. On AI as a Learning Tool, Not a Shortcut
    • Quote: “You still have to have the expertise. You still have to have the fundamentals. People seem to think they can skip over the fundamentals and somehow AI will be the salve over all of that. And where I think we get in trouble is if you just blindly accept whatever the AI says.”
    • Timestamp: 00:45:04–00:45:24
    • Context: Nate discusses the role of AI in learning, cautioning that it should be used to enhance understanding, not to bypass learning core concepts, especially for students.
  14. On Using AI to Support Learning
    • Quote: “I love it in the sense of, if a student is using this, because actually one of my students did this last spring, he was doing some stuff with Kafka and he couldn’t quite figure out how to get it configured and so he asked you know chat GPT or whatever how do I configure this and like, oh here’s what you do and he’s like that’s awesome.”
    • Timestamp: 00:52:38–00:52:52
    • Context: Nate shares an example of a student using AI (ChatGPT) to learn Kafka configuration, illustrating how AI can save time and aid learning for those with foundational knowledge.
  15. On Encouraging Thoughtful Use of AI in Education
    • Quote: “I think that’s the worst thing you can do, frankly, as a teacher is to pretend it’s not there and all my students aren’t using it. They are. So figure out how to incorporate it, figure out how to give them that advice on how to use it intelligently and not just as a total crutch to avoid learning the concepts that we’re trying to teach you.”
    • Timestamp: 00:54:18–00:54:33
    • Context: Nate advocates for integrating AI into education thoughtfully and encourages teachers to guide students to use AI as a learning aid rather than a way to avoid understanding core concepts.
  16. On Encouraging Community Involvement
    • Quote: “I would just encourage folks to get involved, whether that’s attending your local user group, volunteering to give a talk at your local user group, contribute and be a part of this community. There’s nothing that’s holding you back and don’t let your experience level be an issue.”
    • Timestamp: 00:54:59–00:55:15
    • Context: In his closing remarks, Nate urges developers to engage with the Java community through simple actions like attending user groups or giving talks. Contributions at any level are valued in the Java community.

Jeanne Boyarsky on Java, Learning, and Contributing

Duke’s Corner Podcast with Jeanne Boyarsky, a Java developer and Java Champion based in New York City. The conversation covers the evolution of Java, some of the core features of the language and platform, contributing to the Open Source community, and how developers learn and keep up with the technology. Jeanne knew she wanted to do something with computers when she first visited the computer museum  — at age five! Check out her story right here. She’ll inspire you to focus and learn what you love.

Interview Archive