Mina shares reflections from the campaign trail and explores strategies to use your time and skills to affect social change.
Julia Grace has built teams at IBM Research, small startups, and now currently at Slack. She has done due diligence for venture capitalists to determine how well a startup’s engineering team is working together. Drawing on this knowledge, Julia attempts to answer the question: Why do some teams ship features rapidly, support each other, and effectively communicate while others struggle?
The transition from a developer to a Lead Developer can be a rocky one. Yesterday, you were working as a developer and today, suddenly, you find yourself in the role of the Lead Developer. What does this new role mean, and how do you make yourself successful? In this talk, Patrick will explore the ways in which a developer can level up and discover the way of the Lead Developer.
Do you follow Agile processes like Scrum, Kanban or XP... and yet struggling to deliver on time, under budget and without last-minute heroics? Why aren't these supposedly best practices working for you?
It is often said that a developer should understand one level deeper than she's working at. We understand this about our tech, but what about our practices? In this talk, we will dive "one level deeper" into some common agile/scrum/XP practices, and understand what it takes to make them work:
Big, Impossible projects are exciting, transformative, and begin with an overwhelming number of unanswered questions. Developing against a moving target is never easy — you might find yourself doing things that go against best practices such as designing solutions without knowing all the parameters, or encountering dependencies you didn’t even think were possible. Big, Impossible Projects can start out looking small and simple, but like an iceberg, they have much more to them once you get close. In this talk for both new and seasoned leaders, you will learn to navigate the icebergs and bring your next Big, Impossible Project to a successful conclusion.
Over the past ten years, we’ve seen a dramatic shift in the architecture of service-oriented systems. We now build our applications on top of polyglot persistence, micro-services, and cluster management, but most of us have not adapted our security practices in the face of these changes. We check private keys into source control. We bake database passwords into VMs or Docker images. We have no idea who is deploying anything. Enter Vault: an open source tool for managing security for the complex operational environments of today. In this talk, I’ll explain what Vault is and its key features. We’ll go on to talk a bit about how Vault fits into a modern architecture and how to iteratively introduce it or a similar secrets provider into your organization.
Most software engineers don't realize that an outage is more than keeping the TTR low (yes, TTR is very important); it's also about managing the expectations of your customers. After all, your customers don't care about five-nines reliability; they care about five-nines customer service.
The best engineers are focused on making the lives of their customers better. They have inner peace; they are mindful, self-aware and don't indulge in mindless work. They take steps --without being asked-- to prevent a defect from ever reaching production again. "DevOps" --despite all the buzz-- is table stakes these days; the strategic differentiator is how obsessed you are with your customers.
Come find out how the right mindset, soft skills & inner peace can help you become a better engineer - one your customers actually love.
Everyone has blindspots. For developers it is often taking for granted certain technical skill sets. So what happens when you need to build a system for people without those skills? How do you adjust? What do you use as a reference point for common knowledge? How do you get out of your own head?
This talk will tell a story of a project where we attempted to do just that. What we learned. What challenges we faced. And how our final system took into account all of our experiences.
Building complex software projects is an iterative process. We rarely get to spend months designing and writing a complete project plan before releasing something to our users, and no feature is ever truly finished.
In this talk, I'll tell two true stories of building and refactoring applications using microservices as well as some of the lessons my teams learned during the process. You'll see how building your software with microservices can help ensure modularity and make incremental development easier.
1:1s, or intentional time set aside for managers and their direct reports, are magical: they're where you learn what "sparks joy" for your staffer and where they're secretly flagging. They're where you can get ahead of team discord and ferret out communication dysfunctions. But many leaders aren't making 1:1s a practice because they're not sure how useful they are, or because they don't know how to get started, or because they're just not sure how to fit them into their schedule. But as Michael Lopp puts it in his book Managing Humans, "Your reward for a culture of healthy one-on-ones is a distinct lack of drama."
Inspired by Marie Kondo's work on tidying up, I'll share how establishing and protecting regularly-scheduled 1:1s can be the organizational housekeeping your team needs. It was my direct experience of the benefits of 1:1s while working as a software engineer that led me to bring them to my current team, where I work as Director of Engineering managing senior engineers and architects.
Does your team deal with bugs that could have been caught earlier in the development cycle? Wish you could get the benefits of Test-driven development (TDD) but are worried that your dev team might revolt or that stakeholders will think that you're being unproductive? In this talk, we'll discuss an approach I've taken to balance the concerns of developers and stakeholders while simultaneously increasing developer productivity, increasing knowledge sharing, and reducing software defects. I've named this approach "TBD", or "Test-backed development".
Software development has regularly borrowed processes and terminology from outside technology to improve how code gets to customers. For example, Scrum comes from rugby, and sprints come from track and field. However, history has been an often neglected source of insight for software development. The Underground Railroad was a system of pathways and people that provided a way for African-American slaves to escape to non-slave states and countries such as Canada and Mexico. The network stretched from Boston to Austin and consisted of self-organizing teams operating in conditions of extreme uncertainty who were tasked with shipping the most important product of all: freedom.
The Underground Railroad provides insights that tech leads can use to improve their teams, products, and customer relationships. This talk will share timeless lessons of courage and leadership from the men and women who risked everything for the success of their teams.
No one tells developers and project managers to throw things away. We assume that because it's cheap to keep it around, the emotional comfort is worth the tradeoff. But we're not thinking about how vulnerable we make ourselves by not having an automated and tested way of getting rid of things that we don't need anymore.
I want to problematize keeping deprecated codebases around and emphasize that mindless retention of data and code just increases our threat surfaces for attack and data corruption. Attackers in the future may be motivated by both ideology and money, and we are responsible for that.
On March 28, 1979, at exactly 4 o’clock in the morning, control rods slammed into the reactor core of Three Mile Island Unit #2, halting the nuclear reaction because of a fault in the reactor cooling system. At 4:02, the automated emergency cooling system activated as the reactor core temperature continued to rise. At 4:04, one of the plant operators made the befuddling decision to switch off the emergency cooling system, dooming the reactor to partial meltdown.
When something bad happens, it’s easy to just blame someone and move on. Taking the time to find the systemic causes, though, will not only help keep the problem from repeating, it will enable you to build the psychological safety necessary for your team to truly collaborate. Let’s let the story of Three Mile Island teach us how to make our teams stronger through systems thinking and just culture.
Please get in touch with Daisy Wort, Sponsorship Manager, to request a sponsor pack.