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.
What decisions can we make to make the error more readable next time around
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
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.
How to adopt this for larger teams
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
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.