Tag Archives: Developers

No JavaOne 2026 Photos

I was at JavaOne 2026 in California last week. I participated onstage at the Community Keynote and also recorded some audio podcasts, which I’ll post over the next few months at Duke’s Corner. And since I’m on the team that produced the week-long event itself, I had many other duties to attend to throughout the conference as well. I’d say the Community Keynote took the most planning and implementation for me this year, where I hosted a short panel on the Java User Groups with some great JUG leaders. More on that in a later post, but here’s the live stream of the entire keynote that involved the entire team and community guests.

But one thing was missing from this event — I didn’t take a single photo! Usually, I take hundreds!

Instead, this year the Java Developer Relations team hired 3 photographers to shoot most of the event (except for the speaker dinner and the Day 0 events) plus a new feature for speaker headshots. And multiple team members showed up with cameras to shoot various bits as well. It felt weird to not have a camera glued to my face all day, to be honest, since I’ve shot so many events in the past. And I don’t know how I feel about it. On the one hand, shooting events has been a core part of my conference activities for a long time, but on the other hand it was nice to not have to lug around two big cameras and three lenses for 10 hours a day for 4 days straight and then have to edit hundreds of images afterwards. For example, last year I shot JavaOne 2025 all alone (including the speaker dinner and the Day 0 events), which was a challenge for sure. I didn’t shoot headshots because that does actually require another person and specific gear so we didn’t offer that service last year. And there was no room in the budget to hire a photographer to shoot headshots.

But the 600 images I did shoot took a few weeks to edit and publish. It was an enormous amount of work for one person that usually gets done via a small team of photographers and editors. But, hey, those images generated more than 80,000 views on Flickr so that’s cool and who knows how many views on various social media sites. Now, it turned out that no one at Oracle cared about that massive metric, but it’s surely substantial and meaningful to me. And the images are valuable to the Java developers who got them on Flickr via a Creative Commons license so they could be used elsewhere freely. That’s why I shot so many events over the years — to contribute the content to the developer community. Open Source conferences should generate Open Source content, right? It’s interesting that not everyone in the FOSS community agrees with that statement.

But this year? Nothing. I personally have no JavaOne 2026 photos to contribute. That was the plan for this year, of course, but I’ll have to digest that decision for a bit. But what about the many hundreds of images that were shot by the three professional photographers at JavaOne 2026 funded by Oracle? Nothing. I can’t find a single image online from the event. No websites. No social media. Nothing on Flickr under a Creative Commons license. One of the arguments I gave to my team in 2025 was that whenever Oracle hires professional photographers for events the images simply never see the light of day. What’s the point of just dumping them in some corporate database to rot over time behind the firewall? So, let me shoot the event instead so at least we have something to give to the community and for our own use on social as well. Sure, Oracle does post a few tiny low resolution images from their events on a few corporate websites for a short period of time, but even those vanish in mere weeks. Such a dumb waste of resources. And such a wasted opportunity to help build the community by offering massive numbers of free high resolution images from the world’s premier developer event. Sad.

Anyway, here’s something I noticed by NOT shooting images this year. I gave myself time to breathe! Developer conferences are challenging to manage under the best of circumstances. You can easily grind yourself into dust in no time flat working 12 hour days on site following months of planning. But I didn’t do that this year. In fact, I intentionally didn’t even attend all of the events throughout the week but instead chose to go back to my hotel room at times to rest. I could have spent the extra time recording dozens of podcasts, but I didn’t do that either. Instead, I recorded 6, which is a perfectly reasonable number. I did, however, talk to as many developers as I could find. Just hallway conversations. And that was a new exercise for me because in the past I used the camera to engage people. The camera was always my crutch. It was always my filter. This year, though, it was just me. I wasn’t that nervous and I really loved it. I got to know many more people this way since I was more present in every moment. I was there to talk to you, not shoot your photo. The whole thing felt different.

So, it was a good event generally. I may implement this system in the future and just leave the photography behind at this point. I’ve shot about 100,000 images at events since 2000 so maybe that’s enough. Maybe it’s time to just move on.

Bob Treacy: From the Factory Floor to Harvard and 30 Years of Java

Duke’s Corner Java Podcast, March 15, 2026 — Bob Treacy: From the Factory Floor to Harvard and 30 Years of Java

Bob Treacy started his career as a union steward on the factory floor at GE Aircraft Engines. After earning a BS and MS in Computer Science from Boston University while also raising a family, he jumped into software, never looked back, and remains at the leading edge of Java and AI today. He picked up Java in the summer of 1995 at a training session in New York, and the language has been central to his work ever since. Today he is Principal Software Architect and Data Engineer at Harvard’s Institute for Quantitative Social Science, and he has attended more than 20 JavaOne conferences, which is most of Java’s lifespan.

Getting to all those JavaOne events has always been non-negotiable. “Every job I’ve ever gone to, one of the things I demand is that I be able to go to conferences like JavaOne.” The reason, he says, is simple: “It brings a lot of different perspectives, sharing experiences, learning from each other, and just a great group of people.”

At JavaOne 2026 he’ll present work from Harvard’s Dataverse project, an open source platform for preserving and sharing research data. The problem he is solving is straightforward but persistent because researchers treat the repository like a simple archive and skip the metadata that makes their datasets discoverable. His solution uses LLM embeddings and a graph database to compare new dataset descriptions against existing ones and recommend subject categories automatically.

The conversation goes well beyond his upcoming JavaOne session itself. Bob lived Java’s entire evolution from the rough early days of applets through HotSpot, modularity, and the modern work on GPU access via Project Babylon and the Foreign Function and Memory API. On AI, he says that “I think there has to be a human in the loop.” He sees LLMs as causal models, not reasoning systems. “Given these words that came before, what’s the next word going to be? That’s not really intelligence. I don’t totally buy some of the narratives that are out there about AGI.” His advice to students is equally grounded in simplicity. He advises students to learn the code, but spend more time understanding how large systems work together. As he puts it, “just doing pure coding” is no longer enough.

Bob Tracey: LinkedIn | Jim Grisanzio: LinkedIn, X/Twitter

OpenSolaris History on Grokipedia

As a test, I recently requested that Grokipedia update its page on OpenSolaris to include the source code release history I kept while I was the community manager. There were over 80 releases of source code, entire projects, and technical documentation during the five years of the project. I kept the history here. Anyway, I submitted the request to Grokipedia, and a few hours later the page was updated. Just like magic! That’s pretty much impossible with Wikipedia since I’m not one of their chosen editors. In fact, many years ago I tried to make changes to pages on Wikipedia and they were reversed seconds later. So, good on Grokipedia. I’ve long since given up on Wikipedia so it’s great that Grok is moving forward with a new community-driven encyclopedia.

The IDE That Refused to Lose

Twenty-five years ago, a small team of software developers in Prague wanted to build something better. That’s a common characteristic among all good engineers. There is always something better to build. The result in this case was IntelliJ IDEA. And this documentary — IntelliJ IDEA: The Documentary | An origin story — explores how it happened. It’s really good. I know some of the developers interviewed for the program. It reviews the good times and also the challenges the team faced over the years. The company, JetBrains, competed against free tools backed by IBM, survived a subscription pricing backlash, and had to earn trust in the community among Open Source developers. They earned that trust by listening, adjusting, directly engaging developers, and building their community from the beginning.

What comes through most clearly is that the product reflected the people behind it. They built the tool they wanted to use and they had to freedom to do just that. And apparently a lot of other developers wanted the same thing since IntelliJ IDEA is now the #1 IDE for software developers.

I also did a Duke’s Corner Java Podcast recently with the IntelliJ IDEA team — Marit van Dijk and Anton Arhipov: 25 Years of IntelliJ IDEA — and we discussed some of the issues touched on in the documentary.

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