We continue our hiring advice series in this episode. It’s a really powerful thing to have people who have established careers, think about what would have made a difference, think about what is important when we work with and mentor inexperienced and junior people who are building a career.
This episode is full of thoughtful advice on how to build subject matter expertise, and the ephemeral qualities that make somebody a good leader or a good worker, or what we were calling an executive function.
If you are building your career, or helping mentor people who are building a career, you will get a lot out of this.
What are the challenges of interconnectedness and transparency, specifically concerning Kubernetes and cloud native applications?
We have a fascinating discussion sparked by the question of how exposed we are. What happens when something we don’t know is connected is open and exposed as hackable? What happens when it closes, and we didn’t know?
We talked about how this is inherent in the architecture of cloud native applications and what you can do about it.
This discussion should get you thinking about how to architect not just your applications, but the platforms that you need to connect together to make them work.
How do you build GitOps, infrastructure and systems relying on events and monitoring, when you need to revert to a polling loop, or augment a polling loop with an event system?
Today, we drill into concrete technical details about events and monitoring. We also suggest practical functional advice on how Git Ops works, how systems work, and how you can build a resilient system.
Stick around for a bonus at the end of the discussion, where we talk a little bit about complexity!
How do we handle distributing identity? DID stands for distributed identifiers, and today we talk about Web3 as well as distributing identity.
Distributing identity is not just about people and personal identity, but also about things and how we identify and track different things in a distributed way without a centralized infrastructure. That’s fundamental to what Web3 is talking about.
How do we break down the centralization that we have been building over the last 15 years of what Web3 people call Web2, and look at ways to do it in a decentralized way where the trust is between the parties involved? Where it’s set up in a way that you don’t have to have a centralized trust authority.
We spend a lot of time talking about this, what the spec is, what it means, and looking at it in a broader context.
Human factors make governance as code a challenge – today we discuss why looking at things like audit and how we determine what has happened and respond to it in an automated way, may be a great first step to adding controls into a system.
We talk about a lot of human factors of what makes it hard to create a governance system, or what creates a biased system or an unevenly governed system.
We spent the first couple minutes of this podcast talking about our agenda, and those conversations spell out a lot of interesting topics that we will discuss. So hang in for those first couple of minutes, and then we will get straight to the governance.
How do we use chaos monkeys in real life, and practically? This happens all the time when we have failures. The Rogers failure that took out the internet and cell phone use in Canada last week was the start of our discussion.
Predicting how things are going to go out is a common theme for chaos monkeys, and really comes back to how we test infrastructure. Should we be putting it under stress in planned ways like Chaos Monkey, in order to ensure that our increasingly internet and power dependent society is prepared for the inevitable outages?
We have a really fascinating discussion about what it would take to make this type of practice real, including alternatives that people can look at today.
Today, we sat down and talked about current events and how things are going. We don’t need to have an agenda to have a really interesting conversation, and that is exactly what happens!
We start with some current events, the Rogers outage, Elon Musk, Twitter, GDPR, and the Jim’s West space telescope. Then we put those things together into common threads about automation, autonomous cars and how society interacts with these things.
If you’re looking for deep tech, this is not your podcast. Otherwise, enjoy listening to this casual conversation!
How do we manage complexity? Today we discuss sources of complexity and explore design rules. We also talk about how you think about the systems that you’re building in ways that allow them to handle complexity gracefully.
The simple answer is to have people who are good at thinking about complex systems. Part of that is experience in looking at complex systems, seeing how they operate and being ready to deal with that type of thing like training pilots.
How we get to that insight is really significant, and it impacts how you build teams and systems. In addition to how you build systems that defend themselves that are naturally complex, but have the right defense mechanisms to make them more stable over the long term.
What makes people interested in new tech versus the stable, boring, things that keep the lights on work?
It feels to me as if we’re in the phase of development where we start saying, I need to make sure this all works. I’ve followed all the cool stuff, now I need to make sure everything’s working and get my ROI out.
This conversation questions that assumption, talks about why we care, what we’re really trying to accomplish, and digs into what is boring and what is sexy? And what makes them different.