Speakerline
Speakers
Proposals
Events
Tags
Edit a proposal
Adam Cuppy
Ahmed Omran
Alan Ridlehoover
Amit Zur
Andrew Mason
Andrew Nesbitt
Andy Andrea
Andy Croll
Asia Hoe
Avdi Grimm
Ben Greenberg
Bhavani Ravi
Brandon Carlson
Brittany Martin
Caleb Thompson
Caren Chang
Chiu-Ki Chan
Christine Seeman
Cody Norman
Devon Estes
Eileen Uchitelle
Emily Giurleo
Emily Samp
Enrico Grillo
Espartaco Palma
Fito von Zastrow
Frances Coronel
Hilary Stohs-Krause
Jalem Raj Rohit
Jemma Issroff
Jenny Shih
Joel Chippindale
Justin Searls
Katrina Owen
Kevin Murphy
Kudakwashe Paradzayi
Kylie Stradley
Maeve Revels
Maryann Bell
Matt Bee
Mayra Lucia Navarro
Molly Struve
Nadia Odunayo
Nickolas Means
Noah Gibbs
Olivier Lacan
Ramón Huidobro
Richard Schneeman
Rizky Ariestiyansyah
Saron Yitbarek
Sean Moran-Richards
Shem Magnezi
Srushith Repakula
Stefanni Brasil
Sweta Sanghavi
Syed Faraaz Ahmad
Tekin Suleyman
Thomas Carr
Tom Stuart
Ufuk Kayserilioglu
Valentino Stoll
Victoria Gonda
Vladimir Dementyev
Title
Tags (comma-separated, max 3)
Body
Abstract Pam Pierce writes, “Look at your garden every day. Study a plant or a square foot of ground until you’ve learned something new". In debugging my own garden, the practice of daily observation has revealed signals previously overlooked. This practice has followed me to the work of tending to our growing application. This talk visits some familiar places, code that should work, or seems unnecessarily complicated, and digs deeper to find what we missed at first glance. Let’s explore how we can learn to hear all our application tells us and cultivate a methodical approach to these sticky places. For Review Committee Details In this session, I will weave my experiences gardening to similar experiences I've had writing code and the lessons and tools I've gained along the way. I will utilize anecdotes from some garden fails, some humorous pictures, and code snippets to help the audience connect these leanings to places they too may have found themselves. I seek to highlight the seemingly simple processes that can enhance our programming and how to organically allow our applications to grow as requirements and constraints develop. Developers will leave with an idea of common situations that may benefit from closer attention and tools to find and seize those opportunities. You’ll get the most out of this time if you have programmed in a Rails application before, but the general methodology is applicable across stacks. 1. Holey Hell * A story about finding holes in my kale, only to look closer to find caterpillars and the moths that laid them. The story reveals that sometimes you have to dig deeper into the problem to find the solution * We’ll explore an example of keying into a payload from an API and seeing the TypeError: no implicit conversion of String into Integer and misdiagnosing this error and reflexively change the code I felt most unsure about * This experience serves as an example of a familiar error message that can be difficult to understand at first glance but upon further inspection can be useful to get to the solution * We’ll touch upon paying closer attention to the errors our application serves * We'll talk about really read the error, the line number, the stack trace to get a full picture * What decisions can we make to make the error more readable next time around 2. Why is my carrot growing sideways?! * Reaching beneath the disappointment of forked and twisted carrots and understanding the root cause of this wacky growth can tell us something about the soil * Similarly, approaching code smells with an intent to understand the complexity the writer was managing can reveal something about the system in which we are working * We’ll walk through an example of code that seems unnecessarily complex until we dissect the abstraction beneath the complexity * A complete understanding can help us make the most effective change 3. Is that a beet? * Planting seeds, and looking for them within a patch of plants requires patience to wait for the plants to grow and show hallmark signs to tell them apart from weeds * Similarly, in our applications, we experiment with different implementations in different parts of the codebase that are solving different problems * We'll trace the history of a service object from our codebase and changes as requirements were added * We'll talk about how to let time and new requirements guide the growth of our application * Avoiding premature optimization or forcing an abstraction * When to refactor In the second section of the talk, I will show off some tools that have helped me pay closer attention to where our application is growing. 1. Walk in your garden every day * Adopt the practice of daily diff. Spend 10-20 minutes reviewing the commits of the last day to familiarize the team with all the changes happening in the codebase * How to adopt this for larger teams 2. Tend to your weeds * Weed our garden diligently and tend to the sprouting of deprecation warnings, console warnings * Where to add this kind of maintenance to your development process 3. No Passengers * Keeping integrity in pairing, and not falling into a passenger role * When writing tests, ask which error message you expect before running your test to highlight when the failure is not the one you expect * Ask your pair what the outcome of the experiment they are attempting is. Be vocal and active in adding intentionality to your work together. Each experiment should have a purpose Pitch At conferences, we hear about the amusing bugs that take us deep into the guts of Rails or into garbage compaction of Ruby. This ...isn’t that talk. This is about the bugs that don't make it into our stories, the daily "gotchas" that still get us, and offer a tool to help us add some patience and process to our work. I want to bring attention to the decisions we make regularly that we can use to allow our application to grow organically. Through my experiences in consulting and contributing to new codebases, I’ve learned to fine-tune skills that are reusable across codebases. The practice of reading a stack trace or pairing can sound so straightforward. Adopting the practice of slowing down and stepping through the execution line by line, file by file, has been the most powerful to effectively debug and contribute. I want to empower my colleagues with this tool through stories and relatable failures. This fall I went to my first RubyConf and was inspired by our community of Rubyists and the sharing of their experiences. I secretly vowed to be up there one day too, hoping to pass my learnings on to others. In my journey as a still-growing developer, the tools I’ve found most useful are easy to overlook and can seem not worthy for the stage. I want to bring the power of observation to life for my first talk! Speaker Information Sweta Sanghavi Sweta Sanghavi is a Rails developer at Backerkit where she works on building products for backers, creators, and other BackerKats. She likes to think about the magic of pairing, retrospectives, and how to do things better. Iterating and growing with teams gives her almost as much joy as watching her seedlings emerge from the soil. Almost. She once put down scores of beets seeds from which emerged three beet seedlings. She has yet to harvest them.
Back to Speaker Directory