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 did you get into conference speaking?
Completely by accident. Someone pushed me into it, pretty much against my wishes. I was terrified at first, but have grown to really enjoy it. This, of course, means that everyone else should and could speak at conferences too. :-)
How do you prepare for your talks? Do you have any specific rituals you go through before stepping in front of an audience?
I'm a scripter and practicer as opposed to an, err, wing-it-er. Once I sort out the point of the talk and put together a slide deck, I figure out what I plan to say on every slide, and between which words I plan to change slides, and then I rehearse until I feel confident that I can appear unrehearsed. My rule-of-thumb is that I have to give the entire completed talk to my empty office 10 times before I'm ready go on stage.
I once read a recommendation that said a speaker should multiply the number of folks in the audience by their hourly rate in order to decide how much effort should be put into a talk. By that math, the bar for being prepared feels very high.
Ah! That is so nice to hear. I've met a lot of wing-it-ers recently and it's honestly made me feel quite self conscious about how much I need to rehearse.
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.
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.
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!
What are your thoughts on functional programming?
I only have a small bit of experience with functional languages, so I don't get to have much of an opinion. I can say, however, that immutability and no side-effects are great ideas, and that I've borrowed them for my OO.
My initial goal for every new object I write is that it not change, and that it not have side effects. This obviously can't suit every object, but I've been pleasantly surprised about how much can be done under these constraints, and how much the constraints simplify code.
Thanks for taking the time to do this! Your book, POODR, was the first technical/programming book I ever read. I also am enjoying 99 Bottles, and just generally have found all of your technical writing approachable, friendly, and useful.
I'm curious to know: how do you decide what makes for good technical writing (blog post or book)? What does good technical writing do well? What does unapproachable writing miss? And are there any guidelines or goals that you strive for in your own technical writing?
(This question comes to you from someone who'd very much like to write her own programming book someday soon! ☺️)
First, you should definitely write a book. Painful as writing is (at least for me), having written is a great pleasure, and others will be grateful for your efforts.
As far as topics, I just think of things that I know now that younger, less-experienced Sandi would have benefited from having been told. I think of my past self as eager, capable, but vastly ignorant, and feel very sympathetic to the problems she encountered. I have confidence that she could understand things, if only they were explained well. She's the imaginary reader for whom I write, and my main goal is to make her feel smart.
This is a wonderful answer -- THANK YOU! ❤️
Things that I know now that younger, less-experienced Sandi would have benefited from having been told
Things that I know now that younger, less-experienced Sandi would have benefited from having been told
This is such useful advice.
Veidehi I'd like to say that you already have written the equivalent of a book. If you compiled all the content of BaseCS and Technical Tuesdays there would be at least 200 pages of excellent content there.
Thanks for all of your contributions, they have been helpful to a great number of people, myself included.
Please write that book :-)
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.
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?
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?
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.
There is also Pharo and Cuis.
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.
I've moved recently from .NET to Ruby on Rails and it had been quite difficult for me to understand how yo write beautiful and meaningful code, 'till I started reading your books. I love the simple way you explain everything in it. I think that I've improved a lot since my first lines of Ruby and now I can think about improving even more. I'm willing to meet you in Seattle in a few months. Thanks for your sharing!
And thanks for thanking. :-)
Hey Sandi! Thanks for doing this! How often do you write code these days?
Liana, I never get to write enough code. Sigh. Most of the code I write these days is for my own apps.
After many years of working of big apps every day, I had a secret fear that, if I stopped doing that full-time, that I'd forget how. It turns out not. The time I've had over the last few years to think about code has really improved my understanding about what code means, and how best to write it. This has been an unexpected pleasure.
Hey Sandi, thanks so much for doing this AMA!
I'm not too sure if this is related to object-oriented design, but I was wondering about this code snippet I have in my PublishingService object:
true if finalize_book &&
author.update(book_count: (author.book_count + 1)) &&
# other methods
Is this generally an acceptable pattern? When I created this, I assumed it was a standard since Rails' ActiveRecord actions like update return true if it went through as opposed to some final object.
I'm not Sandi Metz but there are a few things that captured my attention about that piece of code.
You're using a service/business/whatever object and that is good ™ (instead of pushing all that code down in the model)
I would pass the book (and the author, unless you infer it from the book object) as an argument to publish book, this makes your code easier to test and mock.
def publish_book(book, author)
finalize_book(book) && author.increase_book_count! && send_announcement_email
Thank you for doing this AMA!
What inspired you to name your latest book "99 Bottles of OOP"?
Long-time reader; first-time poster, here..
How do you image the rise of containers such as Docker will impact (or already have impacted) the way we think about building web applications using more monolithic frameworks such Ruby on Rails?
Let me start by saying that ever since I started programming, your talks and books have been a major influence on me and my work. Thank you a hundred times for taking the time out to write instructions for all the "younger, less-experienced Sandi" developers out there!
I'm curious how you got into programming in the first place, and at what point in your career you felt you could speak about design with authority (something I struggle with myself).
Also, if you weren't involved with programming - what would you be doing now?
What would you recommend to somebody trying to get back into development? Ideally an entry-level position.
How'd you start learning programming, and how did you eventually get into Ruby? What would you say is the main reason you've stuck with it for so long?
Asking as a junior dev who loves Ruby, and ideally would like to use it for the rest of his career. 😬
Hi Sandi, thanks for doing this AMA!
I had a situation where a route call a method to get an amount, and this method used a switch for check the type (Each case call a method).
I'm using Laravel with the pattern of repository/interface so I created 2 repositories (I notice that some cases of the switch are similars so I decided to integrate them in the repositories).
First I create an array of the repositories
Then in the method amount I change to this
What do you think? (I take base of this article of you when-code-duplication-is-the-right...
Hey Sandi, thanks for doing this! I have learned a ton from you, as you were (and still are) one of my references when I just started coding.
I'm looking to improve myself as a developer, and I realized that I can write a lot of code and read a lot, but without feedback it's hard to know if you are on the right path or not. Do you agree with this? If yes, do you have any suggestions to where to find this feedback? Open source seems like a good place.
Thoughts on Ruby 2.5? and Ruby 3x3 (Ruby 3 to be 3 times as fast)? Or Ruby performance in general?
How do you divide your various responsibilities and opportunities in your work life?
What do you spend the most time doing?
How does one correctly ensures thread-safety when dealing with concurrency in OOP?
Thank you so much for writing POODR. It's perfect.
HOW DID I MISS THIS
Hey, Sandi sorry I know this is an old thread but I wonder if you answer this question:
Sandi, greetings, hope you're fine, just wanted to say hello…
We met in Manzanillo, few years ago, in the Magma conference…
Hello right back!
POODR is the best software related book I've ever read. Thanks!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.