Many of us have significant experience in Java. Yet, from time to time, we get tripped up by some code that we quite did not expect to behave the way it does.

In this presentation we will take a look at some of those and get a deeper understanding of the language we use everyday.

A prerelease feature in Java, structure concurrency is going to change how we do concurrent programming.

In this presentation we will take a look at the benefits of this new feature and how to make use of it.

Java has been evolving at a rapid pace. Some of the most noticed changes are the features in the language. However, there are other interesting and significant changes in Java, not related to the language but in the JDK and the ecosystem.

In this presentation we will take a look at some of those exciting changes and how we can benefit from them.

The switch feature of Java has gone through an amazing transformation. In this presentation will start with switch as a statement, transform from there to an expression, and into a full blown pattern matching syntax.

We will get quite deep into this feature to explore various usecases.

Threads have been part of Java since the beginning. But, the new virtual threads, introduced as prerelease in Java 19, are different in how they're implemented and how we can benefit from them.

In this presentation we will learn about virtual threads, the problems they solve, and how to make use of them.

We are knowledge workers and ultimately, we must own our growth and learning. Personal Knowledge Management is a process of collecting information that one uses to gather, classify, store, search, retrieve and share knowledge in their daily activities and the way in which these processes support work activities.

Despite taking notes, bookmarking web content, and highlighting passages in books; often we struggle to recall or rediscover these many insights we pick up daily in our work and life. This session introduces a tool and some process recommendations to never again lose discoveries and knowledge resources.

Michael shares the tools and workflow he (and many on the NFJS tour) use to write, organize and share your thoughts, keep your to-do list, and build your own digital garden. These approaches naturally connects what you know the same way your brain does, and makes it easier to make everything you learn actionable and always at your fingertips.

You'll learn the basics, tips and tricks, and recommendations of these tools and practices; and leave armed to deploy these right away as you continue learning at the conference!

In this example-driven session, we'll review several tips and tricks to make the most out of your Spring development experience. You'll see how to apply the best features of Spring and Spring Boot, including the latest and greatest features of Spring Framework 6 and Spring Boot 3.

Spring has been the de facto standard framework for Java development for nearly two decades. Over the years, Spring has continued to evolve and adapt to meet the ever-changing requirements of software development. And for nearly half that time, Spring Boot has carried Spring forward, capturing some of the best Spring patterns as auto-configuration.

As with any framework or language that has this much history and power, there are just as many ways to get it right as there are to get it wrong. How do you know that you are applying Spring in the best way in your application?

Workshop Requirements

You'll need…

• A Java IDE of your choice. I'll be using Spring Tools, but you are welcome to use IntelliJ, Netbeans, or whatever you prefer for Java development. (Spring Tools–either the Eclipse or VSCode version–or IntelliJ is recommended, though).
• Java 17 or higher. I recommend using SDKMan (https://sdkman.io/) for managing multiple versions of Java on your machine. I'll be using Zulu 17.0.6 for most tasks, but may switch to a Liberica NIK version for purposes of native builds.
• Docker (optional, but may be necessary for some tasks)

Although Java originally promised write once, run anywhere, it failed to fully deliver on that promise. As developers, we can develop, test, and build our applications into WAR or executable JAR files and then toss them over the wall to a Java application server and Java runtime that we have no control over, giving us zero confidence that the application will behave the same as when we tested it.

Containers fulfill the write-once, run anywhere promise that Java wasn't able to, by packaging the runtime and even the operating system along with our application, giving greater control and confidence that the application will function the same anywhere it is run. Additionally, containers afford several other benefits, including easy scaling, efficiency in terms of resource utilization, and security by isolating containers from their host system and from other containers.

While deploying Spring applications in containers has always been possible, Spring Boot makes it easier to containerize our applications and run them in container architectures such as Kubernetes. Spring Boot's support for containerization includes two options: Creating containers based on buildpacks or using layers as a means of modularizing and reducing the size of our application deployments. Moreover, new components in the Spring ecosystem can make your Spring applications Kubernetes-savvy so that they can take advantage of what a containerized architecture has to offer.

In this example-driven session, we're going to look at how to create and deploy Spring applications as container images and deploy them into a Kubernetes cluster. Along the way, we'll also get to know a few of the most useful tools that a Spring developer can employ in their development workflow when building containerized Spring applications. We'll also see how to apply patterns of Spring Cloud–such as configuration, service discovery, and gateways–using native Kubernetes facilities instead of Spring Cloud components. And we'll look at how components of the Spring ecosystem can work with your Spring applications to enable them to thrive in a Kubernetes cluster.

Workshop Requirements

• Java (17 or higher)
• An IDE of your choosing (I'll be using either Spring Tools or IntelliJ, but VSCode or even NetBeans will be fine if you prefer)
• Docker Desktop (https://www.docker.com/products/docker-desktop/)
• Kind (https://kind.sigs.k8s.io/)
• Kubectl (https://kubernetes.io/docs/reference/kubectl/)
• Skaffold (https://skaffold.dev/)

Test your setup: Make sure that the Docker Desktop is running and then type “kind create cluster”. It should take a minute or so, but then you should be able to type “kubectl config current-context” and see “kind-kind” listed.

In this example-driven presentation, we'll focus on how to build reactive APIs in Spring. We'll start with Spring WebFlux, a reactive reimagining of the popular Spring MVC framework for HTTP-based APIs. Then we'll have a look at RSocket, an intriguing new communication protocol that is reactive by design.

Traditionally, applications have been built using a blocking, synchronous model. Although comfortable and intuitive for most programmers, this model doesn't scale well. And although there are several new approaches to reactive programming, they don't necessarily fit into the familiar programming model that Spring developers are accustomed to working with.

Spring 5 introduced a set of new reactive features, enabling non-blocking, asynchronous code that scales well using minimal threads. Moreover, it builds on the same concepts and programming models that Spring developers have used for years.

In this example-driven presentation, we'll focus on working with reactive data persistence. We'll start by seeing how to create reactive repositories for relational databases with Spring Data R2DBC. Then we'll explore non-relational reactive persistence for MongoDB and Cassandra.

Traditionally, applications have been built using a blocking, synchronous model. Although comfortable and intuitive for most programmers, this model doesn't scale well. And although there are several new approaches to reactive programming, they don't necessarily fit into the familiar programming model that Spring developers are accustomed to working with.

Spring 5 introduced a set of new reactive features, enabling non-blocking, asynchronous code that scales well using minimal threads. Moreover, it builds on the same concepts and programming models that Spring developers have used for years.

In this example-driven session, we're going to look at how to implement GraphQL in Spring. You'll learn how Spring for GraphQL builds upon GraphQL Java, recognize the use-cases that are best suited for GraphQL, and how to build a GraphQL API in Spring.

Typical REST APIs deal in resources. This is fine for many use cases, but it tends to be more rigid and less efficient in others.

For example, in an shopping API, it's important to weigh how much or how little information should be provided in a request for an order resource? Should the order resource contain only order specifics, but no details about the order's line items or the products in those line items? If all relevant details is included in the response, then it's breaking the boundaries of what the resource should offer and is overkill for clients that do not need it. On the other hand, proper factoring of the resource will require that the client make multiple requests to the API to fetch relevant information that they may need.

GraphQL offers a more flexible alternative to REST, setting aside the resource-oriented model and focusing more on what a client needs. Much as how SQL allows for data from multiple tables to be selected and joined in response to a query, GraphQL offers API clients the possibility of tailoring the response to provide all of the information needed and nothing that they do not need.

Workshop Requirements

• Java (17 or higher)
• An IDE of your choosing (I'll be using either Spring Tools or IntelliJ, but VSCode or even NetBeans will be fine if you prefer)

Our jobs usually deal with something other than new code. It is usually old spaghetti and difficult-to-read code. How do we test such code? How do we get through it? How can we surgically remove and make some of this harmful code testable?

This session looks at lousy code, and we talk about some strategies we can do to diagnose, test, apply, and finally refactor to produce something that would promote some sanity in your development process. We can do much with our code to make it better and testable while avoiding extensive mocking. The content of this course is all in Java and JUnit.

Workshop Requirements

• JDK 11+
• Maven 3.8.x
• IDE (I will be using IntelliJ)

Kafka is a “must know.” It is the data backplane of the modern microservice architecture. It's now being used as the first persistence layer of microservices and for most data aggregation jobs. As such, Kafka has become an essential product in the microservice and big data world.

This workshop is about getting started with Kafka. We will discuss what it is. What are the components, we will discuss the CLI tools, and how to program a Producer and Consumer.

Kafka is a “must know.” It is the data backplane of the modern microservice architecture. It's now being used as the first persistence layer of microservices and for most data aggregation jobs. As such, Kafka has become an essential product in the microservice and big data world.

This workshop is about getting started with Kafka. We will discuss what it is. What are the components, we will discuss the CLI tools, and how to program a Producer and Consumer.

We live in a world of microservices. Yet, what is a microservice? What defines the boundaries of a microservice? How do we define the relationships between microservices? Thankfully domain-driven design gives us the concepts and practices to better design and decompose our services.

In this session we will consider many of the concepts of DDD — How bounded contexts use Ubiquitous language to model the domain, how context maps can be used to establish the interconnections between services as well aggregates and domains events, all of which will service us well as we go about creating our microservices.

We will also discuss the “tactical” patterns of DDD — We will see how we can “embed” the ubiquitous language in code, and the architectural influences of DDD.

This workshop will have you thinking about how to think in DDD using DDD concepts and ideas. Using polls, and mini-exercises we attempt to better cement the ideas of DDD so we can start applying them at work.

We live in a world of microservices. Yet, what is a microservice? What defines the boundaries of a microservice? How do we define the relationships between microservices? Thankfully domain-driven design gives us the concepts and practices to better design and decompose our services.

In this session we will consider many of the concepts of DDD — How bounded contexts use Ubiquitous language to model the domain, how context maps can be used to establish the interconnections between services as well aggregates and domains events, all of which will service us well as we go about creating our microservices.

We will also discuss the “tactical” patterns of DDD — We will see how we can “embed” the ubiquitous language in code, and the architectural influences of DDD.

This workshop will have you thinking about how to think in DDD using DDD concepts and ideas. Using polls, and mini-exercises we attempt to better cement the ideas of DDD so we can start applying them at work.

It's not just architecture—it's evolutionary architecture. But to evolve your architecture, you need to measure it. And how does that work exactly? How does one measure something as abstract as architecture?

In this session we'll discuss various strategies for measuring your architecture. We'll see how you know if your software architecture is working for you, and how to know which metrics to keep an eye on. We'll also see the benefits of measuring your architecture.

We'll cover a range of topics in this session, including

• Different kinds of metrics to measure your architecture
• The benefits of measurements
• Improving visibility into architecture metrics

You have been using Git for a while. You know how to stage and commit your work, create and delete branches and collaborate with your team members using remotes. But Git often leaves your confused — ever committed to your work to the wrong branch? Even worse, ever accidentally delete a branch that you needed to keep around? And what is God's good name is “Detached HEAD state”? Why tag commits, when we have branches? Is there a better work-flow than just using merges? What's the difference between a merge and a rebase?

The answer to all of these questions, and more, lies in the constitution of a commit, and the directed acyclic graph (DAG) that Git uses to manage your history. This, right here, is the key to understanding everything in Git.

In this hands-on workshop, we will level up your Git skills. We will foray into the underbelly of Git, and reveal the mystery behind the arcane interface that is the Git CLI.

By the end of this workshop, you will have a keen understanding on how best to use Git, as well as know how to dig yourself any prickly situation you might find yourself in. You will become your team's hero(ine). Most importantly, you will walk away with a keen appreciation of how beautiful and elegant Git really is.

You have been using Git for a while. You know how to stage and commit your work, create and delete branches and collaborate with your team members using remotes. But Git often leaves your confused — ever committed to your work to the wrong branch? Even worse, ever accidentally delete a branch that you needed to keep around? And what is God's good name is “Detached HEAD state”? Why tag commits, when we have branches? Is there a better work-flow than just using merges? What's the difference between a merge and a rebase?

The answer to all of these questions, and more, lies in the constitution of a commit, and the directed acyclic graph (DAG) that Git uses to manage your history. This, right here, is the key to understanding everything in Git.

In this hands-on workshop, we will level up your Git skills. We will foray into the underbelly of Git, and reveal the mystery behind the arcane interface that is the Git CLI.

By the end of this workshop, you will have a keen understanding on how best to use Git, as well as know how to dig yourself any prickly situation you might find yourself in. You will become your team's hero(ine). Most importantly, you will walk away with a keen appreciation of how beautiful and elegant Git really is.

In today’s volatile technology and business climate, big architecture up front is not sustainable. Attempts to define the architectural vision for a system early in the development lifecycle does not work. To accept change, teams are moving to agile methods, but agile methods provide little architectural guidance. In this session, we provide practical guidance for software architecture on agile projects.

We will explore several principles that help us create more flexible and adaptable software systems.We’ll expose the true essence of what’s meant when we say “architectural agility.” And we’ll explore the real goal of software architecture and how we can accommodate architectural change to help increase architectural agility.

Monoliths are out and microservices are in. Not so fast. Many of the benefits attributed uniquely to microservices are actually a byproduct of other architectural paradigms with modularity at their core.

In this session, we’ll look at several of the benefits we expect from today’s architectures and explore these benefits in the context of various modern architectural paradigms. We’ll also examine different technologies that are applying these principles to build the platforms and frameworks we will use going forward.

Along the way, we’ll explore how to refactor a monolithic application using specific modularity patterns and illustrate how an underlying set of principles span several architectural paradigms. The result is an unparalleled degree of architectural agility to move between different architectural paradigms.

As of Java 9, modularity is built in to the Java platform…Finally! Yet few teams are using it. And in reality, you may never use it…at least not for a while. However by understanding the module system, you're guaranteed to see the Java platform in a completely different light. In this session, we explore the default module system, how it works on the Java platform, and what’s in the future for the Java Platform Module System.

We will demonstrate the impact that JPMS will have on our existing applications and identify what we must do to get ready for JPMS. You will also see firsthand how to use the JPMS and the benefits that support for modularity on the Java platform will have on your applications.

Software development is an amazing profession, requiring the delicate combination of analytical and creative skills. Understanding architectural patterns, agile best practices, and exploring the depths of platforms, tool, and languages requires deep analytical skills. Yet crafting a system also requires vision and understanding when to deviate from traditional best practices.

In this session, we will explore lessons learned over many years of building large software systems. We will challenge traditional assumptions and explore new ways of thinking.

How does designing Microservices differ from designing more traditional applications?

What is a better way to learn than to take a problem, analyze the requirements, explore the design options, apply the concepts of bounded context, and arrive at the architecture and design of Microservices to realize the requirements?

Come to this workshop to get a practical, hands-on practice to navigate from requirements all the way to a workable solution and along the way learn about different architectural goals and approaches that can help with the design.

Workshop Requirements

git client to fetch the examples and labs from a git repository.

How does designing Microservices differ from designing more traditional applications?

What is a better way to learn than to take a problem, analyze the requirements, explore the design options, apply the concepts of bounded context, and arrive at the architecture and design of Microservices to realize the requirements?

Come to this workshop to get a practical, hands-on practice to navigate from requirements all the way to a workable solution and along the way learn about different architectural goals and approaches that can help with the design.

Workshop Requirements

git client to fetch the examples and labs from a git repository.

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

In this workshop, we will start by discussing how to approach refactoring, the essential steps we need to take, and look into how to incrementally improve the internal design of code to make it extensible, maintainable, and cost-effective to change. In addition to discussing the concepts, we will take several code examples from real projects, discuss the code smells and explore the refactoring techniques. Along the way, we will also dive into refactoring short code samples and measure the quality of code before and after refactoring.

Workshop Requirements

Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

In this workshop, we will start by discussing how to approach refactoring, the essential steps we need to take, and look into how to incrementally improve the internal design of code to make it extensible, maintainable, and cost-effective to change. In addition to discussing the concepts, we will take several code examples from real projects, discuss the code smells and explore the refactoring techniques. Along the way, we will also dive into refactoring short code samples and measure the quality of code before and after refactoring.

Workshop Requirements

Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE

Game of Life is an intriguing game. At first look it looks simple, but as you look closer, it appears to be quite complex. How can we implement this game with different constraints, what are the constraints? Is it possible to use functional programming for this, to honor immutability? You see, it is intriguing.

We will discuss the constraints, think about how we may be able to solve them, and along the way discover how functional programming can play a role. We will have a fully working program, using live coding, at the end of this session, to illustrate some nice ideas that will emerge from our discussions.

As developers we not only operate in different contexts, but also often have these different contexts interplay as part of our work.
Each of the tools that we use — version control systems like Git (along with collaborative tools like Github/Gitlab), IDE's like Eclipse/IntelliJ, build systems like Gradle, Ci/Cd tooling like Jenkins, IaaC tools like Ansible, the command line — all introduce context.

To be effective developers we need to know when to operate in a certain context, combine or tease apart how these contexts interplay.
Can you improve your release announcements if format your commit messages consistently? You bet!
How should your build tool interact with your version control system?
What does naming your files have to do with how you use your IDE?

This session will take a look at several of these contexts — it will attempt to discern between them, explore when you should separate them and when you attempt to bring them together.

With lots of examples, and lots of quizzes this session will definitely leave you thinking about a few things.

This workshop builds an entire event driven data pipeline with Machine Learning and Kafka. From Kafka where we use producers or Kafka Connect to generate information, we then will Kafka Streams to apply a machine learning model to make business decisions.

This intensive lab will start by integrating sources into our backplane, then train our models, and operationalize our model using Kafka Streams. We will then create result topics when we can read in as a report and display visualizations of our data. The result will also be scalable and fault tolerant.

Workshop Requirements

*Github Account

Mob Programming is a style of programming in which the entire team sits together and
works on a single task at a time. Teams that have worked this way have found that
many of the problems that plague normal development just melted away, possibly because communication and learning increases. Teams also find that the quality of their code increases. They find their capacity to create increases. However, the best part of all this is that teams end up being happier and more cohesive.

In this session we introduce the core concepts of mob programming and then get hands-on mobbing on a coding kata.

Mob Programming is a style of programming in which the entire team sits together and
works on a single task at a time. Teams that have worked this way have found that
many of the problems that plague normal development just melted away, possibly because communication and learning increases. Teams also find that the quality of their code increases. They find their capacity to create increases. However, the best part of all this is that teams end up being happier and more cohesive.

In this session we introduce the core concepts of mob programming and then get hands-on mobbing on a coding kata.

This workshop builds an entire event driven data pipeline with Machine Learning and Kafka. From Kafka where we use producers or Kafka Connect to generate information, we then will Kafka Streams to apply a machine learning model to make business decisions.

This intensive lab will start by integrating sources into our backplane, then train our models, and operationalize our model using Kafka Streams. We will then create result topics when we can read in as a report and display visualizations of our data. The result will also be scalable and fault tolerant.

Workshop Requirements

*Github Account

Over the last decade, DevOps has emerged as an influential business philosophy and practice, helping businesses drive high quality software to market faster. DevOps focuses on the elimination of bottlenecks that occur when development and operational resources are too divorced from one another. But what about friction in the development and test process? What about the delayed feedback cycles that come from slow builds and test flakiness? How can we reduce friction in areas that are outside of the focus of DevOps? The presentation will include examples of DPE practices in action from Java projects using the Maven or Gradle build tool.

Attendees will walk away from this presentation with a better understanding of:

• Acceleration technologies for speeding up feedback cycles
• How to use data analytics to quickly determine the root cause of problems and prevent problems from happening in the first place
• The costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
• The importance catching errors earlier, including incorrect signals like flaky tests
• How to make the practice of developer productivity engineering a respected discipline

We have been using JUnit and doing TDD for years, but you can take testing further. In this session, we will discuss some tools you absolutely need for testing your code outside of the regular stack you currently use.

• Property-Based Testing with JQwik
• Mutation Testing with PITest
• Databases Testing with Test Containers
• Performing RestFUL based testing with Rest-Assured
• Perform Asynchronous Testing a Verification using Awaitility

The linux command line is powerful, but for those of us who weren't “borne” into that world, it can be a bit daunting. If the extent of your usage of the command line is limited to a handful of memorized git commands, npm cli, and the occassional copy and paste one-liner from the web, this session is for you.

In this session, we cover the basics of the *nix toolbelt, and how those tools can be chained together to unleash powerful compositions that will transform your workflow. Next we cover a series of tips, tricks, and shortcuts to increase your speed. Finally, we cover shell extensions and plugins worth exploring. If you've been watching command-line wizards with envy; this is your opportunity to join them.

Part one of this series introduces the ideas, motivations, and applications of linked data along with historical context. This more technical session dives deeper into the tech stack and available tooling.

We'll dive into key linked data patterns, explore semantic modeling, graph queries, and talk about applying these ideas in the field, where the rubber meets the road!

The web is arguably the single most impactful revolution in human history (to date). By agreeing on a simple set of standards, we have collectively unlocked all the world's information. Documents can be discovered, retrieved, published, and shared so easily we don't even think about it.

Data, on the other hand, is a different story. Our data remains stuck in the 1980s. Locked in silos, each with a different format, interface, and conventions that must be interpreted by a human, parsed, mapped, and converted. Data is at the heart of many problems we solve today, and we produce data exponentially faster than we can consume it.

Today I can request any document from any server on the web. I need to know nothing about the underlying technology the server uses, nothing about how the information is stored or retrieved, and consume it instantly. We've been evolving those same capabilities with data over the past 20 years and the standards, tools, and technologies are reaching critical mass. The linked data revolution is now one that you can no longer ignore. Join us to see what you've been missing.

Completely Rewritten for 2023

REST is, undoubtedly one of the most maligned and misunderstood terms in our industry today. So many different things have been called REST, that the world has virtually lost all meaning. Many systems and applications that self-describe as “RESTful” usually are not, at least according to REST as defined in Dr. Roy T. Fielding’s 2000 Dissertation, “Architectural Styles and the Design of Network-based Software Architectures”.

The wild success of the architecture derived by Dr. Fielding led many to want to emulate it (even when it was inappropriate to do so). As a shorthand, organizations began referring to “RESTful” systems, which exposed “RESTful” APIs. Over time “REST” became a buzzword referring to a vague generalization of HTTP/json APIs that typically bear little to no resemblance to the central ideas of REST (and thus elicit few of the benefits). Hypermedia is the central pillar and defining characteristic of the REST architectural style yet it remains almost universally absent.

Hypermedia was a revolutionary idea that, while more relevant than ever, is almost forgotten in today's tech space. Consequently few reap the benefits of this idea and ever fewer know what they might be giving up.

Although not every system needs to (or should be) RESTful, it's helpful to understand the key–and often overlooked–ideas to be able to decide if they make sense for your current next project. This session introduces the key foundational ideas and shows what these ideas look like in practices. Although hypermedia and REST don't make sense for every project or system, you'll leave this session with a better understanding of these groundbreaking ideas, practical insights on how to adopt them today, and ultimately armed to approach the trade-offs of this approach mindfully and deliberately.

Integration, once a luxury, is now a necessity. Doing this well, however, continues to be elusive. Early attempts to build better distributed systems such as DCOM, CORBA, and SOAP were widely regarded as failures. Today the focus is on REST, RPC, and graphql style APIs.

Which is best? The go-to answer for architects is, of course, “it depends.”

In this session, we look at the various API approaches, how they attempt to deal with the challenge of decoupling client from server, evolvability, extensibility, adaptability, composability.

The biggest challenge is that needs change over time, and APIs must necessarily evolve. Versioning is challenging, and breaking changes are inevitable. You'll leave this session with a high-level understanding of these approach, their respective trade-offs and ultimately how to align your API approach with your architectural and organizational goals.

Architecture is often described as “the stuff that's hard to change” or “the important stuff (whatever that is).” At its core, architecture defines the very essence of software, transcending mere features and functions to encompass vital capabilities such as scalability, evolvability, elasticity, and reliability. But here's the real question: where do these critical capabilities truly originate?

In this session, we'll embark on a journey to uncover the secrets behind successful architectures. While popular architecture patterns may offer a starting point, it's time to unveil the startling truth – both monolith and microservices-based projects continue to stumble and falter at alarming rates. The key to unparalleled success lies in the art of fine-tuning and tailor-making architectures to precisely fit the unique needs of your organization, environment, and the teams delivering the software.

Step into the future as we introduce a groundbreaking, problem-centric approach to defining and evolving system architectures. Our practical techniques will empower you to transform constraints, both architectural and environmental, into powerful enablers of robust, valuable, and long-lived software systems.

Join us and elevate your architecture game to new heights!

In tech teams it's a constant firefight. We react. Then we react to the reaction… the cycle continues. In all this noise, in all this chaos, how do we move forward. How do we remain proactive?

A great leader must be an enabler for the team. At times this means insulating the team from the noise. At other times it means improving the environment for the team. At all times, however, it requires setting clear priorities and conditions for success.

This session is focused on the art of moving forward in even the noisiest environments.

Software development is an amazing profession, requiring the delicate combination of analytical and creative skills. Understanding architectural patterns, agile best practices, and exploring the depths of platforms, tool, and languages requires deep analytical skills. Yet crafting a system also requires vision and understanding when to deviate from traditional best practices.

In this session, we will explore lessons learned over many years of building large software systems. We will challenge traditional assumptions and explore new ways of thinking.