Effective pair programming between team members of varying levels of experience spreads knowledge and increases the potential productivity of any team. While we may recognize the value of nurturing our early-career developers' skills in order to support the long-term health of teams, how often do we examine the methodology behind how this is done?
Effective pair programming between team members of varying levels of experience spreads knowledge and increases the potential productivity of any team. While we may recognize the value of nurturing our early-career developers' skills in order to support the long-term health of teams, how often do we examine the methodology behind how this is done?
The five Standards of Effective Pedagogy and Learning are:
- joint productive activity
- language development
- contextualization
- challenging activities
- and instructional conversation
In this session, we'll apply these standards to pairing and begin to cultivate the skills of a great teacher, as well as a delightful pair programming partner and excellent lead dev. By learning to impart knowledge in the absence of shame or gatekeeping, we can create environments in which everyone feels safe enough to learn and improve.
About Aisha Blake
Aisha Blake is a Senior Software Engineer at Gatsby, currently building < title of conf >, a musical tech conference. She also supports community by co-organizing self.conference and Detroit Speakers in Tech. A theatre kid turned tech community leader, she approaches speaking and teaching as a way to give others the tools to shine as brightly as they can. In her spare time, she sings karaoke and pets dogs. Aisha is a champion of feedback, fierce accessibility advocate, and a steward of strong teams.
Balancing innovation and toil - Managing work on infrastructure teams
Uma Chingunde
Engineering Manager
Stripe
Infrastructure teams need to balance building features to support product growth and business goals while maintaining current platforms. It is often a trade-off between doing innovative work vs operational work. As leaders, it is our responsibility to ensure user and product goals are met while creating the space for teams to innovate beyond their immediate needs.
Infrastructure teams need to balance building features to support product growth and business goals while maintaining current platforms. It is often a trade-off between doing innovative work vs operational work. As leaders, it is our responsibility to ensure user and product goals are met while creating the space for teams to innovate beyond their immediate needs.
In this talk, we’ll discuss strategies for planning work on infrastructure teams in a way where we can maintain development pace while innovating on platforms. We will talk about strategies to reduce technical debt that infrastructure teams in particular tend to be overwhelmed by. We’ll walk through some examples of both how we have done this with teams at Stripe. We will share processes and cultures that help maintain this balance that you can adopt within your own organization.
About Uma Chingunde
Uma Chingunde is an Engineering Manager at Stripe leading the Compute organization. Uma started her career in the distributed systems space, working on key virtual machine technology at VMware and has led teams at VMware, Delphix and now Stripe. She has a Master’s degree in Computer Science from John Hopkins University.
Schrödinger's Migration
Tanya Reilly
Principal Software Engineer
Squarespace
Is it alive? Is it dead? We all remember when the migration project kicked off with such enthusiasm, but it's been a while since it moved last. Now every other team needs to decide whether to support the old way or the new way. Or both?
Is it alive? Is it dead? We all remember when the migration project kicked off with such enthusiasm, but it's been a while since it moved last. Now every other team needs to decide whether to support the old way or the new way. Or both?
Whether it's a deprecation, a process change or a move to a new platform, half a migration can be much worse than no migration at all.
Let's talk about how to set a migration up for success, and how to accept it when it's failed. We'll cover the vision and the narrative, appealing to emotion, appealing to authority, gentle reminders, less gentle reminders, making the good path the easy one, sticks, carrots, ice cream parties, and when you should give up and make peace with a project that just isn't going to happen.
About Tanya Reilly
Tanya Reilly is a principal software engineer at Squarespace working on infrastructure and site reliability. Before Squarespace she spent 12 years in Site Reliability Engineering at Google. She is originally from Ireland, but is now an enthusiastic New Yorker. Tanya likes raspberry pi, coding on trains and figuring out how systems will break. She blogs at http://noidea.dog.
Serverless: Developer-oriented architecture
Mike Roberts
Partner
Symphonia
Serverless is a way of building applications in the Cloud, embracing technologies that focus more on developing features, and less on the friction that comes from deploying and running software. To be most effective at using Serverless, teams need to consider what the right platform service is in each place. This “serviceful” way of thinking typically has the benefit of significantly increasing the speed at which products can be developed, while also reducing the total cost of operational ownership.
Serverless is a way of building applications in the Cloud, embracing technologies that focus more on developing features, and less on the friction that comes from deploying and running software. To be most effective at using Serverless, teams need to consider what the right platform service is in each place. This “serviceful” way of thinking typically has the benefit of significantly increasing the speed at which products can be developed, while also reducing the total cost of operational ownership.
Getting Serverless right means putting architecture front and center of a team’s way of working - not an activity for an ivory tower, nor just something to happen at project inception. Every story offers the chance to reconsider how the system is built, and how a team can gain an advantage from the ever-growing landscape of cloud platforms. The highest performing Serverless teams are the ones where every developer is an architect.
Such "developer-oriented" architecture is both an opportunity and a challenge. It brings the whole team into an area that has often felt like an elite responsibility, but at the same time architecture is a deep skill that needs to be learned, and often the way we can judge "good" architecture seems very subjective.
In this talk you'll learn how to start on a road of building Serverlessly, how to ask questions of your platform, how to consider tradeoffs, what you need to learn versus what can be ignored, how Serverless changes previously understood "best practices", and what concerns you should consider before proceeding down this road at all. Most importantly you'll have lessons that you can share with your teams to bring them with you on your Serverless journey.
About Mike Roberts
Mike is a partner and co-founder of Symphonia - a consultancy that helps organizations make the most out of the Cloud. Mike's had two decades of industrial experience - as an engineer, tech lead, CTO, and consultant - with plenty of Dev, Ops, and leadership responsibilities in that mix. As a proponent of agile values, Mike understands that the most effective teams are ones where technology is important, but individuals and their interactions even more so.
Refining Systems Data Without Losing Fidelity
Liz Fong-Jones
Developer Advocate
Honeycomb.io
It is not feasible to run an observability infrastructure that is the same size as your production infrastructure. Past a certain scale, the cost to collect, process, and save every log entry, every event, and every trace that your systems generate dramatically outweighs the benefits. If your SLO is 99.95%, then you'll be naively collecting 2,000 times as much data about requests that satisfied your SLI than those that burnt error budget. The question is, how to scale back the flood of data without losing the crucial information your engineering team needs to troubleshoot and understand your system's production behaviors?
It is not feasible to run an observability infrastructure that is the same size as your production infrastructure. Past a certain scale, the cost to collect, process, and save every log entry, every event, and every trace that your systems generate dramatically outweighs the benefits. If your SLO is 99.95%, then you'll be naively collecting 2,000 times as much data about requests that satisfied your SLI than those that burnt error budget. The question is, how to scale back the flood of data without losing the crucial information your engineering team needs to troubleshoot and understand your system's production behaviors?
Statistics can come to our rescue, enabling us to gather accurate, specific, and error-bounded data on our services' top-level performance and inner workings. This talk advocates a three-R approach to data retention: Reducing junk data, statistically Reusing data points as samples, and Recycling data into counters. We can keep the context of the anomalous data flows and cases in our supported services while not allowing the volume of ordinary data to drown it out.
About Liz Fong-Jones
Liz is a developer advocate, labor and ethics organizer, and Site Reliability Engineer (SRE) with 15+ years of experience. She is an advocate at Honeycomb.io for the SRE and Observability communities, and previously was an SRE working on products ranging from the Google Cloud Load Balancer to Google Flights.
She lives in Brooklyn with her wife, metamours, and a Samoyed/Golden Retriever mix, and in San Francisco and Seattle with her other partners. She plays classical piano, leads an EVE Online alliance, and advocates for transgender rights as a board member of the National Center for Transgender Equality.
To grow our technical leadership skills, it’s critical to lean on one’s network of support. We often find mentors: people who can give us helpful advice. But what can be even more valuable is finding “sponsors”, who help us find new opportunities and improve the visibility of our work. As sponsorship is especially important for members of minoritized groups in tech, Lara Hogan walks through tactics you can employ today to be a sponsor for those around you, too.
To grow our technical leadership skills, it’s critical to lean on one’s network of support. We often find mentors: people who can give us helpful advice. But what can be even more valuable is finding “sponsors”, who help us find new opportunities and improve the visibility of our work. As sponsorship is especially important for members of minoritized groups in tech, Lara Hogan walks through tactics you can employ today to be a sponsor for those around you, too.
About Lara Hogan
Lara is an author, public speaker, and coach for managers and leaders across the tech industry. As a founder of Wherewithall, Lara and her team run workshops, roundtables, and trainings on core management skills like delivering great feedback and setting clear expectations. Before Wherewithall, Lara spent a decade growing emerging leaders as the VP of Engineering at Kickstarter and an Engineering Director at Etsy. She champions management as a practice, building fast websites, and celebrating your achievements with donuts (and sometimes sushi). Her latest book, Resilient Management, is here to help those who find themselves responsible for supporting a team of people.
Naming things is hard; linguistics to the rescue!
Andrew Hao
Software Engineer
Lyft
Have you ever waded through messy legacy code, confused and at a loss for understanding the meanings of obscure or outdated concepts? Felt slightly icky at naming a variable the way you did, or frustrated and boxed-in by the incapacity of your naming conventions to capture the true essence of what you’re trying to convey in the business?
Have you ever waded through messy legacy code, confused and at a loss for understanding the meanings of obscure or outdated concepts? Felt slightly icky at naming a variable the way you did, or frustrated and boxed-in by the incapacity of your naming conventions to capture the true essence of what you’re trying to convey in the business?
In this talk, we’ll look to the field of linguistics and semiotic theory, which studies the communication of meaning. Together, we’ll see how naming is an act deeply embedded in a cultural context - the very culture of your software team! We’ll use a cultural lens to identify the challenges of communicating and building systems across your organization and beyond. We’ll discover some cross-cultural tactics to apply to challenging tasks like designing APIs, sharing database stores, schema management, and refactoring legacy systems.
In order to build software in a large organization, we must make the implicit presence of culture explicit, codified in naming conventions, system design, documentation, and cross-team communication. You will emerge from this talk better equipped to design systems that harness the complex vocabulary of your business domain to build software with clarity and precision!
About Andrew Hao
Andrew is a software engineer at Lyft, where he leads a growth engineering team. Prior to that, he was at Carbon Five building software for all kinds of companies. Before that, he was an engineering manager at Blurb.
He is a recovering coffee addict, diehard runner, and reluctant Magna-Tile architect for his two-year-old son.
Talk details coming soon
Kathryn Koehler
Sr Engineering Director, Science
Chan Zuckerberg Initiative
About Kathryn Koehler
Kathryn Koehler is the Sr. Engineering Director, Science for the Chan Zuckerberg Initiative, where her teams build tools and applications to accelerate scientific discovery. CZI’s mission is to support the science and technology to make it possible to cure, prevent, or manage all diseases by the end of this century. In her 20-plus year career, Kathryn has scaled and led engineering teams in ways that allow her inner process wonk to thrive. But she still finds the time to mentor new managers, bike, run, play soccer, and embarrass her kids. Kathryn was formerly Sr. Director of Applications Engineering at Evernote and holds a degree in Mechanical Engineering from Stanford.
About Nick Means
Nickolas Means loves nothing more than a story of engineering triumph (except maybe a story of engineering disaster). When he's not stuck in a Wikipedia loop reading about plane crashes, he spends his days as a Senior Engineering Manager at GitHub. He works remotely from Austin, TX, and spends most of his spare time hanging out with his wife and kids, going for a run, or trying to brew the perfect cup of coffee.
