This is the second in a short series of speaker profiles for JavaOne 2026 in Redwood Shores, California, March 17-19. Get early bird pricing until February 9, and for a limited time, take advantage of a $100 discount by using this code at checkout: J12026IJN100.
In this conversation, Jim Grisanzio from Java Developer Relations talks with developer advocates Marit van Dijk and Anton Arhipov from JetBrains about the 25th anniversary of IntelliJ IDEA, the latest features of the IDE, Anton’s upcoming session at JavaOne in March, and their perspectives on JavaOne as the premier conference for Java developers.
25 Years of IntelliJ IDEA
Just as Java turned 30 this year, IntelliJ IDEA is now 25 years young! Not every technology survives that long, and even fewer thrive while doing it. But both Java and IntelliJ IDEA are doing just that. The secret to this longevity for IntelliJ IDEA, according to Marit van Dijk and Anton Arhipov, comes down to something simple but demanding — staying current with the Java ecosystem and engaging the massive Java development community around the world. The main reason for their success is the huge effort engineered into the platform to produce the technologies that developers need while at the same time staying with all the bleeding edge stuff happening inside the Java community.
This commitment reaches beyond just supporting new Java versions. The IntelliJ IDEA team works on preview features even though specifications sometimes change during the preview process. When Oracle moved to a six-month release cycle for OpenJDK about eight years ago, IntelliJ adapted smoothly since their teams were already involved with the OpenJDK community. Marit says that new release cycle actually streamlined their work. They already knew about preview features and could start developing support upfront, not at the very last moment. This let them iterate alongside the community rather than chasing after it.
The company also collaborates directly with other community members — such as framework developers, build tool teams at Maven and Gradle, and even Google — to implement best practices straight into the IDE. Maven 4 is not even released yet, but IntelliJ already has support ready with migration features to help developers make the transition. Anton says that this effort means that support is not only working with the new version of a technology but also being smart about how you use it. The IDE catches outdated patterns and deprecated APIs and also offers quick fixes to migrate code with a single keystroke.
First and Lasting Impressions
Both Marit and Anton started working at JetBrains years after they had already become devoted IntelliJ users. Their first impressions of the IDE moved them deeply and remain with them today.
For Anton, his first reaction to using IntelliJ IDEA was immediate. “In one word, wow, this is smart. This is an IDE that understands code.” That intelligence in the software became the foundation of his relationship with the technology.
Marit had a similar experience when she switched to IntelliJ IDEA. She had used other IDEs before and they were perfectly fine, but IntelliJ seemed different. “I found that it was actively helpful with the code inspections and quick fixes and helping me when my code didn’t compile or preventing me from making mistakes. And I was sad that I didn’t switch earlier, like years earlier. And I’ve been raving about it ever since. And now they pay me to do that. So, you know, everybody wins.”
AI and the Future of Development
As usual in these conversation, we turned to artificial intelligence and its growing role in software development. Anton will explore this topic in depth at his JavaOne session titled “Spec-Driven Development With AI Agents: From High-Level Requirements to Working Software.” Everyone knows that the AI landscape is changing fast, but things are actually getting simpler, Anton says. Developers can now get better results with less effort and less complex workflows using AI agents. Models are improving at guessing developer intent and reducing the need for careful constraint-heavy prompting.
But Anton sets realistic expectations about AI. When asked whether his session targets junior or senior developers, he says that “we are all juniors in this regard.” The field is so new that nobody can claim years of expertise with AI development tools.
Marit emphasizes another crucial principle about AI-generated code. “You are still responsible for the code,” whether you write it or an agent writes it. It has your name on it. AI does not diminish developer accountability or the need for developers to remain highly skilled in their craft.
Anton adds another dimension about integrating AI with development tools. “AI without the IDE is kind of unreliable, but the IDE without AI is unproductive.” The key, he says, is to fuse these things together leveraging the benefits of both for better productivity. The context the IDE provides and its understanding of your project structure and dependencies makes AI suggestions more relevant and actionable.
JavaOne: Where the Community Comes Together
Anton will be presenting at JavaOne 2026 in March, and both he and Marit shared their perspectives on what makes the conference special.
For Marit, JavaOne has always been unique. The “who’s who of Java” will be there, she says. Last year’s conference-ending “Meet the Architects” panel particularly stood out. The audience could ask Oracle Java architects basically everything about Java for over an hour. This kind of access to the core engineers building and shaping the future of the language is something you would not normally get at any other conference.
Anton shares his view that JavaOne has always been the conference to get all the news about Java. He has always viewed the event as the place where you get condensed information about what’s going on with Java all in one place — the language, the platform, the standards, the frameworks, and the community.
Community and Looking Forward
Marit and Anton maintain close relationships with the developer community through conferences and Java User Groups. Marit says that they have many JUGs in the Netherlands, and many of them invite her to come and speak at their meetups throughout the year. Also, when they travel somewhere for a conference, they look for opportunities to combine that trip with local JUGs to speak there and connect with people. This direct engagement with the open Java community lets Marit and Anton talk to developers directly, see how they can help them better, understand what developers are struggling with, and take that feedback back to the engineering teams. The same authenticity extends to how JetBrains approaches IntelliJ development. The engineering team maintains close relationships with framework developers and library maintainers and OpenJDK to ensure that when new versions release, IntelliJ users have good support from day one.
As IntelliJ IDEA celebrates 25 years, the development continues. They keep releasing new features with every version: the Spring Debugger that helps developers understand their Spring projects at runtime, Command Completion that enables developers to perform commands without memorizing shortcuts, and more. The anniversary celebrations for the teams have included parties with cakes featuring old logos, a game plugin that lets developers play video games while AI generates their code, and social media campaigns engaging the global community. For developers curious about IntelliJ IDEA, Marit and Anton encourage people to subscribe to the JetBrains YouTube channel where they regularly produce videos explaining new features.
This 25-year milestone represents more than just history. It represents an ongoing commitment to understand code, support developers, build the Java community, and evolve alongside the entire ecosystem. This pattern is pervasive among Java developers and also the many companies offering developers advanced tools. The smart IDE that so impressed Anton and Marit years ago continues to get smarter — right along with many other tools and technologies that are growing as a result of the Java platform itself.
This is the first in a short series of speaker profiles for JavaOne 2026 in Redwood Shores, California, March 17-19. Get early bird pricing until February 9, and for a limited time, take advantage of a $50 discount by using this code at checkout: J12026DCP. Register. Sessions.
In this conversation, Jim Grisanzio from Java Developer Relations talks with Jeanne Boyarsky, a Java developer, an author, and a Java Champion based in New York City. Jeanne previews her JavaOne session, which will be a Hands on Lab for Java 25 certification. Previously, Jeanne was a guest on Duke’s Corner in January 2024: Jeanne Boyarsky on Java, Learning, and Contributing.
Preparing for Java 25 Certification
Jeanne will be running a hands-on lab about Java 25 and getting ready for the certification: Becoming One of the First Java 25 Certified Developers in the World (or Learning New Features). The session will cover features added to the language from Java 17 to Java 25. Although the certification has not been announced yet, Jeanne is already preparing for it. “You can be one of the first people in the world to be certified if you come to my talk and learn about it and are ready when the test comes out,” she says.
The lab will walk through tricky questions and edge cases featuring new functionality, with coding practice to explore the features directly. Even if you are not planning to take the certification test, the lab provides a good way to learn about the new features. The session is designed for beginners with one to three years of experience.
Top Features in Java 25
Several features particularly excite Jeanne. She highlights scoped values, which she describes as “a good jump from thread local in order to be able to share code in a nice, safe, contained way.” She also appreciates unnamed variables and unnamed patterns because developers no longer need to use annotations to suppress warnings for unused variables. “You can just use an underscore,” she says.
Jeanne is particularly interested in stream gatherers because streams are one of her favorite features in Java overall. She was excited when stream gatherers were in preview, and now that they are officially released, she can use them in her job. “Nice that the excitement hasn’t worn off, right?”
Among the new features, Jeanne is especially interested in the new main method, as described in JEP 495: Simple Source Files and Instance Main Methods. “I’m super, super, super excited about the new main methods where you don’t need a class and you don’t need the whole static void mess,” she says. This change makes writing code more succinct.
Making Java Accessible to Students
This change in how Java handles the main method enables new developers to learn Java faster. Jeanne volunteers at a high school teaching kids how to code in Java. In the past, teachers had to tell students: “Alright, public class foo, public static void. Don’t worry about what any of that means. We’ll tell you later.” But Jeanne says that curious kids would ask what it meant, and teachers could only say that comes later.
Now, students start with void main, braces, and IO print line. “It’s obvious what everything does,” Jeanne says. Void means it does not return anything, which makes sense to students. They can even use the Java Playground and start with just IO print line. When they move to the command line or an IDE, they only need the void main part without discussing the word class until they are ready to learn about classes and objects.
“It makes their first impression of the language so much better, and it makes it so much faster and easier for them to get started,” Jeanne says. She particularly appreciates the Java Playground because students do not need anything installed on their computers to start. They can write print lines, loops, and control structures, and by the time teachers ask them to install something, they are already invested in programming. “It’s fun.”
Jeanne calls the Java Playground “awesome” and says it’s a “really nice utility” even for experienced developers. She uses it herself for quick tests when she does not want to open an IDE.
JavaOne on Oracle’s Campus
When asked about JavaOne, Jeanne describes the conference as moving to California last year, just outside San Francisco on Oracle’s campus. “The weather was great, which is awesome because I live in New York City. There’s snow outside right now,” she laughs.
The venue particularly impressed her. “It was nice because it was on Oracle’s campus. You got a feel for it. It was pretty. There was a lake. There was a lot of areas to connect with people inside and outside.” The conference was held largely in one building, with lunch in another building nearby, which made it easy to engage people repeatedly. “Even if you don’t know people, the fact that they’re at JavaOne means they’re interested in Java. So, you can go over to anyone and introduce yourself.”
One of Jeanne’s favorite memories from a previous JavaOne was meeting Duke and seeing her book in the Java bookstore.
Advice for Students
When asked for advice for students learning computer science, Jeanne recommends learning the fundamentals while using AI to help. “Rather than using AI to write the code, have it give you practice questions or do code review or ideas of projects,” she suggests.
Students also often ask what professional developers do daily. Her answer provides a realistic picture of professional software development. “Every day is a little bit different, but most days include a mix of meetings, working with my coworkers, code reviews, writing code, now with AI,” she says. Problem solving takes many forms, from performance questions like “Why is this slow?” to security concerns about making systems more secure.
A significant part of her role involves understanding what users actually need. “A lot of the time users ask for what they think they want and not what they actually want,” Jeanne says. Through user interviews, she works to understand what they are trying to accomplish, which often leads to better solutions than what they initially requested. “So not just building what you’re told is a huge thing, especially as you become more senior in your career,” she says. The goal is to make users productive and happy, not just to code.
Technology keeps changing, and for Jeanne, that constant evolution makes the work fun. She has embraced AI tools as coding assistants, using them for pair programming, generating tests, and suggesting next steps. When her team piloted coding assistants, they focused on choosing a tool rather than waiting for the perfect tool. “The important thing is to get a tool and get people going and using it and being more productive,” she says. The learning curve is not high, and the tools pay for themselves almost immediately.
However, Jeanne says that it’s important to understand what you are doing rather than using AI to replace that understanding. “It’s about understanding what you’re doing and not using the AI to replace it because at least with the coding assistance, it’s right 90, 95% of the time,” she says. She talked about an example of asking AI to generate a regular expression while pairing with a junior programmer. The AI started writing it properly but then made an error. “I noticed it right away because I know what correct is,” she says. After giving it another prompt with a hint, it produced the correct result. Without knowing what correct looks like, developers cannot effectively verify and fix AI-generated code.
The AI Hype Cycle
Regarding concerns about AI making developers obsolete, Jeanne is pragmatic. “I’ve heard that enough times that I’m a little skeptical,” she says, adding that this is the third or fourth time some technology has been predicted to take all the jobs. Instead, she sees AI as enabling developers to accomplish more and make users happier. She has a big backlog “that goes on forever.” She says it would be great if we could get more of it done and in the hands of customers.
“I think we’re at that phase in the hype cycle for AI where people are talking about AI like it solves all your problems, [but] it solves some of your problems. But because there’s less acknowledgement of the ones it doesn’t solve, it’s easier to have that skepticism.” When asked if AI represents a paradigm shift or just the latest tool, she responds: “Right now, I think it’s the latest tool, but I do think we’re going to get to the point where we’re programming at a higher level.”
Over the years I’ve worked on teams in construction, marketing, publishing, and software. I ran my own excavating business, built and sold homes and raw land, drove multiple big-rig trucks, and fixed heavy equipment as a mechanic. I also wrote magazine articles and managed publicity campaigns for companies and universities and worked with governments and media outlets around the world. Later I joined Sun Microsystems and Oracle, where I helped build Free & Open Source Software (FOSS) communities, ran global developer conferences, hosted multiple podcasts and video channels, and interviewed hundreds of engineers, scientists, physicians, and other technical professionals.
This disparate mix of experiences has shown me what separates strong teams from weak ones. Strong teams produce excellent work when they have clear roles, open communication, and a genuine focus on merit, quality, and service. But weak teams fall apart under poor leadership, bad planning, or cultures that punish people for speaking up. The best teams make life easier for everyone. People grow, the work gets better, and the whole group thrives. When I join a team, I look for these qualities. If they are missing, I move on if possible. I don’t stick around in places that waste my time.
Building a Strong Team Culture
The strongest teams come from managers who build their teams with purpose and maintain them with steady effort and improvement. These managers create a culture centered on merit, collaboration, and real chances for individuals to grow. They make sure everyone can share ideas and skills, regardless of position or experience. Effective managers also judge work by its quality, not by politics or personality. That builds trust and draws out the best from the team. It also sends a message that merit is the standard, not favoritism.
It starts with hiring. This lays the groundwork for everything that follows. Innovative managers tap current team members early in the hiring process. They collect input from everyone before interviews, include several people directly in discussions with candidates, and review feedback as a group afterward. This gives the entire team ownership and helps find people who fit the culture. Unfortunately, many managers skip this step entirely, which can weaken the team and reduce retention of people who have been producing great work all along. Nothing is more frustrating to the team than having to welcome a new team member you know nothing about and who may not fit.
When a new person starts, effective managers provide solid support right away. They pair the newcomer with an experienced teammate to speed up learning and answer questions as they arise. They share the team’s history, past projects, and major wins so the new member gets the context fast and begins contributing soon. This early investment in onboarding shapes how people view the team and their role in it for years to come.
Overall, the team’s structure, projects, and tasks should be well documented by the manager on an internal wiki that everyone can contribute to. Everyone should know what everyone else is doing. Clear roles are important. They cut down on confusion and lost time. Strong managers define and document these responsibilities, and then let people learn through actual work rather than just instructions. It’s natural for teams to evolve, so these managers watch the dynamics and adjust as needed. They shift workloads when necessary, invest in skills that matter, and improve processes continuously. They create safety so people can admit mistakes or question assumptions without fear. Most of all, managers like this foster pride in high-quality work. They value excellence in every detail, from code to documents to any other output team members produce. They also run blameless reviews to learn from issues without blaming individuals, which encourages honesty and speeds improvement.
What Effective Managers Do
Managing people takes real skill, study, and practice. The best managers balance care for the team with care for the work. They track short-term needs and long-term goals and opportunities at the same time. They stay reliable and visible and avoid jumping between tasks in ways that kill momentum. They protect focused time for the whole team, including themselves, because deep work that generates the most value requires sustained attention that constant interruptions destroy.
These managers look at data to make decisions, but they also know that numbers miss the full picture. People and projects have hidden layers that do not show up in reports. Effective managers welcome needed change but offer stability when things feel shaky. They plan for surprises and guide the team through tough shifts while keeping core goals clear. This balance between flexibility and steadiness marks the difference between managers who keep teams grounded and those who let chaos run wild. They shield the team from distractions and politics that drain energy without adding value. They advocate for people, block unnecessary pressure and distractions, and they keep communication solid especially in rough times. They reply to messages quickly and completely, share clear updates, and use shared channels so no one gets left out. They know instinctively that weak communication breaks trust fast, and once that erodes, it takes months or years to rebuild — if it can be at all.
Conflicts happen in any group, but capable managers handle them directly and calmly. Dodging problems makes everything worse because unresolved tension spreads through the team like a slow poison and can kill a team over time. Performance reviews receive serious attention from these managers. They give honest feedback tied to observable work and real impact. Nothing surprises anyone in a formal review because the conversation has been ongoing throughout the year. They deliver hard feedback privately and early when course corrections still feel manageable rather than catastrophic.
What Team Members Contribute
Everyone helps the team succeed. Strong managers set the tone, but capable contributors are encouraged to take initiative, own their tasks, and support colleagues in ways that multiply the team’s effectiveness. Everyone arrives prepared, on time, and engaged in meetings. They follow simple etiquette, mute when not speaking, and give full attention to the discussion at hand. They join team events to strengthen relationships and step up for tasks that build skills or help others, even when those tasks fall outside their formal job description.
They avoid multitasking because it harms productivity and leads to shallow work that satisfies no one. Instead, great performers handle several commitments by completing them one after another and meeting deadlines through focus rather than frantic juggling. They stay flexible when priorities change, which happens more often than anyone likes. They seek feedback on their work and offer constructive input to others, creating a culture where improvement becomes normal rather than threatening.
Team members make their schedules known, set regular hours, and stay reachable during work time so colleagues can count on them. In distributed setups, everyone posts updates and respond promptly because remote work depends on trust that people will follow through without constant supervision. Communication drives progress in ways that matter more than individual brilliance. Contributors share their current work, ask for help when needed, and clarify expectations before diving in. When they discover a problem, they articulate the issue and show up with a fix. They use team channels for group topics so everyone benefits from the discussion so issues are resolved fast. They send short status updates that keep people informed without overwhelming them. They praise in public and give critical notes privately, which builds morale while still addressing problems. They follow processes, document work well, and connect with outside communities when projects require it, which helps to bring fresh perspectives back to the team.
What First-Line Managers Handle
First-line managers set the culture and deliver results in ways that shape daily experience more than any executive mandate. They balance growing people with shipping projects, and they know that neglecting either one undermines the other. They run regular one-on-ones that go beyond surface chatter to address real concerns. They provide steady feedback throughout the year and ensure annual reviews hold no surprises because the conversation has been open and continuous. They mentor directly or link people to solid mentors who can offer the guidance they themselves cannot provide.
They open space for real talks about work struggles or personal matters that affect performance, recognizing that people bring whole lives to their jobs even if private issues go unstated. They back career moves, even to other teams, because keeping someone in a role they have outgrown helps no one. They keep roles defined and show how work ties to bigger goals so people understand why their efforts matter. They build unity through shared experiences that create bonds beyond the purely transactional. They resolve conflicts fairly, involving HR only when required by handling most issues themselves before they escalate.
First line managers are active and observant. They plan for turnover because people leave, and pretending otherwise leads to knowledge loss that can cripple the team for a time. They cross-train to share knowledge across team members so no single person becomes a bottleneck. They track time off to prevent gaps that leave the team understaffed during critical periods. For projects, they craft a clear vision with team input rather than dictating from above or focusing on their favorite employee. They assign tasks wisely based on skills and growth opportunities. They track progress without hovering, trusting people to deliver while staying alert for problems. They use practical metrics that reveal actual progress rather than vanity numbers that look good in reports but mean nothing. Unlike executives or second line managers, these first line guys are much more involved in the day to day operations, and so they must be sensitive to changes taking place under the surface of all the activity.
They push for needed resources and represent the team upward, making sure leadership understands what every member of the team needs to succeed. It’s obvious to individual contributors when they are left out of upline reporting, and these managers know that and never make this mistake. They communicate consistently with the team, their bosses, and peers across the organization. They raise problems early when solutions still come cheap rather than waiting until a crisis forces expensive fixes. They foster trust across groups because most work now requires collaboration that crosses team boundaries. In distributed teams especially, they ensure meetings feel fair by rotating times and giving remote voices equal weight considering their time zones. They spell out confidentiality clearly so people know what they can share and what must stay private.
Running Effective Meetings
Meetings move communication forward when done well, but poor ones drain time and energy without advancing any real purpose. Capable managers send agendas in advance so people can properly prepare and contribute meaningfully. They share notes after the meeting and archive them for reference, which focuses the conversation and lets absentees catch up on what they missed. This simple discipline prevents the endless rehashing that wastes time in teams with poor documentation.
They start and end meetings on time to honor schedules and prove that focused work matters more than performative presence. They hold one-on-ones to strengthen relationships and spot issues early before they grow into problems that require formal intervention. They limit surprise meetings to true emergencies to protect deep work time periods because every unplanned meeting interrupts focus that takes time to rebuild. They encourage all voices in the room. If someone stays quiet often, they check in privately to understand whether the person has nothing to say or feels unable to say it. Most people who stay quiet in meetings are hiding something and that’s a management problem. Standups remain brief, centered on blockers and decisions rather than detailed status reports that belong in written updates or team discussions.
They hold retrospective meetings when needed and turn findings into real changes rather than treating them as box-checking exercises that produce nothing. The best retrospectives create concrete action items with owners and deadlines. Without that follow-through, the retrospective meetings become cynical rituals where people stop contributing honest feedback because they know nothing will change.
Handling Distributed Teams
Distributed teams face extra challenges from time zones, languages, cultures, and economics that managers cannot wish away with talk about “global collaboration.” Strong managers tackle these directly rather than pretending geography does not matter. They push asynchronous work with good documentation, clear status reports, and written decisions that people can reference across time zones. They rotate meeting times occasionally so the burden spreads fairly instead of forcing the same people to join calls at 2:00 in the morning every week. It’s always nice to give everyone on the team a sense of what everyone else has to deal in remote geographies. The vast majority of managers ignore this issue entirely.
Remote members can lose out on influence when managers favor people they see in person, so effective managers counter that tendency deliberately. They may give remote voices priority at times to compensate for the natural advantage of those who are meeting in person. They move key discussions to text in a shared mailing list where everyone can participate equally. They monitor promotions by location to fix unfair patterns before they calcify into structural inequality. Non-native speakers may get extra time to formulate thoughts in a language that does not come naturally. Managers avoid jokes or phrases that exclude people unfamiliar with local references, and they judge on work quality rather than polish in communication.
Managers who understand international work actually study cultural communication styles because directness that works in one culture can seem rude in another, and consensus-building that one culture values can look like indecision somewhere else. They focus on results rather than matching a certain way of speaking, which often masks cultural bias as professional standards. They design budgets fairly so development chances feel equal regardless of where someone lives. When conference travel or training opportunities consistently favor certain locations, resentment builds and talent drains away from the teams that need it most. Remote team members feel these things immediately, but only a few consciousness manages are aware of this.
Representing the Team
Good internal management needs strong external advocacy because teams do not exist in isolation. Capable managers keep leadership updated on progress, risks, and issues early when interventions still work. Surprises hurt trust because executive leadership needs time to process information and adjust plans and budgets. So, managers need to highlight achievements, particularly for remote people whose work can stay hidden from executives who notice whoever sits near them or who has access to them. In large organizations, good work needs promotion because it will not speak for itself, so great managers share everyone’s work deliberately through newsletters, emails, demos, and presentations that get the team’s name in front of decision makers.
These managers align team efforts with company priorities and shift direction fast if something no longer matters to the business. Holding on to pet projects that leadership has deprioritized wastes time and marks managers as unable to adapt. They nurture relationships with peer teams ahead of time so they have goodwill to draw on when collaboration becomes necessary or when problems need resolution. Solid links ease joint work because people already know each other and trust that requests will get handled fairly. Without those relationships, every interaction starts from scratch and burns energy on establishing credibility that could go toward solving problems.
Delivering Results
The best teams ship quality work on schedule because reliability earns trust that opens doors for future projects. Effective managers set realistic timelines and meet them rather than promising the impossible and disappointing everyone. They favor consistent delivery over rushing to meet arbitrary deadlines that produce crappy work requiring expensive fixes later. When changes come, and they always do, these managers communicate them clearly, reset expectations with stakeholders, and explain the reasons so people understand the decision rather than resenting the disruption.
Well run team build quality products from the beginning with testing, reviews, and rapid feedback loops that catch issues early. Problems that are found in development cost far less than problems found in production, so investing in quality up front saves time and money. Managers running these teams identify problems quickly through monitoring, user reports, and team observation. They resolve them before they escalate into crises that pull everyone into emergency mode and destroy planned work for weeks.
Learning and Growing
Teams stay sharp through continuous improvement that treats learning as essential rather than optional. Strong managers fund conferences, courses, and certifications because everyone knows that skills atrophy without ongoing investment. Learning should be a priority that gets time and budget rather than something people squeeze in around real work. Team members should be encouraged to carve out work time for experiments and side projects because fresh ideas often emerge from open exploration that has no immediate business justification. Markets change rapidly. Preparing for the future needs to occur in the present.
Teams can easily grind themselves down from over working or working on low value or meaningless projects. So, observant managers watch closely for this. They look for burnout through signs like stress, short tempers, or people who quietly pull away from colleagues and activities. They adjust loads early to keep a steady, sustainable pace because burned-out teams produce poor work and lose people to competitors who offer saner conditions or more interesting projects. These managers run retrospective meetings after projects to pull lessons and break bad patterns before they become embedded habits that shape everything the team does.
Connecting Work to Real Impact
People perform best when they see the value in their efforts and understand how their work affects real users or business outcomes. Capable managers continually explain how the team’s tasks link to business goals, customers, partners, or the greater community in concrete terms rather than vague platitudes about innovation and excellence that are backed up by nothing. These childish statement are obvious, aren’t they? Instead, great managers make the connection obvious and reinforce it with data often because the link between daily work and the larger purpose gets lost in the grind of tickets and deadlines. It’s the responsibility of the manger to make these things clear.
Great managers also keep end users front and center so the team solves actual problems rather than building features that seem clever but serve no real need. They pass user feedback directly to the group in detail complete with quotes and context that make the people behind the data real. They recognize wins publicly with information that shows what the team accomplished and why it mattered. This lifts everyone’s spirits and shows what the organization values, which shapes future work more than any strategy document.
Giving Autonomy and Ownership
Strong teams empower people with ownership that makes work meaningful rather than treating them as interchangeable resources executing orders from above. Effective managers define clear goals and limits, and then they trust people to decide inside those bounds how to reach the objectives. This is critical for establishing trust, which accelerates work and sharpens judgment because people learn from their own choices. Micromanagement, on the other hand, stifles drive by signaling that managers expect failure and must control every detail to prevent disaster. It also reveals a weak manager who lacks confidence.
Autonomy is critical. It promotes accountability because people are encouraged to own both their successes and setbacks in a blame-free space that encourages honest assessment. Managers who promote autonomy encourage their people to openly talk about errors because learning speeds up when people can admit mistakes without fear of punishment. These managers assign stretch projects with support to build skills that formal training can’t provide. As a result, growth occurs when people are encouraged to tackle hard challenges safely but with backup available if things go wrong. And they sometimes do. But this freedom is important so people try approaches that might fail. That’s what generates new opportunities.
Great managers also spotlight top work openly to prove that merit counts for everyone, not just the favored insiders that many times emerge when groups form over time. When promotion and recognition follow visible achievement, people believe the system works fairly and they invest their best efforts. But when politics and favoritism determine who advances, talented people disengage or leave for places that reward their contributions. How many people on your team have long ago quietly quit with a smile on their face?
Final Thoughts
These observations come from working on teams across multiple industries and also from conversations with hundreds of professionals who built, led, and contributed to successful groups. Teams change, challenges shift, but clear communication, mutual respect, and commitment to merit and excellence endure across contexts. Take these ideas as a foundation. Adapt them to your situation. Refine them as you learn what works in your own environment. And good luck creating great teams.
By far the best project I’ve worked on over the years — OpenSolaris 2004-2010 and Solaris 2010-2016. It’s not even close, too. Hopefully, I’ll find a great project in the future that will meet or even surpass OpenSolaris and Solaris. The standard is high, though.
I’m always mindful of how much I talk while doing podcast interviews. At times I think I’m talking too much and getting in the way, and other times I struggle with how to keep things moving if I’m not saying enough. It’s a balance. But I’m learning. In this audio file below, I’m on top and my guest is on the bottom. This is the mix I’m most comfortable with. I just want to insert myself or respond to guide the interview, so I can highlight the guest and then get out.
Editing audio files for podcasts. Interviewer on top, guest on bottom.
Jim Grisanzio from Java Developer Relations talks with Chris Hermansen, a Java developer, consultant, and data analyst from Canada. Chris discovered Java in the 1990s and was drawn to its free accessibility and object-oriented design. He particularly appreciated Java’s straightforward single inheritance model over C++’s complexity. But Chris’s path to technology came through mathematics rather than computer science. He identifies streams as Java’s most transformative feature for data analysis work and praises how it improved code readability and maintainability. On consulting, Chris cautions against Silicon Valley mantras like “fail often” when applied outside prototyping contexts, and he observes cultural differences in how engineers approach problem-solving with some preferring abstract discussion while others focusing on concrete data. Chris emphasizes that technology work remains fundamentally human and stresses the importance of listening, maintaining humanity in professional life, and avoiding corporate stereotypes. For students, he notes the differences between learning with modern IDEs versus the command line tools of his era when he learned to code, so he advises that new learners to try multiple approaches to deepen their understanding. His core message, which became the episode’s title, is simple: “Don’t be afraid to create.”
Discovering Java in the 1990s
Chris discovered Java in the mid-1990 when Java was announced while working as a data analyst. “Java came along and it was free to use. It wasn’t open source at that point, but it was free to use,” he says. “And it really intrigued me because of its object-oriented approach to things, which was something that didn’t come with the platform we were working on.” Unlike the purchased software products he was using at the time, Java offered a free and accessible alternative that promised serious long-term value.
He also appreciated how Java’s design avoided the complexities of C++, especially the problems with multiple inheritance. He and a colleague had been discussing moving from Pascal to either C or C++, but his colleague had concerns about C++’s complexity, particularly around multiple inheritance. “The first thing that really jumped out to me was the straightforward single inheritance pathway and the use of interfaces to define contractual relations between code,” Chris says. Java’s approach to inheritance immediately stood out as cleaner and more maintainable.
Features like array bounds checking and interfaces for defining contractual relationships between code further convinced him he was learning something that would age well. “I felt that I was learning something that would wear well over time. I wouldn’t turn around and look at what I’d done 10 or 15 or 20 years later and say, yuck, what was I thinking?” After committing to Java and sticking with it through the learning process, he found it repaid his effort many times over. “I liked it and I stuck with it, and I found it paid me back enormously for my investment in learning.”
Career Path Through Mathematics
Chris’s path to technology came through math rather than traditional computer science. He actually stumbled into science during the registration process at school in the 1970s and eventually pursued math after deciding against engineering. His career took him through various mathematical applications, including consulting and data analysis positions in forestry.
Java’s Evolution: Streams and Beyond
Regarding Java’s evolution, Chris identified streams as the biggest feature improvement for his work. When asked about new features that have been useful in his applications, he immediately identifies streams as transformative. “I mean, streams was the big one. Streams just made a whole difference to the way you would handle data,” he says.
He contrasts the old approach of writing hundreds of lines of nested for loops with the more elegant stream-based approach: “And so streams has just made that a whole lot easier. And the code is so much more readable and maintainable than the old 500 line do loops that we used to have in Fortran that turned into the 375 line for loops in Java. Anyway, so streams is a big one, a really big one for me. The biggest, I would say.”
He also valued the introduction of templates (generics) in Java 5 or 6, which represented a significant evolution in the language and allowed applying libraries to custom classes. He praised the Java community for keeping the platform and ecosystem viable, noting that the combination of an active developer community and a satisfied user base creates a virtuous cycle that keeps the platform evolving and improving: “There’s enough Java programmers out there, enough people interested in the continuing viability of Java that they keep it going, that they modernize it, that they solve new problems with it, that they make it perform better than it ever has before.” He added a “big shout out to the garbage collection people that do that amazing stuff,” acknowledging the often-invisible work that performance engineers at Oracle do to make Java faster and more efficient for developers.
Throughout the discussion, Chris talked at length about developers, the user community, and the technology. He has a nice habit of mixing the issues seamlessly. Check out this gem below where he beautifully concluded that Java is far more than a language because it’s really a movement.
“The user community is, generally speaking, pretty satisfied with [Java]. And it’s a broad enough user community. It’s got people like me. It’s got people still doing desktop Java. It’s got people using it on servers. And there’s a whole tool ecosystem out there. Personally, I prefer working right at the command line. I always have. But the application that I mentioned we built using NetBeans, which came out of Sun originally. And it’s quite a nice IDE. I don’t think it’s the most popular one. It doesn’t really matter. It’s still a very nice one. And it gave us a big part of that long-term support. And lately, I find myself using other JVM languages. So it’s not just Java. It’s the JVM that underpins it, that has permitted a flowering of alternative approaches to things that, generally speaking, work very well together with Java. So, it’s a pretty cool thing. It’s a movement. It’s not just a programming language.”
Consulting, Professionalism, and Cultural Differences
On consulting and professionalism, Chris stresses the importance of contributing to the team to best serve customers. He cautions against embracing some Silicon Valley software mantras — such as “fail early, fail often” — when applied outside their intended prototyping context. “And I know failure is a thing that people talk about in software development. Fail early, fail often. But you don’t hear consultants saying fail often. It’s not a good look for a consulting company,” he says.
Instead, Chris focuses on engineering being technically excellent and using open communications to help ensure the team’s success. “In a consulting organization, you really have to be a team player,” he says. He clarifies that getting prototypes out for feedback certainly has merit: “Get something out there and [letting] people throw rocks at it and [recording] what they say [that’s] false and recognize that, okay, you failed, but at least you moved the ball down the field. I’m a huge fan of prototyping.”
Throughout the years in his career Chris also observed cultural differences in problem-solving approaches around the world. He says that some cultures prefer abstract discussion while others focus on concrete data. “Never mind all these grand theories. Let’s actually look what we have. And really, you know, like don’t go down that rabbit hole either. Look at what you have and base things on the reality that you know about,” he advises. He warns against getting lost in theoretical discussions: “Resist the old, you know, the medieval concept of how many angels on the head of a pin kind of thing. Just don’t go there.”
The Human Side of Technology Work
Chris emphasizes that technology work remains fundamentally human. Near the end of the conversation, Chris focuses what he sees as most important: “I would just emphasize maybe that we’re human beings here and we’re driven by our human desires and wills. And as you rightly pointed out, cultural things roll into that,” he says. Despite all the technical discussion about tools, languages, methods, and preferences, the work is ultimately done by human beings with human needs and motivations.
Cultural factors, listening skills, and collaborative team approaches matter as much as technical competence. “Remember, you spend a long time of your life at your job. And so, it’s important that that contributes to your humanity and that your humanity contributes back.” He encourages developers to remember their humanity throughout their careers, to contribute meaningfully to their teams and communities, and to avoid becoming caricatures of the latest corporate culture. “It’s really important to remember that you’re part of a group of human beings here. You don’t want to be a Dilbert comic,” he says, using the comic strip as a reference point for the dehumanized corporate worker trapped in absurd bureaucracy.
On the importance of listening, Chris shares wisdom from a sign he saw years ago: “If God had intended man to speak more than he listened, he would have given him two mouths and one ear. Listen more, say less.” When discussing custom solutions versus off-the-shelf tools, and after discussing how being familiar with algorithms allows you to blend approaches for better solutions, Chris delivers what became the title of the episode: “Basically, you know, if there’s not something off the shelf that — Don’t be afraid to create!” This is a message that Chris encourages all developers to embrace because they have such advanced skills right at their fingertips.
Advice for Students: Learning Then and Now
That creation framework extends to Chris’s advice to students learning software development. Students today face different challenges than he did decades ago. Chris compared his learning experience years ago with his daughter’s more recent computer science education. Modern students learn differently through sophisticated IDEs that suggest improvements and refactor code automatically, while Chris and his colleagues back in the day learned using only a command line, a text editor, and a compiler.
“The difference is really striking between the two because the only tool we had was the command line, the text editor, and the compiler,” he says. Modern IDEs provide capabilities like automatic refactoring and code suggestions that fundamentally change what students focus on during their education. He notes that learning with modern tools creates almost a different world than learning in his era: “And so it was really almost learning a different discipline for her than it was for me.”
He advises students to try multiple approaches to problem-solving and to explore all their options to apply their technical skills in many diverse fields. “And I think if there’s a lesson to be taken from that, sometimes it might be fun once you’ve learned how to do something in the IDEs to try and do it the old way and see what it’s like just creating from nothing, you know, and starting out that way. And vice versa, guys like me that always insist on using VI at the command line, we should learn an IDE. It’s time.”
Finally, Chris reflects on the value of learning multiple approaches to solving problems. This goes beyond just technical skills to understanding the problem itself more deeply: “I think learning several different ways to solve a problem ultimately teaches you more about the problem. And learning more about the problem, I think, teaches you a bit about yourself and how you go about solving things and your value to your organization.” During the entire conversation on technology, Chris consistently wove in the human element. We are people, after all. We’re just using digital tools to create.
Here’s the latest Java Platform Extension for Visual Studio Code with Java 25 and notebooks support. And 4.6 million downloads too! Great job by the Java engineering team in India! I hope to meet the team there when I go back to India in April 2026 for a session at GIDS. Will also stop by the Bangalore Java User Group as well. Should be a great trip.
In September 2025 Oracle released JDK 25 with sixteen enhancements. Java 25 represents the 16th consecutive release under Java’s six-month cycle, which demonstrates the company’s predictable delivery of production-ready features while still maintaining Java’s position as the leading programming language for enterprises of all sizes. Java 25 includes language innovations such as primitive types in pattern matching and flexible constructor bodies.
The release also introduces module import declarations to simplify working with modular libraries and compact source files to help beginners write simpler programs. Incidentally, the updates to help new developers get started with Java fast represent a major ongoing effort from the engineering team to evolve Java to better engage students at universities around the world. Try the new feature on the Java Playground on Learn.java for yourself. From Sharat Chander’s Post on JEP 512:
Evolves the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Rather than using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and later seamlessly expand those programs to use more advanced features as their skills grow. Experienced developers will likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large.
There are library improvements that include the fifth preview of structured concurrency for managing related tasks across threads and scoped values for sharing immutable data efficiently. The release adds stable values as performance-optimized constants and continues developing the Vector API for optimal CPU instructions. Security enhancements include a PEM encoding API for cryptographic objects and a Key Derivation Function API. The TLS protocol now supports more granular algorithm constraints and keying material exporters. The performance improvements include compact object headers that reduce heap size by shrinking object headers. Ahead-of-time command-line ergonomics and method profiling speed up application startup and warmup times. Monitoring capabilities are expanded through JDK Flight Recorder with CPU-time profiling, cooperative sampling for thread stack analysis, and method timing facilities.
Java 25 contains 2,606 fixed issues. Oracle contributed 1,655 fixes and the community contributed 951, which continues to demonstrate that Java is leading FOSS project that takes code contributions from developers worldwide. Oracle’s long-term support for the release runs through September 2033.
Get ready for Java 26 coming in March 2026 at JavaOne. Follow the development at OpenJDK and contribute. Follow all the technical content from the Java Platform Group, the engineering team that builds Java, on Inside.java.
Conversation with Barry Burd, a computer science teacher, an author, and the co-leader for two Java User Groups (JUGs). Barry is based in New Jersey and he’s taught at the undergraduate level for decades. His journey with Java began in 2004 when he attended small user group meetings of just five or six people. Those gatherings, once part of the Amateur Computer Group of New Jersey, have evolved into the Garden State Java User Group and the New York Java SIG, which now regularly feature Java Champions and prominent speakers from the Java development community. The transformation of the two JUGs on the East Coast of the U.S. reflects the broader growth of the entire Java ecosystem globally.
What distinguishes Barry’s perspective is his view of computer science as an art form. He frequently compares elegant code to works of art. He asks students who question the practical value of certain technical concepts whether they would ask the same question in a course about the Mona Lisa. This artistic perspective extends to his appreciation of Java as well. He marvels at the language’s thoughtful design, where features fit together as a unified whole rather than random pieces of technology thrown together haphazardly.
Java’s appeal for Barry grows from multiple sources. The language’s backward compatibility has been crucial for his work as an author and a teacher. He says that only one program broke across multiple editions of his books over the years. He contrasts this long term stability with other platforms that change frequently and force him to spend time fixing previously working code. The elegance and careful thought behind Java’s design resonates deeply with him. He appreciates the early decisions about inheritance and interfaces and the entire evolution of Java from the engineers under the stewardship of architects like Brian Goetz at Oracle.
Barry says that the six-month release cycle introduced in recent years has injected new life into the Java ecosystem. He sees the platform as self-sustaining now with strong leadership that shows no signs of fading. Living near New York City, he says that financial institutions depend on Java’s industrial strength reliability for obvious reasons. The technology serves two audiences well, he says, those who need rock-solid, enterprise-grade systems and those like himself who appreciate the beauty of well-crafted software.
When asked why Java is so great, Barry commented about the community but also added this bit: “I guess the other reason is that it’s good for industrial strength programming. People in the area of the world where I live in, close to New York City, in the financial district, rely on it. It’s just not breakable the way other platforms are.”
If you ever have a chance to take a software development class from Barry Burd, take it. You’ll love it.
Context: Barry discusses his approach to teaching and what drives him in the classroom. He emphasizes the importance of enthusiasm and helping students who are motivated by the subject matter itself, not just career prospects.
Time Stamp: (00:31:42)
Quote: “When I have a class full of people where they’re asking questions and most importantly, laughing at my jokes, I am thrilled. For me, it’s a party. It’s not a classroom. It’s a sort of a, let’s get together and have fun with this topic.”
On the Love of Programming
Context: Barry describes his teaching philosophy and how he tries to convey his passion for computer science to his students, while also acknowledging that not everyone shares that passion.
Time Stamp: (00:32:05)
Quote: “I want them to understand that I love talking about this stuff and that if they share any of that love, I want them to participate in it.”
On Computer Science as an Art Form
Context: When asked why computer science matters and what he tells students about the field, Barry explains his perspective on programming as an artistic endeavor rather than purely practical skill.
Time Stamp: (00:44:05)
Quote: “For a lot of the courses, I treat it as an art form. There’s such a thing as elegant code and there’s such a thing as inelegant code. There’s such a thing as a beautiful algorithm and there’s such a thing as an algorithm that shouldn’t exist but does.”
On the Beauty of Computer Science
Context: Barry elaborates on why he teaches computer science, comparing it to art appreciation and explaining his personal motivation for working in the field.
Time Stamp: (00:46:05)
Quote: “When I think, why computer science? It’s because it’s artistic! It’s, oh yeah, I mean, it’s useful. And I certainly respect that. And I’m glad that people develop useful things for it. But my own interest in it is the beauty of it.”
On Java’s Industrial Strength
Context: Barry discusses why Java has had such longevity and what makes it special compared to other languages, particularly its reliability for critical systems.
Time Stamp: (00:55:59)
Quote: “I guess the other reason is that it’s good for industrial strength programming. People in the area of the world where I live in, close to New York City, in the financial district, rely on it. It’s just not breakable the way other platforms are.”
On Java’s Elegance and Thoughtful Design
Context: Barry explains what drew him to Java and what keeps him committed to the language, emphasizing the careful design philosophy behind it.
Time Stamp: (00:53:03)
Quote: “The other important part is it is so elegant. It is written, it is created, so thoughtfully.”
Time Stamp: (00:53:42)
Quote: “When Brian Getz and his team create new features, new classes, new parts of the Java ecosystem, they do it with the most careful thought possible.”
Time Stamp: (00:54:05)
Quote: “Overall, the platform is so well thought out. It’s such, for the purpose of teaching, it’s such a sensible way of exposing the underlying concepts of object-oriented programming and now more recently, data-driven, data-oriented programming.”
On Languages That Lack Industrial Strength
Context: Barry contrasts Java’s thoughtful design with other languages that feel less carefully constructed.
Time Stamp: (00:54:44)
Quote: “There are other languages whose names I won’t mention that seem like they’re pieces of stuff thrown together willy-nilly, not at particularly industrial strength.”
On Java as a Unified Whole
Context: Barry describes his appreciation for how Java’s features work together coherently and how this aligns with his way of thinking.
Time Stamp: (00:54:59)
Quote: “Java is this unified whole. I appreciate ideas that I can think of as one thing.”
Time Stamp: (00:55:42)
Quote: “There’s so much of Java that was created thoughtfully that in my mind feels like one idea, one snapshot. And that’s what I like to teach. And that’s what I like to write about.”
On the Six-Month Release Cycle
Context: Barry discusses what has helped Java remain vibrant and relevant over 30 years, particularly the introduction of more frequent releases in recent years.
Time Stamp: (01:01:05)
Quote: “The introduction of the six-month release cycle seems to have given an injection of life into the Java ecosystem that has really, really been good for it.”
On Java’s Future Sustainability
Context: When asked whether Java can sustain its quality and community over time, Barry expresses confidence in the platform’s future.
Time Stamp: (01:01:58)
Quote: “It seems to be self-sustaining. The introduction of the six-month release cycle seems to have given an injection of life into the Java ecosystem that has really, really been good for it. The fact that the stewards, the people at the head of the story who are managing the overall platform are doing a tremendous job right now.”
On Industrial Strength and Elegance Together
Context: Barry reflects on what the Java community needs going forward, balancing practical reliability with aesthetic appeal.
Time Stamp: (01:02:23)
Quote: “We need code that works for the developers, and we need code that’s elegant for us dreamers like me, crazy people.”
On Education Section at JavaOne
Context: Barry recalls an important moment when he realized that Oracle was seriously interested in the education sector, which made him feel less like an imposter at Java conferences.
Time Stamp: (00:21:32, 00:22:00)
Quote: “That educator session at JavaOne in 2025 … that was the first time that I saw that … Oracle is getting hyped up about the education sector. That was great! That was a wonderful session.”
On Java User Groups Evolution
Context: Barry describes the dramatic transformation of his local Java user group from informal learning sessions to a professional organization featuring top speakers.
Time Stamp: (00:02:45)
Quote: “We would, somebody in the group would find a topic to talk about, some platform, some piece of software, some Java thing, and they would kind of learn about it the week before and go in and talk about it. I gave some speeches like that, some presentations where I had no idea what I was talking about. I just learned it the week before.”
Time Stamp: (00:03:35)
Quote: “Suddenly we’ve gone from this group where it’s a bunch of people just spouting stuff that they learned last week to a first class Java User Group.”
On Being Thrilled by Haskell
Context: Barry recounts asking Brian Goetz what language he uses when “cheating on Java” and being delighted by the answer.
Time Stamp: (00:51:40)
Quote: “I was thrilled. His answer was Haskell. And I was just like, yeah, yes, man, yes. That’s a wonderful language.”
On Backward Compatibility
Context: Barry explains why Java’s backward compatibility has been crucial for his work as an author, contrasting it with other platforms that break frequently.
Time Stamp: (00:52:05)
Quote: “I’ve written six editions of beginning programming with Java for Dummies, and I’ve written eight editions of Java for Dummies. And the entire time that I’ve written these books, there was exactly one program that broke from one edition to the other. Just one.”
Time Stamp: (00:52:37)
Quote: “I’m working right now with another platform and, you know, they change it every month. They break things. Oh my God, how am I going to deal with these? I spend half my time just fixing programs that were working two weeks ago. I hate that. Backward compatibility is really nice.”
On First Encountering Java
Context: Barry recalls his first experience with Java when it was still in beta, reading the language specifications and being impressed by the design decisions around inheritance and interfaces.
Time Stamp: (00:53:12)
Quote: “The first time I encountered Java was Java was in beta and I downloaded the language specs. And I read it and I started off and it said it looked like C, C++ for a while. But then I read what they’re going to do with inheritance and what they’re going to do with interfaces. Wow, that is, as my colleague said years ago, that was like putting on a comfortable pair of shoes.”
On Feature Development Process
Context: Barry discusses how the Java team approaches adding new features to the language, emphasizing their methodical and thoughtful process.
Time Stamp: (00:54:27)
Quote: “In general, when they add a feature, it’s because they’ve spent a long, long time making sure that that feature fits nicely into the language, that that feature is usable, that that feature isn’t going to cause conflict and trouble with other parts of the language and cause trouble for other developers.”
On Teaching Through Visualization
Context: Barry describes his teaching methodology and how he works to help students conceptualize programming concepts as complete mental pictures rather than just syntax.
Time Stamp: (00:30:32)
Quote: “My teaching method changes every single day. Every day I’m trying to think of a new way of drawing pictures within their minds. You know, a loop isn’t a bunch of letters, F-O-R, open parentheses, blah, blah, blah, blah, blah. It’s something that you can see. It’s something you can feel.”
Time Stamp: (00:31:20)
Quote: “This is the picture. This is what you should think of all at once when you think of the quicksort. It’s not a bunch of lines of code. It’s this idea, you know, watch those little pieces bubble from one part of the list to another.”
I’m always looking for opportunities. I learned that from my father, who never let an opportunity go unnoticed. Opportunities may seem rare but that’s not true. They’re common. They’re flying all over the place. The issue is that we miss them because we’re too distracted, or when we spot them we’re too afraid to grab them. The only way around this problem is to practice. Try one. Fail. Learn. Try again. Get it! Start small so you don’t risk too much. Scale that process over time. Simple.
This opportunity bit is critical because life is brutal in that it can wreck anything it sees at any given moment. We need to implement as many opportunities as we can just to break even! Remember, it can take decades to recover from some crash life delivers. Or sometimes there is no recovery at all. I know this to be true. Painfully.
I think about this all the time because I’ve missed so many opportunities over the years — but I’ve captured a few along the way as well. A big one I leveraged a while back is represented by the image below. That’s Atul Chitnis. He used to run a software conference in Bangalore called FOSS.IN. I met him via my friend Danese Cooper. Back then I was on the OpenSolaris project at Sun, and I had a community development presentation I was working on. I didn’t really have much experience delivering sessions to large audiences, but Danese thought I’d be good and she said I should submit my presentation to the conference. She also contacted Atul and recommended me. I then spoke to Atul myself and pitched my story. He bought it! I got a session on the main stage! That was my first OpenSolaris session at a real FOSS conference. This wasn’t a vendor sponsored thing. It was real.
My point is that we all need help. We can’t do anything alone around here. That’s why our network is critical. Look for people who will give you a shot. It’s possible your network contains connections you can’t easily see. Keep looking. Keep practicing. Keep pithing.
Atul is no longer with us. He passed in 2013 but I think of him and appreciate that he gave me an opportunity.
