Привет, я Санди Мец, автор книг Практическое объектно-ориентированное проектирование на Ruby и 99 бутылок ООП, и я верю в простой код и понятные объяснения. Я предпочитаю работающее программное обеспечение, практические решения и длительные поездки на велосипеде (не обязательно в таком порядке), и я пишу, консультирую и преподаю объектно-ориентированный дизайн. "Спрашивай о чем угодно"

How do you prepare for your talks? Do you have any specific rituals you go through before stepping in front of an audience?

Я сценарист и практик, а не э-э-э-э-э-э-э-э-э-э. Как только я выясняю суть выступления и составляю колоду слайдов, я выясняю, что я планирую сказать на каждом слайде, и между какими словами я планирую менять слайды, а затем репетирую, пока не почувствую уверенность, что могу выступать. неотрепетированный. Мое эмпирическое правило заключается в том, что я должен произнести полностью законченную речь в моем пустом офисе 10 раз, прежде чем я буду готов выйти на сцену.
Однажды я прочитал рекомендацию, в которой говорилось, что спикер должен умножить количество людей в аудитории на их почасовую ставку, чтобы решить, сколько усилий следует приложить к выступлению. Судя по этой математике, планка готовности кажется очень высокой.

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.

Вот сделка. Сила динамически типизированных объектно-ориентированных языков достигается только тогда, когда вы пишете заслуживающие доверия объекты, использующие утиную типизацию и полиморфизм, а затем доверяете их правильному поведению. Если по каким-то причинам (наклонность или предыстория) вы не можете предотвратить создание ненадежных объектов, вероятно, лучше использовать статическую типизацию.

Эти стили программирования различны, и их объединение приводит к худшему из обоих миров.

What are your thoughts on functional programming?

У меня небольшой опыт работы с функциональными языками, так что мне нечего сказать. Однако я могу сказать, что неизменность и отсутствие побочных эффектов — отличные идеи, и что я позаимствовал их для своего ОО.

Моя первоначальная цель для каждого нового объекта, который я пишу, состоит в том, чтобы он не менялся и не имел побочных эффектов. Очевидно, что это не может подойти для каждого объекта, но я был приятно удивлен тем, как много можно сделать при этих ограничениях и насколько эти ограничения упрощают код.

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?

Во-первых, вы обязательно должны написать книгу. Как бы ни было больно писать (по крайней мере, для меня), писать — большое удовольствие, и другие будут благодарны за ваши усилия.

Что касается тем, я просто думаю о вещах, которые я знаю сейчас, и которые были бы полезны более молодой и менее опытной Сэнди. Я думаю о себе в прошлом как о нетерпеливом, способном, но совершенно невежественном, и очень сочувствую проблемам, с которыми она столкнулась. Я уверен, что она могла понять некоторые вещи, если только они были хорошо объяснены. Она — воображаемый читатель, для которого я пишу, и моя главная цель — заставить ее почувствовать себя умной.

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? :-)

Кристен, боюсь, я ужасно переключаю контекст. У меня получается лучше всего, когда я могу погрузиться в одну вещь и игнорировать все остальное. Это часто означает, что я пренебрегаю мелкими вещами (аргументы, электронная почта), чтобы работать над большими вещами (главой книги или выступлением).

Я смирился с этим своим качеством и просто в основном устроил свою жизнь так, чтобы я мог так работать.

Единственное, что я обнаружил, это то, что лучше всего я пишу в начале дня. Я могу писать прозу утром, делать перерыв, а потом, например, днем ​​писать код. Написание прозы для меня очень болезненно, а код — это всегда радость, поэтому я склонен вознаграждать себя кодом, как только закончу все остальное.

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?

Эндрю, с удовольствием.
А, TDD. Я считаю, что мой код получается лучше, если я сначала пишу тесты, но я глубоко сочувствую тому, насколько это сложно. Сначала написание тестов может помочь вам создать несвязанный код. Если вы пишете тесты вторыми, а затем обнаруживаете, что тесты имеют сложную настройку, это говорит о том, что ваш код слишком тесно связан. Если вы сначала пишете тесты и настаиваете на простой настройке, вы, естественно, получите хорошо развязанный код.

Ссылка: https://dev.to/sandimetz/im-sandi-metz-ask-me-anything-4ff9