Tag Archives: Developers

The Value of Contributing: Mentorship

I found this interview on the JetBrains YouTube Channel really interesting: Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn’t 1.0 – Andrew Kelley Explains

Some developers really love to code. They share their code and they mentor others to share their code as well. The entire process is a challenge for them. It’s their passion. It’s their craft. And for these guys they aren’t casually dumping their entire development experience for the latest automated AI system to come along.

Here’s Zig Software Foundation lead Andrew Kelley during the interview:

“I love computers. And I love learning about what people are doing with them. And there’s a sense of mystery and magic that you can get from reading someone’s explanation of a project that they did that took them a very long time. They had to learn lessons, and they had to increase their skill as a programmer and as a user of computers in order to accomplish this goal. And when you read a blog post like this, it’s brilliant. It captures the imagination. It makes you think about what you could do yourself. It teaches you something. It connects you to them emotionally.”

And that’s why Andrew bans the use of AI on his Zig projects.

Instead, he’s seeking that close connection with his contributors. He’s seeking excellence and discovery from the many procedures involved in software development. I picked up on this attitude right away because I’ve interviewed many engineers about the value of contributing. Many of them hold remarkably similar views to Andrew, and they talk at length about the importance of contributing to the community.

Here Andrew explains it beautifully:

“The main point of doing code reviews and having contributions, instead of us just doing all work ourselves, is mentorship. The whole point is that a contributor can become a core team member eventually or a more valuable contributor. This will help the project because we’ll have more people who can contribute to Zig skillfully. And it will help their resume because they’ll be a better systems programmer, and they can then take those skills elsewhere.”

But the contributions Andrew used to get from developers using AI were “garbage and had no value whatsoever,” he says. That’s pretty strong language. But Andrew has very high standards and would prefer to engage developers directly on their contributions during the code writing, review, and integration process. That’s where he builds valuable, long term relationships where contributors become more skilled, the core team benefits, and the product maintains the highest quality possible. AI, he says, only gets in the way of that process.

Education is also a big reason for why Andrew holds this view.

“This policy just makes sense because the Zig project is also an education project. That’s part of our mission statement. We’re providing guidance and education to students. So we’re all trying to learn. We’re all trying to get better at programming. And so people who are sending AI pull requests, those people are not helping this goal. In fact, I think that they’re detracting from this goal. So, for our project, I think that the strict no AI policy is an appropriate policy.”

Many times websites bury their organizational mission statements down at the bottom of the page or tucked inside a nav element. But on the Zig Software Foundation site, it’s printed right at the top as the first item.

For developers using AI, Andrew says, it’s simply not worth investing in them. “They aren’t going to join the core team later, not a chance,” Andrew says. It takes too much time away from the reviewers, and the contributors don’t learn anything in the process and are less likely to stick around. Andrew isn’t just saying this, though. His team has tried taking AI contributions but it hasn’t worked out, and they still have hundreds of contributions that still need reviewing. So he’s speaking from his own experience. He’s actually quite thoughtful about the whole thing, so it’s hard to argue that he’s just making a mistake or that he’s blind to the emergence of AI.

So, what’s the lesson? Learn your craft. Learn it well. Go deep into the details so you can demonstrate your expertise so that it’s unmistakable to more advanced developers. And look at the entire process as a community building exercise. In other words, it’s personal. It’s more than just code. Don’t outsource that opportunity to a machine. And then you can build lasting human relationships with the core team via iterations about your code that you submitted yourself. That’s a powerful signal to send into the noisy world of software development. It’s also a simple technique that can be applied to any field you choose. All craftsmen in all trades know this.

Andrew’s position on AI may fly in the face of the current trend of developers embracing AI tools, so we’ll have to see how he and his project evolve as AI grows to pervade more levels of software development. So far, though, Andrew remains emphatic. And judging from many of his comments throughout the interview and how deeply he gets into system development, I bet he sticks to that view. At the end of the conversation, Andrew says he’s probably unemployable at this point and is best suited to be on his own. He’s clearly an entrepreneur at heart, and his standard is “uncompromising perfection.” Can’t argue with that.

And finally, here’s a shout-out to the JetBrains team for talking to Andrew, who said flatly in the interview that he doesn’t use JetBrains products because he only uses FOSS software. Even with advanced IDEs on the market, Andrew’s development set up remains simple and open: “It’s just a terminal and Vim.” Like I said earlier, he loves to code, And he seems as hard core about that as you can get. But the important bit for JetBrains is that they had him on at all. The interview has nearly 900K views in just three weeks, which is vastly more traffic than other recent videos on the channel. Most software vendors would never do this, no matter what traffic a guest could generate. Most vendor channels exist to simply sell products. But JetBrains with this decision demonstrates that they are also concerned with promoting excellence in software development and in building the overall software community. Good for them.

A Treasure Trove of Java Stories

The Duke’s Corner Java Podcast gets a nice mention in the IntelliJ IDEA Java Annotated Monthly for August 2026. See “The importance of telling our Java stories” from Donald Raab right up top: “We all have stories to tell, but they sometimes only get told when we tell them. Jim Grisanzio shared an archive of 77 Duke’s Corner Podcasts, which is a literal treasure trove of Java stories.”

Interviewing Developers

Since 2017 I have interviewed about 500 developers for articles, audio, video, and live streams at events on a variety of topics including Java, Linux, Oracle Database, MySQL, AI/ML, Developer Tools, Oracle Cloud, and Open Source. 

Libsyn Audio | Podcast Video | Highlights on X | Photos

Most of my interviews these days take place via Zoom from my kitchen, which I find frustrating because I greatly prefer the connection of live interactions at conferences. That’s a bug. I’m working on a fix. But for now, I’m making do. The checklist below captures some insights I’ve gained about the interpersonal dynamics of interviewing software developers. This isn’t about podcast equipment or technical setup. Instead, it focuses on creating a comfortable environment for guests, drawing out compelling stories, and fostering engaging conversations that resonate.

As I continue learning, I revisit these points regularly and update as needed. They’re shaped by my own painful journey in this field without formal mentorship, so I’m always open to feedback to help refine my approach. The whole experience has been pretty personal for me, to be honest, considering that I’ve radically changed careers a few times, I’ve had to start over from scratch repeatedly, and I couldn’t talk fluently until I was well into my 40s. So be it. That’s life.

Anyway, here’s what I’ve learned so far.

Before You Hit Record

Talk to them first.

Don’t just send your guests a calendar invite with a link and hope for the best. Some developers aren’t used to being interviewed, and they may be apprehensive initially. Do a quick call first. Send them an email explaining what you’re doing. Is this video or just audio? How long will it take? What kinds of things will we talk about? Then, when the interview day comes, I always start recording at least 15 minutes after getting on the call just so we can chat about their latest projects before recording, which helps guests get comfortable, sets a collaborative tone, and organizes things in my own head as well. I’m always nervous at the beginning so killing a few minutes up top is always best.

If you are live on site, you can do this simple preparation work right before you turn on the camera if you have a simple interview with an experienced guest. But for more complex things, you may need more time to prepare. For example, at JavaOne 2025, I ran a Duke’s Corner Podcast panel during the Day 3 Community Keynote, and for that I did a lot of preparation. First, I did my own prep to scope out the entire segment. Then I selected three interesting Java developers as panelists. Then I pinged them via email with all the details, and we had some online threads as we agreed to everything. Then we met as a group at the JavaOne speaker dinner on Monday a few days before the keynote to go over issues together and start the process of gelling as a group. Then we participated in rehearsals with the other Day 3 speakers on Wednesday. Then finally we ran live on Thursday. The result? Our session was perfect! But it did take some real preparation. When the stakes are high like this (a live keynote session) it’s best to layer the preparation with your guests so you don’t miss any of the details and everyone knows what to expect.

Do your homework.

If you show up unprepared, you’re wasting everyone’s time. And if your guest is experienced, you also run the risk of embarrassing yourself. But most developers aren’t experienced at interviews, and they aren’t media trained with prepared talking points like you’d get with a CEO or marketing executive. It’s your job to dig into their work a bit and find a few interesting threads. Check their GitHub accounts, read their blogs, look at their conference talks. If they’re involved in a user group, find out what they’ve been up to lately. Check their posts on X or LinkedIn or their project mailing lists to stay current with their latest community discussions and contributions.

This homework isn’t just about having some solid background data to generate interesting questions. It shows respect for their work and their time, it builds a genuine connection when you meet, and it makes the whole conversation flow better. 

Start Strong, End Strong

Jump right in.

Don’t waste time with long, awkward small talk or forced jokes at the start of an interview. Pre-plan the start so you can begin efficiently. This is always the hardest part for me, especially when doing live streams because you only have one take. So, just do your introduction, get a quick response, and get going into the content. You’ll feel better once things get rolling! For example, if your guest organized a hackathon recently that helped streamline bug triaging, start there. That’s perfect. After your introduction and your guest’s response, jump in with something like this: “Hey, I saw your recent hackathon — tell me how that came together.” In other words, be pleasant and professional. But move! I’m not saying you have to make the intro so short to fit into the insane YouTube “shorts” of mere seconds up front. But don’t hang out with meaningless jabber either. 

Plan your exit.

Every conversation has a natural lifespan. You’ll feel it when the energy starts winding down, you’ve run out of questions, or your start repeating yourself. Plan for wrapping up smoothly. I always tell guests upfront that I’ll give them a chance for final thoughts when we get near the end. When you feel that you’ve covered everything you can simply move along to this: “Ok, before we wrap up, is there anything else you want to add? Any plans coming up? Anything you want the community to know before we go?” Now, I wouldn’t ask all of those questions in a row like that. Those are just examples of one or two to use. After their response, it’s perfectly acceptable to say, something like this: “Oh, I love that. That’s great. Ok, we’re done. Let’s get out of here! Have a great trip to JavaZone in Oslo. See you next time.” Or something like that. They’ll respond with a quick bit. And you’re out. Or sometimes you’ll be able to cut right after your goodbye. Just go with the flow but always have the intention of ending things with some precision. If you want to summarize some key takeaways occasionally before saying goodbye, and if it feels natural, that’s fine too. There are many ways to end. Just don’t drag it out. Also, always thank your guests and tell them when the episode will be out. The goal here is to get out before the energy dies because it will be obvious to listeners if you don’t. 

Listen!

Your superpower is your silence.

Listening. This is critical. It sounds obvious, but really very few people have mastered this skill. Actually listen to what your guest is saying in real time. You must listen to your guests while they are talking not only so they feel heard but also so you can facilitate the conversation naturally and things flow well. It’s obvious when one person in an interview is not listening to the other person. You can see it all over YouTube and especially on news programs. Also, just recall conversations you’ve had in real life. You know immediately when you aren’t being heard, right? Now put that experience on audio and video for all to see and hear. It’s ugly. 

I know it’s tempting to think about your next question while your guest is talking. But resist that urge. If you are on site, I know it’s hard to listen when there are sound distractions in the room, and when you’re worrying if someone will crash into the camera (which happened to me many times). And, of course, it’s hard to listen when you can’t remember if you even turned on the camera or if you focused properly and set the white balance correctly. It’s best to have a short checklist on site because things can get confusing, especially when you are working alone, which has always been the case for me. And even have a short checklist for doing Zoom interviews from your kitchen. Checklists work. Remember, surgeons and airline pilots and people in many other professions use checklists daily so there’s no reason we can’t as well. 

Use whatever tool you can to free your mind so you can listen in the moment. When someone tells you about fixing a critical bug or organizing their first meetup, really hear them as they are talking. Respond with some body language so they know you are following their story. Paraphrase what they said: “So your mentorship program actually helped people contribute to OpenJDK for the first time? That’s excellent!” This shows you’re paying attention and often encourages them to elaborate with even more details. Simply providing a brief summary is a great way to keep people talking while you navigate the conversation.

And don’t be afraid to respond with short quips like: “That’s cool!” or “Wow! How’d that work?” when something genuinely interests you. Sudden and authentic reactions help keep the conversation flowing naturally, which is what we all do in normal conversations without microphones and cameras. Just think of the last chat you had with a friend in your favorite coffee shop as a great example of normalcy. Try to keep your guests talking with subtle, familiar cues like this. Or sometimes, if they end before you think they should, be even more obvious. “No, keep going! That’s great. How did that situation end?” You’ll probably have to do this with a semi humorous voice to avoid appearing too aggressive. Most people get it, though.

Bridging and Flowing

Keep it moving.

Comment on what your guest just said before moving to the next topic. It would be great if you could also weave a new issue into your summary of their previous comment to help bridge them to the new issue. If they mention contributing to a project, acknowledge it: “That bug fix sounds like it was pretty complex. How did you approach that with so little information and no time?” You’ve summarized their comment and added a new bit in the hopes of moving them along if the next issue is a logical next step or somehow related. If things are dragging along too much on any given subject, though, you may need to shift topics more assertively because bridging isn’t possible. Just be direct: “That’s great. Really cool experience. Ok, let’s move on to the community. Talk about your work with your local user group. I’ve heard you are running the JUG now.”

If they keep going off on tangents about something unrelated, gently redirect: “That’s interesting. Hold that thought. I want to go back to your contribution process first…” Or even more direct, “Wait, go back. That was interesting.” Use their input to steer the conversation smoothly in the direction you want to go or to keep them moving along their path efficiently. If they casually mention mentoring and then move on to something else without saying much, make a mental note to ask about mentoring next. This keeps things organic and layers issues in some logical way. Now, there are cases when you don’t need to respond to topic shifts. Their answer just ends a good sequence really well, and maybe you can provide some silent space and some body language to move along. Watch skilled interviewers. They do this more than you realize. 

And finally, try to keep the conversation going fluently by directing your guest to comment on specific issues rather than always asking question one, question two, question three. Weave in some open statements like, “You mentioned you’ve contributed to the Linux kernel as well as OpenJDK. I thought that was interesting. Tell me more about that.” In other words, you aren’t even asking a question here. You’re getting people talking by making statements or directly telling them to comment on something. Think about normal conversations with your friends. They’re based on a variety of free-flowing questions, statements, prompts, and body language. No one likes a formal Q&A session. Mix it up so the discussion is as natural as possible. 

Asking Better Questions

Simple is best.

Keep it simple! Ask one question at a time. Or if you ask two make them directly related in a string where one builds on the other to add more clarity. Don’t ask disparate or compound questions! This only causes stress as the guest, the audience, and you try to keep track of your too-cute “three part” question. I see people ask these compound questions all the time: “How did you get started with OpenJDK, and what was your testing process, and also how did that work connect with your user group experience?” Nobody can answer that well, especially if you’re doing a live interview at a busy conference with a microphone right under your guest’s nose and a camera focused on their face. Where would they even start? Your guest won’t appreciate the unnecessary complexity too, trust me on that. I’ve made this mistake many times.

Instead: “How did you get started contributing to OpenJDK?” Stop. Let them answer. Then follow up: “Oh, sounds like a great opportunity. What was your testing process like before you submitted your code?” Stop. Let them answer. Then follow up: “I see, ok, so from that code integration process you met the JUG leader since he was the gatekeeper on the project.” That’s not even a question but those statements summarize the story and encourage the guest to say something like this: “Yes, we had so many conversations getting that fix tested and integrated on a tight deadline that we became friends and she invited me to do a session describing the technical details at the next JUG meeting on contributing to OpenJDK.” 

So, if there are multiple parts to an issue, break things up into multiple questions and statements and just talk them out to their natural conclusion. No compound questions ever! Don’t put that tracking burden on your guests or yourself.

Also, try using some open-ended prompts: “Tell me about that bug fix” rather than “Did you find it challenging?” The statement “tell me about it” opens things up, whereas the “challenging” bit narrows things down. Both are valid but know when to use them. Ultimately, you want your guests to describe situations and stories and entire sequences of events, not simply answering yes/no answers. Always encourage people to tell you about something. In other words, prompt them and then step back and give them some space to explore. Then you can judge how much time they need, and you can adjust and guide them where needed. The goal here is to get them to describe experiences they’ve had via short stories. That’s what makes it easy for them to speak articulately for longer periods of time because as they are speaking they are re-living the the experience. And that’s when their natural personality comes out.

If the issue is complex, you may need to get more specific: “Break down your testing framework as if you’re explaining it to a new engineer on the team. Just give me a few of the more important steps to follow.” Don’t expect them to give you the full task list from the manual to do an integration. But you can expect a top-level overview of a process just as they’d do in a normal conversation. And avoid leading questions like “Isn’t X process better for that issue?” Instead ask “What drew you to that approach?” to get more detailed responses. There’s no need to put them on the spot with your judgements. Plus, you may not like it if they come back and embarrass you with their response! Remember, this is a conversation, not a competition. 

Getting Good Stories

Everyone loves a story.

Before you start recording, ask your guests to think about a few stories they can tell. It’s good to have this conversation before the interview so they have some time to think about blending some stories into the overall themes of the conversation. You need details in responses, of course, but those bits should be expressed through a series of situations or short stories. This is why you don’t need to provide specific questions up front. Just offer your guests broad topics for discussion and let them wrap their content into their own personal stories. Once the story starts, you can listen if it’s flowing well or insert some quips to move things along in whatever direction that’s necessary. 

Funny disasters work great as stories. “Tell me about that time you accidentally took down the bank on day one” or “What’s the worst bug fix you’ve ever integrated on a Friday afternoon?” A few dramatic stories in a conversation can go a long way to making things interesting and less stressful for both parties. These kinds of stories reduce stress and provide the audience with relatable, genuine, and memorable experiences. But be careful with the disasters. Make sure that everything worked out ok because you don’t want to surprise them on a live interview if something really terrible happened.

Also, when people tell real stories, their whole demeanor changes. Watch for this and encourage it with your own body language. They may get more animated, more detailed, more authentic. They light up! Watch how they come alive right in front of you! The technical stuff is important, but the human stories are what make people want to keep listening. 

Push for vivid details.

If possible, ask questions that create scenes and narratives. Weaving in the five human senses (hearing, touch, sight, taste, smell) is a helpful technique. “What was it like in that room when you realized what happened? Who else was there? What did they say?” Probe for how things were felt. Also, directly ask your guests to take you there: “Wait, go back. Take me into that scene. What was it like when you first heard you were nominated and approved to be a Java Champion? You were on the keynote stage in front of everyone. Wow!” Get them to talk about the situation by reliving the memory. They’ll love it. What was on their screen when the system crashed? How did their team react? What did they do when they were organizing the event when the hurricane hit and blew trees into the conference center? Things like this. Thinking in terms of human and natural elements makes stories that have technical details more engaging.

Managing Different Comfort Levels

Being interviewed is a unique experience. 

Recognize that being interviewed is a different skill than presenting a session. I’ve seen some famous developers who regularly present at big conferences in front of thousands of people who actually feel and look noticeably uncomfortable being interviewed. And this makes sense. They don’t have a laptop in front of them. They’ve not rehearsed the discussion. They’ve not been media trained. They don’t have control! Don’t assume they’re skilled at this specific task of recorded or live, free-flowing conversations, especially when you stick the microphone under their nose for the first time. One time I was at a conference streaming some interviews, and the guest wanted to use his laptop and show his slides. He just had no confidence that he could take his content and turn it into a verbal conversation. It happens. And it’s your job to manage this problem.

Make it a habit to put all your guests at ease right up front. Frame it as a fun chat to share their story with the community. Tell them this is a mutual discussion, not a journalism interview. We’re having some fun here! That’s it. Let them know that pauses are fine, stumbles are normal, and you can always edit things out later if something breaks. I often mention that I mess up my own introductions half the time, which helps them relax. And when I wreck their names in the first five seconds that leads to laughing. False starts are normal for Zoom interviews and are easily edited out. But if it happens when live streaming, have a handy tool to re-start on the fly: “Oh, wait, I messed that up, say your name again? Oh, wow, I was really off, eh?” And laugh. But don’t keep laughing. Move on fast. We’re all human. Making mistakes appear normal is the best way to adjust when doing things live. Just prepare accordingly.

Let Them Ask You Questions

Turnabout is fair play!

Encourage your guests to occasionally ask you questions too! This is a great way to ease nerves and sometimes leads to unexpected insights as it puts you as the host in the position of answering a question. During interviews when someone asks me about trends I’m seeing in the community or my experience with building Open Source communities, it often sparks great follow-up discussions. Don’t hog the microphone, though. Get in, move it along, get out.

And don’t be surprised if you feel uncomfortable when this happens! Remember, asking questions isn’t the same experience as answering them! There are many skilled interviewers who aren’t that good at being interviewed! So, characterize the interview as a conversation: “This is just us chatting about your work, so feel free to ask me anything as we move along.” 

Know When to to be Quiet

Shut up!

Try not to speak too much throughout the interview. The guest should be talking about 70% of the time with you prompting them all along the way. You need to find a balance where you can insert yourself in the discussion to offer context to keep things going. Adding a comment here and there to give them a break is also fine. They will appreciate the time to relax. But if you talk too much, the interview will look and sound awkward because the guest will be sitting silent too long and they may look uncomfortable. This is even more awkward when you are doing a live standup hogging the mic and your guest just has to stand there. Very few guests can handle this so don’t put them in this situation. It’s your job to learn how to stand silent while they are doing the majority of the talking. This is where body language comes in really handy. You don’t actually have to stand still. You can move around a bit so your body language helps promote the conversation.

Also, don’t try to one-up your guest. Yes, interviewers do this. It’s amazing. If they tell you about a major outage they caused as their best outrageous story, don’t follow with your own outage story that tops them. Instead: “Wow, that sounds intense. How did you recover from that in such a short time?” Or if you did have a similar experience and want to contribute the story, you could say something like this: “Oh, I ran into something like that, too, so I can relate. But yours was worse!” And laugh. Remember, the guest is the focus of the discussion, not you. You can regularly check the ratio of your voice vs your guest’s voice in any audio editor by just looking at the two wave forms. Yours should have lots of silence throughout the interview, but when you talk it needs to matter.

Sound Quality Matters

Good sound and solid projection.

Although this post isn’t about gear, which requires its own dedicated post, here’s a quick reminder that the sound quality is more important than perfect video when doing podcasts. For remote interviews, insist on decent microphones or headsets. There are many perfectly affordable USB mics that require no setup. They need to be used. I’ve postponed and even canceled interviews when the audio quality was too poor. You can only fix so much in post. And since your goal is to make your guest look good and provide some entertaining content for the community, having bad sound in 2026 isn’t acceptable. It doesn’t have to be perfect. But it can’t be bad. 

Also a sensitive issue related to sound is having to ask guests to assert themselves more. It’s fine to have a headset or a good microphone, but if your guests are too shy to project their voice that’s an issue too. So, just gently ask for more energy! You want them looking and sounding good. Hopefully, they’ll appreciate the thought. Most do. I’ve had to make this request a few times because some developers are naturally shy. But most times you can manage the low energy issue by asking better questions, and asking them to tell stories based on their own personal experiences. The story is the key. That’s what bring out their natural personality. Do that and most projection issues go away.

Handling the Tricky Stuff

Preventing conflicts. 

To prevent people from potentially stumbling on sensitive topics like community conflicts, political issues, or competitive corporate products, just mark these issues out of bounds from the start of the interview. No exceptions. I always make this request, and I’ve never had a guest disagree. We are fortunate that our companies allow us to mix freely in open development communities using company resources, so we ought to keep our conversations focused on the things that are openly approved for public discussion. 

After It’s Over

We’re done. 

Send thank-you notes and let your guests know when the episodes will be live. Encourage them to share it with their networks since developers are obviously well-connected in their communities. Asking for feedback is always nice too. If you don’t want to send a mail afterwards because everyone already has too much mail, that’s fine. Just thank your guest after the conversation and give the publication details. In other words, don’t just end the live interview and disappear. Stop the recording and chat freely for a few minutes to properly say goodbye and wrap up any final details.

The best developer interviews feel like conversations between colleagues, not formal Q&A sessions. When you get it right, you’ll walk away having learned something new, and your audience will feel like they just spent an hour with someone they’d love to grab a coffee with and talk about some code.

Interviews on Java, MySQL, Cloud, Database, and FOSS. Taiwan 2019.

Here’s the article from above stripped down into a short checklist.

Before You Hit Record

Initial Contact

  • Send email explaining format (video/audio), duration, and general topics to set clear expectations and reduce guest anxiety.
  • Do a quick pre-call if the topic is complex or the guest seems nervous so you can uncover interesting stories and build rapport.
  • For Zoom interviews: start recording 15 minutes after joining to chat informally about their latest projects first. This helps guests relax and organizes your thoughts.
  • For live on-site: prep right before recording if the guest is experienced, but allow more time for those who are less comfortable on camera.
  • For complex events (panels, keynotes): layer preparation over multiple touchpoints including emails, group meetings, and rehearsals to ensure everything runs smoothly.
  • Tell guests general topics but don’t provide specific questions to preserve natural, spontaneous responses.
  • Set boundaries on off-limits topics (politics, competitive products, community conflicts) from the start to prevent uncomfortable moments.

Research

  • Check GitHub accounts for recent commits to understand their current technical work.
  • Read their blogs and articles to learn their communication style and key interests.
  • Review conference talks and presentations to identify topics they’re passionate about.
  • Research user group involvement and activities to understand their community contributions.
  • Check recent X, LinkedIn, or mailing list posts to stay current with their latest discussions.
  • Find interesting threads to explore during conversation so you can demonstrate respect and build a genuine connection.

During the Interview

Opening

  • Pre-plan your introduction to start efficiently, especially critical for live streams where you only get one take. But have a transition tool if you do mess up the live stream opening.
  • Jump straight into content after brief introductions. Don’t waste time with forced small talk.
  • Start with their recent work or achievements to engage them immediately with familiar territory.
  • Skip lengthy small talk and forced jokes that create awkward energy instead of authentic connection.

Listening

  • Actually listen in real time. Don’t plan your next question while they’re talking or you’ll create disjointed exchanges.
  • Use checklists to free your mind from technical worries (camera settings, recording status) so you can focus on the conversation.
  • Paraphrase what they said to show you’re following and encourage them to elaborate further.
  • Use body language and verbal cues (“That’s cool!” “Wow!”) to signal genuine interest and keep energy flowing.
  • React authentically to keep the conversation flowing. Forced reactions are obvious and create distance.

Bridging and Flow

  • Comment on what they just said before shifting topics to create seamless transitions.
  • Weave new issues into summaries of previous comments to bridge naturally: “That bug fix sounds complex. How did you approach it with so little time?”
  • Redirect gently if they go off on tangents: “That’s interesting. Hold that thought. I want to go back to your contribution process first…”
  • Use open statements, not just questions (“Tell me more about that”) to create conversational flow rather than interrogation.
  • Make mental notes to circle back to casual mentions they didn’t fully explore.
  • Mix questions, statements, prompts, and body language to make the conversations flow well. This isn’t a Q&A session.

Questioning

  • Ask one question at a time, or at most two directly related questions that build on each other.
  • Never ask compound or disparate multi-part questions that stress out guests, audiences, and yourself.
  • Break complex issues into multiple simple questions and guide guests through each part as they respond.
  • Use open-ended prompts (“Tell me about…”) instead of closed questions (“Was it challenging?”) to encourage storytelling.
  • Avoid leading questions (“Isn’t X better?”) and instead ask “What drew you to that approach?” for more detailed responses.
  • Guide them to explain complex concepts simply: “Break down your testing framework as if you’re explaining it to a new team member. Just a few of the top points.”
  • Let them answer fully before following up. Don’t interrupt their flow.

Story Collection

  • Ask guests beforehand to prepare a few stories so they have time to think about blending narratives into conversation themes.
  • Request funny disasters or dramatic moments (“Tell me about that time you took down the bank on day one”) to reduce stress and engage audiences.
  • Push for vivid sensory details (what they saw, heard, felt) to create scenes that draw listeners in.
  • Ask them to “take you into that scene” to get them reliving the memory rather than just reporting facts.
  • Encourage them to describe moments: “What was it like in that room when you realized what happened? Who was there?”
  • Focus on human elements, not just technical details. Watch how guests light up and become animated when telling real stories they’ve experienced.

Guest Comfort

  • Recognize that being interviewed differs from presenting. Even experienced conference speakers may feel awkward without slides or rehearsals.
  • Frame the interview as a fun chat, not a journalism interview. “This is a mutual discussion. We’re having fun here.”
  • Reassure that pauses/stumbles are normal and editable to create a safe space for authentic responses.
  • Share that you mess up too (introductions, names) to help them relax and feel less pressure.
  • Create safe space for authentic responses, especially for guests who aren’t media trained or don’t have control like they do in their presentations.
  • Adjust for guests who aren’t media trained. Don’t assume they’re skilled at free-flowing live or recorded conversations.

Role Flexibility

  • Encourage guests to ask you questions to ease nerves and spark unexpected insights.
  • Characterize the exchange as a two conversation, not a one way interrogation: “This is just us chatting about your work, so feel free to ask me anything as well.”
  • Expect to feel uncomfortable when you yourself are answering their questions! Asking questions is a different skill than answering them, even for experienced interviewers.

Managing Your Airtime

  • The guest should speak about 70% of the time with you prompting them along the way to keep things moving.
  • Insert yourself only to provide context or keep things going. Add comments here and there to give them breaks.
  • Don’t one-up their stories. If they share a major outage story, respond with “That sounds intense—how did you recover?” not your own outage tale.
  • Stay silent while they talk during live standups. Hogging the mic makes guests look uncomfortable standing there on camera. It’s your job to stand there and NOT look uncomfortable when you are not talking.
  • Check waveforms in post-production. Your waveform should show lots of silence.

Sound Quality

  • Insist on decent microphones or headsets for remote interviews. Affordable USB mics require no setup and must be used.
  • Postpone/cancel if audio quality is too poor. You can only fix so much in post-production, and bad sound is no longer acceptable.
  • Gently ask guests to project more energy if needed. Many developers are naturally shy but you want them sounding good.
  • Use headphones to monitor audio in real time so you can catch problems before they ruin the recording.

Closing

  • Plan your exit strategy because every conversation has a natural lifespan and you need to get out before energy dies.
  • Tell guests upfront you’ll ask for final thoughts so they can prepare something meaningful to end.
  • Use: “Before we wrap up, anything else to add? Any plans coming up?”
  • Keep your closing concise. Don’t drag it out with lengthy summaries unless it feels natural.
  • Thank them and provide episode release date to maintain clarity and goodwill.
  • Get out before energy dies because it will be obvious to listeners if you linger too long.

After the Interview

Follow-Up

  • Send a thank-you note to reinforce goodwill and maintain professional relationships.
  • Confirm episode release date so they know when to expect and share the content.
  • Encourage sharing within their networks since developers are well-connected in their communities.
  • Ask for feedback (“Any suggestions for how I could make these conversations better?”) to build long-term relationships and to learn yourself.
  • Or: Skip the final email. But don’t just disappear. Stop recording and chat freely for a few minutes to properly say goodbye
  • Maintain momentum for future collaboration and potential referrals to other interesting guests.

Obviously, this isn’t an exhaustive list of issues to consider. But it’s a good start. Cheers.

Duke’s Corner: The Final Archive

Here are all 77 podcasts I did for Duke’s Corner from 2022 to 2026. It was my great pleasure to interview all of these wonderful Java developers who spoke so passionately about the technology and the community over the years. All of your stories were amazing and inspiring! I loved every single conversation! Sadly, though, for me it’s all over now. Must make way for prompts and inference, I guess. But maybe we’ll meet again sometime soon. And thank you for all the nice comments on LinkedIn and X. Duke’s Corner Podcasts: https://grisanzio.com/duke/

Cristian Schuszter at JavaOne 2026

Cristian Schuszter at JavaOne 2026 | Duke’s Corner Java Podcast | June 15, 2026

Here’s the fifth interview I did at JavaOne 2026. Cristian Schuszter is a PhD in systems engineering and a Tech Lead at CERN in Geneva. He’s been at CERN for 8 years, but he’s been coding since he was eight years old. He loves working with and contributing to the Java community and other Open Source projects. This was Cristian’s first JavaOne, and his session, “30 Years of Java Development: Keeping it All Together,” covered how CERN keeps Java running across teams since 1998. Like any large company, CERN uses a lot of legacy code supporting systems that, in Cristian’s words, “need to keep running.” Java is not only used for business critical applications at CERN but also for accelerator system operations. On working at CERN among Nobel laureates, Cristian said, “I felt like I thrived in this kind of environment.” Cristian also helped revive the Voxxed Days developer conference at CERN and started the CERN Java User Group.

Luiz Real at JavaOne 2026

Duke’s Corner Java Podcast | May 26, 2026 | Luiz Real at JavaOne 2026

Here’s the thrid of six interviews I did at JavaOne 2026. Luiz Real is an engineer and college professor from the SouJava Community in Sao Paulo, Brazil. He came to JavaOne 2026 for the first time this year to build relationships, catch up on the latest technical features in Java, and to mix with the Java Champions. He says building those connections is something you can only do in person at a conference like this. “JavaOne for me is a career changing thing,” he says.

Luiz has been around Java for 18 years and working with it professionally for at least eight years. He’s a lead software developer at a large university and currently building digital management systems. The university runs more than 80 systems in Java. As he puts it, “Java in the enterprise world is, I think, the most reliable, the most used language.” Luiz is also a college professor, so he sees both sides of Java in industry and academic. His students are picking up Java because the jobs are there and they pay well. The hard part isn’t learning the language. It’s in the application. Students learn the fundamentals but sometimes struggle to apply them to real problems solutions. So Luiz brings real problem sets into class, works through them step by step, and explains what he’s doing as he goes.

On AI, Luiz sees real opportunities for Java developers. “Even in the AI era, we can do a lot more with AI now with Java,” he says. “You see language is a tool. I’m telling my students that if they want to learn they should learn as many tools as they can. This is very good for them because it’s just one more thing that they can put in their resumes and one more thing that can help them to achieve what they want and to solve the problems that the market presents to us.”

But there’s a catch he sees in his classroom regarding AI. Many students use AI to build things for them rather than to understand how those things work. So, he pushes students to ask the follow up questions about how the code they just built actually works. AI should be a tool for learning and extending their knowledge of Java development.

Luiz says his biggest opportunity for his career was when he joined the Java community. Everyone is so passionate about the language, he says, and willing to share what they know. “SouJava is one of the biggest communities in the world,” Luiz says. The community hosts at least one in person meetup a month, sometimes two or three. “Every month we get more than 100 people in person, and hundreds more online.” When SouJava partners with other communities, the events grow to 200-400 people in person. Everyone is a volunteer, from the registration desk to the speakers themselves. Attendees feel the energy and want to stay involved. They want to become friends and step up as the next speakers. SouJava also runs international sessions in English, in person and streamed live. “Everyone is welcome in our community.”

Henri Tremblay at JavaOne 2026

Henri Tremblay at JavaOne 2026 | Duke’s Corner Java Podcast | May 18, 2026

Here’s the second interview I did at JavaOne 2026 in March. Henri Tremblay is a Java Champion, Montreal JUG leader, and EasyMock lead developer from Canada.

Henri’s session at JavaOne covered the Java Memory Model, which is a topic he believes every Java developer should understand well. He’s been to six JavaOne’s and had warm words for the conference, which represents a rare opportunity to meet the people whose code runs on systems and devices all over the world.

He has clear advice for developers: read books, understand how and why your code works, and get out there and join the community.

We also talked about why Java still powers so much of the world’s critical infrastructure, from banks to the Mars rover. Henri pointed out that companies often start in C++ and then move to Java because Java runs nearly as fast once it’s going and is far easier to change later.

On AI, Henri had a balanced view. He uses it for tedious work, like sifting through a gigabyte of logs to find a single error. But he was also clear about the risks. “We should not get lazy at reviewing code because AI will generate tons and tons of code. It’s not bad at reviewing it, but still it makes mistakes.” He warned that AI reflects the average of what’s on GitHub, and most code on GitHub isn’t great. Your role, he said, is to find a better answer.

For students and junior developers, he says they should also leverage AI for learning, but he advises that they internalize the fundamentals of software engineering deeply. “Read books, please, please!” He pointed to Core Java, the book he originally learned from and is now helping revise. Blogs and YouTube videos only tough on surface level issues. Books take you deep and that’s the knowledge you need to grow your career.

Henri Tremblay on LinkedIn: https://www.linkedin.com/in/henritremblay/
Jim Grisanzio on LinkedIn: https://www.linkedin.com/in/jimgris/

Bill Joy’s Future

Was Bill Joy Correct Back in 2000? What His Warning Means for Science, Technology, and AI Today.

Since there’s a lot of distracting and unfortunate AI doom in the media these days, I figured I’d go back and revisit Bill Joy in April 2000 for some history on the pending catastrophes we keep hearing about today. I remember that Joy’s massive article “Why the Future Doesn’t Need Us” hit really hard twenty-six years ago. Joy was a cofounder of the iconic Sun Microsystems, after all. He helped build the Internet. And here he was now warning that three technologies might eventually lead to human extinction. Unlike today, though, that negative perspective was a pretty novel idea back then. The technologies he cited that could end us all included robotics, genetic engineering, and nanotechnology. His core argument was actually pretty simple. These were not like past technologies. These new things could potentially replicate themselves, and that’s the bit that would change everything if they were used as weapons or just got loose by accident.

I first read Joy’s article at a coffee shop in Cupertino, California right across the street from Sun where I worked in software systems marketing. The article was widely read at Sun and also across Silicon Valley and for months also generated wild discussions about Joy and his analysis. Many people just called him crazy. But that only demonstrates to me that those who made such flippant statements never read his article or thought deeply about his arguments. Others knew better, though. They knew full well that Joy was documenting in detail the very real risks of rapidly developing technology and the consequences of ignoring them.

That is, of course, the standard and pervasive culture of Silicon Valley. The valley may be big, but it’s remarkably insular as well. I didn’t know Joy at the time I read his article, but I went on to meet him several times at Sun and worked closely with his teams promoting projects like SPARC, Solaris, Java, Jini, and later on JXTA. I didn’t really know him well, of course, but he was always friendly and professional to me. He was quiet, too, and I always found him a serious thinker who obviously knew far more than he ever expressed. Sun was filled with such characters. They all fascinated me to no end.

The timing of the Joy article is also interesting. He said he had been working on the essay since his 1998 conversation with Ray Kurzweil and continued revising drafts through 1999. When Wired published the piece in April 2000, the tech world was at its peak. The NASDAQ hit a high of 5,048 in March of 2000 just a few weeks before the article dropped. And at that time Sun’s stock reached $250 a share, which gave the company a market cap around $200 billion. That was a significant achievement for 2000. Sun was one of the hottest companies in the valley back then, and it was quite an experience working there. The place was buzzing with activity. I loved it. Many of us did. So, it was into that environment of overt tech optimism running at manic levels that Joy published his thoughts about our potentially perilous future.

Andy Bechtolsheim, Vinod Khosla, Scott McNealy, and Bill Joy at the Sun Reunion in Silicon Valley in October 2019. Photo by Jim Grisanzio.

Boom!

Then everything blew up. The bubble burst. By mid-April 2000 the NASDAQ suffered its worst week in history and dropped more than 25 percent. Companies started dumping workers like I’ve never seen before. Joy’s dark warnings about unchecked technology landed precisely as that optimism crashed. He obviously couldn’t have seen the future, but his timing was remarkable.

Joy’s warnings took on an even darker tone the following year. After publishing the Wired article, he signed a book contract to expand on the concepts. He moved into a hotel room in New York City and surrounded himself with gloomy books covering plagues and nuclear bombs and other such material he was studying about the future risks of technology. Then on September 11, 2001 came the terrorist attacks we’ve come to know as 9/11. I knew a few people who worked at the Sun building in New York City, but I didn’t know Joy was also in the city at the time. He said he stood in the streets with everyone else and watched the impossible happen in real life. The next morning he went back outside and observed a long line of sanitation trucks parked on Houston Street ready to haul away the rubble. Everything below 14th Street was closed, he said. “It was quite a compelling experience, but not really, I suppose, a surprise to someone who had his room full of the books I was reading,” he said in a TED Talk. “I was not surprised that it happened at all.”

Joy eventually abandoned the book project. I point this out just as an aside since the event occurred shortly after he published the article I’m writing about here in this post. Still, it does reflect the feeling of the times. How much had changed in Silicon Valley and the United States in just one year.

Who Is Bill Joy?

Joy was born in 1954 in Michigan, and he was considered a child prodigy. He started school early, was reading by age three, and later excelled in math and science. He even graduated high school at 16. He loved books and thinking, and that became his escape from the world. He also loved science fiction and devoured Heinlein’s “Have Spacesuit, Will Travel” and Asimov’s “I, Robot” with its Three Laws of Robotics. He wanted to be a ham radio operator, which were the Internet hackers of their day, but he couldn’t afford the equipment. On TV, Star Trek inspired his imagination, and Gene Roddenberry’s “The Prime Directive” clearly resonated with him. You can actually see that ethic woven into his writing thereafter.

At Berkeley in the 1970s, he created the vi text editor, which to his surprise, was still widely used more than twenty years later Some hard core developers still use it even now. He also developed the Berkeley version of the Unix operating system and was a key contributor to the TCP/IP network stack. When the other founders of Sun Microsystems (Andy Bechtolsheim, Vinod Khosla, and Scott McNealy) invited him to join them, he participated in the creation of advanced microprocessor technologies and software technologies such as Java and Jini. As co-designer of three microprocessor architectures — SPARC, picoJava, and MAJC — he helped drive innovations that shaped modern computing.

By the time he wrote his famous Wired essay, Joy was only 45 years old and at the peak of his influence among developers in Silicon Valley. But Joy was far more than just a coder. He was well connected to the broader scientific community as well. That’s what made his article so jarring to so many people. He was not an uninformed critic chiming in from outside with yet another opinion in the media, which we’re all familiar with today as we read the news. He was a core architect of the digital age who was expressing deep doubts about where his own work was leading. His self-reflection was pervasive during this time in his writings and during his conference presentations.

The Kurzweil Meeting

Joy’s concern seemed to begin at George Gilder’s Telecosm conference in 1998 when he met Ray Kurzweil, who was an inventor and futurist. Kurzweil talked about how the rate of technological improvement was accelerating and also how humans may merge with robots or download their consciousnesses to achieve near immortality. I remember attending several talks on this topic of immortality when I moved to Silicon Valley in early 2000. It always sounded so silly to me. I wondered how such smart people could take that stuff so seriously. But even now some people in these circles talk about downloading themselves. It still sounds silly. The other bits, though, about intelligent robots and genetic engineering were much more reasonable given my own experience working in the biotech industry before I joined Sun. Joy had heard such talk before and always felt sentient robots were science fiction. But hearing it from someone he respected changed things. Kurzweil gave him a preprint of “The Age of Spiritual Machines,” which outlined a utopian future where humans gained near immortality by becoming one with robotic technology. I don’t know how far Joy goes with respect to robotic sentience, but it’s clearly more than I’m willing to accept.

Nevertheless, Joy’s unease intensified after reading the book. He felt sure Kurzweil was understating the dangers. Then he found a passage in the book describing a dystopian future where machines become so capable that humans depend on them completely. The passage argued that we wouldn’t consciously hand over control to the bots. Instead, “the human race might easily permit itself to drift into a position of such dependence on the machines that it would have no practical choice but to accept all of the machines’ decisions.” In other words, we would gradually grow dependent. I can surely see that as a potential reality, no question about it.

But that passage came from Ted Kaczynski, the Unabomber! Joy admits this realization was uncomfortable to say the very least since he was taking a point from a terrorist seriously. Many people have said the same thing after reading Kaczynski’s words, and he’s actually still cited even today. Kaczynski’s bombs had killed three people and wounded many others. One bomb gravely injured David Gelernter, one of Joy’s colleagues and friends. But Joy felt compelled to confront the argument because, however uncomfortable, he saw merit in that single passage about the unintended consequences of technology.

The Self-Replication Problem

Joy’s main concern centers around one key difference between powerful 21st-century technologies and those of the 20th-century. Nuclear weapons required huge facilities and rare materials. But genetic engineering, nanotechnology, and robotics, what Joy called GNR technologies, require less infrastructure and can potentially make copies of themselves. A bomb explodes once, but a self-replicating machine doesn’t stop. And that could be a serious problem if something goes wrong.

This matters because knowledge spreads freely. You can’t control ideas at all like you may be able to control uranium. Once people know how to genetically engineer bacteria or design tiny self-replicating machines, that knowledge exists in the world and will move rapidly. A small group, even one person, could potentially cause massive harm. Joy calls this “knowledge-enabled mass destruction.” As he wrote, “I think it is no exaggeration to say we are on the cusp of the further perfection of extreme evil, an evil whose possibility spreads well beyond that which weapons of mass destruction bequeathed to the nation-states, on to a surprising and terrible empowerment of extreme individuals.”

He made that point even sharper later. The real danger, he said, is no longer nation-states but individuals or small groups now empowered with “pandemic power.” These new digital, self-replicating technologies give extreme individuals the kind of destructive capability once reserved only for governments. That shift changes everything because the ramifications of mistakes or ill intent can’t be calculated or controlled.

The advancement of technology was clearly moving faster and Joy knew it. He learned about complex systems and non-linear systems from physicists Stephen Wolfram and Brosl Hasslacher in the early 1980s. These are systems where small changes move in unpredictable ways and where feedback loops create unexpected outcomes. Thus, they are extremely difficult to predict. Later, Joy deepened his understanding of these issues after conversations with Danny Hillis, a pioneer of parallel supercomputers and co-founder of the Long Now Foundation, biologist Stuart Kauffman, and Nobel laureate Murray Gell-Mann. Hasslacher and Mark Reed, a leading researcher in molecular electronics at Yale, also gave him insight into molecular electronics, which is the manipulation of matter at the atomic and molecular level where individual atoms replace transistors. When you get to this point in Joy’s article you can’t help but realize that he’s going well beyond just being a smart software developer who happened to strike it rich by helping found a successful tech company in the valley.

Joy knew that the merger of computers and physical sciences was creating enormous power, which up to that point others hadn’t expressed clearly in the popular tech media. By 2030, Joy calculated, we would likely build machines a million times as powerful as personal computers of 2000. That’s enough computing power to make the scenarios that worried him technically possible. As he wrote, “But now, with the prospect of human-level computing power in about 30 years, a new idea suggests itself: that I may be working to create tools which will enable the construction of the technology that may replace our species. How do I feel about this? Very uncomfortable.” He admitted he had once been too optimistic about nanotechnology. Having struggled his entire career to build reliable software systems, it seemed to him more than likely that this future would not work out as well as some people had imagined.

Three Scenarios

Joy walks through what could actually happen with these technologies. What’s interesting is that evolution itself would be one of the driving forces moving these technologies from a positive outcome to something very negative in the wrong hands.

One — Robots might simply out-compete humans for resources the way better-adapted species have always displaced others. We wouldn’t need a robot uprising. Hans Moravec, a roboticist and futurist at Carnegie Mellon, argued that “in a completely free marketplace, superior robots would surely affect humans as North American placentals affected South American marsupials.” So, economic forces alone could push us aside. Also, the dream of robotics includes downloading our consciousnesses into machines. But Joy questions whether a downloaded consciousness would be human in any meaningful sense. The robots would not be our children, and on that path our humanity might be lost entirely. This is one of the reasons why I take Joy seriously. He sees the obvious problem with the downloading issue in a way that others in this field simply do not.

Two — Genetic engineering gives us power to create devastating plagues, either by accident or intention. Joy calls this the “White Plague” scenario, which references a Frank Herbert novel where a molecular biologist weaponizes his knowledge. We now know these profound changes in biological sciences could be imminent and could challenge all of our notions of what life is, and Joy points out that the public remains skeptical even by the standards of 2000.

Three — Nanotechnology could produce “gray goo,” which are self-replicating nanobots that consume the biosphere. Eric Drexler, an engineer and pioneer of molecular nanotechnology, warned in 1986 that “tough omnivorous ‘bacteria’ could out-compete real bacteria. They could spread like blowing pollen, replicate swiftly, and reduce the biosphere to dust in a matter of days.” Joy notes grimly, “Gray goo would surely be a depressing ending to our human adventure on Earth, far worse than mere fire or ice, and one that could stem from a simple laboratory accident. Oops.”

The Manhattan Project Parallel

Joy uses the atomic bomb as his template. After Hiroshima and Nagasaki, physicists were shocked by what they created. Oppenheimer later said the physicists “have known sin.” But there was a real opportunity to prevent a nuclear arms race by internationalizing nuclear power as documented in 1946 via the Acheson-Lilienthal report and the Baruch Plan. It failed, though, because political distrust and competitive pressure got in the way. Within years, the Soviets had the bomb, and the arms race was on. This is a pattern that will repeat in the future.

Freeman Dyson, a theoretical physicist who worked on nuclear weapons and later advocated arms control, captured the moment: “The glitter of nuclear weapons. It is irresistible if you come to them as a scientist. To feel it is there in your hands, to release this energy that fuels the stars, to let it do your bidding. To perform these miracles, to lift a million tons of rock into the sky. It is something that gives people an illusion of illimitable power, and it is, in some ways, responsible for all our troubles, this, what you might call technical arrogance, that overcomes people when they see what they can do with their minds.”

Up to that point, everyone feared nuclear bombs as the ultimate expression of madness. But Joy feared that we were repeating the pattern with even more dangerous technologies, and the commercial incentives for their production would be enormous. Nations compete. Corporations compete. Individuals compete. Researchers want and need breakthrough innovations. The momentum builds, and pretty soon it’s almost impossible to stop. We are being propelled into the new century with no plan, no control, no brakes. However, the driver is not military necessity this time but instead private sector economic gain and competitive pressure. This is human nature, though. Our history is literally filled with these processes. It’s who we are. Joy was simply stating the obvious.

The Relinquishment Argument

This is the part that bothered many people the most. Joy argues for “relinquishment,” or the voluntary decision not to pursue certain lines of knowledge or technology because they are too dangerous. This goes against everything we believe about the value of knowledge and open inquiry, especially in Silicon Valley and across the scientific community generally.

That may be why Joy’s article struck such a nerve. The general population is used to various power centers attempting to curtail their freedoms for whatever reason of the day. But regular people are largely powerless to do much about it beyond voting, which is time consuming, or protesting, which brings its own personal risks. The scientific and technological elite, however, represents something different. They are one of the power centers themselves, and here was one of their own, a high profile one at that, advocating for relinquishment. You have to give it to Joy. He was brave to express such thoughts directly in the face of powerful people.

So Joy asks, what if the unlimited pursuit of knowledge puts us all in mortal danger? He points out that we have done this before. At a 1989 nanotechnology conference, Joy said, “We cannot simply do our science and not worry about these ethical issues.” The United States unilaterally abandoned biological weapons development because the logic was clear. These weapons were easy to replicate and could easily end up in malicious hands. We would be more secure if nobody developed them, and we embodied this concept in the 1972 Biological Weapons Convention and 1993 Chemical Weapons Convention.

Joy further quotes Thoreau: “We do not ride on the railroad. It rides upon us.” Then he asks directly, “The question is, indeed, Which is to be master? Will we survive our technologies?”

Joy isn’t advocating the stopping of all research. He just prefers being thoughtful and strategic about which lines of inquiry we pursue and which ones we intentionally avoid. It means international agreements, verification systems, and scientists adopting ethical codes like the Hippocratic oath. It requires transparency and cooperation. Within that context, he sounds reasonable, right?

Personal Responsibility

Joy writes honestly about his own sense of responsibility: “I feel, too, a deepened sense of personal responsibility, not for the work I have already done, but for the work that I might yet do, at the confluence of the sciences.” That statement carries some weight because Joy was someone who helped create the technologies that might enable the dangers he himself feared.

But he finds hope in the Dalai Lama’s “Ethics for the New Millennium,” which argues that the most important thing is to conduct our lives with love and compassion for others, and that our societies need a stronger notion of universal responsibility. This awareness of greater spiritual principles at play in a world of technology is rare among the valley elite. Joy was saying that neither material progress nor the pursuit of knowledge is the key to happiness. We need to find alternative outlets for our creative forces beyond the culture of perpetual technological and economic growth.

In the TED Talk he gave six years after publishing his article, Joy made the point even clearer. The solution, he said, can’t be technology alone. We need both better public policy and deeper moral progress. He spoke of the need for “the head and the heart,” which echoes Russell and Einstein. He also argued that scientists, technologists, and businessmen must be held personally accountable under the law for the consequences of their inventions. That must have been shocking to Joy’s peers! Yet, today they face no such responsibility. That, he believed, had to change. What’s striking about hearing him articulate these perfectly reasonable points is that they aren’t taken that seriously during the time he was writing or even now. Many thoughtful people say similar things at technical conferences or in political speeches. We all clap and support the concepts. Yet, very little actually changes. Or at least the changes take so long and occur in such small steps that we’re left unsatisfied in the present moment.

Was Joy Right?

Joy’s article was unique for its time in the popular press. When it appeared on Wired’s cover in April 2000, it created quite the rumble in tech circles. Joy even said it generated thousands of letters to the editor, many of them overtly hostile. Wired had been a cheerleader for the digital age for nearly a decade. Its shift from cheering to warning marked an important and surprising moment in the digital community. Also, Bill Joy wasn’t some alarmist outsider like many others. He was one of the core architects. His warning came from inside the cathedral and it certainly resonated. At the time, I was working in marketing at Sun, and one of my jobs was to promote Sun’s technologies to the media. In press interviews during this period reporters would always bring up Joy’s article even if the meeting was booked to cover another issue. We had to draft briefing and messaging documents to prepare executives, managers, and engineers that we brought into all interviews because we knew Joy’s article would always come up in the discussion. I remember many stressful meetings and awkward interviews from this period.

The article also presaged much of what we are experiencing now but not necessarily always in the ways Joy anticipated. His specific predictions about nanotechnology have not materialized yet. And the gray goo scenario is now considered flawed and implausible. Most scientists believe built-in limitations make runaway nanotechnology improbable. But the science is never settled, so we’ll just have to see how things evolve in the future.

But Joy’s underlying concerns were clearly prescient. And we have to deal with that. He worried about knowledge-enabled destruction, powerful technologies becoming widely available, and complex systems we don’t fully understand. All of these have become more relevant as artificial intelligence has advanced today far faster than most people expected in 2000. Interestingly, Joy only explicitly mentioned artificial intelligence once in his article, possibly because he was writing at the tail end of the second “AI winter.” Yet his concerns about self-replicating technologies and systems moving beyond human control resonate well with some of the modern AI risk debates these days.

In 2025, Joy himself reviewed his Wired article in a comprehensive session at Berkeley that covered scientific advancements over the last 50 years. He said he was called a doomer for his article in 2000, but to him it was just a matter of pragmatic realism. “So if we look back 25 years, the risk was real. It’s happened roughly like I said, and we haven’t done anything about it, which is really kind of frustrating and disturbing.” He also connected his original argument from 2000 to the technologies of today. Whereas 20th century technologies require rare raw materials, the thing about “21st century technologies is that they only require information. So, they’re fundamentally different and more dangerous and difficult-to-impossible to control.” One example he cites is that AI today is “verging on being able to do recursive self-improvement,” which is the very process he warned about decades ago.

He also warned about mirror life, which he described in the Berkeley session as a possible threat to the biosphere and cited recent reports from Stanford and Nature. He framed it as just one more example of powerful technologies that could cause catastrophic harm if misused. His concern remains fixed on crazy people using advanced technologies “to do bad things as their first act, and we wouldn’t have the chance to stop them.” His conclusions weren’t encouraging, which certainly fits the tone of his original piece in Wired back in 2000. Technology today has become more powerful, the financial incentives have become more intense, and society still hasn’t done enough to address the dangers he identified years ago. It seems like his predictions were pretty close to an observation of reality today.

In the same 2025 session, Joy said that the early calls for an AI pause and stronger rules for deployment were justified. “For the AI risk I think the people weren’t wrong that we need a pause, and we need rules, and we need to be aware that we’re giving very powerful tools to everybody. I mean, we have the bill of rights and freedom of speech, and we say it’s just information and everybody should have access to everything. That means if we spend a trillion dollars collectively in our society making something which has some good uses and also can be dangerous I have to give it to everybody independent of the fact that I’m then thereby giving it to the people for whom it can be dangerous. Or should I say, well, that’s some specialized knowledge and maybe it should be more closely held.” Fair point. But where to draw the line is the issue and that goes well beyond just talking about technology.

So, Joy recognizes the benefits of AI here, just as he recognizes the value of other technologies. But he also reserves much more of his focus to describe in detail his concerns about the risks. That fits well with the views he expressed in 2000.

He said that the field of advanced technology has quickly become another arms race driven by enormous financial incentives, which repeats the pattern of technical arrogance that he warned about in relation to nuclear weapons in his original Wired article. “People are so excited about what they can do with their minds, they just can’t help themselves. And there’s such a pot of money out there that they just can’t stop.” He said society was now “skating right past” the period when the technology is still flexible enough to control. Once everyone has money and status invested in the race, he warned, changing direction would become much harder. There’s a “social physics” he describes that makes things seriously complicated and extremely difficult for people to consider the consequences. The danger, though, isn’t necessarily the technology itself, which also has many benefits. Instead, the issue is that the technology in the wrong hands can cause problems that can’t be prevented or fixed.

That 2025 session at Berkeley is the first time I’ve heard Joy address his Wired article in detail in the context of today’s debates over technological risk. Hopefully, he’ll keep contributing to the debate because unlike many others in the media at present, Joy can speak articulately about the benefits of the technology without also losing sight of the risks. He has that credibility because he’s lived the history directly. Perhaps he will because now he’s working on an AI startup with his son, daughter-in-law, Claude, ChatGPT, and Gemini as the only employees. So, Bill Joy is very much in the game. It will be fascinating to see what he builds and how that differs from the current implementations of AI.

The Sun Sets

After leaving Sun in 2003, Joy moved into venture capital and focused on green energy and climate change investments at Kleiner Perkins. He also worked as a principal investigator and chief scientist at Water Street Capital. Now at 71, he’s focusing on his AI startup with his kids. And aside from his 2025 session at Berkeley, he’s mostly remained silent in public regarding the debate he actually started 26 years ago. It’s almost as if he said what he wanted to say in 2000, briefly repeated many of the same concepts in 2025, and now we’re left to digest his thoughts and hopefully implement his lessons all these years later. I doubt we will. I saw very little press coverage or social commentary of his 2025 talk at Berkeley.

Over the years, Joy didn’t stay stuck in doom or alarm. After the Wired article he actively tried to move toward better outcomes. He invested in solutions and backed innovations in education, new options to preserve the environment, and a major $200 million biodefense fund aimed at closing the gaps that could lead to a pandemic. He came to believe that we can’t solve the management of dangerous technology with just more technology alone. Instead, we need better policies, markets that price in the true cost of potential catastrophes, and a much deeper moral awareness. That combination of thoughts remains relatively rare today. Perhaps that explains the silence in the market that continues to just focus on doom rather than solutions.

Joy put it simply in that earlier talk at TED. “We can’t pick the future, but we can steer the future.” Over the years technologies have changed, but the fundamental challenge he identified in 2000 remains relevant now. Figuring out how to pursue knowledge and innovation while also maintaining enough wisdom and caution to survive the unintended consequences seems to be a question others should carefully consider today. Yet, few are doing so. In fact, the mania is running faster than ever and being driven by many people who have never heard of Bill Joy.

In his article, Joy compared coding to Michelangelo releasing statues from marble. He described his software engineering in a similar way to those ecstatic moments when the code emerged from his imagination as if it were already waiting in the machine to be freed. He ended his essay with that same image. After eighteen pages of text exploring multiple scientific disciplines and warning about existential dangers from the exploitation of technology, he wrote, “I am up late again, it is almost 6 am. I am trying to imagine some better answers, to break the spell and free them from the stone.”

Well, twenty-six years later, we’re all still up late as well. We’re still searching for those answers. But now we go forward in the wild world of AI, which probably represents the biggest paradigm shift enabling new opportunities in tech since the Internet itself. We should embrace those opportunities, but will we also consider and mitigate the risks?

Cluetrain Yesterday and Today

When I lived in California in late 2000 I read probably the best book on modern communications ever written: The Cluetrain Manifesto by Rick Levine, Christopher Locke, Doc Searls, and David Weinberger. The authors actually teased the book on the web in their 95 Theses in 1999, so we all knew what was coming would be equally outrageous. Couldn’t wait.

Back then I worked in Cupertino, and many times I’d take breaks and walk across the street from the office to get some coffee and flip through the pages. I loved it. It represented a radical departure in marketing and communications at the time because seemed obviously influenced by developers in the rapidly growing Free and Open Source Software movement (FOSS). I was already familiar with most of the topics in Cluetrain because I worked at Sun Microsystems and mixed with FOSS engineers every day. Still, it was cool to see the concepts applied to marketing where these ideas were totally unknown.

Cluetrain made bold predictions about markets becoming conversations, about authentic voice displacing canned corporate messaging, and about employees and customers breaking free from rigid command and control structures. We read it widely at Sun, especially those of us managing FOSS projects. Back then Sun was opening millions of lines of code, so the book gave us useful language as we built projects and engaged development communities. It also came in handy for dealing with the media, which was my primary job at the time. Cluetrain also fit Sun’s culture perfectly because the place seemed at times more like a frat house than a corporation.

The Prediction: Markets Are Conversations

The Cluetrain Manifesto’s central argument was clear. Mass media had interrupted human conversation and turned people into passive consumers and markets into targets. Even within Sun’s generally open culture, there were still power centers in marketing and product development talking in terms of “targeting” the media, developers, and customers. That positioning drove me nuts because the engineers never spoke that way. Cluetrain argued that the Internet would reverse that old paradigm because people could now talk directly to each other about products, communities, and companies across traditionally closed corporate firewalls.

The authors based their conclusions on their own observations. They showed how customers were gathering in online forums to compare notes, share experiences, and help each other get things done. Engineers at companies could openly explain their software to peers in the community and to potential customers without a corporate communications department in between. Companies that tried to control these conversations through legal threats or PR spin got mocked online, often without realizing it, so it fell to people like me to explain what was happening to teams internally. That was a painful process, I can assure you. The pushback from the more conservative teams was significant. But I never had to justify the book’s ideas to developers because in the FOSS community open communication was just considered normal.

But Cluetrain wasn’t simply calling for friendlier or more open marketing process. It was challenging the idea that companies should attempt to control the conversation about them. That was a wasted opportunity in the Cluetrain paradigm. The people building the products always knew more than the marketing department, and the customers using those products often knew things the company itself didn’t. The Internet let those conversations thrive at a scale that had never existed before, and it didn’t require everyone to agree to the latest message. In fact, disagreement was generally part of the value. People could challenge companies publicly and develop their own understanding of a product without waiting for the officially approved marketing campaign.

What Actually Happened

The first part of the prediction proved accurate. Conversations exploded online. Developer interactions thrived. Customer and developer reviews became crucial to purchasing decisions. Social media finally gave employees and customers a public voice, and many companies encouraged this change. For example, Sun and Microsoft were among the first large software companies to build blogging platforms for employees to talk with outside communities. Development engineers usually led the way, and within a few years Sun had more than two thousand employees blogging and talking to whoever they needed to talk to in order to get their jobs done. That openness was a real relief from the constraints of corporate life, and for a while the old, one-way broadcast model lost some of its grip. We used to call that old broadcast strategy “megaphone marketing” at Sun, but we were now in a many-to-many world. It was cool.

But the manifesto underestimated how quickly new gatekeepers would emerge, and how differently they would operate. The authors understood the Internet would break down old barriers between companies and their audiences, but they couldn’t have anticipated that the new communication systems would themselves become enormous businesses with their own tools and economic incentives.

Facebook, Twitter, Instagram, YouTube, and other platforms created spaces for open conversation, but they also monetized it. Attention became a product. Personal data became even more valuable than before. Algorithms became necessary to sort through the volume, but those same algorithms also began deciding which conversations got seen. A thoughtful explanation doesn’t necessarily earn more attention than an outrageous claim, and content that produces a strong emotional reaction can be worth much more to a platform than content that’s simply accurate or understated. And we all began to see this in our social feeds. A casual peek at a colleague’s screen would reveal that their online conversations showed an entirely different world based on their preferences that were amplified by the platform’s algorithms.

Bots and fake accounts made it worse and the line between an authentic participant and a manufactured one grew harder to see. And a well funded campaign could manufacture the appearance of agreement without any real support behind it. But developers could always see this. Most early FOSS projects ran on Mailman lists, so those discussions among engineers largely escaped the corporate swamp for years. Over time, though, as more engineers drifted onto social media, they were pulled into the mess too. The Internet didn’t eliminate gatekeepers. It built new ones with far more precision than the old media ever had. Also, whereas the old media tended to be centralized, the new one was atomized and embedded everywhere.

The Transformation of Corporate Communication

Companies adapted to these open changes quickly. They hired social media managers and community managers, built brand accounts, and encouraged employees to act as ambassadors. The language of Cluetrain worked its way into corporate communications and marketing meetings, which made it feel like the old model was changing. But something got lost along the way.

The manifesto called for people to speak from a genuine passion and their firsthand knowledge from working within an open community. However, what companies built instead was a new form of managed authenticity. Posts were getting written by communications teams and checked by legal before going out. Influencers were paid to look organic. Employees were encouraged to speak publicly while at the same time getting detailed guidance on exactly what they could and couldn’t say. Some companies appeared to be part of the conversation while also working to keep as much of the control as possible.

But other companies were more genuine about it. They admitted mistakes and let employees talk freely and participate in the communities. At Sun we aired plenty of our dirty laundry in public blogs, and the community noticed that and appreciated it. Several Microsoft bloggers did the same. But those were exceptions rather than the rule, and over time most companies learned to fold blogs and social media into the same communications machine they’d always run. Once authenticity became something a company could measure and manage, it turned into just another item in the corporate toolkit. It was wild to see people in marketing meetings starting to borrow the language engineers had used for years, at least on a surface level.

The Complexity of Authentic Voice

The manifesto also underestimated how hard an authentic voice is to maintain inside an large organization. It’s easy to say employees should speak honestly. It’s harder when those employees have managers, legal departments, and reasonable worries about what happens if they say the wrong thing publicly. People are complicated. They carry competing loyalties, worry about their careers, get tired, make mistakes, and sometimes just disagree with the company they work for.

Also, authentic doesn’t automatically mean good, either. A customer’s honest opinion can be unreasonable. An employee’s honest take can rest on a bias they don’t even recognize. A developer can be technically brilliant and still be a troll. FOSS communities learned this a long time ago, which is why so many projects eventually had to write and enforce conduct policies. Openness alone was never enough, especially when systems scale.

The manifesto also didn’t foresee how authenticity itself would become a commodity. Brands hire consultants to develop an authentic voice. Corporations spend real money trying to appear genuine, and influencers get paid to look like ordinary people making ordinary recommendations. As a result, people learned to perform realness the way they once performed professionalism, and once everyone is trying to appear authentic, authenticity just becomes another style of engagement. This is just a normal process of how organizations full of complicated people operate. It’s to be expected.

What the Manifesto Got Right, and What It Missed

Despite these blind spots, Cluetrain identified something real about how business would change. Markets did become more transparent, and information asymmetries did shrink. Customers and development communities gained real leverage over corporations. Microsoft’s own path from calling Linux a cancer to actively engaging open source projects is a good example. Companies that ignored what customers were saying suffered brand damage faster than they would have in the old broadcast era. And the hyperlinked organization the authors described turned out to be real to a certain degree. Work became more distributed. Information stopped moving strictly through the hierarchy. A developer could talk directly with a customer, and an employee could find the person who knew how to solve a problem without asking permission to cross multiple layers of management. Some managers didn’t love this, of course, but they couldn’t really stop it. Many even saw Cluetrain as an opportunity for career advancement and skill development.

What the authors missed, though, was that they underestimated how well old power would simply adapt. They believed the Internet would make hierarchy less important, and in some ways it did, but hierarchy didn’t disappear. It mostly moved online. They also underestimated scale. Small communities can sustain honest conversation because people get to know each other quickly. They learn who is helpful, who is selling, and who has a real history in the project. That doesn’t necessarily hold once a platform reaches millions or billions of people, though. Context breaks down, algorithms fill the gap by deciding which participants and messages get seen, and gaming becomes easier.

They didn’t foresee algorithmic curation either. The Internet made more information available, but that didn’t mean people would actually see more of it. Two people can use the same platform and end up with entirely different views of what’s happening because the platform is showing each of them a different slice of reality. And they didn’t anticipate how concentrated the new gatekeepers would become. All these years later handful of companies now provide the infrastructure most online conversation runs through. They set the rules, run the algorithms, and collect the data. The promise of decentralized conversation gave way to a new kind of centralized control.

The AI Complication

Then we got artificial intelligence, which is where Cluetrain gets interesting again. The authors believed people could tell the difference between corporate language and the way real people actually talk. That held up fine in 1999. It’s much harder to claim today, though.

AI can write a customer review, draft a social post, answer a support question, or generate an image that looks real. And it can do all of this while maintaining a consistent personality for years. Now, fake reviews and manufactured enthusiasm existed long before AI. What’s changed most recently is how cheap, easy, and fast it is to produce content at scale, and that undercuts one of the manifesto’s core assumptions. If authentic voice is what matters, but we can’t reliably tell which voices are authentic, what happens to the conversation? We used to be able to easily spot corporate messaging, but it’s getting harder and harder to spot AI messaging as those systems become pervasive.

It gets more interesting once you stop thinking about individual fake messages and start thinking about participants themselves. An AI system can answer questions, defend a company, criticize a competitor, and take part in a developer community to the point where people start developing relationships with it. But human reputation develops through repeated interactions where you have something at stake and have to live with what you said. But now an AI agent can simulate the pattern of that outcome without having any of the human substance behind it. Its apparent expertise actually came from a model trained on other people’s work, and its apparent reputation really belongs to whoever operates it either at the LLM or the harness level. That’s a bigger challenge to Cluetrain than simply noting that AI can write marketing copy.

Automation Is Not AI

There’s a distinction worth making here because it sometimes gets lost in many discussions about AI. Automation has been removing humans from transactions for decades. A vending machine does it. An ATM does it. A self checkout does it. None of those systems need AI at all.

I was reminded of this recently while clothes shopping in Tokyo. I expected a clerk to check each item, scan or key in the price, and fold everything neatly for me That’s usually how it goes here. This is Japan, after all. Direct human service matters. A lot. Instead, I dumped a tangled pile of ten items into a bin, and the system identified everything immediately, listed everything on a screen, and let me pay with a quick tap of my card (I love the security on that last part). No human involved anywhere in the process, and no bar codes for me to scan myself. It just worked. What matters here is that this kind of checkout doesn’t need AI to be impressive. RFID (Radio Frequency Identification) can identify a pile of products without anyone scanning them one by one, which is what makes the example useful beyond AI specifically. Automation has been removing people from physical transactions for a long time. We’re all used to it now even though we may not like it. This may help explain why people are so sensitive about AI because AI now extends that same trend but into our conversations. Now an AI agent can replace the conversation itself.

Where Cluetrain Still Works

I still see the original Cluetrain principles working in the FOSS projects I’m part of, though. A developer asks a question on a mailing list, and other developers respond with real knowledge and no filter. They argue, share code, make mistakes, correct each other, and build things together because there’s context and an expectation of openness and credibility. People develop reputations in these spaces. You learn who has expertise, who tends to cause trouble, and who is genuinely trying to help. That history and experience over time gives the conversation weight that a comment in a text box on a website can’t create on its own.

I’d revise one part of the usual argument here, though. It’s not quite right to say Cluetrain works at human scale and fails at platform scale, since some gigantic communities function well and some tiny ones are dysfunctional. What actually matters is context, reputation, shared purpose, and accountability. A local bookstore can have those things. So can a software consultancy, a FOSS project, or a single team inside a much larger company. But Cluetrain breaks down once a conversation gets so large and impersonal that participants lose the ability to build context and reputation, while at the same time the platform itself gains more say over what everyone sees.

What We Need Now

The Internet did change business, and authentic conversations did become more important. But the story didn’t unfold as cleanly as Cluetrain predicted. Markets became conversations, sure, but many of those conversations are now mediated by platforms with their own economic incentives. Our content is now run through algorithms built to hold our attention, and our conversations are increasingly populated by AI that can imitate humans well enough to fool most people who aren’t looking closely.

That raises real questions. Does it matter whether the voice answering you is human as long as it gives you what you need? Many times it doesn’t matter. And that’s fine. But in most cases, people tend to seek human interactions. The real question is how markets will function at scale if we really can’t tell who, or what, we’re talking to. We don’t know the answers yet since all of this is still emerging. Some companies are being transparent about their use of AI and are disclosing when people are talking to a bot. Some companies are now saying that AI is just a tool to augment humans rather than a replacement for humans. Others, however, will remain less transparent about their use of AI simply because the incentive to cut human involvement is massive. Those companies seem intent on pushing the narrative that AI will just replace people in the future.

I don’t think AI will destroy human conversation or replace people entirely. Markets are changing, that’s true, and many people will be displaced, but that’s been happening forever. Nevertheless, People will keep seeking relationships, expertise, and direct contact with other people. That’s just an innate human characteristic. And the more artificial our digital environments become, the more valuable genuine interactions will get. That may be part of why live conferences still draw big crowds. When you’re standing in a room talking to someone, you don’t have to wonder if an algorithm or someone bot produced the experience. It’s just real.

That’s what Cluetrain ultimately got right. Markets are conversations because markets are made of people. The Internet made those conversations possible at a scale no one could have imagined in 1999, but it also built new gatekeepers, new incentives, and new questions about who or what we’re actually talking to. I still talk about Cluetrain at developer conferences, even though almost nobody in the room has heard of it anymore. The book may be mostly forgotten, but the basic idea holds. We should still want knowledgeable people talking directly with customers and developers talking directly with their peers. And we should still want communities where reputation gets earned through real contribution rather than assigned by algorithms that can be gamed.

Bruno Borges at JavaOne 2026

Duke’s Corner Java Podcast — Bruno Borges at JavaOne 2026

Here’s the first of six interviews from JavaOne 2026. Bruno Borges works at Microsoft on GitHub’s Core AI developer relations team. The conversation covers the future of Java in a world of AI, the value of learning core computer science fundamentals in school, the shifting role for software developers from just writing code to architecting higher level systems, the new business value opportunities for developers as they leverage AI technologies, and Bruno’s new AI-assisted website called Java Evolved that visually compares old and new Java code patterns.