Про nocode
Ещё с первых лет в айти меня постоянно преследовали инструменты разработки без написания кода. MS Frontpage, какое-то визуальное программирование в универе, потом – тильда и другие конструкторы. Но всегда я понимал, что это инструменты для тех, кто не может писать код, а я ИЛИТА – мне удобнее всё сделать самому – проще поддерживать, больше гибкости.
И вот в 2021 поймал себя на мысли, что начал регулярно пользоваться nocode-инструментами для решения задач, которые раньше бы запрограммировал
• Собрал для себя телеграмм-бота, помогающего вести бюджет. Он связывает телеграмм и табличку в google sheets.
• Используем integromat для наведения порядка на общем гугл-диске. Бот автоматически раскидывает видео демо по папкам с нужными правами + шлёт сообщения в слак каналы
• Сделали onboarding-бота через Slack workflows, который скидывает новичкам полезную инфу про компанию и ссылки
• Лучше подружили джиру и гихтаб с помощью jira automation – меняем лейблы в джире, чтобы понимать статусы пулл-реквестов, автоматически меняем статусы
Ещё с первых лет в айти меня постоянно преследовали инструменты разработки без написания кода. MS Frontpage, какое-то визуальное программирование в универе, потом – тильда и другие конструкторы. Но всегда я понимал, что это инструменты для тех, кто не может писать код, а я ИЛИТА – мне удобнее всё сделать самому – проще поддерживать, больше гибкости.
И вот в 2021 поймал себя на мысли, что начал регулярно пользоваться nocode-инструментами для решения задач, которые раньше бы запрограммировал
• Собрал для себя телеграмм-бота, помогающего вести бюджет. Он связывает телеграмм и табличку в google sheets.
• Используем integromat для наведения порядка на общем гугл-диске. Бот автоматически раскидывает видео демо по папкам с нужными правами + шлёт сообщения в слак каналы
• Сделали onboarding-бота через Slack workflows, который скидывает новичкам полезную инфу про компанию и ссылки
• Лучше подружили джиру и гихтаб с помощью jira automation – меняем лейблы в джире, чтобы понимать статусы пулл-реквестов, автоматически меняем статусы
Зачем разработчику уметь писать?
В большинстве продуктовых команд для опытного разработчика намного важнее софт-скилы, нежели hard. Один из таких скилов – написание текстов ✍️. Почему это важно?
• Вы понимаете, с кем разговариваете и о чём. Умея правильно сформулировать мысль вы предоставите максимум контекста и правильно зададите вопрос, не перегружая собеседника деталями, что сэкономит время обоим
• Вы лучше будете коммуницировать с остальной командой. Например, если что-то сломалось – мало написать «я починил». Важно предоставить необходимые детали – почему? Что мы сделали, чтобы это не ломалось потом? Это интересно не только разработчикам, а всей команде продукта
• Вы будете думать о «читателе» не только в текстах, но и в коде. Надевая шляпу «читателя» вашего собственного кода вы будете понимать, какие места в коде наименее понятны и предоставите необходимые детали, будете использовать правильное именование или добавите комметарии (не комментируя при этом каждую строчку кода)
• Будучи одновременно и человеком, который пишет код и который делает код-ревью вы облегчите задачу для ревьюера – аналогично коду вы предоставите необходимую информацию. Мы, например, используем шаблон для пулл-реквестов, чтобы разработчики не забывали про правильное описание
• Когда вы пишете текст, поясняя ваши действия, вы проводите своего рода ретроспективу проделанного. Часто на этом этапе можно понять, что на самом деле вы сделали не то, что хотели 🤔
• Парадоксально, но часто вы не сможете написать хороший код, если не можете написать хороший текст. Он может решать задачу, хорошо и быстро работать, но его будет трудно читать и поддерживать. Видели код, который пишут программисты-олимпиадники? А их тексты?
Как говорят в basecamp – если вы выбираете между двумя одинаковыми кандидатами – выбирайте того, который лучше пишет.
Считаете ли вы скилл написания текстов важным?
✍️ – да, нужно постоянно писать
🙅 – пустое описание, "fixed" в описании PR и погнали, некогда писать!
В большинстве продуктовых команд для опытного разработчика намного важнее софт-скилы, нежели hard. Один из таких скилов – написание текстов ✍️. Почему это важно?
• Вы понимаете, с кем разговариваете и о чём. Умея правильно сформулировать мысль вы предоставите максимум контекста и правильно зададите вопрос, не перегружая собеседника деталями, что сэкономит время обоим
• Вы лучше будете коммуницировать с остальной командой. Например, если что-то сломалось – мало написать «я починил». Важно предоставить необходимые детали – почему? Что мы сделали, чтобы это не ломалось потом? Это интересно не только разработчикам, а всей команде продукта
• Вы будете думать о «читателе» не только в текстах, но и в коде. Надевая шляпу «читателя» вашего собственного кода вы будете понимать, какие места в коде наименее понятны и предоставите необходимые детали, будете использовать правильное именование или добавите комметарии (не комментируя при этом каждую строчку кода)
• Будучи одновременно и человеком, который пишет код и который делает код-ревью вы облегчите задачу для ревьюера – аналогично коду вы предоставите необходимую информацию. Мы, например, используем шаблон для пулл-реквестов, чтобы разработчики не забывали про правильное описание
• Когда вы пишете текст, поясняя ваши действия, вы проводите своего рода ретроспективу проделанного. Часто на этом этапе можно понять, что на самом деле вы сделали не то, что хотели 🤔
• Парадоксально, но часто вы не сможете написать хороший код, если не можете написать хороший текст. Он может решать задачу, хорошо и быстро работать, но его будет трудно читать и поддерживать. Видели код, который пишут программисты-олимпиадники? А их тексты?
Как говорят в basecamp – если вы выбираете между двумя одинаковыми кандидатами – выбирайте того, который лучше пишет.
Считаете ли вы скилл написания текстов важным?
✍️ – да, нужно постоянно писать
🙅 – пустое описание, "fixed" в описании PR и погнали, некогда писать!
Сто раз отмерь, сто раз отрежь
Старая поговорка «сто раз отмерь, один раз отрежь» не работает в современной разработке. Неправильно отрезал – возьми новую доску. Нет времени планировать идеальный результат, потому что он таким не будет никогда. Нельзя ничего сделать идеально с первой попытки. Чем дольше делается первая версия – тем позже ты получишь инсайты о том, как можно сделать это лучше.
Долгие итерации негативно влияют и на твою мотивацию, и на уровень коммуникаций в команде. Почему?
1. Долго делаешь? Тебе тяжелее воспринимать негативный фидбек. Представь себе ситуацию, что ты делал что-то пол года но уже первый тест показал, что всё это не то и нужно идти в другом направлении. Сколько продлится твоя мини-депрессия?
2. Долго делаешь? Людям вокруг сложнее тебе сказать, что это можно сделать лучше, потому что см. п. 1. Вместо ориентации на продукт команда будет ориентироваться на эмпатию. «Ой, сейчас ему скажу, что можно было сделать по-другому и лучше, а он обидится – он же это 3 месяца делал. Лучше промолчу!». А что выберешь ты, сделать лучше продукт или не задеть чьи-то чувства? Так просто не ставь людей перед таким выбором.
3. Долго делаешь? Тебе сложнее держать фокус. Мотивация делать новый проект всегда выше, чем заканчивать что-то, начатое полгода назад. «Вот сейчас мы ещё чуть-чуть допилим и точно выкатимся!» – в 80% случаев ложь. Доделаете – придумаете, как сделать ещё лучше. И снова никто это не увидит. Кто любит делать что-то в стол?
4. Долго делаешь? Ты не делаешь другие вещи, а значит они простаивают. Или наоборот, ты делаешь их параллельно, теряя фокус с большой задачи
Как этого избежать?
• Используй правило OHIO – only hold it once. Сделай минимально рабочее решение, выкати его в прод и забудь о нём до следующей итерации. Либо у тебя будет новая цель для улучшения сделанного, либо сделаешь другую задачу/фичу/проект
• Декомпозируй. Раздели большой продукт/фичу на небольшие, но рабочие куски – так будет возможность в любой из промежуточных шагов уже выкатить всё на реальных пользователей. А долгосрочное видение поможет заложить правильную архитектуру для дальнейшего улучшения
• Отвечаешь за код? Чаще показывай и тестируй его
– Сразу открой pull request, коллеги будут делать ревью параллельно твоей работе и тебе сложно будет уйти не туда
– Чаще мёрж свои пулл-реквесты. Так не будет конфликтов и будет больше уверенности, что ничего нигде не сломалось
– Запланируй откат. Выкатить баг на прод – не проблема, проблема – не иметь возможности быстро его откатить или пофиксить.
• Отвечаешь за продукт? Чаще релизь
– Не уверен, что фича зайдёт пользователям? Выкати на небольшой процент аудитории
– Фича ещё не готова? Выключи её через feature toggle, пусть она ждёт своего часа в приложении
А какой философии придерживаешься ты?
🤔 – ну надо же всё продумать и сделать качественно
🚀 – быстро в прод
Старая поговорка «сто раз отмерь, один раз отрежь» не работает в современной разработке. Неправильно отрезал – возьми новую доску. Нет времени планировать идеальный результат, потому что он таким не будет никогда. Нельзя ничего сделать идеально с первой попытки. Чем дольше делается первая версия – тем позже ты получишь инсайты о том, как можно сделать это лучше.
Долгие итерации негативно влияют и на твою мотивацию, и на уровень коммуникаций в команде. Почему?
1. Долго делаешь? Тебе тяжелее воспринимать негативный фидбек. Представь себе ситуацию, что ты делал что-то пол года но уже первый тест показал, что всё это не то и нужно идти в другом направлении. Сколько продлится твоя мини-депрессия?
2. Долго делаешь? Людям вокруг сложнее тебе сказать, что это можно сделать лучше, потому что см. п. 1. Вместо ориентации на продукт команда будет ориентироваться на эмпатию. «Ой, сейчас ему скажу, что можно было сделать по-другому и лучше, а он обидится – он же это 3 месяца делал. Лучше промолчу!». А что выберешь ты, сделать лучше продукт или не задеть чьи-то чувства? Так просто не ставь людей перед таким выбором.
3. Долго делаешь? Тебе сложнее держать фокус. Мотивация делать новый проект всегда выше, чем заканчивать что-то, начатое полгода назад. «Вот сейчас мы ещё чуть-чуть допилим и точно выкатимся!» – в 80% случаев ложь. Доделаете – придумаете, как сделать ещё лучше. И снова никто это не увидит. Кто любит делать что-то в стол?
4. Долго делаешь? Ты не делаешь другие вещи, а значит они простаивают. Или наоборот, ты делаешь их параллельно, теряя фокус с большой задачи
Как этого избежать?
• Используй правило OHIO – only hold it once. Сделай минимально рабочее решение, выкати его в прод и забудь о нём до следующей итерации. Либо у тебя будет новая цель для улучшения сделанного, либо сделаешь другую задачу/фичу/проект
• Декомпозируй. Раздели большой продукт/фичу на небольшие, но рабочие куски – так будет возможность в любой из промежуточных шагов уже выкатить всё на реальных пользователей. А долгосрочное видение поможет заложить правильную архитектуру для дальнейшего улучшения
• Отвечаешь за код? Чаще показывай и тестируй его
– Сразу открой pull request, коллеги будут делать ревью параллельно твоей работе и тебе сложно будет уйти не туда
– Чаще мёрж свои пулл-реквесты. Так не будет конфликтов и будет больше уверенности, что ничего нигде не сломалось
– Запланируй откат. Выкатить баг на прод – не проблема, проблема – не иметь возможности быстро его откатить или пофиксить.
• Отвечаешь за продукт? Чаще релизь
– Не уверен, что фича зайдёт пользователям? Выкати на небольшой процент аудитории
– Фича ещё не готова? Выключи её через feature toggle, пусть она ждёт своего часа в приложении
А какой философии придерживаешься ты?
🤔 – ну надо же всё продумать и сделать качественно
🚀 – быстро в прод