Два года пишем RFC — статистика
Два года как я Lead/Engineering Manager в платёжке Palta. А на следующей неделе я ухожу из компании в очередной творческий отпуск.
Время подводить итоги. Начну с моей самой любимой инициативы.
С первого месяца я начал продвигать идею предварения крупных изменений текстовыми документами — RFC — Request for Comments.
В этом посте будет анализ двух лет применения этой практики. Чтобы пошарить опыт, подвести итоги и иметь под рукой агитку для моего следующего места работы.
Paul Graham: Superlinear returns
(c) DALL-E: "Vrubel painting of a blogger crying with admiration while reading an essay by another, more experienced, author." DALL-E отказывается рисовать по запросам с именами.
Рекомендую эссе Paul Graham: Superlinear returns.
Что мне нравится в текстах Paul Graham так это опережение моих писательских планов. Пол периодически пишет про то, что я давно хочу написать, но пока не могу — ещё не Paul Graham :-D
Конкретно на тему нелинейных изменений я уже лет 10 хочу написать эссе да побольше. Но если бы я сел его писать сейчас, то это был бы длиннопост со странными графиками и терминами и без таких интересных примеров как у Пола. Поэтому приходится давать ссылки на его эссе.
Дальше, в общем-то, можете мой пост не читать. Главное оригинальное эссе прочтите. Но оставлю пару заметок для истории, которые лучше читать после оригинального эссе.
Как завалить собес у меня
Мы в Palta активно ищем сотрудников, поэтому я собеседую людей уровня senior & lead. А до этого в Melsoft доводилось мидлов и выше собеседовать. Накопился ряд наблюдений, которыми хочется поделиться.
Сначала хотел написать на глобальную тему, вроде разницы между junior, middle, senior & lead, но дело шло туго, поэтому сделаю проще.
Расскажу о косяках, которые с большой вероятностью помешают пройти собеседование конкретно у меня.
По отдельности каждая проблема — не приговор, но точно снижает шансы на положительное впечатление.
Для каждой проблемы я написал упрощённый пример диалога. Надеюсь получилось наглядно. Главное помните, что вопросы и ответы там придуманы специально для иллюстрации проблемы, а не взяты из реальных собесов. По большей части :-)
Верификация частными случаями
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Гены, мемы и мемплексы
Расскажу как правильно смотреть я смотрю на культурные явления и взаимодействие с ними. В явления запишем всё: обычаи, законы, песни, холивары, языки программирования, методологии разработки — любой информационный артефакт нашей цивилизации. Но примеры в основном будут из IT.
Также этот пост можно считать заготовкой аргументов на случай, если придётся отбиваться от навязывания консультаций по какому-нибудь scrum.
Мемплекс это и есть сложносоставное культурное явление. Это слово буду использовать и дальше, так как оно красивое и короткое.
Начну издалека — с пары оговорок и биологии, как наиболее изученной области проявления эволюции. Потом по аналогии рассмотрим элементарные информационные конструкции — мемы. Потом мемплексы.