My passion is taking a metaphysical approach to software engineering: what is the nature of the collaborative game that we continuously play, and are there better, more contextually-aware ways to play that game?
By day I lead a team tasked with taking a first-principles-centric approach to intentionally enabling programming language usage at the largest bank in the United States.
By night I write and teach my way through a masterclass in software engineering and architecture targeting early-career software engineers working in large-scale enterprise technology organizations.
To win the game. More seriously: to get 1% better every day at providing business value through software.
I'm a 22-year veteran of the enterprise software industry. I've played almost every role I can imagine:
I've worked at Fortune 500 companies, a tenacious teal cloud startup, and a not-for-profit children's hospital. I've written a book, and I've hosted a podcast. I've learned a lot along the way, including many things I wish I'd known when I first got started. And so now I want to pass those learnings on to you, especially if you've only just begun your career.
“Humans became behaviourally modern the moment they committed to storing abstract information outside their brains.” —Lyn Wadley
As architects, we often bridge the gaps that exist between all of the teams and stakeholders involved in the success or failure of a system. Because of this, information is hitting us from every direction. How we capture, organize, distill, and express this information is critical to our own success or failure.
Unfortunately, while excellent at abstract thinking, our brains are equally terrible at random recall. What we need is a second brain that excels at providing us with the right information at the right time. In this session, we're going to learn Digital Knowledge Management workflows and tools that will help us build and use that second brain.
In 1971, Gerald M. Weinberg published The Psychology of Computer Programming, which contained an insightful exposition of what he called “Egoless Programming.” Later, Lamont Adams was inspired to chisel the Ten Commandments of Egoless Programming. As architects we are leaders, and it's incumbent upon us to provide a healthy example of what a professional technologist looks like. But if there's a key flaw that many architects have, it's likely ego.
In this talk, we're going to examine how Adams' ten commandments apply just as well to our practice of software architecture as they do to programming, and how we can use them as a guide.
Want to know the highest leverage work you can do to improve your enterprise's technical architecture?
Make the right thing to do the easiest thing to do.
The best way to do this is by creating Paved Paths, typically manifested as software architecture templates or blueprints accompanied by automation.
In this session, we're going to look at several different aspects of Paved Paths: