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
