Tag Archives: developers

The Real AI Boom from Marc Andreessen

Marc Andreessen has been right about a lot of things. He co-invented Mosaic, which inspired Netscape and helped popularize the web that was invented by Tim Berners-Lee at CERN. He identified the concept of “software eating the world” well before most people knew what that even meant. In 2011, he predicted that within a decade five billion people would own smartphones. The number turned out to be six billion. Close enough. So when he sits down and tells us that 2025 was the most interesting year of his life, and that he expects 2026 to exceed it, maybe we should give him a quick listen.

Now, although Andreessen has been right about many tech trends, he’s also a supreme cheerleader and entertainer so you have to listen with a skeptical ear. I don’t think he’s malicious at all, but we have to question and observe carefully by doing our own research. And we have to watch how capital flows through markets and vendors because at present AI represents probably the biggest spend in recent years. Anyway, I enjoy listening to Andreessen because he forces me to think about what’s possible within a world that has gone mad. He’s always building. Contrast that optimistic view to the doomers who only wreck things and offer nothing of actionable value in return. That’s the tell. Marc hedges himself at many points, as well, so that’s good enough for me. It’s a reasonable starting point, anyway.

So, let’s take a look at his latest take on AI: Lenny’s Podcast: Marc Andreessen | The real AI boom hasn’t even started yet

In this recent conversation on Lenny Rachitsky’s podcast, Andreessen laid out a view of the AI moment that cuts across almost everything we hear in the megaphone media. The panic about job loss, he says, is based on a fundamental misreading of the world we actually live in. The fear that AI will make young workers obsolete gets it almost exactly backwards. And the comparison people keep making to past technological disruptions uses the wrong baseline entirely. His argument isn’t simple. But it is coherent. And once you hear it and understand his framework, the conversation we’ve been hearing about AI starts to look a little different.

What he Got Wrong

Before going further, it’s worth saying that Andreessen is the first to flag his own record. “I’ve been wrong about tons of things,” he says, joking about having buried his failures somewhere behind the shed. One example includes his famous debate with Peter Thiel about whether technological progress had stalled. Andreessen originally argued the optimistic side, of course, and insisted that progress was still happening. He now gives Thiel’s argument much more credit than he once did, at least in part. Thiel’s core claim was that we had plenty of progress in bits, meaning software, the internet, and digital technology, but very little progress in atoms, which is represented by the physical or built world. And the evidence supports him. Look around. We see bridges built in the 1930s. Dams built in the 1910s. Cities founded in the 1880s. “What have we done recently?” Andreessen asks. “Where are the new cities? Where are new dams? Where is the California high speed rail?”

He doesn’t mention that Japan and China and some nations in the European Union have had high speed rail for decades, but he surely knows that because he travels constantly. I found that missed opportunity odd. Perhaps he’s just commenting on how spotty the physical world has evolved. The infrastructure build out in China in recent decades dwarfs anything in the West, yet he fails to mention that as well. The built world, he says, is simply not that different from fifty years ago. That seems true. If you compare 1870 to 1930 or 1930 to 1970 the physical transformation was dramatic during both of those periods. Then compare 1970 to today, and it’s far less impressive than it feels. After hearing that I have to think he’s focused much more on the United States than the rest of the world.

The reason for this lack of progress, he argues, is structural. Red tape. Rules. Restrictions. Politics. Regulations. Unions, cartels, and monopolies that have every incentive to prevent rapid change. Healthcare is his favorite example. “By rights AI is going to have a dramatic impact on the healthcare system in very positive ways,” he says, “but large parts of the medical system are cartels.” Doctors are a cartel. Nurses are a cartel. Hospitals are a cartel. And then on top of that, all of these systems are increasingly acting like a government monopoly. ChatGPT is almost certainly a better doctor than your doctor today, he says, but it can’t get a license to practice medicine. It can’t prescribe medications. It can’t perform procedures. The technology is ready. The institutions are not. That’s an interesting take. But I’d much prefer my doctor leveraging AI as a tool instead of letting AI take the lead. There’s no way I’d trust ChatGPT running a spinal surgery on my back. No way. It’s not smart enough.

But this is also why he doesn’t expect AI to transform everything overnight. “There are real structural impediments in the economy and in the political system that prevent rates of change anywhere near the rates people had in the past.” Maybe AI causes us to revisit those assumptions for the first time in decades. That would be the optimistic view. It surely is time to build, as he once famously said. It’s true that the deep state is the impediment in modern times, but it’s also true that much of the previous innovation he’s talking about took place with no guardrails whatsoever. Keep in mind that much of the building that took place previously during the industrial revolution was driven by the very concept of “cartels” that he criticizes as the gatekeepers of today. If he were challenged on this, he’d admit it, I’m sure. I don’t think he’s trying to hide here. I just think he’s passionate about progress and anything that holds that back needs to be overcome.

The World is Not What You Think

To understand why Andreessen is still broadly optimistic despite all of the above, you first have to accept something uncomfortable. His view is that despite everything we’ve felt over the past fifty years, technological progress in the actual economy has been extraordinarily slow.

“It’s felt like we’ve been in a time of great technological change,” he says, “but actually if you look for evidence of that, like statistical evidence, analytical evidence, you basically can’t find it.”

Economists measure technological progress through productivity growth, which is essentially a mathematical expression of how much technology is actually moving the needle in the economy. And by that measure, the United States has been running at roughly half the pace it sustained between 1940 and 1970, and about a third of the pace it ran between 1870 and 1940. What about the smartphones and social media and cloud computing that felt so revolutionary? In terms of measurable economic impact, they barely registered compared to the era of electrification, railroads, and mass manufacturing.

So when people worry that AI is going to blow up the economy the way past technologies did, they’re actually comparing it to a fifty-year stretch of relative stagnation. The real baseline, the comparison that should inform how we think about what’s coming, is the period from 1870 to 1930. And people who lived through that era didn’t experience it as disruption. They experienced it as abundance.

“If you go back and you read accounts of 1870 to 1930,” Andreessen says, “people just thought the world was awash with opportunity.”

That may be true for some people, or even many people, but if you are familiar with that period in the United States, it’s hard to miss how disruptive and painful those times were for many people. Do you really think the air in New York City was as clean back then as it is now? Do you really think workers had a better life working the mills in Boston in the late 1800s than the pampered kids working in air-conditioned offices in Los Angeles or Silicon Valley now? I get Andreessen’s point, and I largely agree from a macro perspective. But it would be nice if he would at least recognize some of these inconvenient facts during his interviews. Technological progress isn’t always just about some innovation measured in a clean record-breaking economic report. What did it take to get there? Go back and talk to the people who broke their bodies to build all of that infrastructure from 1870 to 1930.

The Demographic Time Bomb

Now layer on top of this a second fact that rarely enters the AI conversation — parts of the world are depopulating. That’s the message in the media. It’s also why many people have accepted mass migration as a solution. We’ll leave that insanity for another day.

Nevertheless, birth rates across the developed world, and increasingly across the developing world, have fallen below replacement level. The United States, China, Japan, Korea, and many countries in Europe are all heading toward population decline over the next century. Andreessen argues that this creates a context in which AI isn’t just a nice productivity enhancement. It’s a necessity.

Here’s the part that almost nobody is talking about. Without AI, the more pressing economic crisis wouldn’t be too many jobs disappearing. It would be too few workers to fill them, too little consumer demand to sustain growth, and an economy gradually hollowing itself out. “You’d be looking at these very dystopian scenarios of an economy self-euthanizing over time,” he says. That is the world we were heading into before the models arrived. Here Andreessen gets quite negative and sees no alternative but to embrace the robots. That’s one view, certainly. But it’s also not the only view.

“If we didn’t have AI, we’d be in a panic right now about what’s going to happen to the economy,” he says. And the only reason we’re not in that panic is because the technology showed up at exactly the right moment. “The timing has worked out miraculously well. We’re going to have AI and robots precisely when we actually need them.”

This reframes the job loss anxiety entirely. In a world where working-age populations are shrinking and immigration is increasingly politically constrained, the workers who do exist are not going to be displaced. They are going to be scarce. “The remaining human workers are going to be at a premium, not at a discount,” he says.

The Job Loss Panic is the Wrong Panic

Andreessen is direct about what he thinks of the mainstream narrative on AI and employment. “The job-substitution, job-loss thing is very reductive. It’s an overly simplistic model.”

His reasoning is straightforward. We’ve been in an era of such slow economic change that even a dramatic acceleration from AI would only bring us back to historical norms, not blow past them. “Even if AI triples productivity growth in the economy, which would be a massively big deal, it would take us back to the same level of job churn that was happening between 1870 and 1930.” And that era was one in which people felt surrounded by opportunity, not displacement. Again, he’s focusing on one part of the equation here, which is expected given his own personal net worth. Does he see the other side? It’s hard to tell.

Even in the more radical scenario, where AI genuinely transforms entire industries overnight, the economics don’t point toward mass misery. They point toward something much stranger and more interesting, which is a collapse in prices. Deflation.

Think through the mechanics. Massive productivity growth means more output for less input. You’re substituting AI for human workers, or for entire categories of effort. The result is gluts of goods and services across affected sectors. And from those gluts, prices fall. The thing that costs you a hundred dollars today costs ten dollars tomorrow. “That’s the equivalent of giving everybody a giant raise, right? Because now they have all this additional spending power.” That spending power fuels growth, creates new fields, and leaves everyone materially better off.

And even if some unemployment does emerge at the far end of that process, the social safety net becomes dramatically cheaper to run, because the costs of everything it covers — healthcare, housing, education — have collapsed along with everything else. “There’s no scenario in which everybody’s just poor,” he says. “In fact, it’s quite the opposite.”

He’s careful to note that none of this is bold or precise prediction. “Everything I’ve just described is just a very straightforward extrapolation on very basic economics.” More likely, he expects the process to be incremental rather than overnight. But even the incremental version, in his view, is a fundamentally good news story. This is a typical view for those who have experienced the many boom-bust cycles in Silicon Valley.

The Philosopher’s Stone

Before getting into what people should actually do about all this, Andreessen takes a detour through the history of alchemy that turns out to be the most memorable passage in the conversation. Take Isaac Newton. He spent decades obsessed with a problem he could never solve. The problem was the philosopher’s stone. It’s a hypothetical process for transmuting lead into gold to convert the most common thing in the world into the most rare and valuable thing in the world. Newton never cracked it. Nobody has ever cracked it. But people have surely tried and that’s led to a great deal of fraud over the years.

“Now we literally have a technology that transfers sand into thought,” Andreessen says. “The most common thing in the world, converted into the most rare thing in the world. AI is the philosopher’s stone.” That may be a stretch. But I appreciate the optimism. He’s not being metaphorical, though.. Silicon is literally made from sand. And what comes out the other end is something that seems to be reasoning, creating, diagnosing, writing, and codind. Newton would have approved. Andreessen believes we’re largely there now, but I have to think we have a ways to go yet.

Jobs and Tasks

Here is where Andreessen makes a distinction that most people miss entirely, and it reframes the whole anxiety around careers.

A job, he says, is not the atomic unit. It’s a bundle of tasks. “Everybody wants to talk about job loss, but really what you want to look at is task loss. The job persists longer than the individual tasks.”

This has always been true. In the 1970s, no vice president typed their own correspondence. They dictated memos to secretaries, who typed and mailed them. When email arrived, the secretary’s role shifted. Instead of typing letters, secretaries printed incoming emails and hand-delivered them to the executive’s office, then typed the executive’s handwritten replies and sent them back. Today, executives handle their own email, while their assistants manage travel, logistics, and scheduling. Both roles survived. Both roles changed completely.

The question most people are asking, will my job disappear, is the wrong question. The right question is which tasks in your job are about to rotate out, and whether you’re ready to absorb the new ones that replace them. For people who work for Silicon Valley companies, this is normal. Life changes, sometimes radically, like clockwork every six months or so. It’s just normal.

The Original Calculator was a Person

Andreessen traces a history of coding that puts the current moment into context. The word “calculator” originally referred not to a machine but to a person. Rooms full of human beings performing mathematical calculations by hand, sometimes thousands of them, for insurance companies calculating actuarial tables, military logistics, and government agencies. He’s right about this. I can remember as a kid when my father took me to his office at Grumman Aerospace. I saw massive rooms of dozens of designers hunched over boards sketching aircraft schematics by hand. Things changed when computer-aided design and manufacturing (CAD/CAM) came along, which enabled one engineer to handle what used to take a whole team to achieve. It’s real.

Back to Andreessen. After human calculators came machine computers and machine code. The first computers had no programming languages but instead were programmed in ones and zeros. Then came punch cards. Then assembly language, which was essentially machine code with a layer of readable English on top. Then higher-level languages like C, which compiled down to machine code. Then scripting languages.

That last transition is the relevant one for the masses of developers. When JavaScript and Python and Perl arrived, there was a loud argument in the technical community about whether scripting was real programming. “Real programmers,” the objection went, write code that compiles to machine code. They do their own memory management. They understand every layer. Scripting was cheating because the complexity of previous tools was now buried in the system. That’s automation.

The scripting skeptics were wrong. Those languages swept the world. Most coding today happens through scripting languages that have abstracted away multiple layers of detail that programmers once managed by hand.

AI coding is the next layer. The day job of the best programmers right now is not writing code. It’s arguing with AI bots. “They sit there and they shift from browser to browser, terminal to terminal,” Andreessen says, “and their day job now is kind of arguing with the AI bots trying to get them to write the right code, then debug it, fix the problems, change the spec.” He’s stretching here again because even a casual conversation with advanced software engineers will reveal that they are still writing most of the code. True automaton of code generation will take more time. It’s coming though. And fast.

But if you don’t know how to write the code yourself, you can’t evaluate what the bots are giving you. You can’t tell when something is wrong. Multiple engineers have told me this as well. Your understanding still has to go all the way down as much as possible. If the goal is to be one of the best software people in the world, he says, you want to understand every layer of the stack, including how the AI itself works. And AI, conveniently, is your best friend for learning all of that. Ask it to teach you. Have it quiz you. “There’s never been a technology before where you can ask it: teach me how to do this thing.”

The Mexican Standoff

For the product managers, engineers, and designers who make up a large share of the technology workforce, Andreessen has a characteristically vivid way of describing what’s happening right now.

“There’s a Mexican standoff happening between those three roles. Every coder now believes they can also be a product manager and a designer because they have AI. Every product manager thinks they can be a coder and a designer. And then every designer knows they can be a product manager and a coder.”

And here’s the interesting bit. They’re all more or less correct. AI is now good enough at all three functions that someone with deep expertise in one area really can use it to do credible work in the other two. The irony, he notes, is that all three will eventually realize they can also replace their manager with AI, aiming the guns, as he puts it, up the org chart. That’s the next phase of the standoff. The question is not whether the roles are converging. They clearly are. The question is what that means for how people should build their careers.

Build an E, not a T

The conventional career advice for the past decade has been to become T-shaped. Develop deep in one discipline with broad familiarity across adjacent ones. During the conversation, Lenny proposed an evolution of that model, something more like an E or an F laid on its side with multiple genuine verticals of competency rather than just one. Andreessen agreed. It’s a useful frame and it’s also commonly known among tech types.

Scott Adams, the creator of Dilbert, put the underlying principle well. “The additive effect of being good at two things is more than double,” Andreessen says. “The additive effect of being good at three things is more than triple. You become a super-relevant specialist in the combination of the domains.”

Adams himself was a pretty good cartoonist and a pretty good student of business. Neither skill alone would have produced Dilbert. Together, they produced one of the most successful cartoons in history. In Hollywood, the directors who can also write are not just doubly valuable. They’re categorically different from everyone else.

Andreessen’s friend Larry Summers, the former Harvard president, frames it as an economic principle. Don’t be fungible, Summers would tell people. Don’t be a cog. Don’t be replaceable. Andreessen extends the point further. If you’re just a designer, just a product manager, or just a coder, you can in theory be swapped out. But someone who combines those domains in a way that’s genuinely rare becomes “massively important because you’re one of the only people in the world who can do that combination.” This isn’t easy to do. And keep in mind that everyone’s doing it so the ability to compete still remains at the core of any career.

All you can do is keep leveraging all the tools you possibly can. But there’s also something deeper here about how AI functions as a learning tool, not just a productivity tool. You can watch it work and learn from what it’s doing. You can ask it where you went wrong. You can run one AI against another, have one write the code and a second one debug it, and let them argue. These are skills, Andreessen says, that are going to become incredibly valuable.

Three Layers of What AI Actually Changes

When Andreessen talks to the most forward-thinking founders right now, he describes three distinct layers of transformation, each more profound than the last.

The first is AI redefining the product itself. Take Adobe and Photoshop, a decades long franchise in image editing. Is AI a feature to be added to Photoshop for smarter editing? Or do users just stop editing images entirely because they’re generating new ones from scratch? The answer varies by domain, but the question is being asked everywhere.

The second layer is AI redefining jobs within companies. If you have budget for a hundred coders, do you still want a hundred but now each doing ten times more? Or do you now only need ten? The best founders are working through this right now.

The third layer, the one he says hasn’t quite emerged yet, is AI redefining what a company even is. “Can you have entire companies where the founder does everything,” he asks, “because what the founder is doing is overseeing an army of AI bots?” Bitcoin is probably the most spectacular example. Instagram and WhatsApp achieved enormous outcomes with tiny teams. The holy grail of the one-person, billion-dollar outcome has existed as an aspiration for years. AI may finally make it achievable at scale.

Determinate vs. Indeterminate Optimism

Andreessen’s investment philosophy at Andreessen Horowitz is built on a framework he borrows, and gently argues with, from Peter Thiel. Thiel distinguishes between determinate optimists, people who believe the future will be better because they are going to do a specific thing to make it so, and indeterminate optimists, people who believe things will improve without being able to say exactly how. Thiel has historically been skeptical of the latter, seeing it as a polite name for wishful thinking.

Andreessen pushes back. A16Z’s strategy is firmly indeterminate optimist, and he doesn’t think that’s a weakness. The founders they back need to be determinate optimists. Elon Musk is the archetype. He’s building the electric car, building the solar panels, getting to Mars. He’s very specific, very committed. Founders get to run their companies and put their hand on the steering wheel. VCs don’t. And history remembers Henry Ford, not the seed investor who funded him alongside nine other car companies that failed.

But the virtue of indeterminate optimism at the portfolio level is that it runs as many experiments as possible, across as many smart people trying as many interesting things as possible. “The great virtue of the capitalist system, of the American economy, of Silicon Valley, is we don’t just have one determinate optimist and we don’t just have ten. We have a thousand, and then ten thousand.” You don’t have to pick the winner in advance. You have to make sure the system that produces winners keeps running.

Beyond the Human Ceiling

Andreessen admits he has always struggled a little with the concept of Artificial General Intelligence (AGI). There’s the cosmic definition, which is essentially the singularity, a moment where self-improving machines race so far ahead of human judgment that human decisions become irrelevant. He doesn’t think we’re heading there, at least not in the near-term. And then there’s the more general industry definition, which the co-founder of Anthropic has described as AI that can perform a broad set of the most economically valuable tasks as well as a human. We’re getting close to that, if we’re not already there.

But Andreessen thinks even that definition undersells what’s actually coming. The reason is that human skill level is not a theoretical ceiling. It’s a biological one.

Human fluid intelligence caps out around an IQ of 160. That’s the Einstein level. At 140, you’re looking at the world’s best research scientists and best-selling authors. At 130, the sharpest lawyers. At 110, a strong line manager. At 105, a careful small-business accountant. The range of impressive human cognition, 110 to 160, is determined entirely by what fits inside the human skull. There’s no theoretical limit beyond that. We’re just capped by our own biology.

Current AI models are already testing in the 130 to 140 range by some measures, Andreessen says. They will reach 160. And then, unlike humans, they won’t stop. “I think we’re going to have AI models relatively quickly that are going to be 160, 180, 200, 250, 300,” he says. And the question that follows from that, he says, is not threatening. Would the world be better off with more Einsteins or fewer? More, obviously. The same logic applies to machines that think at that level or beyond it.

He’s candid about what that means on a personal level too. “I know a bunch of people who are smarter than I am,” he says. “And I know it because when I talk to them, at a certain point I’m just like, this person is outthinking me and they’re going to keep outthinking me.” He reads ten books on a topic and forgets almost everything a few days later. His memory isn’t perfect. His processing has limits. Living with those constraints is just the condition of being human. Having tools available that don’t share those constraints is something we genuinely haven’t experienced before, and he thinks we’re not fully appreciating what that means.

What Marc Reads

Andreessen is an active consumer of information. His media diet reflects the same disciplined thinking he applies to everything else. He reads X for what’s happening right now, and old books for what’s timeless. Everything in the middle — magazines, newspapers, newsletters — he approaches with heavy skepticism. Go back and read old newspapers, he says. None of the predictions played out. None of it was actually relevant. The problem with the middle, he says, is that by the time a magazine article hits publication it’s often already out of date.

There is a big exception, though, which is directly accessing specific domain practitioners and the content they produce. These are the people who are actually doing real work and the things they’re writing or talking about. Podcasts, long-form conversations, technical newsletters written by people with real skin in the game. That’s where the real signal lives. “The world is awash in that today in a way that it wasn’t as recently as ten years ago.” People love talking about what they do, and for the first time in history, the rest of us have direct access to them.

What this actually means for you

The philosopher’s stone, the thing Newton spent his life chasing, turned out to be real. It’s just that what it transmutes isn’t lead into gold. It’s curiosity and effort and deep knowledge into something that, for most of human history, only a very small number of people ever got to become. Andreessen is not predicting a frictionless utopia. The structural impediments are real — the cartels, the red tape, the politics, the regulations — that prevent meaningful progress in atoms for the last half a century. And they will continue to slow things down. So, if you’re building in the physical world, budget accordingly, I guess.

But at the level of the individual, the picture is different. The person who goes deep in at least one domain, uses AI to extend genuine competency into two or three others, and treats the technology as a teacher rather than just a tool, that person can move into the best labor market in fifty years. Not because the world is getting easier but because they will be genuinely hard to replace.

“People who really want to improve themselves and develop their careers should be spending every spare hour at this point talking to AI,” Andreessen says. “Train me up. Superpower me.”

The real AI boom, he seems to be saying, isn’t the one that’s been happening or that we hear on social media and the news. Instead, it’s the one that starts when people understand what they’re actually holding in their hands.

We’ll see. I’m certainly all over it. Every. Single. Day.

Ideas Expressed in Code

Still the best quote I have about how to move an idea forward among a group of Open Source kernel developers. Pure gold.

Back on OpenSolaris years ago we had a lot of community conversations and flame wars that started out with the “Why don’t you just …” construction and then things spun around from there. At various points (usually after hundreds of such mails) the kernel engineers would occasionally chime in with a precise gem like this one below. Get to work. Write something.

[ogb-discuss] Re: [osol-discuss] Re: Project Proposal - (what is/was Indiana)

Bryan Cantrill bmc at eng.sun.com
Thu May 31 15:41:47 PDT 2007
Previous message: [ogb-discuss] obtaining a contributor grant


> More source code and less comments/opinions!

Yes, please. I don't think one can necessarily fault the OpenSolaris community for being bureaucratic; if a project wishes to lead with the process and follow with the prototype, life will naturally feel very bureaucratic. I (rather strongly) believe that this is _not_ the way that software should be developed; in software, ideas are expressed in _code_ -- the implementation _is_ the idea. If an idea has not been implemented, it is (in my opinion) premature to call it an "idea" -- it is rather a notion, a daydream or perhaps a fancy. If one has such a thought, the first order of business is not to send out proposals or give speeches or navigate through process but rather to sit down and write some code: build a prototype, share it with some like-minded people, incorporate their feedback, expand the community (note, lowercase "c") and iterate. If one does this and one's ideas are sound, the process (in my experience) naturally follows; people naturally gravitate to good ideas.

This is not to say that the OpenSolaris processes can't be used to help this process of iteration -- just that they should be used to help the process, not initiate it.

- Bryan

Hard Core, Real Work

How Elon Works | How Elon Thinks: There are endless lessons in these two podcasts about how Elon Musk works and thinks. Love him or hate him, there is still much to learn from such a powerful person who controls so many resources. Steve Jobs was a similar character in technology. Anyway, on the Musk links above, I like the “hard core” and “real work” bits best. I used to hear both of those words regularly when I worked on the OpenSolaris Project. In fact, many FOSS developers used those terms when I worked in the valley. I don’t hear them much these days, though.

Paul Bakker: Go Build a Lot of Stuff!

Duke’s Corner Java Podcast | February 3, 2026 | Paul Bakker: Go Build a Lot of Stuff!

This is the third in a short series of speaker profiles for JavaOne 2026 in Redwood Shores, California, March 17-19. Get early bird pricing until February 9, and for a limited time, take advantage of a $100 discount by using this code at checkout: J12026IJN100. Register. Sessions.

In this conversation, Jim Grisanzio from Java Developer Relations talks with Paul Bakker, an engineer and Java architect in California. Paul is a staff software engineer in the Java Platform team at Netflix. He works on improving the Java stack and tooling used by all Netflix microservices and was one of the original authors of the DGS (GraphQL) Framework. He is also a Java Champion, he’s published two books about Java modularity, and he’s a speaker at conferences and Java User Groups.

Java Is Everywhere at Netflix

Paul will present “How Netflix Uses Java: 2026 Edition” at JavaOne in March. The session updates previous year’s talk because Java keeps evolving at Netflix. “Netflix is really staying on the latest and greatest with a lot of things,” Paul says. “We’re trying new things. And that means there’s always new stuff to learn every year.”

Java powers both Netflix streaming and enterprise applications used internally and supporting studio teams. “Java is everywhere at Netflix,” Paul says. “All the backends, they are all Java powered.” Why Java? It comes down to history and practicality. The original team members were Java experts, but more importantly, “Java is also just the best choice for us,” he says. The language balances developer productivity and runtime performance. At Netflix’s scale with thousands of AWS instances running production services, runtime performance is critical.

Netflix engineers stay closely connected with development at OpenJDK. They test new features early and work with preview releases or builds before official releases. When virtual threads appeared, Netflix engineers tested immediately to measure performance gains. Paul says they give feedback on what works, what doesn’t work, and what they would like to see different. This just demonstrates the value of being involved with OpenJDK, and Paul says they have a really nice back and forward with the Oracle engineering teams.

The microservices architecture Netflix adopted years ago enabled the company to scale. This approach has become common now, but Netflix pioneered talking about it publicly. Breaking functionality into smaller pieces lets teams scale and develop services independently. Most workloads are stateless, which enables horizontal scaling. Production services for streaming often run several thousand AWS instances at a time.

Early on with Java Applets

Paul’s coding journey started at 15 when he got his first computer and wanted to learn everything about it. Working at a computer shop repairing machines, the owner asked if he knew how to build websites. Paul said no but wanted to learn. He was curious about everything that involved computes. Java applets were hot back then. With nothing online available, he bought a book and started hacking away. “It was so much fun that I also decided right at that point basically like, oh, I’m going to be an engineer for the rest of my life,” he says.

That’s clarity for a 15-year-old. And it’s remarkable. But Paul says it felt natural. He just started doing it, had such a good time, and knew that was what he wanted to do. When he started university around 2000, right during the dot-com bubble and crash, professors warned students not to expect to make money in engineering because the bubble had burst. Paul still remembers how funny that seems now. You can never predict the future.

Initially, he learned Java and PHP simultaneously. Java powered client-side applications through applets while PHP ran server-side code. The roles have completely reversed now.

Engaging the Community

Paul attended his first JavaOne in 2006. “Those were really good times,” he says about the early conferences when everything felt big and JavaOne was the only place to learn about Java. Back then, around 20,000 people would travel to San Francisco every year. It was the one and only place to learn what was new in Java. All the major news would be released at JavaOne each year. The world has changed. Now information spreads instantly and continually online, but Paul misses something about those early days.

The more recent JavaOne conferences offer something different but equally valuable. Paul points to last year’s event in Redwood City as a great example. While the conference is still big, it’s small enough that attendees can actually talk with the Oracle JDK engineers and have deeper conversations. The folks who work on the JDK and the Java language are all there giving presentations, but they’re also totally accessible for hallway chats. “That makes it really interesting,” Paul says. This direct access to the people building the platform distinguishes JavaOne from other conferences.

Java User Groups also played an important role in Paul’s development. He lived in the Netherlands before moving to the Bay Area nine years ago. In the Netherlands, the NLJUG (Dutch Java User Group) organized two conferences a year, J-Spring and J-Fall. Paul would go to both every year. That was his place to learn in Europe. He has been continuing that pattern right up until now, which is why he is speaking at JavaOne again.

Open Source software has also been another major aspect of community for Paul. He has always been active in Open Source because he says it’s a fun place to work with people from all over the world solving interesting problems. Besides being a critical part of his professional career, it was also his hobby. Paul says the Open Source aspect with the community behind it is maybe his biggest thing that he really enjoyed over the years.

AI Throughout Development

AI now occupies much of Paul’s professional focus. At Netflix, engineers use AI tools throughout the development lifecycle. Paul uses Claude Code daily, though other developers prefer Cursor, especially for Python and Node work. Most Java developers at Netflix work with Claude Code. The tools integrate with GitHub for pull request reviews, help find bugs, and assist with analyzing production problems by examining log files.

Paul describes using AI as having a thinking partner to t all to and code with. Sometimes he needs to bounce ideas around, and the AI gives insights he might have missed or suggests additional issues to consider. For repetitive tasks like copying fields between objects, AI handles the grunt work efficiently. “That’s the nice thing about an AI,” Paul says. “While a person would probably get really annoyed with all this feedback all the time and like having to repeat the work over and over again, but an AI is like, fine, I’ll do it again.”

Go Build a Lot of Stuff!

When asked about advice for students, Paul’s answer comes quickly and has not changed much over the years. “I think what I really recommend is just go and build a lot of stuff,” he says. “The way to get to become a better developer is by doing a whole lot of development.”

That’s timeless advice students can easily adopt no matter how the modern tools for learning have changed. Paul had to go to a bookstore and buy a book to learn programming. Students today have AI tools to help them and advanced IDEs. But the fundamental principle remains the same, which is to build interesting applications. Paul recommends that students come up with a fun problem and just build it. You learn by making mistakes. You build a system, reach the end, and realize the new codebase already struggles with maintainability. Then you ask what you could have done differently. Those real-life coding experiences teach you how to design code, architect code, and write better code.

Paul also suggests that students use AI tools but not blindly. Do not just accept whatever an AI generates. Instead, try to understand what came out, how it could have been done differently, and experiment with different approaches. Use the tools available but really understand what is going on and what options you have.

Some students and even practicing developers worry that advanced tools might eliminate their future role as developers. Paul says that nobody knows exactly how things will look in the future because tools get better almost every day now. But AI tools are just tools. Someone needs to drive them and come up with the ideas they should build. Plus, the tools at present are far from a state where you can hand them a task, never look at it again, and have everything work perfectly. Substantial hand-holding is involved.

“Is our daily work going to change? Very likely,” Paul says. “That’s already happening.” But he tries to see this change as a positive thing. “It’s a new tool that we can use. It makes certain parts of our job more fun, more interesting. You can get more things done in some ways and be open to it.”

Why Java Works

At the end of the conversation, Paul answered a simple question — Why Java? What makes it great? — with a simple and direct answer: “Java is the perfect balance of developer productivity and runtime performance.”

That balance matters where Paul works at Netflix. But it also matters for students learning their first language, for teams building enterprise applications, and for developers choosing tools that will sustain long careers. Paul’s career started with Java applets 20 years ago when he bought a book and started hacking away. The language and platform has evolved dramatically since then, moving from client-side applets to powering massive backend services that stream entertainment to millions globally via Netflix. Through all that change, the core appeal remains — you can build things efficiently for many platforms and those things run fast.

Key Quotes from the Conversation

On Java at Netflix
“Java is everywhere at Netflix.” (00:01:25)
Context: Paul describes how Java powers both the streaming backend that consumers use and the enterprise applications for internal and studio use.

On Why Netflix Chose Java
“However, Java is also just the best choice for us. If you think about backends, Java is a really good mix of developer productivity on the one hand, but also runtime performance.” (00:02:20)
Context: Explaining why Netflix continues to use Java beyond historical reasons, emphasizing the balance between development speed and execution performance.

On Building Career and Reputation
“I just started hacking away. And it was so much fun that I also decided right at that point, basically like, oh, I’m going to be an engineer for the rest of my life.” (00:05:35)
Context: Paul recalls discovering programming at age 15 through Java applets and immediately knowing this would be his career.

On Early JavaOne Conferences
“My favorite moments from JavaOne are actually way back in time in 2006, 2007, when this was all so big and it was the place to learn.” (00:25:21)
Context: Reflecting on the importance of JavaOne in the mid-2000s as the primary venue for learning about Java developments before information became instantly available online.

On Recent JavaOne Conferences
“I think last year was a really good example. It was the first time in Redwood City. I think that worked out really well. The folks who actually work on the JDK and on the Java language, they’re all there and they’re giving presentations, but they’re also accessible to like have a chat with.” (00:13:49)
Context: Describing how recent JavaOne conferences offer direct access to the core Oracle JDK engineers and platform developers, which makes deeper technical conversations convenient.

On Advice for Students
“I think what I really recommend is just go and build a lot of stuff. The way to get to become a better developer is by doing a whole lot of development.” (00:21:32)
Context: Providing timeless advice that applies regardless of whether students use books, online resources, or AI tools to learn.

On Using AI Tools
“That’s the nice thing about an AI, while a person would probably get really annoyed with all this feedback all the time and like having to repeat the work over and over again. An AI is like, fine, I’ll do it again.” (00:19:04)
Context: Describing the patience of AI tools compared to human collaborators when iterating on code.

On AI and Developer Jobs
“But also, they’re just tools. And someone needs to drive these tools and come up with the ideas that these tools should be building.” (00:23:39)
Context: Addressing concerns about AI replacing developers by emphasizing that tools need human direction and creativity.

On Staying Positive About Change
“Yeah, it’s a new tool that we can use. It makes certain parts of our job more fun, more interesting. You can get more things done in some ways and be open to it.” (00:24:08)
Context: Encouraging developers to embrace AI as an enhancement to their work rather than a threat because no one can predict the future.

Rapid Fire: Why Java?
“Java is the perfect balance of developer productivity and runtime performance.” (00:24:45)
Context: Paul’s concise answer to what makes Java great in a rapid-fire question round at the end of the podcast.

Rapid Fire: AI Advice
“I think it’s a useful tool. It is changing the way we do development, but I think it can make our jobs more interesting and embrace it and see in which ways you can use it.” (00:24:56)
Context: Paul’s perspective on how developers should approach AI tools.

Rapid Fire: Advice for Students
“Build a lot of stuff. The way to become a better developer is to develop a lot, like build all the things that you can come up with.” (00:25:10)
Context: The core message Paul sends to coding students.

Duke's Corner Java Podcast
Duke’s Corner Java Podcast

Paul Bakker: X, LinkedIn | Duke’s Corner Java Podcast: Libsyn | Jim Grisanzio: X, LinkedIn, Website

Marit van Dijk and Anton Arhipov: 25 Years of IntelliJ IDEA

Marit van Dijk and Anton Arhipov: 25 Years of IntelliJ IDEA | Duke’s Corner Java Podcast | January 29, 2026

This is the second in a short series of speaker profiles for JavaOne 2026 in Redwood Shores, California, March 17-19. Get early bird pricing until February 9, and for a limited time, take advantage of a $100 discount by using this code at checkout: J12026IJN100.

JavaOne: Register | Sessions

In this conversation, Jim Grisanzio from Java Developer Relations talks with developer advocates Marit van Dijk and Anton Arhipov from JetBrains about the 25th anniversary of IntelliJ IDEA, the latest features of the IDE, Anton’s upcoming session at JavaOne in March, and their perspectives on JavaOne as the premier conference for Java developers.

25 Years of IntelliJ IDEA

Just as Java turned 30 this year, IntelliJ IDEA is now 25 years young! Not every technology survives that long, and even fewer thrive while doing it. But both Java and IntelliJ IDEA are doing just that. The secret to this longevity for IntelliJ IDEA, according to Marit van Dijk and Anton Arhipov, comes down to something simple but demanding — staying current with the Java ecosystem and engaging the massive Java development community around the world. The main reason for their success is the huge effort engineered into the platform to produce the technologies that developers need while at the same time staying with all the bleeding edge stuff happening inside the Java community.

This commitment reaches beyond just supporting new Java versions. The IntelliJ IDEA team works on preview features even though specifications sometimes change during the preview process. When Oracle moved to a six-month release cycle for OpenJDK about eight years ago, IntelliJ adapted smoothly since their teams were already involved with the OpenJDK community. Marit says that new release cycle actually streamlined their work. They already knew about preview features and could start developing support upfront, not at the very last moment. This let them iterate alongside the community rather than chasing after it.

The company also collaborates directly with other community members — such as framework developers, build tool teams at Maven and Gradle, and even Google — to implement best practices straight into the IDE. Maven 4 is not even released yet, but IntelliJ already has support ready with migration features to help developers make the transition. Anton says that this effort means that support is not only working with the new version of a technology but also being smart about how you use it. The IDE catches outdated patterns and deprecated APIs and also offers quick fixes to migrate code with a single keystroke.

First and Lasting Impressions

Both Marit and Anton started working at JetBrains years after they had already become devoted IntelliJ users. Their first impressions of the IDE moved them deeply and remain with them today.

For Anton, his first reaction to using IntelliJ IDEA was immediate. “In one word, wow, this is smart. This is an IDE that understands code.”  That intelligence in the software became the foundation of his relationship with the technology.

Marit had a similar experience when she switched to IntelliJ IDEA. She had used other IDEs before and they were perfectly fine, but IntelliJ seemed different. “I found that it was actively helpful with the code inspections and quick fixes and helping me when my code didn’t compile or preventing me from making mistakes. And I was sad that I didn’t switch earlier, like years earlier. And I’ve been raving about it ever since. And now they pay me to do that. So, you know, everybody wins.”

AI and the Future of Development

As usual in these conversation, we turned to artificial intelligence and its growing role in software development. Anton will explore this topic in depth at his JavaOne session titled “Spec-Driven Development With AI Agents: From High-Level Requirements to Working Software.” Everyone knows that the AI landscape is changing fast, but things are actually getting simpler, Anton says. Developers can now get better results with less effort and less complex workflows using AI agents. Models are improving at guessing developer intent and reducing the need for careful constraint-heavy prompting.

But Anton sets realistic expectations about AI. When asked whether his session targets junior or senior developers, he says that “we are all juniors in this regard.” The field is so new that nobody can claim years of expertise with AI development tools.

Marit emphasizes another crucial principle about AI-generated code. “You are still responsible for the code,” whether you write it or an agent writes it. It has your name on it. AI does not diminish developer accountability or the need for developers to remain highly skilled in their craft.

Anton adds another dimension about integrating AI with development tools. “AI without the IDE is kind of unreliable, but the IDE without AI is unproductive.” The key, he says, is to fuse these things together leveraging the benefits of both for better productivity. The context the IDE provides and its understanding of your project structure and dependencies makes AI suggestions more relevant and actionable.

JavaOne: Where the Community Comes Together

Anton will be presenting at JavaOne 2026 in March, and both he and Marit shared their perspectives on what makes the conference special.

For Marit, JavaOne has always been unique. The “who’s who of Java” will be there, she says. Last year’s conference-ending “Meet the Architects” panel particularly stood out. The audience could ask Oracle Java architects basically everything about Java for over an hour. This kind of access to the core engineers building and shaping the future of the language is something you would not normally get at any other conference.

Anton shares his view that JavaOne has always been the conference to get all the news about Java. He has always viewed the event as the place where you get condensed information about what’s going on with Java all in one place — the language, the platform, the standards, the frameworks, and the community.

Community and Looking Forward

Marit and Anton maintain close relationships with the developer community through conferences and Java User Groups. Marit says that they have many JUGs in the Netherlands, and many of them invite her to come and speak at their meetups throughout the year. Also, when they travel somewhere for a conference, they look for opportunities to combine that trip with local JUGs to speak there and connect with people. This direct engagement with the open Java community lets Marit and Anton talk to developers directly, see how they can help them better, understand what developers are struggling with, and take that feedback back to the engineering teams. The same authenticity extends to how JetBrains approaches IntelliJ development. The engineering team maintains close relationships with framework developers and library maintainers and OpenJDK to ensure that when new versions release, IntelliJ users have good support from day one.

As IntelliJ IDEA celebrates 25 years, the development continues. They keep releasing new features with every version: the Spring Debugger that helps developers understand their Spring projects at runtime, Command Completion that enables developers to perform commands without memorizing shortcuts, and more. The anniversary celebrations for the teams have included parties with cakes featuring old logos, a game plugin that lets developers play video games while AI generates their code, and social media campaigns engaging the global community. For developers curious about IntelliJ IDEA, Marit and Anton encourage people to subscribe to the JetBrains YouTube channel where they regularly produce videos explaining new features.

This 25-year milestone represents more than just history. It represents an ongoing commitment to understand code, support developers, build the Java community, and evolve alongside the entire ecosystem. This pattern is pervasive among Java developers and also the many companies offering developers advanced tools. The smart IDE that so impressed Anton and Marit years ago continues to get smarter — right along with many other tools and technologies that are growing as a result of the Java platform itself.

Anton Arhipov: X , BlueSky, Linkedin
Marit van Dijk: Website, Linkedin, BlueSky, X 
Jim Grisanzio: X, Linkedin
Duke’s Corner Java Podcast: Libsyn
Oracle Java Developer Relations: Inside.java, Dev.Java, Learn.java
Topics Discussed: IntelliJ IDEA 25th Birthday, The Java Dukes, What’s new in IntelliJ IDEA 2025, Spring Debugger, Command Completion

Duke's Corner Java Podcast
Duke’s Corner Podcast

Jeanne Boyarsky: Get Ready for Java 25 Certification

Jeanne Boyarsky: Get Ready for Java 25 Certification | Duke’s Corner Java Podcast, January 21, 2026

This is the first in a short series of speaker profiles for JavaOne 2026 in Redwood Shores, California, March 17-19. Get early bird pricing until February 9, and for a limited time, take advantage of a $50 discount by using this code at checkout: J12026DCP. RegisterSessions.

In this conversation, Jim Grisanzio from Java Developer Relations talks with Jeanne Boyarsky, a Java developer, an author, and a Java Champion based in New York City. Jeanne previews her JavaOne session, which will be a Hands on Lab for Java 25 certification. Previously, Jeanne was a guest on Duke’s Corner in January 2024: Jeanne Boyarsky on Java, Learning, and Contributing.

Preparing for Java 25 Certification

Jeanne will be running a hands-on lab about Java 25 and getting ready for the certification: Becoming One of the First Java 25 Certified Developers in the World (or Learning New Features). The session will cover features added to the language from Java 17 to Java 25. Although the certification has not been announced yet, Jeanne is already preparing for it. “You can be one of the first people in the world to be certified if you come to my talk and learn about it and are ready when the test comes out,” she says.

The lab will walk through tricky questions and edge cases featuring new functionality, with coding practice to explore the features directly. Even if you are not planning to take the certification test, the lab provides a good way to learn about the new features. The session is designed for beginners with one to three years of experience.

Top Features in Java 25

Several features particularly excite Jeanne. She highlights scoped values, which she describes as “a good jump from thread local in order to be able to share code in a nice, safe, contained way.” She also appreciates unnamed variables and unnamed patterns because developers no longer need to use annotations to suppress warnings for unused variables. “You can just use an underscore,” she says.

Jeanne is particularly interested in stream gatherers because streams are one of her favorite features in Java overall. She was excited when stream gatherers were in preview, and now that they are officially released, she can use them in her job. “Nice that the excitement hasn’t worn off, right?”

Among the new features, Jeanne is especially interested in the new main method, as described in JEP 495: Simple Source Files and Instance Main Methods. “I’m super, super, super excited about the new main methods where you don’t need a class and you don’t need the whole static void mess,” she says. This change makes writing code more succinct.

Making Java Accessible to Students

This change in how Java handles the main method enables new developers to learn Java faster. Jeanne volunteers at a high school teaching kids how to code in Java. In the past, teachers had to tell students: “Alright, public class foo, public static void. Don’t worry about what any of that means. We’ll tell you later.” But Jeanne says that curious kids would ask what it meant, and teachers could only say that comes later.

Now, students start with void main, braces, and IO print line. “It’s obvious what everything does,” Jeanne says. Void means it does not return anything, which makes sense to students. They can even use the Java Playground and start with just IO print line. When they move to the command line or an IDE, they only need the void main part without discussing the word class until they are ready to learn about classes and objects.

“It makes their first impression of the language so much better, and it makes it so much faster and easier for them to get started,” Jeanne says. She particularly appreciates the Java Playground because students do not need anything installed on their computers to start. They can write print lines, loops, and control structures, and by the time teachers ask them to install something, they are already invested in programming. “It’s fun.”

Jeanne calls the Java Playground “awesome” and says it’s a “really nice utility” even for experienced developers. She uses it herself for quick tests when she does not want to open an IDE.

JavaOne on Oracle’s Campus

When asked about JavaOne, Jeanne describes the conference as moving to California last year, just outside San Francisco on Oracle’s campus. “The weather was great, which is awesome because I live in New York City. There’s snow outside right now,” she laughs.

The venue particularly impressed her. “It was nice because it was on Oracle’s campus. You got a feel for it. It was pretty. There was a lake. There was a lot of areas to connect with people inside and outside.” The conference was held largely in one building, with lunch in another building nearby, which made it easy to engage people repeatedly. “Even if you don’t know people, the fact that they’re at JavaOne means they’re interested in Java. So, you can go over to anyone and introduce yourself.”

One of Jeanne’s favorite memories from a previous JavaOne was meeting Duke and seeing her book in the Java bookstore.

Advice for Students

When asked for advice for students learning computer science, Jeanne recommends learning the fundamentals while using AI to help. “Rather than using AI to write the code, have it give you practice questions or do code review or ideas of projects,” she suggests.

Students also often ask what professional developers do daily. Her answer provides a realistic picture of professional software development. “Every day is a little bit different, but most days include a mix of meetings, working with my coworkers, code reviews, writing code, now with AI,” she says. Problem solving takes many forms, from performance questions like “Why is this slow?” to security concerns about making systems more secure.

A significant part of her role involves understanding what users actually need. “A lot of the time users ask for what they think they want and not what they actually want,” Jeanne says. Through user interviews, she works to understand what they are trying to accomplish, which often leads to better solutions than what they initially requested. “So not just building what you’re told is a huge thing, especially as you become more senior in your career,” she says. The goal is to make users productive and happy, not just to code.

Technology keeps changing, and for Jeanne, that constant evolution makes the work fun. She has embraced AI tools as coding assistants, using them for pair programming, generating tests, and suggesting next steps. When her team piloted coding assistants, they focused on choosing a tool rather than waiting for the perfect tool. “The important thing is to get a tool and get people going and using it and being more productive,” she says. The learning curve is not high, and the tools pay for themselves almost immediately.

However, Jeanne says that it’s important to understand what you are doing rather than using AI to replace that understanding. “It’s about understanding what you’re doing and not using the AI to replace it because at least with the coding assistance, it’s right 90, 95% of the time,” she says. She talked about an example of asking AI to generate a regular expression while pairing with a junior programmer. The AI started writing it properly but then made an error. “I noticed it right away because I know what correct is,” she says. After giving it another prompt with a hint, it produced the correct result. Without knowing what correct looks like, developers cannot effectively verify and fix AI-generated code.

The AI Hype Cycle

Regarding concerns about AI making developers obsolete, Jeanne is pragmatic. “I’ve heard that enough times that I’m a little skeptical,” she says, adding that this is the third or fourth time some technology has been predicted to take all the jobs. Instead, she sees AI as enabling developers to accomplish more and make users happier. She has a big backlog “that goes on forever.” She says it would be great if we could get more of it done and in the hands of customers.

“I think we’re at that phase in the hype cycle for AI where people are talking about AI like it solves all your problems, [but] it solves some of your problems. But because there’s less acknowledgement of the ones it doesn’t solve, it’s easier to have that skepticism.” When asked if AI represents a paradigm shift or just the latest tool, she responds: “Right now, I think it’s the latest tool, but I do think we’re going to get to the point where we’re programming at a higher level.”

Building Great Teams

Over the years I’ve worked on teams in construction, marketing, publishing, and software. I ran my own excavating business, built and sold homes and raw land, drove multiple big-rig trucks, and fixed heavy equipment as a mechanic. I also wrote magazine articles and managed publicity campaigns for companies and universities and worked with governments and media outlets around the world. Later I joined Sun Microsystems and Oracle, where I helped build Free & Open Source Software (FOSS) communities, ran global developer conferences, hosted multiple podcasts and video channels, and interviewed hundreds of engineers, scientists, physicians, and other technical professionals.

This disparate mix of experiences has shown me what separates strong teams from weak ones. Strong teams produce excellent work when they have clear roles, open communication, and a genuine focus on merit, quality, and service. But weak teams fall apart under poor leadership, bad planning, or cultures that punish people for speaking up. The best teams make life easier for everyone. People grow, the work gets better, and the whole group thrives. When I join a team, I look for these qualities. If they are missing, I move on if possible. I don’t stick around in places that waste my time.

Building a Strong Team Culture

The strongest teams come from managers who build their teams with purpose and maintain them with steady effort and improvement. These managers create a culture centered on merit, collaboration, and real chances for individuals to grow. They make sure everyone can share ideas and skills, regardless of position or experience. Effective managers also judge work by its quality, not by politics or personality. That builds trust and draws out the best from the team. It also sends a message that merit is the standard, not favoritism.

It starts with hiring. This lays the groundwork for everything that follows. Innovative managers tap current team members early in the hiring process. They collect input from everyone before interviews, include several people directly in discussions with candidates, and review feedback as a group afterward. This gives the entire team ownership and helps find people who fit the culture. Unfortunately, many managers skip this step entirely, which can weaken the team and reduce retention of people who have been producing great work all along. Nothing is more frustrating to the team than having to welcome a new team member you know nothing about and who may not fit.

When a new person starts, effective managers provide solid support right away. They pair the newcomer with an experienced teammate to speed up learning and answer questions as they arise. They share the team’s history, past projects, and major wins so the new member gets the context fast and begins contributing soon. This early investment in onboarding shapes how people view the team and their role in it for years to come.

Overall, the team’s structure, projects, and tasks should be well documented by the manager on an internal wiki that everyone can contribute to. Everyone should know what everyone else is doing. Clear roles are important. They cut down on confusion and lost time. Strong managers define and document these responsibilities, and then let people learn through actual work rather than just instructions. It’s natural for teams to evolve, so these managers watch the dynamics and adjust as needed. They shift workloads when necessary, invest in skills that matter, and improve processes continuously. They create safety so people can admit mistakes or question assumptions without fear. Most of all, managers like this foster pride in high-quality work. They value excellence in every detail, from code to documents to any other output team members produce. They also run blameless reviews to learn from issues without blaming individuals, which encourages honesty and speeds improvement.

What Effective Managers Do

Managing people takes real skill, study, and practice. The best managers balance care for the team with care for the work. They track short-term needs and long-term goals and opportunities at the same time. They stay reliable and visible and avoid jumping between tasks in ways that kill momentum. They protect focused time for the whole team, including themselves, because deep work that generates the most value requires sustained attention that constant interruptions destroy.

These managers look at data to make decisions, but they also know that numbers miss the full picture. People and projects have hidden layers that do not show up in reports. Effective managers welcome needed change but offer stability when things feel shaky. They plan for surprises and guide the team through tough shifts while keeping core goals clear. This balance between flexibility and steadiness marks the difference between managers who keep teams grounded and those who let chaos run wild. They shield the team from distractions and politics that drain energy without adding value. They advocate for people, block unnecessary pressure and distractions, and they keep communication solid especially in rough times. They reply to messages quickly and completely, share clear updates, and use shared channels so no one gets left out. They know instinctively that weak communication breaks trust fast, and once that erodes, it takes months or years to rebuild — if it can be at all.

Conflicts happen in any group, but capable managers handle them directly and calmly. Dodging problems makes everything worse because unresolved tension spreads through the team like a slow poison and can kill a team over time. Performance reviews receive serious attention from these managers. They give honest feedback tied to observable work and real impact. Nothing surprises anyone in a formal review because the conversation has been ongoing throughout the year. They deliver hard feedback privately and early when course corrections still feel manageable rather than catastrophic.

What Team Members Contribute

Everyone helps the team succeed. Strong managers set the tone, but capable contributors are encouraged to take initiative, own their tasks, and support colleagues in ways that multiply the team’s effectiveness. Everyone arrives prepared, on time, and engaged in meetings. They follow simple etiquette, mute when not speaking, and give full attention to the discussion at hand. They join team events to strengthen relationships and step up for tasks that build skills or help others, even when those tasks fall outside their formal job description.

They avoid multitasking because it harms productivity and leads to shallow work that satisfies no one. Instead, great performers handle several commitments by completing them one after another and meeting deadlines through focus rather than frantic juggling. They stay flexible when priorities change, which happens more often than anyone likes. They seek feedback on their work and offer constructive input to others, creating a culture where improvement becomes normal rather than threatening.

Team members make their schedules known, set regular hours, and stay reachable during work time so colleagues can count on them. In distributed setups, everyone posts updates and respond promptly because remote work depends on trust that people will follow through without constant supervision. Communication drives progress in ways that matter more than individual brilliance. Contributors share their current work, ask for help when needed, and clarify expectations before diving in. When they discover a problem, they articulate the issue and show up with a fix. They use team channels for group topics so everyone benefits from the discussion so issues are resolved fast. They send short status updates that keep people informed without overwhelming them. They praise in public and give critical notes privately, which builds morale while still addressing problems. They follow processes, document work well, and connect with outside communities when projects require it, which helps to bring fresh perspectives back to the team.

What First-Line Managers Handle

First-line managers set the culture and deliver results in ways that shape daily experience more than any executive mandate. They balance growing people with shipping projects, and they know that neglecting either one undermines the other. They run regular one-on-ones that go beyond surface chatter to address real concerns. They provide steady feedback throughout the year and ensure annual reviews hold no surprises because the conversation has been open and continuous. They mentor directly or link people to solid mentors who can offer the guidance they themselves cannot provide.

They open space for real talks about work struggles or personal matters that affect performance, recognizing that people bring whole lives to their jobs even if private issues go unstated. They back career moves, even to other teams, because keeping someone in a role they have outgrown helps no one. They keep roles defined and show how work ties to bigger goals so people understand why their efforts matter. They build unity through shared experiences that create bonds beyond the purely transactional. They resolve conflicts fairly, involving HR only when required by handling most issues themselves before they escalate.

First line managers are active and observant. They plan for turnover because people leave, and pretending otherwise leads to knowledge loss that can cripple the team for a time. They cross-train to share knowledge across team members so no single person becomes a bottleneck. They track time off to prevent gaps that leave the team understaffed during critical periods. For projects, they craft a clear vision with team input rather than dictating from above or focusing on their favorite employee. They assign tasks wisely based on skills and growth opportunities. They track progress without hovering, trusting people to deliver while staying alert for problems. They use practical metrics that reveal actual progress rather than vanity numbers that look good in reports but mean nothing. Unlike executives or second line managers, these first line guys are much more involved in the day to day operations, and so they must be sensitive to changes taking place under the surface of all the activity.

They push for needed resources and represent the team upward, making sure leadership understands what every member of the team needs to succeed. It’s obvious to individual contributors when they are left out of upline reporting, and these managers know that and never make this mistake. They communicate consistently with the team, their bosses, and peers across the organization. They raise problems early when solutions still come cheap rather than waiting until a crisis forces expensive fixes. They foster trust across groups because most work now requires collaboration that crosses team boundaries. In distributed teams especially, they ensure meetings feel fair by rotating times and giving remote voices equal weight considering their time zones. They spell out confidentiality clearly so people know what they can share and what must stay private.

Running Effective Meetings

Meetings move communication forward when done well, but poor ones drain time and energy without advancing any real purpose. Capable managers send agendas in advance so people can properly prepare and contribute meaningfully. They share notes after the meeting and archive them for reference, which focuses the conversation and lets absentees catch up on what they missed. This simple discipline prevents the endless rehashing that wastes time in teams with poor documentation.

They start and end meetings on time to honor schedules and prove that focused work matters more than performative presence. They hold one-on-ones to strengthen relationships and spot issues early before they grow into problems that require formal intervention. They limit surprise meetings to true emergencies to protect deep work time periods because every unplanned meeting interrupts focus that takes time to rebuild. They encourage all voices in the room. If someone stays quiet often, they check in privately to understand whether the person has nothing to say or feels unable to say it. Most people who stay quiet in meetings are hiding something and that’s a management problem. Standups remain brief, centered on blockers and decisions rather than detailed status reports that belong in written updates or team discussions.

They hold retrospective meetings when needed and turn findings into real changes rather than treating them as box-checking exercises that produce nothing. The best retrospectives create concrete action items with owners and deadlines. Without that follow-through, the retrospective meetings become cynical rituals where people stop contributing honest feedback because they know nothing will change.

Handling Distributed Teams

Distributed teams face extra challenges from time zones, languages, cultures, and economics that managers cannot wish away with talk about “global collaboration.” Strong managers tackle these directly rather than pretending geography does not matter. They push asynchronous work with good documentation, clear status reports, and written decisions that people can reference across time zones. They rotate meeting times occasionally so the burden spreads fairly instead of forcing the same people to join calls at 2:00 in the morning every week. It’s always nice to give everyone on the team a sense of what everyone else has to deal in remote geographies. The vast majority of managers ignore this issue entirely.

Remote members can lose out on influence when managers favor people they see in person, so effective managers counter that tendency deliberately. They may give remote voices priority at times to compensate for the natural advantage of those who are meeting in person. They move key discussions to text in a shared mailing list where everyone can participate equally. They monitor promotions by location to fix unfair patterns before they calcify into structural inequality. Non-native speakers may get extra time to formulate thoughts in a language that does not come naturally. Managers avoid jokes or phrases that exclude people unfamiliar with local references, and they judge on work quality rather than polish in communication.

Managers who understand international work actually study cultural communication styles because directness that works in one culture can seem rude in another, and consensus-building that one culture values can look like indecision somewhere else. They focus on results rather than matching a certain way of speaking, which often masks cultural bias as professional standards. They design budgets fairly so development chances feel equal regardless of where someone lives. When conference travel or training opportunities consistently favor certain locations, resentment builds and talent drains away from the teams that need it most. Remote team members feel these things immediately, but only a few consciousness manages are aware of this.

Representing the Team

Good internal management needs strong external advocacy because teams do not exist in isolation. Capable managers keep leadership updated on progress, risks, and issues early when interventions still work. Surprises hurt trust because executive leadership needs time to process information and adjust plans and budgets. So, managers need to highlight achievements, particularly for remote people whose work can stay hidden from executives who notice whoever sits near them or who has access to them. In large organizations, good work needs promotion because it will not speak for itself, so great managers share everyone’s work deliberately through newsletters, emails, demos, and presentations that get the team’s name in front of decision makers.

These managers align team efforts with company priorities and shift direction fast if something no longer matters to the business. Holding on to pet projects that leadership has deprioritized wastes time and marks managers as unable to adapt. They nurture relationships with peer teams ahead of time so they have goodwill to draw on when collaboration becomes necessary or when problems need resolution. Solid links ease joint work because people already know each other and trust that requests will get handled fairly. Without those relationships, every interaction starts from scratch and burns energy on establishing credibility that could go toward solving problems.

Delivering Results

The best teams ship quality work on schedule because reliability earns trust that opens doors for future projects. Effective managers set realistic timelines and meet them rather than promising the impossible and disappointing everyone. They favor consistent delivery over rushing to meet arbitrary deadlines that produce crappy work requiring expensive fixes later. When changes come, and they always do, these managers communicate them clearly, reset expectations with stakeholders, and explain the reasons so people understand the decision rather than resenting the disruption.

Well run team build quality products from the beginning with testing, reviews, and rapid feedback loops that catch issues early. Problems that are found in development cost far less than problems found in production, so investing in quality up front saves time and money. Managers running these teams identify problems quickly through monitoring, user reports, and team observation. They resolve them before they escalate into crises that pull everyone into emergency mode and destroy planned work for weeks.

Learning and Growing

Teams stay sharp through continuous improvement that treats learning as essential rather than optional. Strong managers fund conferences, courses, and certifications because everyone knows that skills atrophy without ongoing investment. Learning should be a priority that gets time and budget rather than something people squeeze in around real work. Team members should be encouraged to carve out work time for experiments and side projects because fresh ideas often emerge from open exploration that has no immediate business justification. Markets change rapidly. Preparing for the future needs to occur in the present.

Teams can easily grind themselves down from over working or working on low value or meaningless projects. So, observant managers watch closely for this. They look for burnout through signs like stress, short tempers, or people who quietly pull away from colleagues and activities. They adjust loads early to keep a steady, sustainable pace because burned-out teams produce poor work and lose people to competitors who offer saner conditions or more interesting projects. These managers run retrospective meetings after projects to pull lessons and break bad patterns before they become embedded habits that shape everything the team does.

Connecting Work to Real Impact

People perform best when they see the value in their efforts and understand how their work affects real users or business outcomes. Capable managers continually explain how the team’s tasks link to business goals, customers, partners, or the greater community in concrete terms rather than vague platitudes about innovation and excellence that are backed up by nothing. These childish statement are obvious, aren’t they? Instead, great managers make the connection obvious and reinforce it with data often because the link between daily work and the larger purpose gets lost in the grind of tickets and deadlines. It’s the responsibility of the manger to make these things clear.

Great managers also keep end users front and center so the team solves actual problems rather than building features that seem clever but serve no real need. They pass user feedback directly to the group in detail complete with quotes and context that make the people behind the data real. They recognize wins publicly with information that shows what the team accomplished and why it mattered. This lifts everyone’s spirits and shows what the organization values, which shapes future work more than any strategy document.

Giving Autonomy and Ownership

Strong teams empower people with ownership that makes work meaningful rather than treating them as interchangeable resources executing orders from above. Effective managers define clear goals and limits, and then they trust people to decide inside those bounds how to reach the objectives. This is critical for establishing trust, which accelerates work and sharpens judgment because people learn from their own choices. Micromanagement, on the other hand, stifles drive by signaling that managers expect failure and must control every detail to prevent disaster. It also reveals a weak manager who lacks confidence.

Autonomy is critical. It promotes accountability because people are encouraged to own both their successes and setbacks in a blame-free space that encourages honest assessment. Managers who promote autonomy encourage their people to openly talk about errors because learning speeds up when people can admit mistakes without fear of punishment. These managers assign stretch projects with support to build skills that formal training can’t provide. As a result, growth occurs when people are encouraged to tackle hard challenges safely but with backup available if things go wrong. And they sometimes do. But this freedom is important so people try approaches that might fail. That’s what generates new opportunities.

Great managers also spotlight top work openly to prove that merit counts for everyone, not just the favored insiders that many times emerge when groups form over time. When promotion and recognition follow visible achievement, people believe the system works fairly and they invest their best efforts. But when politics and favoritism determine who advances, talented people disengage or leave for places that reward their contributions. How many people on your team have long ago quietly quit with a smile on their face?

Final Thoughts

These observations come from working on teams across multiple industries and also from conversations with hundreds of professionals who built, led, and contributed to successful groups. Teams change, challenges shift, but clear communication, mutual respect, and commitment to merit and excellence endure across contexts. Take these ideas as a foundation. Adapt them to your situation. Refine them as you learn what works in your own environment. And good luck creating great teams.

OpenSolaris, 2005-2010
By far the best project I’ve worked on over the years — OpenSolaris 2004-2010 and Solaris 2010-2016. It’s not even close, too. Hopefully, I’ll find a great project in the future that will meet or even surpass OpenSolaris and Solaris. The standard is high, though.

Don’t Talk too Much!

I’m always mindful of how much I talk while doing podcast interviews. At times I think I’m talking too much and getting in the way, and other times I struggle with how to keep things moving if I’m not saying enough. It’s a balance. But I’m learning. In this audio file below, I’m on top and my guest is on the bottom. This is the mix I’m most comfortable with. I just want to insert myself or respond to guide the interview, so I can highlight the guest and then get out.

Editing audio files for podcasts.
Editing audio files for podcasts. Interviewer on top, guest on bottom.

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

New Java VS Code Extension

Here’s the latest Java Platform Extension for Visual Studio Code with Java 25 and notebooks support. And 4.6 million downloads too! Great job by the Java engineering team in India! I hope to meet the team there when I go back to India in April 2026 for a session at GIDS. Will also stop by the Bangalore Java User Group as well. Should be a great trip.