Publicly viewable title. Ideally catchy, interesting, essence of the talk. Limited to 60 characters.
- Regular Session
- Workshop
I included track description
I think this talk fits into Fundamentals track and I've included its description. The remaining tracks and their descriptions can be found here.
- Fundamentals - While no one knows all the things, there are some significant fundamental skills and tools that are helpful to know when starting down the path of development work. Talks in this track should explore this theme, potentially covering a wide variety of topics ranging from command-line tools (the command line itself, git, dotfiles, SQL, etc.) all the way to bigger ideas like how to manage work. We specifically are looking for talks that craft an enlightening, educational narrative, rather than being a grab bag of miscellaneous tips and tricks.
A concise, engaging description for the public program. Limited to 600 characters.
Don't panic. My new feature is about to be deployed, which can only mean that I'm on the verge of being exposed as the imposter I already know myself to be. I'm not panicking. YOU'RE PANICKING.
Building new features is a fundamental part of the job of a software developer, but the panic, fear, and uncertainty that for many of us go hand in hand with releasing our code to the public is not. I want to tell you the story of how I was able to ship a major feature with calm certainty. Come learn to use release strategies that experienced engineers often take for granted, but are not taught in CS programs or bootcamps.
Include any pertinent details such as outlines, outcomes or intended audience.
Objective: Rails Conf Participants will be able to employ panic-reducing release strategies so feature releases can be calm and certain affairs.
Intended Audience: This talk will be most compelling for new developers or those who have not worked on large applications serving millions of customers and may not have exposure to some release strategy best practices.
Outline:
- Brief personal intro
- At the start of my career I did not have adequate knowledge of release strategy best practices. As a result, I got myself into a pickle more than once and developed a deep anxety around publishing code. At the same time, I noticed more experienced developers seemed cavalier about new releases.
- Release strategies, their benefits, and how I used them (w/ illustrative code examples where appropriate):
- Feature flags - the ability to toggle features on and off without deploying new code
- Canarying code or rollling it out to a subset of customers - deploying code to only a subset of servers or making it visible to a subset of customers
- Circuit breaker pattern - Automatically skip code that is erroring
- Logging and error monitoring
- Benefits of using these release stratgies include confidence (less panic), more control over the feature, increased visibility into how a particular feature is running, and leveling up one's one career
Explain why this talk should be considered and what makes you qualified on the topic
1. Relatable - Every Rails developer could benefit from a clear discussion of release strategy best practices. This will help us build better software for the world and make us happier developers in the process.
2. Helpful - I learned that there are some fundamental release strategies that many experienced engineers routinely employ to mitigate panic, increase their visibility into how code is running, and build their own reputation for reliable feature releases. Many of these techniques are often taken for granted in high functioning engineering teams, but they are definitely not part of standard CS degree, code school curricula. I want to share my experience successfully using these tools and patterns so that participants can confidently release features, overcome imposter syndrome and stop panicking.
3. Fills a gap - Data structures, algorithms, agile best practices, testing, and object oriented programming are all part of quality computer science and code school curricula at this point. But, the practical experience of deploying code used by millions is tough to appreciate without going through it personally. This talk takes aim at this gap.
4. Entertaining - I love public speaking. From wedding toasts, to local meetups, to company-wide meetings, I enjoy sharing ideas publicly and I have been told I'm not bad at it.
5. Based on Teaching Experience - Before becoming a developer, I worked in public K12 education for over a decade. As a result I can verbally explain things pretty well and am reasonably up to date with adult learning best practices.
Sounds like a great talk! I would attend.
Feature flags - Watch out for feature flags that might cache! (I can't remember where, but I got burned by that in our codebase once)