Growing Software From Seed, by Sweta Sanghavi

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
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
  2. 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
  3. 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
  4. 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
  5. We’ll touch upon paying closer attention to the errors our application serves
  6. We'll talk about really read the error, the line number, the stack trace to get a full picture
  7. What decisions can we make to make the error more readable next time around

  8. Why is my carrot growing sideways?!

  9. 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

  10. 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

  11. We’ll walk through an example of code that seems unnecessarily complex until we dissect the abstraction beneath the complexity

  12. A complete understanding can help us make the most effective change

  13. Is that a beet?

  14. 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

  15. Similarly, in our applications, we experiment with different implementations in different parts of the codebase that are solving different problems

  16. We'll trace the history of a service object from our codebase and changes as requirements were added

  17. We'll talk about how to let time and new requirements guide the growth of our application

  18. Avoiding premature optimization or forcing an abstraction

  19. 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
  2. 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
  3. How to adopt this for larger teams

  4. Tend to your weeds

  5. Weed our garden diligently and tend to the sprouting of deprecation warnings, console warnings

  6. Where to add this kind of maintenance to your development process

  7. No Passengers

  8. Keeping integrity in pairing, and not falling into a passenger role

  9. When writing tests, ask which error message you expect before running your test to highlight when the failure is not the one you expect

  10. 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

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.

Edit proposal


RailsConf 2021 - Accepted [Edit]

Add submission