Про 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/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!
А что из этого мешало вам?
Про стандартизацию
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть production-ready проект с кучей интеграций, проверок и понятным release-флоу, а своё время тратить на решение проблем бизнеса. Все в команде знают, как писать js или ruby, всем понятно что писать в пулл-реквестах, все могут просто копипастить конфиг для CI, который уже претерпел пару десятков итераций и решает сотни проблем. А деплой будет работать как для одного сервера, так и для кластера из 10 – и думать об этом на старте не нужно.
О чем нужно помнить, стандартизируя процессы?
– Система ≠ бюрократия. «Где задачку брали – туда и за апрувом идите. И вообще не видите, у нас обед?»
– Система должна ускорять и упрощать, а не наоборот
– Отвечайте на вопрос почему. «Окей, мы используем 2 пробела, а не 4. А где я могу почитать внутренний срачик на эту тему и его итоги?»
– Нужна возможность для обхода системы. «Проверка на гитхабе загорелась красным, но мне некогда править опечатки – на проде пожар! Как мне зарелизиться?»
– Нужен прозрачный формат улучшения. «Ребята, есть идея для обсуждения – а может уже попробуем react вместо jquery?»
– Нужно место и время для экспериментов. Время для анархии, чтобы люди понимали пользу стандартов (например, хакатоны). Небольшие проекты, чтобы пробовать что-то новое и улучшать стандарты.
– Нужно ставить стандарты под сомнение. Каждый раз, применяя тот или иной стандарт нужно задумываться, а не стал ли он карго-культом?
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть production-ready проект с кучей интеграций, проверок и понятным release-флоу, а своё время тратить на решение проблем бизнеса. Все в команде знают, как писать js или ruby, всем понятно что писать в пулл-реквестах, все могут просто копипастить конфиг для CI, который уже претерпел пару десятков итераций и решает сотни проблем. А деплой будет работать как для одного сервера, так и для кластера из 10 – и думать об этом на старте не нужно.
О чем нужно помнить, стандартизируя процессы?
– Система ≠ бюрократия. «Где задачку брали – туда и за апрувом идите. И вообще не видите, у нас обед?»
– Система должна ускорять и упрощать, а не наоборот
– Отвечайте на вопрос почему. «Окей, мы используем 2 пробела, а не 4. А где я могу почитать внутренний срачик на эту тему и его итоги?»
– Нужна возможность для обхода системы. «Проверка на гитхабе загорелась красным, но мне некогда править опечатки – на проде пожар! Как мне зарелизиться?»
– Нужен прозрачный формат улучшения. «Ребята, есть идея для обсуждения – а может уже попробуем react вместо jquery?»
– Нужно место и время для экспериментов. Время для анархии, чтобы люди понимали пользу стандартов (например, хакатоны). Небольшие проекты, чтобы пробовать что-то новое и улучшать стандарты.
– Нужно ставить стандарты под сомнение. Каждый раз, применяя тот или иной стандарт нужно задумываться, а не стал ли он карго-культом?
Слова паразиты, часть 1
— А нельзя было нормально протестировать?
— Я это не сделал, потому что менеджер нормально задачу не оформил!
— Когда ты станешь нормальным разработчиком – тогда зарплату и повысим
— Ты не нормально с клиентом разговариваешь!
— А может мы будем нормальные процессы использовать?
Слово нормально в последнее время стало для меня триггером – если человек его употребляет, значит он не может давать конструктивный фидбек. Плохо, нормально, хорошо – эти слова помогают выразить ваше отношение к чему-либо, но дают 0 информации собеседнику о том, что вы имеете ввиду. Хотите чтобы люди нормально делали – давайте нормальный фидбек. Рассказывайте, что для вас норма
— А нельзя было нормально протестировать?
— Я это не сделал, потому что менеджер нормально задачу не оформил!
— Когда ты станешь нормальным разработчиком – тогда зарплату и повысим
— Ты не нормально с клиентом разговариваешь!
— А может мы будем нормальные процессы использовать?
Слово нормально в последнее время стало для меня триггером – если человек его употребляет, значит он не может давать конструктивный фидбек. Плохо, нормально, хорошо – эти слова помогают выразить ваше отношение к чему-либо, но дают 0 информации собеседнику о том, что вы имеете ввиду. Хотите чтобы люди нормально делали – давайте нормальный фидбек. Рассказывайте, что для вас норма
Про Николая Иронова
Тяжелый физический труд, рутинные задачи, конвеерное производство. Задачи офисных сотрудников, телефония. Так постепенно автоматизация проникала в разные сферы бизнеса. Сейчас всё чаще пытаются автоматизировать и заменить разработчиков. Но всегда считалось, что дизайн – это исскуство и робот никогда не заменит дизайнера.
Но ведь всегда лучше попборовать, а не гадать. Причём можно сделать это не в виде эксперимента, а сразу с внедрением в бизнес и получать по 100к рублей за каждую работу нейросети, заменяющей дизайнера. Не хочу вдаваться в оценку работ, но сам факт такого внедрения – это ещё один шаг в сторону выполнения работы людей программами, хотя бы для достижения быстрых, но не идеальных результатов. Ещё немного и нейросети преодолеют склон просвещения и выйдут на плато продуктивности – тогда большинство компаний будут применять нейросети в своих повседневных задачах.
Если не хотите потерять в ценности из-за развития технологий – задумайтесь, а не занимаетесь ли вы одним и тем же изо дня в день? Если вы примете участие в роли консультанта в разработке нейросети, которая будет выполнять бóльшую часть ваших рутинных задач – останется ли что-то для вас? Сможете ли вы развивать её или она заменит вас полностью?
И что думаете о работах Иронова?
👨🎨 – настоящее искусство
🤖 - нет в них души
Тяжелый физический труд, рутинные задачи, конвеерное производство. Задачи офисных сотрудников, телефония. Так постепенно автоматизация проникала в разные сферы бизнеса. Сейчас всё чаще пытаются автоматизировать и заменить разработчиков. Но всегда считалось, что дизайн – это исскуство и робот никогда не заменит дизайнера.
Но ведь всегда лучше попборовать, а не гадать. Причём можно сделать это не в виде эксперимента, а сразу с внедрением в бизнес и получать по 100к рублей за каждую работу нейросети, заменяющей дизайнера. Не хочу вдаваться в оценку работ, но сам факт такого внедрения – это ещё один шаг в сторону выполнения работы людей программами, хотя бы для достижения быстрых, но не идеальных результатов. Ещё немного и нейросети преодолеют склон просвещения и выйдут на плато продуктивности – тогда большинство компаний будут применять нейросети в своих повседневных задачах.
Если не хотите потерять в ценности из-за развития технологий – задумайтесь, а не занимаетесь ли вы одним и тем же изо дня в день? Если вы примете участие в роли консультанта в разработке нейросети, которая будет выполнять бóльшую часть ваших рутинных задач – останется ли что-то для вас? Сможете ли вы развивать её или она заменит вас полностью?
И что думаете о работах Иронова?
👨🎨 – настоящее искусство
🤖 - нет в них души
Главный вопрос
Есть люди, которые избегают вопроса «почему». Если руководитель спросит такого человека, почему он сделал именно так – он будет думать, что руководитель «включает начальника», «давит авторитетом», хочет «завалить» решение. Если спросит просто коллега – будет думать, что тот недостаточно умён, чтобы понять самому. Если подчинённый – «он что, сомневается в моих решениях!?». Обычно, те же люди не задают вопросы сами.
А ответы на этот вопрос – это «клей» для команд. Когда члены команды понимают историю принятия решения и его причины – они не будут ставить его под сомнение. Когда люди имеют возможность открыто задавать вопросы, не боясь показаться глупым, они вскрывают все недоработки менеджмента, вспоминают о забытых идеях, понимают выбранные приоритеты и выбирают оптимальные пути решения. Зная, что нужно публично ответить на вопрос «почему мы делаем именно это?» менеджеры составляют более осознанный план и занимаются более глубокой рефлексией своих действий. У любой задачи может быть много правильных решений, поэтому и для разработчиков/дизайнеров важно понимать, почему коллега выбрал именно этот путь – так проще в будущем поддерживать этот код и принимать подобные решения.
Культура открытых вопросов – драйвер роста ваших команд. Как начать выстраивать такую культуру?
— Сразу отвечай в своей работе «почему так?», не дожидаясь явного вопроса
— Не воспринимай вопросы, как индикатор критики или глупости
— Потрать время на объяснение – инвестиция этого времени быстро начнёт себя окупать
— Не стесняйся задавать вопросы
— Не бойся задавать неудобные вопросы
— Не скрывай правду. Даже если планируешь что-то сделать просто потому, что кажется что это сработает или просто интересно/хочется это сделать – так всем и говори!
Есть люди, которые избегают вопроса «почему». Если руководитель спросит такого человека, почему он сделал именно так – он будет думать, что руководитель «включает начальника», «давит авторитетом», хочет «завалить» решение. Если спросит просто коллега – будет думать, что тот недостаточно умён, чтобы понять самому. Если подчинённый – «он что, сомневается в моих решениях!?». Обычно, те же люди не задают вопросы сами.
А ответы на этот вопрос – это «клей» для команд. Когда члены команды понимают историю принятия решения и его причины – они не будут ставить его под сомнение. Когда люди имеют возможность открыто задавать вопросы, не боясь показаться глупым, они вскрывают все недоработки менеджмента, вспоминают о забытых идеях, понимают выбранные приоритеты и выбирают оптимальные пути решения. Зная, что нужно публично ответить на вопрос «почему мы делаем именно это?» менеджеры составляют более осознанный план и занимаются более глубокой рефлексией своих действий. У любой задачи может быть много правильных решений, поэтому и для разработчиков/дизайнеров важно понимать, почему коллега выбрал именно этот путь – так проще в будущем поддерживать этот код и принимать подобные решения.
Культура открытых вопросов – драйвер роста ваших команд. Как начать выстраивать такую культуру?
— Сразу отвечай в своей работе «почему так?», не дожидаясь явного вопроса
— Не воспринимай вопросы, как индикатор критики или глупости
— Потрать время на объяснение – инвестиция этого времени быстро начнёт себя окупать
— Не стесняйся задавать вопросы
— Не бойся задавать неудобные вопросы
— Не скрывай правду. Даже если планируешь что-то сделать просто потому, что кажется что это сработает или просто интересно/хочется это сделать – так всем и говори!
Создавай систему
Что полезнее, один раз сходить на пробежку в 15км и упасть от бессилия или регулярно 2 раза в неделю бегать по 3км? Прочитать «Войну и мир» или постоянно читать и заниматься самообразованием? Кто больше ценится в команде – тот, кто может «затащить» перед дедлайном, работая без передышек и задерживаясь на работе или тот, кто стабильно выдает крутой результат, заканчивая работать в 18:00?
Очевидно, что в долгосрочной перспективе, как для отдельно взятого человека, так и для команды побеждает система – меньше стресса, больше результатов, качество которых постоянно растёт. Да, ты можешь находиться на «пике» за счёт единоразовых сверхусилий или удачи, но через какое-то время ты оттуда слетишь, если не будет системы. Какой процент исполнителей, популярных позапрошлым летом ты помнишь сейчас? А какие гениальные стартапы, которые быстро взелетели 5 лет назад ещё существуют?
Система – это ускорение. Если ты двигаешься медленно, но с постоянным ускорением, через какое-то время ты обгонишь тех, кто уже сейчас двигается быстро, но с постоянной скоростью. Хочешь постоянно «лезть» вверх, ускоряясь?
Работая над системой, вместо постоянного решения возникающих проблем, можно избежать ситуаций, требующих героев. Не нужно ложиться грудью на амбразуру, если из неё никто не будет стрелять. При этом важно уметь тушить пожары – единоразовый фейл не должен рушить выстроенную систему.
Как недавно сказал наш СЕО – «есть люди, которые могут сделать хорошо, а есть те, которые не могут делать плохо». Стройте систему, чтобы быть вторыми.
Что полезнее, один раз сходить на пробежку в 15км и упасть от бессилия или регулярно 2 раза в неделю бегать по 3км? Прочитать «Войну и мир» или постоянно читать и заниматься самообразованием? Кто больше ценится в команде – тот, кто может «затащить» перед дедлайном, работая без передышек и задерживаясь на работе или тот, кто стабильно выдает крутой результат, заканчивая работать в 18:00?
Очевидно, что в долгосрочной перспективе, как для отдельно взятого человека, так и для команды побеждает система – меньше стресса, больше результатов, качество которых постоянно растёт. Да, ты можешь находиться на «пике» за счёт единоразовых сверхусилий или удачи, но через какое-то время ты оттуда слетишь, если не будет системы. Какой процент исполнителей, популярных позапрошлым летом ты помнишь сейчас? А какие гениальные стартапы, которые быстро взелетели 5 лет назад ещё существуют?
Система – это ускорение. Если ты двигаешься медленно, но с постоянным ускорением, через какое-то время ты обгонишь тех, кто уже сейчас двигается быстро, но с постоянной скоростью. Хочешь постоянно «лезть» вверх, ускоряясь?
Работая над системой, вместо постоянного решения возникающих проблем, можно избежать ситуаций, требующих героев. Не нужно ложиться грудью на амбразуру, если из неё никто не будет стрелять. При этом важно уметь тушить пожары – единоразовый фейл не должен рушить выстроенную систему.
Как недавно сказал наш СЕО – «есть люди, которые могут сделать хорошо, а есть те, которые не могут делать плохо». Стройте систему, чтобы быть вторыми.
Про потребление контента
Сложно представить современного человека, который не потребляет контент постоянно. Подкасты, статьи, видео. Часто это информация, которую даже нельзя применить здесь и сейчас. Так нужна ли она? Или это информационный мусор?
Знания можно уложить в 3 группы: первая безграничная – «не знаю, что не знаю». Там будет что-то, с чем вы никогда в жизни не сталкивались и проблемы, о существовании которых не подозреваете. Вторая – что-то, о чем вы слышали, но не можете сказать, что что-то в этом понимаете. И самая маленькая — вы знаете, что вы это знаете.
Весь профессиональный рост – это расширение зоны «знаю, что не знаю» и постепенное её заполнение «знаю, что знаю». На старте люди часто фокусируются на заполнении середины, не расширяя её. Отсюда и мемы в стиле
— Junior: я ничего не знаю
— Middle: я всё знаю
— Senior: я ничего не знаю, ну и ладно
Чтобы не попасть в ловушку «я все знаю» нужен баланс, насмотренность. Заглядывать в соседние технологии, понимать, чем занимаются люди вокруг, что используют, как. Если вдруг кажется, что вот теперь вы профессионал и во всем разобрались — есть плохие новости.
Постоянное потребление информации это ещё и источник идей. Не знаешь, что делать? Смотри, что делают другие. Создай систему для постоянного переваривания информации и совершенствуй ее — в помощь rss/reading lists/pocket и выделенное время в календаре. Лучше постоянный поток идей, чем их отсутствие.
Ведь ещё Ньютон говорил «То, что мы знаем - капля воды, то, чего мы не ведаем - целый океан, так что читай статейки»
Сложно представить современного человека, который не потребляет контент постоянно. Подкасты, статьи, видео. Часто это информация, которую даже нельзя применить здесь и сейчас. Так нужна ли она? Или это информационный мусор?
Знания можно уложить в 3 группы: первая безграничная – «не знаю, что не знаю». Там будет что-то, с чем вы никогда в жизни не сталкивались и проблемы, о существовании которых не подозреваете. Вторая – что-то, о чем вы слышали, но не можете сказать, что что-то в этом понимаете. И самая маленькая — вы знаете, что вы это знаете.
не знаю, что не знаю
┏━━━━━━━━━━━━━━━━━━━┓
┃знаю, что не знаю ┃
┃ ╔══════════════╗ ┃
┃ ║знаю, что знаю║ ┃
┃ ╚══════════════╝ ┃
┗━━━━━━━━━━━━━━━━━━━┛
Весь профессиональный рост – это расширение зоны «знаю, что не знаю» и постепенное её заполнение «знаю, что знаю». На старте люди часто фокусируются на заполнении середины, не расширяя её. Отсюда и мемы в стиле
— Junior: я ничего не знаю
— Middle: я всё знаю
— Senior: я ничего не знаю, ну и ладно
Чтобы не попасть в ловушку «я все знаю» нужен баланс, насмотренность. Заглядывать в соседние технологии, понимать, чем занимаются люди вокруг, что используют, как. Если вдруг кажется, что вот теперь вы профессионал и во всем разобрались — есть плохие новости.
Постоянное потребление информации это ещё и источник идей. Не знаешь, что делать? Смотри, что делают другие. Создай систему для постоянного переваривания информации и совершенствуй ее — в помощь rss/reading lists/pocket и выделенное время в календаре. Лучше постоянный поток идей, чем их отсутствие.
Ведь ещё Ньютон говорил «То, что мы знаем - капля воды, то, чего мы не ведаем - целый океан, так что читай статейки»
Лучший интерфейс — отсуствие интерфейса. Лучшее решение задачи — без написания кода. Умение использовать инструменты, которые упрощают вашу жизнь и позволяют удалить «инфрастуктурный» код из вашего продукта, сфокусироваться на решении бизнес-проблем – необходимый скилл любой команды.
Решил в нескольких частях рассказать про бесплатные инструменты, которые облегчают жизнь нашим командам разработки. В первой части про
– Newrelic
– Sentry
– Imgproxy
– Cloudflare
Решил в нескольких частях рассказать про бесплатные инструменты, которые облегчают жизнь нашим командам разработки. В первой части про
– Newrelic
– Sentry
– Imgproxy
– Cloudflare