![Cover image for I'm Sandi Metz, Ask Me Anything! [Finished]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2F3k3uoshlgimkmqmry14d.jpeg)
Hi, I'm Sandi Metz, author of Practical Object-Oriented Design in Ruby and 99 Bottles of OOP, and I believe in simple code and straightforward explanations. I prefer working software, practical solutions and lengthy bicycle trips (not necessarily in that order) and I write, consult, and teach about object-oriented design.
Ask me anything!
Top comments (60)
Hello again! A question I forgot - shortly before I joined my current engineering team, they'd spent a few days doing a workshop with you (they called it "Sandifest" 😂). What sort of things do you do when you spend time with a development team? How do you determine what subject matter to focus on?
Again, thanks a million :D
Hey, Anna, I teach a 3-day OO course, and that may be what your folks are talking about. The course gets tuned to the group, but contains a set of foundation OO ideas that I cover for every class. It's really about how to think in OO.
Awesome! Thanks :D
How do I explain OOP to young students that don't know any other programming paradigms? Because classes are just representations, not the real world. Why do we need OOP?
Hi Sandi, thanks for doing this AMA. When you code, do you follow TDD religiously? I like to write tests, but have a hard time writing tests before functionality, so I tend to write tests after the fact. What downsides do you see to writing tests second?
Andrew, this is my pleasure.
Ah, TDD. I find my code turns out better if I write tests first, but I am deeply sympathetic about how hard that can be. Writing tests first can help drive you to create decoupled code. If you write tests 2nd, and then find that the tests have complicated setup, this suggests that your code is too tightly coupled together. If you write tests first, and insist on having simple setup, you'll naturally end up with nicely decoupled code.
That makes sense, thanks!
Would you advise your career path to other developers?
Hi Sandi! Thank you for investing the time to do this AMA. I admire your work, especially your approachability as a teacher and your ability to make concepts accessible to different audiences. My question for today, however, centers around something I am currently grappling with...
How often do you context switch between writing, consulting, and teaching? Do you have any tips for streamlining this process? In particular, I find switching between writing and other non-writing tasks within a day to be somewhat challenging (some days more than others). Also, how do you avoid burn out? So basically...how do you do it all? :-)
P.s. I "met" you when someone sent me a link to one of your conference talks. I loved it so much that I read POODR (even though I did not know Ruby). I learned a lot about OO (and also about Ruby). So thank you!
Kristen, I fear that I'm terrible at context switching. I do best when I can bury myself in one thing and ignore everything else. This often means that I neglect the small things (arg, email) in order to work on big things (a book chapter, or a talk).
I'm reconciled to this quality of myself, and just have basically arranged my life so that I can work like this.
The one thing I've found is that I do my best writing early in the day. I can write prose in the morning, take a break, and then write code in the afternoon, for example. Writing prose is super painful for me, and code is always a joy, so I tend to reward myself with code, once other writing is done.
I think I work in similar patterns, any advice on the specifics of arranging your life to fit your work style?
Thank you so much for your candid response!
"I do best when I can bury myself in one thing and ignore everything else" --> your point about accepting this quality and arranging things so you can work the way that is most natural to you is super helpful! I have the same quality (I prefer to bury myself in one thing) but have been resisting accepting it. So now I am going to try to rework things so I can work the way I work best, instead of trying to convince myself I can be or have to be a context-switching-super-star.
I am also going to try your approach to writing in the morning. Typically I fill my morning with other things in effort to "get them out of the way so I can write". I'm going to flip that and write first thing in the morning so I can get to the other things in the afternoon.
When you are dealing with optimization, which do you give more preference/weight in terms of performance. Is it time complexity or memory consumption. And how do you decide which data structure to use?
How do you feel about static analysis tools for code coverage, code quality, styling etc.
I love them, in their place, and taken with a grain of salt. Static analysis tools can't get everything right, but they can supply an unbiased, reproducible overview of the state of code.
Like, for example:
Is it getting worse or getting better?
What parts of the code hold the most danger for someone who doesn't know the app?
I don't want to be pushed around by metrics, but I do want the insights they can give me.
Got a list of tools you'd recommend?
You've mentioned Smalltalk a bit in your presentations and podcast appearances. Do you still do any Smalltalk programming?
Nope, but if I had the free time, I certainly would. Squeak looks interesting. My go-to dynamically typed OO language these days is still Ruby.
Hi, Sandi!
Thank you for your books, they are great :)
A couple of questions:
What was it like collaborating on your newest book with Katrina, versus being the only author? How did that impact your process?
Collaborating with Katrina was equal parts delightful and a cause of great head-banging, as you'd likely expect. Let me be clear--Katrina is wonderful, it's just that the very process of collaboration requires compromise, and blending disparate ideas. This was good for the resulting book, but not necessarily welcomed in the moment.
Any memorable conflicts that you're both laughing about now?!
Too many, really, to pick one. Katrina and I as very different. The core lesson for me was that while it's easy to pair with someone who is like you, it's better, if you can stand it, to pair with someone who is different.
Being forced to resolve our differences improved our understanding of the material, and vastly improved that book. This only worked because, despite our head-banging, we respected one another's ideas, and believed that if we stayed at a discussion (read, argument) long enough, we would find that we actually agreed.