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:
Hi Sandi,
thank you for doing this AMA - I really enjoyed POODR, I learned a lot from it and that is although I have never written any major Ruby code before or after it ;)
I'd be really curious about your thoughts on the value of type systems, especially since you have very strong roots in Smalltalk and Ruby.
I've "grown up" mostly on statically typed languages (Pascal, Java, Haskell), but I've learned to appreciate dynamically typed languages a lot in the last 4 years (especially Javascript and Clojure). Working in a Java shop that is short of being considered a heretic. In your experience, do you see a middle ground?
Fabian, first let me confess that I'm an outlier in that most of my OO experience is in dynamically typed languages, and that in my code, I don't get run-time type errors. Because my experience is that dynamic typing is perfectly safe, I find myself resenting having to enter type annotations when I work in statically typed languages. While I appreciate the fact that static typing means that I don't have to write some tests, I hate having to add this extra code.
Having said that, I realize that many folks have had different experiences with dynamic typing. I write trustworthy code where objects behave like you'd expect. This means that I can trust that any object with which I'm interacting just works. This, in turn, means that I don't have to check if objects behave the right way. Sadly, I've seen many OO applications where these things were not true. Folks fall into the trap of writing code that's not trustworthy. Because they can't trust message sends to return objects that behave correctly, they have to check the type of the return of messages sends. This leads to a descending spiral of manually adding type checking, and code which ultimately breaks in confusing and painful ways.
Here's the deal. The power of dynamically typed OO languages is attained only when you write trustworthy objects that use duck-typing and polymorphism, and then trust them to behave correctly. If for some reason (inclination or background) you can't prevent the creation of untrustworthy objects, it's probably better to use static typing.
These styles of programming are different, and combining them leads to the worst of both worlds.