Notes from Sandi Metz fireside chat with Women Who Code

June 8, 2015

The absolute highlight of my trip to RailsConf this year was an event put on by Women Who Code featuring Sandi Metz! Sandi is a widely respected teacher and consultant in the Ruby community. She really focuses on clear explanations and her talks are set up so that people at all experience levels can get something out of them. And as it turns out, she also has great insights to share about making technical decisions, getting up the courage to start giving talks, and so much more wisdom generally.


Below are my notes for the session, but WWC actually managed to record the whole thing too! It's an hour and 20 minutes long, but I might even watch it again myself, even though I was there (the person that's kind of loud and asking lots of questions? That was me!)



Anyway, I tried to clean up my notes and roughly rearrange them by general category.

Her own background:
  • music student but then into votech school for data processing—this is fun story, you should listen to it
  • no thought at the time (late 70s) that CS was only for men
  • There are different types of programmers: she likes understanding the shape of the whole from the details, into abstraction
  • great for her to partner with Katrina Owen because Katrina is the opposite, derives from the bottom up

Definition for simple code:
  • “the inebriation test” — look at code you didn’t write, after you’ve had a few drinks
  • if you’re really smart, will write simple code
  • code that seems inevitable later actually required a lot of time to write
  • sequence diagram on whiteboard first, figure out objects & message
  • insist that things be simple—refuse to write complex code
  • leaned Object-Oriented (OO) by writing OO code
  • hadn’t read literature on it
  • there are easier ways to learn this: Steve Freeman & Price - Java & testing book, GOOS
  • Rebecca Wirfs-Borck — single responsibility design
  • Eric Evans Domain-driven design (PDF short version)

TDD
  • already done design work
  • TDD easy when you know a lot of design
  • sequence diagrams helpful because then rest is implementation detail, don’t have to worry about writing code that you get attached to
  • TDD: sucked at beginning, now vastly improved code, always find bugs
  • don’t remember how small objects work, but ok, have tests
  • tests of the right kind, don’t test everything
  • believed in people who said TDD was a good idea (they’re lying or otherwise not good enough yet) — bosses would’ve said “good enough” without it

Monoliths vs SOA:
  • lots of revolving door software — don’t have to deal with consequences
  • but in real world, app will live a long time, app gets bigger
  • the next shiny thing, not Rails, is coming
  • want to be able to change part of your app to newest thing, without having to port over your entire app
  • big monolithic apps hard to change -> go out of business
  • breaking up large app without OO into services — will fail
  • need to isolate bits of app into objects
  • “find the seams” — then extract into another app
  • network latency is a problem, but want to get there
  • edges with clear APIs

Preview of her RailsConf 2015 talk:
  • if is always with an else
  • even if about that thing, it’s a specialization of that’s also a thing
  • missing code
  • objects to embody holes in your code
  • yin & yang if you have a thing, then model the absence of something. just as real as a thing, need it for good OO design.
  • “nothing is something” null object pattern
  • like inventing zero, just as real as everything else (this analogy was actually a question from me, that then got a shoutout in Sandi's newsletter! I'm still a little giddy about that!)
  • biologically wired to be good at people names
  • yield the block (true) vs ignore the block (false)
  • if/else without conditionals
  • true - true yield the block
  • false - true ignore the block

Writing books:
  • nobody would read POODR while it was being written, hated writing
  • finding a voice — writing is hard enough without owning your voice, so do it, bend it there
  • couldn’t do academic tone
  • well just going to be goofy, didn’t want to write book anyway
  • new book: 99 bottles, first 2 days of course — join this mailing list!

Coming up with talk ideas:
  • your perfect audience: the you that didn’t know what you know now. past you would be very sympathetic, very grateful
  • don’t keep from doing things because of people who know more
  • create content for people who know less
  • people better than you—motivating to learn, strive
  • there’s someone out there who needs you!
  • judge yourself against the right people
  • looking at people’s talks — she’ll help people in Hangouts
  • there’s science about performing under stress like public speaking (“Choke” book)
  • everyone is terrified the first time, no way to know if you’ll get over it until you try it
  • don’t judge based on talks at work
  • don’t decide in advance you can’t do it
  • “good enough as an explainer & slide-maker” to get across idea
  • “praise is great but unhelpful” — how to improve?

Making technical decisions:
  • I know I’ll be wrong, don’t have enough data
  • choose the errors that are the easiest to recover from
  • learn to make many small things
  • then fix it later, err on side of small until you know it’s too small
  • bet that you’re wrong
  • DRY — deciding that 2 things are the same, adding in an abstraction
  • much easier to deal with duplication
  • easy to fix problem of finding duplicates
  • going from 2 (duplicate) -> 3, might decide you have enough information now
  • but if you know there’ll be 4, duplication for the 3rd item, wait for #4
  • hard to recover from bad abstraction

Other topics:
  • career advice: commitment to learning over writing 80 hours of code a week — that feels like it’s truth as dominant culture, but only inside the cave
  • functional programming — immutability, no side effects
    • can write function OO code
    • book: functional programming for OO programmer
  • create subdirectory namespace under ActiveRecord for models
    • things in model can be plain old Ruby object, to manage business logic
    • not have concerns in Activerecord, AR just for managing database
    • drive edges of framework apart
    • make AR not the center of the universe
  • naming things:
    • use local experts on names, or else have a time box on deciding on names. make a best name you can change later if needed
    • what story will these names tell to the next person
    • care about the names
  • “not the last book you’ll read”
    • you have a right to be here
    • have to help each other believe
    • if you’re somewhere invalidating, get outside support or leave
    • can’t fix everything