Про 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, пусть она ждёт своего часа в приложении
А какой философии придерживаешься ты?
🤔 – ну надо же всё продумать и сделать качественно
🚀 – быстро в прод
5 блокеров для вашего развития
Недавно общался с нашим разработчиком про развитие и порефеклексировал на тему того, что мне мешало или наоборот, помогало в развитии как инженера. Пришёл к выводам, что часто замедляет развитие следующее:
1️⃣ Боязнь показаться некомпетентным. Часто амбиции и желание казаться умнее побеждают здравый смысл. Ты чего-то не понимаешь, но молчишь, потому что не хочешь в этом признаться. И чем дольше – тем сильнее это будет мешать. Если же всегда держать в уме, что ты чего-то не знаешь и это нормально – будет легче задавать вопросы. Спрашивай, ошибайся, даже тупи иногда! Ты никогда не будешь знать всё, но у тебя всегда будет шанс узнать что-то новое. Ты хочешь казаться топовым специалистом или быть им?
2️⃣ Ожидание, что тебя всему научат. Да, в больших компаниях могут помочь сделать personal development plan, там даже может быть внутренняя школа/академия, но только ты отвечаешь за своё обучение. Любой мой бывший одногруппник скажет, что 80% информации на факультете информатики ему ничего не дали, так почему образование в какой-то компании будет лучше? Ищи информацию, анализируй свои сильные и слабые стороны, проси фидбек от коллег и руководителей, понимай свои цели и «создавай» образовательный курс под себя, а не ожидай, что это кто-то сделает за тебя
3️⃣ Слепая вера авторитетам. «Тимлид сказал, что так делать нельзя». «Наш лучший бекендер говорит, что postgres лучше mysql». «В твиттере написали, что надо использовать redux». Инструменты развиваются. Ограничения устаревают. Почти для любого инструмента можно найти место, где он будет работать лучше самого популярного решения (а ещё это же утверждение справедливо для людей!). Лучшие умы не решали всех задач и не пробовали всё. «Оборотная сторона экспертов – то, что они слишком много знают о текущих ограничениях. Кто-то, взглянув свежим взглядом, может обойти эти ограничения практически благодаря своему невежеству» (с) Патти МакКорд – Сильнейшие. Анализируйте разные мнения, ищите противоположные точки зрения, задавайте вопросы!
4️⃣ Вера в то, что можно всему научиться по статьям. Статьи помогают решать проблемы и могут помочь ответить на конкретный вопрос. Но что делать, когда даже вопрос не известен? Книги помогают опуститься на другой уровень абстракции – они читаются дольше и с бóльшим погружением, часто они помогают задавать вопросы, но не дают ответов. Стековерфлоу помогает использовать чужие ответы, книги – давать свои.
5️⃣ Перекладывание ответственности. «Менеджер плохо сформулировал задачу», «На бекенеде сделали неправильное апи, не могу продолжать». Да, часто хочется написать такой коммент в jira/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!
А что из этого мешало вам?
Недавно общался с нашим разработчиком про развитие и порефеклексировал на тему того, что мне мешало или наоборот, помогало в развитии как инженера. Пришёл к выводам, что часто замедляет развитие следующее:
1️⃣ Боязнь показаться некомпетентным. Часто амбиции и желание казаться умнее побеждают здравый смысл. Ты чего-то не понимаешь, но молчишь, потому что не хочешь в этом признаться. И чем дольше – тем сильнее это будет мешать. Если же всегда держать в уме, что ты чего-то не знаешь и это нормально – будет легче задавать вопросы. Спрашивай, ошибайся, даже тупи иногда! Ты никогда не будешь знать всё, но у тебя всегда будет шанс узнать что-то новое. Ты хочешь казаться топовым специалистом или быть им?
2️⃣ Ожидание, что тебя всему научат. Да, в больших компаниях могут помочь сделать personal development plan, там даже может быть внутренняя школа/академия, но только ты отвечаешь за своё обучение. Любой мой бывший одногруппник скажет, что 80% информации на факультете информатики ему ничего не дали, так почему образование в какой-то компании будет лучше? Ищи информацию, анализируй свои сильные и слабые стороны, проси фидбек от коллег и руководителей, понимай свои цели и «создавай» образовательный курс под себя, а не ожидай, что это кто-то сделает за тебя
3️⃣ Слепая вера авторитетам. «Тимлид сказал, что так делать нельзя». «Наш лучший бекендер говорит, что postgres лучше mysql». «В твиттере написали, что надо использовать redux». Инструменты развиваются. Ограничения устаревают. Почти для любого инструмента можно найти место, где он будет работать лучше самого популярного решения (а ещё это же утверждение справедливо для людей!). Лучшие умы не решали всех задач и не пробовали всё. «Оборотная сторона экспертов – то, что они слишком много знают о текущих ограничениях. Кто-то, взглянув свежим взглядом, может обойти эти ограничения практически благодаря своему невежеству» (с) Патти МакКорд – Сильнейшие. Анализируйте разные мнения, ищите противоположные точки зрения, задавайте вопросы!
4️⃣ Вера в то, что можно всему научиться по статьям. Статьи помогают решать проблемы и могут помочь ответить на конкретный вопрос. Но что делать, когда даже вопрос не известен? Книги помогают опуститься на другой уровень абстракции – они читаются дольше и с бóльшим погружением, часто они помогают задавать вопросы, но не дают ответов. Стековерфлоу помогает использовать чужие ответы, книги – давать свои.
5️⃣ Перекладывание ответственности. «Менеджер плохо сформулировал задачу», «На бекенеде сделали неправильное апи, не могу продолжать». Да, часто хочется написать такой коммент в jira/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!
А что из этого мешало вам?