Два года как я Lead/Engineering Manager в платёжке Palta. А на следующей неделе я ухожу из компании в очередной творческий отпуск.
Время подводить итоги. Начну с моей самой любимой инициативы.
С первого месяца я начал продвигать идею предварения крупных изменений текстовыми документами — RFC — Request for Comments.
В этом посте будет анализ двух лет применения этой практики. Чтобы пошарить опыт, подвести итоги и иметь под рукой агитку для моего следующего места работы.
Чтоб я ещё когда взялся делать blackboard мультиагентную систему с темпоральными свойствами :-D
В этом посте будет краткое подведение итогов, чтобы закрыть вопрос.
Заметок по ходу эксериментов я не делал, поэтому какие-то интересные детали рассказать сложно — в голове всё смешалось и затёрлось уже.
Последние несколько недель использовал GitHub Сopilot, благо для Emacs есть плагин. Поделюсь впечатлениями.
Для справки, я уже лет 15 осознанно не использовал умное автодополнение. Всё моё автодополнение — это DynamicAbbreviations, по сути — дополнение написанного слова на основе словаря из открытых исходников.
Причина отказа такая: используя «умное» автодополнение (например, подсказку аттрибутов/методов объекта) перестаёшь понимать проект. Начинаешь на автомате брать предлагаемые варианты методов/переменных, не разбираясь что они конкретно делают и есть ли альтернатинвые варианты.
В краткосрочной перспективе отказ от автодополнения повышает нагрузку на человека (особенно на память) и замедляет работу, но в доглосрочной даёт глубокое понимание проекта, возможнсоть крутить его в голове как угодно, что с лихвой окупает потери на скорости в моменте. А поскольку я работаю только над долгими проектами, долгосрочная выгода важнее.
С Copilot я, похоже, вернуcь к умному автодополнению, в его более правильном варианте.
Итак, давайте посмотрим чего умеет и не умеет Copilot.
Мы в Palta активно ищем сотрудников, поэтому я собеседую людей уровня senior & lead. А до этого в Melsoft доводилось мидлов и выше собеседовать. Накопился ряд наблюдений, которыми хочется поделиться.
Сначала хотел написать на глобальную тему, вроде разницы между junior, middle, senior & lead, но дело шло туго, поэтому сделаю проще.
Расскажу о косяках, которые с большой вероятностью помешают пройти собеседование конкретно у меня.
По отдельности каждая проблема — не приговор, но точно снижает шансы на положительное впечатление.
Для каждой проблемы я написал упрощённый пример диалога. Надеюсь получилось наглядно. Главное помните, что вопросы и ответы там придуманы специально для иллюстрации проблемы, а не взяты из реальных собесов. По большей части :-)
Экспресс пост в ответ на вопрос.
Кратко: чтобы лучше кодить, надо больше кодить :-) и вдумчиво читать код.
Если чуть подробнее, то вопрос сложный и что-то посоветовать из чтения мне сложно:
Я больше писал, чем читал :-D В итоге, когда я начал читать шаблоны проектирования, я подумал: «и что тут такого, я уже с этим сталкивался», когда листал совершенный код, я подумал аналогично. То есть моя практика обгоняла теорию.
Из книг я читал то, что советовали преподаватели в универе, благо было кому советовать, и то, что считал интересным. Страуструпа, например, 2 раза прочитал.