💬 Навыки коммуникации
Коммуникация - ключевой элемент работы в команде. Ты будешь постоянно взаимодействовать с другими людьми, в том числе и с теми, кто далек от технической части. Именно поэтому тебе и важно прокачивать свои навыки общения.
Самое главное - это излагать мысли ясно и кратко. Не используй сложную техническую терминологию и старайся объяснять так, чтобы тебя мог понять даже твой сосед, который работает водителем такси. Еще один крутой навык - уметь слушать собеседника. Старайся даже не просто слушать, а слышать и понимать его точку зрения. И, наконец, будь открытым к обратной связи и критике. Ты должен быть гибким и должен быть готов менять стиль общения в зависимости от ситуации.
Как можно развивать свои навыки общения:
1. Читай книги по коммуникации. Они помогут разобраться в психологии общения и дадут полезные рекомендации.
2. Практикуйся. Чем больше ты общаешься с другими людьми, тем больше понимаешь, как лучше формулировать свои мысли.
3. Прислушивайся к обратной связи. Ты даже можешь самостоятельно просить дать комментарии у своих коллег. Такая история поможет найти узкие места и проблемы в твоем общении.
4. Рефлексируй. После каждой сложной беседы или переговоров постарайся проанализировать, что пошло не так и как можно было действовать лучше.
Потрать свое время и свои силы на развитие своих навыков коммуникации. Это обязательно пригодится как на работе, так и в жизни
#evolution
Коммуникация - ключевой элемент работы в команде. Ты будешь постоянно взаимодействовать с другими людьми, в том числе и с теми, кто далек от технической части. Именно поэтому тебе и важно прокачивать свои навыки общения.
Самое главное - это излагать мысли ясно и кратко. Не используй сложную техническую терминологию и старайся объяснять так, чтобы тебя мог понять даже твой сосед, который работает водителем такси. Еще один крутой навык - уметь слушать собеседника. Старайся даже не просто слушать, а слышать и понимать его точку зрения. И, наконец, будь открытым к обратной связи и критике. Ты должен быть гибким и должен быть готов менять стиль общения в зависимости от ситуации.
Как можно развивать свои навыки общения:
1. Читай книги по коммуникации. Они помогут разобраться в психологии общения и дадут полезные рекомендации.
2. Практикуйся. Чем больше ты общаешься с другими людьми, тем больше понимаешь, как лучше формулировать свои мысли.
3. Прислушивайся к обратной связи. Ты даже можешь самостоятельно просить дать комментарии у своих коллег. Такая история поможет найти узкие места и проблемы в твоем общении.
4. Рефлексируй. После каждой сложной беседы или переговоров постарайся проанализировать, что пошло не так и как можно было действовать лучше.
Потрать свое время и свои силы на развитие своих навыков коммуникации. Это обязательно пригодится как на работе, так и в жизни
#evolution
💪 Научись принимать неудачи
Факапы — неотъемлемая часть жизни разработчика. Ты столкнешься с багами, ошибками и проблемами, которые потребуют от тебя гибкости и поиска новых решений. Принятие неудач и обучение на своих ошибках — ключевая часть нашей работы, если, конечно, ты хочешь развиваться как разработчик.
Сделав факап, не опускай руки, а попробуй найти причину его возникновения и извлеки урок. Спроси себя, что ты мог бы сделать иначе и как ты можешь предотвратить подобные ситуации в будущем. Помни, что ошибки — это не просто возможность, но и необходимость для твоего роста и развития. Принимая неудачу, ты прокачиваешься в своей области и становишься увереннее. Это поможет тебе в решении будущих, более сложных задач.
И что еще важно: твой руководитель прекрасно понимает, что ошибки случаются. Ты же не думаешь, что он сам никогда не факапил? Не нужно скрывать их, лучше попроси помощи и совета и попытайся вместе проанализировать произошедшее.
#evolution
Факапы — неотъемлемая часть жизни разработчика. Ты столкнешься с багами, ошибками и проблемами, которые потребуют от тебя гибкости и поиска новых решений. Принятие неудач и обучение на своих ошибках — ключевая часть нашей работы, если, конечно, ты хочешь развиваться как разработчик.
Сделав факап, не опускай руки, а попробуй найти причину его возникновения и извлеки урок. Спроси себя, что ты мог бы сделать иначе и как ты можешь предотвратить подобные ситуации в будущем. Помни, что ошибки — это не просто возможность, но и необходимость для твоего роста и развития. Принимая неудачу, ты прокачиваешься в своей области и становишься увереннее. Это поможет тебе в решении будущих, более сложных задач.
И что еще важно: твой руководитель прекрасно понимает, что ошибки случаются. Ты же не думаешь, что он сам никогда не факапил? Не нужно скрывать их, лучше попроси помощи и совета и попытайся вместе проанализировать произошедшее.
#evolution
💡Чтобы прокачать себя как разработчика, нужно всего лишь...
...писать как можно больше кода. Чем больше ты практикуешься, тем лучше ты изучаешь синтаксис и подходы языка разработки. Ты научишься общепринятым паттернам и с каждым разом будешь писать более чистый и эффективный код.
Однако важно помнить, что написание кода — это не только о количестве, но и о качестве. Если есть возможность — делай задачи не на скорость, а на качество. Быстро выполнить и отдать задачу - это хорошо, но это негативно скажется и на дальнейшем масштабировании твоего проекта, и на твоем развитии. Удели время написанию чистого, хорошо организованного, легко читаемого и понятного кода.
Ниже несколько сайтов, которые помогут тебе в развитии хард-скиллов:
1. LeetCode
- Алгоритмы и структуры данных.
- Подходит как для подготовки к собеседованиям, так и для улучшения навыков в алгоритмах.
2. Codewars
- Задачи создаются сообществом и делятся по сложности.
- Позволяет тренироваться на разных языках программирования.
3. Codecademy
- Интерактивные курсы по различным языкам и технологиям.
- Отличное место для начинающих.
4. Exercism
- Задачи на различные языки программирования с акцентом на менторство.
- Участники могут получать обратную связь от опытных разработчиков.
Эти ресурсы помогут тебе не только улучшить свои навыки программирования, но и понять, в каких областях ты чувствуешь себя наиболее уверенно и что еще стоит изучить.
В комментариях пиши ресурсы, которые ты тоже мог бы порекомендовать как джуниорам, так и опытным разработчикам.
#evolution
Однако важно помнить, что написание кода — это не только о количестве, но и о качестве. Если есть возможность — делай задачи не на скорость, а на качество. Быстро выполнить и отдать задачу - это хорошо, но это негативно скажется и на дальнейшем масштабировании твоего проекта, и на твоем развитии. Удели время написанию чистого, хорошо организованного, легко читаемого и понятного кода.
Ниже несколько сайтов, которые помогут тебе в развитии хард-скиллов:
1. LeetCode
- Алгоритмы и структуры данных.
- Подходит как для подготовки к собеседованиям, так и для улучшения навыков в алгоритмах.
2. Codewars
- Задачи создаются сообществом и делятся по сложности.
- Позволяет тренироваться на разных языках программирования.
3. Codecademy
- Интерактивные курсы по различным языкам и технологиям.
- Отличное место для начинающих.
4. Exercism
- Задачи на различные языки программирования с акцентом на менторство.
- Участники могут получать обратную связь от опытных разработчиков.
Эти ресурсы помогут тебе не только улучшить свои навыки программирования, но и понять, в каких областях ты чувствуешь себя наиболее уверенно и что еще стоит изучить.
В комментариях пиши ресурсы, которые ты тоже мог бы порекомендовать как джуниорам, так и опытным разработчикам.
#evolution
💡 Соблюдай баланс работы и отдыха
Мир IT движется и развивается максимально быстро и интенсивно. Работа в этой сфере часто бывает напряженной и полной стресса. Именно поэтому важно не забывать уделять время отдыху.
Почему мы часто изматываем сами себя и выгораем?
- Мы не можем вовремя остановиться. Мы можем сидеть над задачкой часами, до тех пор, пока ее "не победим". Хотя, как правило, утром, на свежую голову, мы находим решение за полчаса.
- Наше внимание распыляется. Мы живем в мире информационного шума и огромного количества раздражителей. Нужно уметь привести наше сознание в состояние покоя и умиротворения.
Ты удивишься, но регулярные перерывы в течение рабочего дня могут улучшить твою продуктивность. Например, короткие прогулки на свежем воздухе помогут "перезагрузить" мозг.
Своим сотрудникам я постоянно говорю о том, что работая 8 часов без перерыва ты покажешь эффективность меньше, чем если ты будешь работать чуть меньше, но будешь периодически отдыхать.
Также не забывай уделять время своим увлечениям и интересам вне работы. Это поможет тебе поддерживать баланс между работой и личной жизнью. Заботясь о себе, ты будешь лучше справляться с работой. Ты будешь подходить к решению задач и проблем с ясным умом и свежим взглядом.
Что спасает конкретно меня? Это семья и свежий воздух, спорт и настолки. Все это позволяет отвлечься от рутины и немного "переключить" мозг в режим отдыха.
Что я бы НЕ стал рекомендовать. Сериалы, ютубчик и компьютерные игры. Все же от экрана надо отдыхать. Соблюдаю ли я это - тоже нет. Возможно данный пост - акт самовнушения в пользу life-balance. =)
В общем - не забывай отдыхать, и твой код скажет тебе спасибо.
Расскажи, как ты справляешься с выгоранием и стрессом, и можешь ли посоветовать что-то из своего опыта?
#evolution
Мир IT движется и развивается максимально быстро и интенсивно. Работа в этой сфере часто бывает напряженной и полной стресса. Именно поэтому важно не забывать уделять время отдыху.
Почему мы часто изматываем сами себя и выгораем?
- Мы не можем вовремя остановиться. Мы можем сидеть над задачкой часами, до тех пор, пока ее "не победим". Хотя, как правило, утром, на свежую голову, мы находим решение за полчаса.
- Наше внимание распыляется. Мы живем в мире информационного шума и огромного количества раздражителей. Нужно уметь привести наше сознание в состояние покоя и умиротворения.
Ты удивишься, но регулярные перерывы в течение рабочего дня могут улучшить твою продуктивность. Например, короткие прогулки на свежем воздухе помогут "перезагрузить" мозг.
Своим сотрудникам я постоянно говорю о том, что работая 8 часов без перерыва ты покажешь эффективность меньше, чем если ты будешь работать чуть меньше, но будешь периодически отдыхать.
Также не забывай уделять время своим увлечениям и интересам вне работы. Это поможет тебе поддерживать баланс между работой и личной жизнью. Заботясь о себе, ты будешь лучше справляться с работой. Ты будешь подходить к решению задач и проблем с ясным умом и свежим взглядом.
Что спасает конкретно меня? Это семья и свежий воздух, спорт и настолки. Все это позволяет отвлечься от рутины и немного "переключить" мозг в режим отдыха.
Что я бы НЕ стал рекомендовать. Сериалы, ютубчик и компьютерные игры. Все же от экрана надо отдыхать. Соблюдаю ли я это - тоже нет. Возможно данный пост - акт самовнушения в пользу life-balance. =)
В общем - не забывай отдыхать, и твой код скажет тебе спасибо.
Расскажи, как ты справляешься с выгоранием и стрессом, и можешь ли посоветовать что-то из своего опыта?
#evolution
Планирование - ключ к успеху
Для разработчика важно с самого начала своей карьеры развивать хорошие привычки. Одной из них является планирование, которое может значительно повлиять на твою продуктивность и эффективность. Нужно уметь оценивать и планировать рабочие задачи, встречи с коллегами, да и не рабочие дела тоже.
Планирование поможет тебе не только стать более эффективным, но и завоевать доверие окружающих, так как ты сможешь работать с их ожиданиями. Твои коллеги и заказчики будут понимать сроки старта и(или) выполнения задач. Самому же тебе будет легче разгребать рутину - ты будешь подходить к задачам более систематизированно, да и задачи не будут теряться в потоке происходящего.
Сейчас есть куча инструментов для планирования. Электронные календари помогут тебе следить за важными событиями и задачами. Приложения для создания списков задач, например, Trello или Todoist, помогут структурировать свои действия и контролировать выполнение поставленных задач. Также не забывай о технике Pomodoro, которая может помочь разбить рабочий процесс на короткие интервалы, улучшая концентрацию и продуктивность.
Сам я использую следующие инструменты:
- Trello для работы с задачами в "потоке"
- Jira + Kanban - планирование задач на краткосрок
- Календарь - для планирования встреч и брони слотов
- Бумажный блокнот (да, я старовер) - для быстрой записи важной информации для последующего ее переноса
- Когда занимался только разработкой - использовал Pomodoro, очень помогало оставаться в тонусе
В комментариях пиши, какие инструменты юзаешь сам. Мне, да и другим подписчикам, это будет интересно.
Что еще можно добавить?
Будет круто, если ты сможешь ставить себе крупные (на долгосрок) и еженедельные цели, будешь отслеживать свой прогресс и собирать обратную связь от коллег для постоянного улучшения своих результатов. Приучая себя к планированию и активному использованию инструментов тайм-менеджмента, ты создашь прочную основу для своей карьеры в качестве программиста и обеспечишь себе долгосрочный успех.
#evolution
Для разработчика важно с самого начала своей карьеры развивать хорошие привычки. Одной из них является планирование, которое может значительно повлиять на твою продуктивность и эффективность. Нужно уметь оценивать и планировать рабочие задачи, встречи с коллегами, да и не рабочие дела тоже.
Планирование поможет тебе не только стать более эффективным, но и завоевать доверие окружающих, так как ты сможешь работать с их ожиданиями. Твои коллеги и заказчики будут понимать сроки старта и(или) выполнения задач. Самому же тебе будет легче разгребать рутину - ты будешь подходить к задачам более систематизированно, да и задачи не будут теряться в потоке происходящего.
Сейчас есть куча инструментов для планирования. Электронные календари помогут тебе следить за важными событиями и задачами. Приложения для создания списков задач, например, Trello или Todoist, помогут структурировать свои действия и контролировать выполнение поставленных задач. Также не забывай о технике Pomodoro, которая может помочь разбить рабочий процесс на короткие интервалы, улучшая концентрацию и продуктивность.
Сам я использую следующие инструменты:
- Trello для работы с задачами в "потоке"
- Jira + Kanban - планирование задач на краткосрок
- Календарь - для планирования встреч и брони слотов
- Бумажный блокнот (да, я старовер) - для быстрой записи важной информации для последующего ее переноса
- Когда занимался только разработкой - использовал Pomodoro, очень помогало оставаться в тонусе
В комментариях пиши, какие инструменты юзаешь сам. Мне, да и другим подписчикам, это будет интересно.
Что еще можно добавить?
Будет круто, если ты сможешь ставить себе крупные (на долгосрок) и еженедельные цели, будешь отслеживать свой прогресс и собирать обратную связь от коллег для постоянного улучшения своих результатов. Приучая себя к планированию и активному использованию инструментов тайм-менеджмента, ты создашь прочную основу для своей карьеры в качестве программиста и обеспечишь себе долгосрочный успех.
#evolution
🤖 vs 👤: Профдеформация
Перестань мыслить абсолютными величинами. Нам, как ИТшникам, проще думать в категориях "да-нет" или "черное-белое". Да, компьютеры работают на основе двоичных вычислений. Результатом каждого логического элемента является 0 или 1. Человеческое мышление гораздо сложнее и гибче. Но мы - не компьютеры. Мы - люди. Каждое правило имеет исключение, каждое решение может иметь свои компромиссы.
Часто мы стремимся упростить сложные вещи, классифицировать их как "хорошие" или "плохие", "правильные" или "неправильные". Это помогает нам быстро принимать решения, особенно в стрессовых или кризисных ситуациях. Нужно понимать, что такой подход ограничивает наше видение проблемы и порой мешает видеть всю картинку целиком.
Подходы и решения проблем, всегда имеют свои плюсы и минусы. И это касается не только нашей работы, но и жизни. Именно поэтому очень важно анализировать ситуацию и применять тот или иной подход в зависимости от конкретных обстоятельств.
Понимаю ли я это? Да.
Пытаюсь ли я большинство решений принять, пытаясь применить алгоритмы? Тоже да =(
Но уже меньше.
#evolution
Перестань мыслить абсолютными величинами. Нам, как ИТшникам, проще думать в категориях "да-нет" или "черное-белое". Да, компьютеры работают на основе двоичных вычислений. Результатом каждого логического элемента является 0 или 1. Человеческое мышление гораздо сложнее и гибче. Но мы - не компьютеры. Мы - люди. Каждое правило имеет исключение, каждое решение может иметь свои компромиссы.
Часто мы стремимся упростить сложные вещи, классифицировать их как "хорошие" или "плохие", "правильные" или "неправильные". Это помогает нам быстро принимать решения, особенно в стрессовых или кризисных ситуациях. Нужно понимать, что такой подход ограничивает наше видение проблемы и порой мешает видеть всю картинку целиком.
Подходы и решения проблем, всегда имеют свои плюсы и минусы. И это касается не только нашей работы, но и жизни. Именно поэтому очень важно анализировать ситуацию и применять тот или иной подход в зависимости от конкретных обстоятельств.
Понимаю ли я это? Да.
Пытаюсь ли я большинство решений принять, пытаясь применить алгоритмы? Тоже да =(
🔧 Отладка
Начинающие разработчики часто недооценивают отладку. Когда ты пишешь код, очевидно, что ты думаешь о том, как он будет работать. Но столь же важно предусмотреть, как он может НЕ РАБОТАТЬ, и как ты будешь проводить отладку уже в условиях реальной эксплуатации.
Отладка - это не только об ошибках. Это о понимании поведения кода в разных кейсах и в разных условиях. Отладка помогает обеспечить стабильность и надёжность приложения. Она может помочь в решении вопросов, касающихся безопасности, поскольку позволяет обнаруживать потенциальные уязвимости.
Оставляй за собой "следы" - логи и комментарии в коде. Это поможет в будущем не только тебе, но и тем, кто будет работать с кодом после тебя.
Кроме того, стоит разобраться в инструментах тестирования. Потрать время, чтобы разобраться c DevTools, Inspector, системой онлайн аналитики (например Firebase Crashlytics) и это окупится, когда дело дойдет до масштабирования или поиска неочевидных ошибок.
Помимо этих инструментов, важно писать тесты (юнит, виджет, голден и т.п.) и использовать систему контроля версий, чтобы отслеживать, когда и какие изменения приводят к ошибкам.
Помни, что отладка - это не просто поиск и исправление багов. Это забота о будущем твоего проекта. Уделяй этому достаточно времени и внимания, и ты увидишь, как твой код становится надёжнее, а твоя работа - проще и приятнее.
#evolution
Начинающие разработчики часто недооценивают отладку. Когда ты пишешь код, очевидно, что ты думаешь о том, как он будет работать. Но столь же важно предусмотреть, как он может НЕ РАБОТАТЬ, и как ты будешь проводить отладку уже в условиях реальной эксплуатации.
Отладка - это не только об ошибках. Это о понимании поведения кода в разных кейсах и в разных условиях. Отладка помогает обеспечить стабильность и надёжность приложения. Она может помочь в решении вопросов, касающихся безопасности, поскольку позволяет обнаруживать потенциальные уязвимости.
Оставляй за собой "следы" - логи и комментарии в коде. Это поможет в будущем не только тебе, но и тем, кто будет работать с кодом после тебя.
Кроме того, стоит разобраться в инструментах тестирования. Потрать время, чтобы разобраться c DevTools, Inspector, системой онлайн аналитики (например Firebase Crashlytics) и это окупится, когда дело дойдет до масштабирования или поиска неочевидных ошибок.
Помимо этих инструментов, важно писать тесты (юнит, виджет, голден и т.п.) и использовать систему контроля версий, чтобы отслеживать, когда и какие изменения приводят к ошибкам.
Помни, что отладка - это не просто поиск и исправление багов. Это забота о будущем твоего проекта. Уделяй этому достаточно времени и внимания, и ты увидишь, как твой код становится надёжнее, а твоя работа - проще и приятнее.
#evolution
🕒 Проекты и сроки
Сегодня хотелось бы затронуть тему, которая актуальна для многих из нас - сроки на проектах.
Сейчас мы живем в мире, где темп жизни крайне высок. Естественно, это накладывает отпечатки и на нашу работу - сроки постоянно поджимают, заказчики хотят продукт, как можно быстрее, на старте проекта все пытаются найти способ, как подвинуть дедлайн ближе. Но потом мы сталкиваемся с ситуацией, когда какие-то вещи занимают больше времени, чем мы планировали. (И это не только в ИТ, но и в жизни)
Мы пытаемся что-то улучшить в проекте, добавить какие-то интересные фичи или детали. Но любой шаг приводит и к сдвигу сроков.
И что же с этим делать?
- Закладывай риски. Если ты считаешь, что вот тут что-то может пойти не так, то будь уверен, что оно именно так и пойдет. Всегда будь готов к тому, что проект может затянуться.
- Работай с ожиданиями. Всегда держи в курсе всех участников проекта о текущем статусе и возможных проблемах. Если ты видишь, что не успеваешь, то не надо это скрывать. Другие участники команды, твое руководство и заказчик должны понимать актуальные сроки, даже если это их расстроит.
- Будь гибким. Научись быстро перестраиваться и перераспределять ресурсы в ответ на меняющиеся обстоятельства. Как и в первом пункте - если ты думаешь, что что-то может поменяться (в функционале, взаймодействию, архитектуре, требованиям), лучше считать, что оно поменяется, и планируй свои действия в том или ином случае. Это как проговаривание диалогов в голове, только ДО диалогов, а не ПОСЛЕ.
Помни, что главное - не безупречность каждого шага, а способность адаптироваться и двигаться вперед, несмотря на трудности.
(с) Джейсон Стетхем
#evolution
Сегодня хотелось бы затронуть тему, которая актуальна для многих из нас - сроки на проектах.
Сейчас мы живем в мире, где темп жизни крайне высок. Естественно, это накладывает отпечатки и на нашу работу - сроки постоянно поджимают, заказчики хотят продукт, как можно быстрее, на старте проекта все пытаются найти способ, как подвинуть дедлайн ближе. Но потом мы сталкиваемся с ситуацией, когда какие-то вещи занимают больше времени, чем мы планировали. (И это не только в ИТ, но и в жизни)
Мы пытаемся что-то улучшить в проекте, добавить какие-то интересные фичи или детали. Но любой шаг приводит и к сдвигу сроков.
И что же с этим делать?
- Закладывай риски. Если ты считаешь, что вот тут что-то может пойти не так, то будь уверен, что оно именно так и пойдет. Всегда будь готов к тому, что проект может затянуться.
- Работай с ожиданиями. Всегда держи в курсе всех участников проекта о текущем статусе и возможных проблемах. Если ты видишь, что не успеваешь, то не надо это скрывать. Другие участники команды, твое руководство и заказчик должны понимать актуальные сроки, даже если это их расстроит.
- Будь гибким. Научись быстро перестраиваться и перераспределять ресурсы в ответ на меняющиеся обстоятельства. Как и в первом пункте - если ты думаешь, что что-то может поменяться (в функционале, взаймодействию, архитектуре, требованиям), лучше считать, что оно поменяется, и планируй свои действия в том или ином случае. Это как проговаривание диалогов в голове, только ДО диалогов, а не ПОСЛЕ.
Помни, что главное - не безупречность каждого шага, а способность адаптироваться и двигаться вперед, несмотря на трудности.
#evolution
Как удержать проект под контролем и не дать ему раздуться?
Сегодня пост больше для ТимЛидов, наверное.
А суть у него простая - очень важно уметь управлять объемом работы в проектах. Что это значит на практике?
- Умей говоить "НЕТ". Часто в процессе работы над проектом возникают новые идеи и предложения, которые могут значительно расширить его объем. Важно уметь говорить "нет" или предлагать альтернативы, которые не будут затягивать сроки.
- Прозрачность в коммуникациях. Если всё же решаешь внести изменения, не забудь сообщить заказчику или начальнику, как это повлияет на сроки и качество проекта. Важно, чтобы все участники были в курсе изменений и их последствий.
- А как успеть в срок? Иногда стоит посмотреть, что можно убрать из проекта без ущерба для качества, или что можно сделать уже после запуска. Оптимален подход "fast follow" - когда сначала запускаем основную часть, а затем дорабатываем детали.
Главное - помнить, что успешный проект - это не тот, который включает в себя максимум идей, а тот, который реализован качественно и в срок. Управляя объемом работы, ты не только защищаешь проект, но и помогаешь команде сфокусироваться на главном.
#evolution
Сегодня пост больше для ТимЛидов, наверное.
А суть у него простая - очень важно уметь управлять объемом работы в проектах. Что это значит на практике?
- Умей говоить "НЕТ". Часто в процессе работы над проектом возникают новые идеи и предложения, которые могут значительно расширить его объем. Важно уметь говорить "нет" или предлагать альтернативы, которые не будут затягивать сроки.
- Прозрачность в коммуникациях. Если всё же решаешь внести изменения, не забудь сообщить заказчику или начальнику, как это повлияет на сроки и качество проекта. Важно, чтобы все участники были в курсе изменений и их последствий.
- А как успеть в срок? Иногда стоит посмотреть, что можно убрать из проекта без ущерба для качества, или что можно сделать уже после запуска. Оптимален подход "fast follow" - когда сначала запускаем основную часть, а затем дорабатываем детали.
Главное - помнить, что успешный проект - это не тот, который включает в себя максимум идей, а тот, который реализован качественно и в срок. Управляя объемом работы, ты не только защищаешь проект, но и помогаешь команде сфокусироваться на главном.
#evolution
💡 Проблемы и решения
Как перевести критику и наличие проблемы в реальные действия? Важно не только говорить о проблемах, но и находить пути их решения. Я достаточно часто сталкиваюсь с тем, что проблемы не решаются, а латаются. И все чаще меня это начинает раздражать.
Так как не злить в такой ситуации своего руководителя? )
Думай аналитически. Если есть проблема, не пытайся повесить на нее заплатку, чтобы починить. Попробуй докопаться до истины - а что приводит к этой ошибке? А как устроен этот функционал, что ошибка вообще появляется? ЭТО МАСТ ХЕВ!
Декомпозируй задачу. Начни с разбивки большой проблемы на мелкие части. Это упрощает поиск решений и делает задачу менее страшной.
Ну и не забывай поработать на перспективу =)
Как я писал раньше - в ИТ, если ты стоишь на месте, ты движешься назад. Не останавливайся в своем профессиональном росте. Ходи на конференции, общайся с комьюнити, ведь общение с коллегами открывает новые перспективы и дарит идеи. Ну и попробуй заглянуть в "Чистый код" Мартина. Ну, или если ты руководитель, то в "Как пасти котов" Рейнвотера.
Анализируй чужой опыт. Изучение успешных и неудачных проектов помогает понять, какие стратегии работают, а какие нет.
Использование методологий. Тут я долго думал, стоит ли это писать тут. Очень крупная история, о которой нужно писать отдельный пост. Но, дабы ты не хейтил меня в комментариях (или наоборот хейтил) отмечу.
Scrum, Kanban и пр. - отличные инструменты для эффективной работы над проектами. Они помогают организовать процесс, сосредоточиться на важном и быстро реагировать на изменения.
Помни, что на пути к успеху важно не только видеть проблемы, но и активно искать пути их решения.
Поделись в комментариях своим опытом.
Что тебе помогало решить максимально сложную или неочевидную проблему? Насколько тебе помогает твой прошлый опыт? Какой должен быть баланс в техопыте и умении подойти аналитически по твоему мнению?
#evolution
Как перевести критику и наличие проблемы в реальные действия? Важно не только говорить о проблемах, но и находить пути их решения. Я достаточно часто сталкиваюсь с тем, что проблемы не решаются, а латаются. И все чаще меня это начинает раздражать.
Так как не злить в такой ситуации своего руководителя? )
Думай аналитически. Если есть проблема, не пытайся повесить на нее заплатку, чтобы починить. Попробуй докопаться до истины - а что приводит к этой ошибке? А как устроен этот функционал, что ошибка вообще появляется? ЭТО МАСТ ХЕВ!
Декомпозируй задачу. Начни с разбивки большой проблемы на мелкие части. Это упрощает поиск решений и делает задачу менее страшной.
Ну и не забывай поработать на перспективу =)
Как я писал раньше - в ИТ, если ты стоишь на месте, ты движешься назад. Не останавливайся в своем профессиональном росте. Ходи на конференции, общайся с комьюнити, ведь общение с коллегами открывает новые перспективы и дарит идеи. Ну и попробуй заглянуть в "Чистый код" Мартина. Ну, или если ты руководитель, то в "Как пасти котов" Рейнвотера.
Анализируй чужой опыт. Изучение успешных и неудачных проектов помогает понять, какие стратегии работают, а какие нет.
Использование методологий. Тут я долго думал, стоит ли это писать тут. Очень крупная история, о которой нужно писать отдельный пост. Но, дабы ты не хейтил меня в комментариях (или наоборот хейтил) отмечу.
Scrum, Kanban и пр. - отличные инструменты для эффективной работы над проектами. Они помогают организовать процесс, сосредоточиться на важном и быстро реагировать на изменения.
Помни, что на пути к успеху важно не только видеть проблемы, но и активно искать пути их решения.
Поделись в комментариях своим опытом.
Что тебе помогало решить максимально сложную или неочевидную проблему? Насколько тебе помогает твой прошлый опыт? Какой должен быть баланс в техопыте и умении подойти аналитически по твоему мнению?
#evolution
💪 Ответственность
Я часто слышу "Эта часть кода не моя", "Ошибка не на моей стороне", "Только тут мой код". Важно осознавать, что наша ответственность выходит далеко за рамки просто написания кода своими ручками.
Когда ты работаешь над проектом, ты не просто создаешь отдельные функции или модули. Ты создаешь систему, которая будет работать как единое целое. И задача каждого разработчика - убедиться, что эта система работает безупречно на всех этапах.
Это значит, что ты должен думать не только о том, как написать эффективный код, но и о том, как он взаимодействует с другими элементами системы, как он влияет на производительность, безопасность и удобство пользователя (и другого разработчика).
Старайся с самого начала думать как архитектор, а не только как исполнитель. Старайся предвидеть потенциальные проблемы. Думай о том, как улучшить систему, чтобы она могла соответствовать меняющимся требованиям и ожиданиям. Думай о том, что твой код может быть масштабирован.
Не бойся брать на себя ответственность за целостность проекта и его успех. Именно от этого зависит качество твоей работы (и работы команды) и твой профессиональный рост.
#evolution
Я часто слышу "Эта часть кода не моя", "Ошибка не на моей стороне", "Только тут мой код". Важно осознавать, что наша ответственность выходит далеко за рамки просто написания кода своими ручками.
Когда ты работаешь над проектом, ты не просто создаешь отдельные функции или модули. Ты создаешь систему, которая будет работать как единое целое. И задача каждого разработчика - убедиться, что эта система работает безупречно на всех этапах.
Это значит, что ты должен думать не только о том, как написать эффективный код, но и о том, как он взаимодействует с другими элементами системы, как он влияет на производительность, безопасность и удобство пользователя (и другого разработчика).
Старайся с самого начала думать как архитектор, а не только как исполнитель. Старайся предвидеть потенциальные проблемы. Думай о том, как улучшить систему, чтобы она могла соответствовать меняющимся требованиям и ожиданиям. Думай о том, что твой код может быть масштабирован.
Не бойся брать на себя ответственность за целостность проекта и его успех. Именно от этого зависит качество твоей работы (и работы команды) и твой профессиональный рост.
#evolution
Мы часто зарываемся в свою работу, забывая, что являемся частью большой команды, где каждый вносит свой вклад в общий успех. Да, наша работа – это создание или развитие приложения, которое, возможно, является ключевым продуктом компании. Но это не означает, что наша роль ограничивается только кодом.
Помни, что в компании есть и другие отделы: sale, PR, финансы и т.д. Зная, как они работают, какие задачи решают, ты получишь более полное представление о работе всей компании. Это позволит тебе лучше понимать те решения, которые принимаются на разных уровнях, и увидеть, как твоя работа вписывается в общую картину. Ну и, конечно, позволит тебе генерировать собственные идеи, что не останется незамеченным
Все это актуально даже в стартапах, где каждый сотрудник – это важная часть механизма. Понимание процессов вне твой прямой специализации может сыграть ключевую роль в успехе всего проекта.
Не стесняйся заводить разговоры с коллегами из других отделов, узнавай о их работе, делись своими знаниями о твоей. Такой обмен опытом не только расширяет кругозор, но и способствует более эффективной и гармоничной работе всей команды.
Уверен, что такой подход поможет тебе стать не только лучше в техническом плане, но и даст более глубокое понимание бизнес-процессов в целом.
#evolution
Please open Telegram to view this post
VIEW IN TELEGRAM
- Не задавай глупые вопросы!
Часто это мы слышим в детстве, в школе, а иногда и в университете. Но так ли это применимо на нашей работе?
Когда ты находишься в своей компании и обсуждаешь за чашечкой кофе проект или какую-то технологию, у тебя может возникнуть вопрос, который покажется простым или глупым. Но, как показывает практика, на самом деле, кто-то еще может задаваться таким же вопросом. Не стесняйся спрашивать!
Откровенно говоря, никто и не вспомнит, что именно ты спросил, но знания, которые ты получишь, могут быть запредельно полезными.
Задавая вопрос в рабочем чате, ты делаешь хорошо не только для себя, но и для всей команды. Иногда именно такие "глупые" вопросы приводят к самым важным разъяснениям и деталям по твоей таске.
Запомни такую штуку: у нас нет глупых вопросов, есть только недостаток информации.
Я много раз видел, как разрабочик постеснялся задать вопрос, сделал, как понял, а потом это привело к каким-то поистине фатальным последствиям. Когда детали задачи, которые показались ему очевидными и глупыми, выяснялись, на фиксы могло уйти в два-три раза больше времени, чем заняла сама задача, так как на созданной архитектуре могли отладится и другие разработчики или даже команды.
Так что я хочу сказать?
- Задавай глупые вопросы!
#evolution
Часто это мы слышим в детстве, в школе, а иногда и в университете. Но так ли это применимо на нашей работе?
Когда ты находишься в своей компании и обсуждаешь за чашечкой кофе проект или какую-то технологию, у тебя может возникнуть вопрос, который покажется простым или глупым. Но, как показывает практика, на самом деле, кто-то еще может задаваться таким же вопросом. Не стесняйся спрашивать!
Откровенно говоря, никто и не вспомнит, что именно ты спросил, но знания, которые ты получишь, могут быть запредельно полезными.
Задавая вопрос в рабочем чате, ты делаешь хорошо не только для себя, но и для всей команды. Иногда именно такие "глупые" вопросы приводят к самым важным разъяснениям и деталям по твоей таске.
Запомни такую штуку: у нас нет глупых вопросов, есть только недостаток информации.
Я много раз видел, как разрабочик постеснялся задать вопрос, сделал, как понял, а потом это привело к каким-то поистине фатальным последствиям. Когда детали задачи, которые показались ему очевидными и глупыми, выяснялись, на фиксы могло уйти в два-три раза больше времени, чем заняла сама задача, так как на созданной архитектуре могли отладится и другие разработчики или даже команды.
Так что я хочу сказать?
- Задавай глупые вопросы!
#evolution
Техдолг
Мы часто думаем, что всегда найдётся время вернуться и исправить все недочеты в коде. Но давай будем честными - в большинстве случаев, мы до него или добираемся очень не скоро, или не добираемся вообще. Чаще всего код, который мы пишем сегодня, остаётся с нами на долгое время (навсегда). Старайся не оставлять за собой техдолг начиная с самого старта разработки.
Понимаю, что в мире идеальных сроков и неограниченных ресурсов мы бы все писали чистый, идеальный код. Но реальность такова, что иногда приходится идти на компромиссы. Важно уметь правильно приоритезировать: какие недочеты в коде мы готовы терпеть в ближайшем будущем, а какие нужно исправить немедленно.
Помни, что технический долг — это не просто плохо написанный код. Это любые решения, которые упрощают жизнь сейчас, но могут создать большие проблемы в будущем. Думай о нем, как о чем-то, к чему-ты НИКОГДА не вернешься, пока не наступит момент, когда без глобального пересмотра архитектуры не обойтись.
#evolution
Мы часто думаем, что всегда найдётся время вернуться и исправить все недочеты в коде. Но давай будем честными - в большинстве случаев, мы до него или добираемся очень не скоро, или не добираемся вообще. Чаще всего код, который мы пишем сегодня, остаётся с нами на долгое время (навсегда). Старайся не оставлять за собой техдолг начиная с самого старта разработки.
Понимаю, что в мире идеальных сроков и неограниченных ресурсов мы бы все писали чистый, идеальный код. Но реальность такова, что иногда приходится идти на компромиссы. Важно уметь правильно приоритезировать: какие недочеты в коде мы готовы терпеть в ближайшем будущем, а какие нужно исправить немедленно.
Помни, что технический долг — это не просто плохо написанный код. Это любые решения, которые упрощают жизнь сейчас, но могут создать большие проблемы в будущем. Думай о нем, как о чем-то, к чему-ты НИКОГДА не вернешься, пока не наступит момент, когда без глобального пересмотра архитектуры не обойтись.
#evolution
Удаленка
К удаленке и компании, и работники, зачастую относятся неоднозначно. Некоторые организации отменяют удалёнку, другие, наоборот, вообще закрывают офисы.
Удалённая работа имеет как положительные, так и отрицательные стороны. Лично я работаю из дома гораздо больше и интенсивнее, чем это делал в офисе, но я знаю людей, которые работают "на лайте". Кто-то совмещает работу дома с играми или фитнессом. Кому-то не нравится сам процесс поездки в офис. Кому-то сложно(мне) общаться постоянно в мите/зуме.
Удалённая работа позволяет экономить время на дорогу, а это дает больше времени для себя и семьи. Но при этом, если семья находится тоже дома, то внимание начинает дико распыляться.
Тут мое краткое имхо:
- Работать дома - неплохо
- Заниматься управленкой дома - так себе
И да. Фактически на удаленке люди делятся на две стороны:
- Целеустремленные и самостоятельные. Чем меньше их трогаешь, тем эффективнее они работают.
- Ленивые гедонисты. Они обуза, которую команда тащит за собой, как груз. Если тебе кажется, что такой чувак сейчас сидит играет, спит или гуляет, то скорее всего - тебе не кажется.
Со стороны компаний тоже все неоднозначно.
Работники на удаленке обходятся дешевле и она позволяет привлекать крутых работников со всего мира.
Кому удаленка подходит (имхо):
- Компании с хорошим, но не выдающимся продуктом, которым нужны мощные спецы
- Малые компании и стартапы, которые вышли "на плато", для экономии финансов
Кому удаленка не подходит (имхо):
- Стартапы на ранней стадии требуют интенсивной работы и быстрого принятия решений
- Быстро растущие компании-лидеры на рынке, которым важна координация внутри и очень быстрое принятие решений.
По опыту и те, и другие, в большинстве своем, используют гибридный график.
И еще немного моего имхо, и, так сказать, финальное слово.
Не надо возводить в абсолют все сказанное.
Удалённая работа — не универсальное решение, подходящее всем без исключения. Как и работа в офисе.
Просто будь гибким и взвешивай лично свои плюсы и минусы по отношению к ней.
#evolution
К удаленке и компании, и работники, зачастую относятся неоднозначно. Некоторые организации отменяют удалёнку, другие, наоборот, вообще закрывают офисы.
Удалённая работа имеет как положительные, так и отрицательные стороны. Лично я работаю из дома гораздо больше и интенсивнее, чем это делал в офисе, но я знаю людей, которые работают "на лайте". Кто-то совмещает работу дома с играми или фитнессом. Кому-то не нравится сам процесс поездки в офис. Кому-то сложно
Удалённая работа позволяет экономить время на дорогу, а это дает больше времени для себя и семьи. Но при этом, если семья находится тоже дома, то внимание начинает дико распыляться.
Тут мое краткое имхо:
- Работать дома - неплохо
- Заниматься управленкой дома - так себе
И да. Фактически на удаленке люди делятся на две стороны:
- Целеустремленные и самостоятельные. Чем меньше их трогаешь, тем эффективнее они работают.
- Ленивые гедонисты. Они обуза, которую команда тащит за собой, как груз. Если тебе кажется, что такой чувак сейчас сидит играет, спит или гуляет, то скорее всего - тебе не кажется.
Со стороны компаний тоже все неоднозначно.
Работники на удаленке обходятся дешевле и она позволяет привлекать крутых работников со всего мира.
Кому удаленка подходит (имхо):
- Компании с хорошим, но не выдающимся продуктом, которым нужны мощные спецы
- Малые компании и стартапы, которые вышли "на плато", для экономии финансов
Кому удаленка не подходит (имхо):
- Стартапы на ранней стадии требуют интенсивной работы и быстрого принятия решений
- Быстро растущие компании-лидеры на рынке, которым важна координация внутри и очень быстрое принятие решений.
По опыту и те, и другие, в большинстве своем, используют гибридный график.
И еще немного моего имхо, и, так сказать, финальное слово.
Не надо возводить в абсолют все сказанное.
Удалённая работа — не универсальное решение, подходящее всем без исключения. Как и работа в офисе.
Просто будь гибким и взвешивай лично свои плюсы и минусы по отношению к ней.
#evolution
Сегодня я хочу рассказать об инструменте Git, который может очень помочь тебе при отладке. Этот инструмент называется git bisect.
Возможно, ты уже сталкивался с ситуацией, когда нужно было выяснить, после какого изменения в коде в проекте появилась ошибка. Перебирать все коммиты вручную – не самое приятное занятие, особенно если ошибка была допущена давно. Именно здесь на помощь приходит git bisect.
Принцип работы git bisect основан на методе бинарного поиска. Тебе лишь нужно указать "хороший" коммит, в котором ошибка точно отсутствует, и "плохой" коммит, в котором ошибка уже есть. Git bisect автоматически проведет тебя через процесс бинарного поиска между этими двумя точками, помогая постепенно сужать круг подозреваемых, пока не найдет коммит, начиная с которого баг стал проявляться.
Использование git bisect начинается с запуска команды git bisect start, после чего ты помечаешь известные «хороший» и «плохой» коммиты соответствующими командами. Git затем предложит тебе проверить определенный коммит, и ты сообщишь, есть данная ошибка в нем или нет. Процесс повторяется, пока не будет найден коммит, который и послужил причиной появления бага.
Ссылка на доку: [тык]
#evolution
Please open Telegram to view this post
VIEW IN TELEGRAM
Lottie vs. Rive
Сегодня хочу рассказать о двух популярных инструмента анимации — Lottie и Rive. Оба инструмента позволяют создавать и интегрировать анимацию в приложения, но имеют свои особенности и преимущества.
Lottie
Lottie — это инструмент для создания и интеграции анимированных векторных изображений (анимаций) в приложения. Он основан на формате Adobe After Effects, который позволяет создавать сложные анимации с использованием различных эффектов и переходов. Lottie поддерживает множество форматов файлов, включая JSON.
Плюсы:
1. Простота использования: Благодаря поддержке JSON формата, lottie становится доступным для разработчиков любого уровня
2. Кроссплатформенность: его простота и универсальность позволяет использовать одни и те же анимации на разных платформах.
3. Широкое комьюнити: это влечет за собой и большое количество готовых анимаций в сети
4. Гибкость: Lottie позволяет настраивать анимацию и эффекты, что даёт больше контроля над результатом.
Минусы:
1. Ограничения по сложности: Lottie не подходит для очень сложных анимаций с большим количеством элементов и эффектов.
2. Производительность: В некоторых случаях Lottie может потреблять больше ресурсов, что влияет на производительность приложений, особенно на устройствах с низкой производительностью.
Rive
Rive – это мощный инструмент для создания интерактивных анимаций и дизайна. Он позволяет разработчикам создавать более сложные и интерактивные анимации прямо в редакторе Rive и легко интегрировать их в приложения. Rive использует собственный формат файлов, который обеспечивает более высокую производительность и качество анимации.
Плюсы:
1. Интерактивность: Rive поддерживает интерактивные анимации, которые могут реагировать на пользовательские действия.
2. Мощный редактор: Он интуитивно понятный и функциональный и не принуждает погружаться в дебри разработки
3. Производительность: Rive обеспечивает быструю и плавную анимацию благодаря своему формату файлов
Минусы:
1. Сложность использования: Rive имеет более сложный интерфейс, чем Lottie, что может затруднить его использование для новичков.
2. Размер файлов: Анимации, созданные в Rive, могут быть более тяжелыми, что увеличивает размер приложения.
В итоге, выбор между Lottie и Rive зависит от конкретных потребностей вашего проекта. Если вам нужны простые и легкие анимации с быстрой интеграцией, Lottie будет отличным выбором. Для сложных, интерактивных и высокопроизводительных анимаций лучше подойдет Rive.
Напоминаю:
ТЕХНОЛОГИЯ ДОЛЖНА ЧЕТКО РЕШАТЬ ПОСТАВЛЕННЫЕ ЗАДАЧИ И НЕ СОЗДАВАТЬ ПРОБЛЕМ
#evolution
Сегодня хочу рассказать о двух популярных инструмента анимации — Lottie и Rive. Оба инструмента позволяют создавать и интегрировать анимацию в приложения, но имеют свои особенности и преимущества.
Lottie
Lottie — это инструмент для создания и интеграции анимированных векторных изображений (анимаций) в приложения. Он основан на формате Adobe After Effects, который позволяет создавать сложные анимации с использованием различных эффектов и переходов. Lottie поддерживает множество форматов файлов, включая JSON.
Плюсы:
1. Простота использования: Благодаря поддержке JSON формата, lottie становится доступным для разработчиков любого уровня
2. Кроссплатформенность: его простота и универсальность позволяет использовать одни и те же анимации на разных платформах.
3. Широкое комьюнити: это влечет за собой и большое количество готовых анимаций в сети
4. Гибкость: Lottie позволяет настраивать анимацию и эффекты, что даёт больше контроля над результатом.
Минусы:
1. Ограничения по сложности: Lottie не подходит для очень сложных анимаций с большим количеством элементов и эффектов.
2. Производительность: В некоторых случаях Lottie может потреблять больше ресурсов, что влияет на производительность приложений, особенно на устройствах с низкой производительностью.
Rive
Rive – это мощный инструмент для создания интерактивных анимаций и дизайна. Он позволяет разработчикам создавать более сложные и интерактивные анимации прямо в редакторе Rive и легко интегрировать их в приложения. Rive использует собственный формат файлов, который обеспечивает более высокую производительность и качество анимации.
Плюсы:
1. Интерактивность: Rive поддерживает интерактивные анимации, которые могут реагировать на пользовательские действия.
2. Мощный редактор: Он интуитивно понятный и функциональный и не принуждает погружаться в дебри разработки
3. Производительность: Rive обеспечивает быструю и плавную анимацию благодаря своему формату файлов
Минусы:
1. Сложность использования: Rive имеет более сложный интерфейс, чем Lottie, что может затруднить его использование для новичков.
2. Размер файлов: Анимации, созданные в Rive, могут быть более тяжелыми, что увеличивает размер приложения.
В итоге, выбор между Lottie и Rive зависит от конкретных потребностей вашего проекта. Если вам нужны простые и легкие анимации с быстрой интеграцией, Lottie будет отличным выбором. Для сложных, интерактивных и высокопроизводительных анимаций лучше подойдет Rive.
Напоминаю:
ТЕХНОЛОГИЯ ДОЛЖНА ЧЕТКО РЕШАТЬ ПОСТАВЛЕННЫЕ ЗАДАЧИ И НЕ СОЗДАВАТЬ ПРОБЛЕМ
#evolution
Как стать экспертом в любой области?
Стать экспертом в разработке или в любой другой области — это не просто вопрос времени или освоения новых знаний. Это тернистый путь, который требует постоянного погружения в новую сферу.
Есть такая модель обучения, которая называется «4 стадии компетентности».
Эта модель, предложенная Ноэлем Берчем еще в 70х годах, помогает понять путь от начинающего до эксперта. Она описывает этапы, через которые проходит каждый человек при освоении нового навыка.
Стадия 1: Неосознанная некомпетентность
На этом этапе ты не знаешь, что ты чего-то не знаешь (неизвестное незнание). Ты можешь иметь завышенную уверенность в своих навыках, так как ещё не осознаёшь, как много не понимаешь. Этот эффект особенно ярко выражен на начальных этапах, когда кажется, что всё легко, но на самом деле ты ещё не осознаёшь сложности задач.
Например: джун может не знать о важности систем контроля версий или думать, что программирование — это просто написание кода.
Как двигаться дальше: Задай себе вопрос: «Что мне нужно узнать?». Главное на этом этапе — начать обучение. Учи базу, читай про лучшие практики и создавай простые проекты. Так ты начнешь понимать, что и сколько ещё нужно изучить.
Стадия 2: Осознанная некомпетентность
Здесь начинается настоящее обучение. Ты осознаёшь, что не обладаешь нужными знаниями и навыками, но начинаешь активно работать над этим. На этом этапе может возникнуть синдром самозванца, но важно помнить, что это нормальный процесс.
Например: после потери изменений в коде джун осознаёт важность системы контроля версий, но ещё не умеет ею пользоваться.
Как двигаться дальше: Ставь четкие цели, смотри митапы, принимай участие в open-source проектах и ищи наставников среди опытных разработчиков. Помни, что каждый эксперт когда-то был новичком.
Стадия 3: Осознанная компетентность
Ты уже обладаешь необходимыми навыками, но тебе нужно сознательно контролировать свои действия, чтобы всё выполнять правильно. Это требует больше времени и усилий, но ты уже достаточно уверенно работаешь с чем-то новым.
Например: сотрудник освоил основы Git — умеет делать коммиты, создавать ветки и объединять их, но всё ещё нужно обращаться к документации.
Как двигаться дальше: Продолжай задавать себе вопрос: «Как сделать это более эффективно?». Поставь перед собой цель работать над сложными проектами, которые требуют большей практики. Если уделять этому хотя бы 1-2 часа в день, через несколько месяцев можно заметно улучшить свои навыки.
Стадия 4: Неосознанная компетентность
Ты настолько хорошо овладел навыком, что выполняешь действия на автомате, практически не задумываясь.
Наример: опытный разработчик свободно использует Git, решает конфликты слияния и даже помогает другим, не задумываясь о каждом шаге. Всё это происходит на почти бессознательном уровне благодаря большому опыту.
Как двигаться дальше: Даже на этом уровне важно продолжать учиться и совершенствоваться. Единственный путь к такому уровню — практика, практика и ещё раз практика.
Прогресс через стадии компетентности
По мере продвижения по этим стадиям ты можешь столкнуться с «Парадоксом эксперта». Чем больше ты узнаёшь, тем больше осознаёшь, как много ещё предстоит изучить. Это может вызывать синдром самозванца, особенно на стадии осознанной компетентности, когда навыков уже много, но уверенность в себе ещё не полностью сформирована.
Чтобы справиться с этим, важно признавать, что синдром самозванца — это часть процесса роста. Регулярно оценивай свои успехи, ищи обратную связь от других и помогай начинающим, чтобы закрепить свои знания.
В конечном итоге, путь к мастерству требует времени, терпения и постоянной практики.
#evolution
Стать экспертом в разработке или в любой другой области — это не просто вопрос времени или освоения новых знаний. Это тернистый путь, который требует постоянного погружения в новую сферу.
Есть такая модель обучения, которая называется «4 стадии компетентности».
Эта модель, предложенная Ноэлем Берчем еще в 70х годах, помогает понять путь от начинающего до эксперта. Она описывает этапы, через которые проходит каждый человек при освоении нового навыка.
Стадия 1: Неосознанная некомпетентность
На этом этапе ты не знаешь, что ты чего-то не знаешь (неизвестное незнание). Ты можешь иметь завышенную уверенность в своих навыках, так как ещё не осознаёшь, как много не понимаешь. Этот эффект особенно ярко выражен на начальных этапах, когда кажется, что всё легко, но на самом деле ты ещё не осознаёшь сложности задач.
Например: джун может не знать о важности систем контроля версий или думать, что программирование — это просто написание кода.
Как двигаться дальше: Задай себе вопрос: «Что мне нужно узнать?». Главное на этом этапе — начать обучение. Учи базу, читай про лучшие практики и создавай простые проекты. Так ты начнешь понимать, что и сколько ещё нужно изучить.
Стадия 2: Осознанная некомпетентность
Здесь начинается настоящее обучение. Ты осознаёшь, что не обладаешь нужными знаниями и навыками, но начинаешь активно работать над этим. На этом этапе может возникнуть синдром самозванца, но важно помнить, что это нормальный процесс.
Например: после потери изменений в коде джун осознаёт важность системы контроля версий, но ещё не умеет ею пользоваться.
Как двигаться дальше: Ставь четкие цели, смотри митапы, принимай участие в open-source проектах и ищи наставников среди опытных разработчиков. Помни, что каждый эксперт когда-то был новичком.
Стадия 3: Осознанная компетентность
Ты уже обладаешь необходимыми навыками, но тебе нужно сознательно контролировать свои действия, чтобы всё выполнять правильно. Это требует больше времени и усилий, но ты уже достаточно уверенно работаешь с чем-то новым.
Например: сотрудник освоил основы Git — умеет делать коммиты, создавать ветки и объединять их, но всё ещё нужно обращаться к документации.
Как двигаться дальше: Продолжай задавать себе вопрос: «Как сделать это более эффективно?». Поставь перед собой цель работать над сложными проектами, которые требуют большей практики. Если уделять этому хотя бы 1-2 часа в день, через несколько месяцев можно заметно улучшить свои навыки.
Стадия 4: Неосознанная компетентность
Ты настолько хорошо овладел навыком, что выполняешь действия на автомате, практически не задумываясь.
Наример: опытный разработчик свободно использует Git, решает конфликты слияния и даже помогает другим, не задумываясь о каждом шаге. Всё это происходит на почти бессознательном уровне благодаря большому опыту.
Как двигаться дальше: Даже на этом уровне важно продолжать учиться и совершенствоваться. Единственный путь к такому уровню — практика, практика и ещё раз практика.
Прогресс через стадии компетентности
По мере продвижения по этим стадиям ты можешь столкнуться с «Парадоксом эксперта». Чем больше ты узнаёшь, тем больше осознаёшь, как много ещё предстоит изучить. Это может вызывать синдром самозванца, особенно на стадии осознанной компетентности, когда навыков уже много, но уверенность в себе ещё не полностью сформирована.
Чтобы справиться с этим, важно признавать, что синдром самозванца — это часть процесса роста. Регулярно оценивай свои успехи, ищи обратную связь от других и помогай начинающим, чтобы закрепить свои знания.
В конечном итоге, путь к мастерству требует времени, терпения и постоянной практики.
#evolution
Миф о «гениальном программисте»
Спойлер, если тебе лень читать:
Нет гения, который бы написал продукт в одиночку, а сотрудничество и открытость — ключ к успеху в разработке.
Если не лень, читай ниже
Почему самое существование этого мифа - вредно?
Дай угадаю - ты хочешь казаться умными и боишься выглядеть глупо перед коллегами. Из-за этого ты иногда прятался в "пещерах", работал с кодом в одиночку и не спешил делиться результатами до тех пор, пока они не станут идеальными. Но мы оба же понимаем, что это только тормозило твой прогресс.
Успешный продукт — это результат коллективного труда, а не усилий одного "гения". Даже великие проекты, которые мы приписываем отдельным людям, на самом деле создавались командами. Работа в одиночку ограничивает твой рост и развитие проекта. А "гении", которые создали продукт, зачастую являются сильными бизнесменами и маркетологами.
Как преодолеть страх и начать работать в команде?
1. Расслабься. Пойми, что цель — не показать свою "гениальность", а создать лучший продукт вместе с командой.
2. Обратная связь. Не бойся показывать свой код и получать критику. Это возможность учиться и совершенствоваться.
3. Неудача == опыт. Ошибки — это нормально. Главное — учиться на них и двигаться дальше.
4. Будь открытым к новым идеям. Как бы это странно не звучало, но позволь другим влиять на твои решения. Ты и не заметишь, когда сам станешь генератором идей.
5. Практикуйся и делись знаниями. Чем больше ты взаимодействуешь с коллегами, тем быстрее растешь как профи.
А в какой момент вообще стоит показывать свой код, свой проект или делиться знаниями?
Не жди, пока проект станет идеальным. Если у тебя сформированы основные идеи, основная концепция, и еще есть пространство для развития - значит пора! Это поможет не только избежать ошибок, но и сделать проект лучше.
Итого:
Миф о гениальном программисте — всего лишь миф. Настоящий успех приходит через сотрудничество, открытость и готовность учиться у других. Не бойся делиться своими идеями и кодом.
Make code great again!
P.S. Исключения из правил есть, но они на то и исключения. Кроме того они связаны с огромными рисками, так что забываем про Stardew Valley )
#evolution
Спойлер, если тебе лень читать:
Если не лень, читай ниже
Почему самое существование этого мифа - вредно?
Дай угадаю - ты хочешь казаться умными и боишься выглядеть глупо перед коллегами. Из-за этого ты иногда прятался в "пещерах", работал с кодом в одиночку и не спешил делиться результатами до тех пор, пока они не станут идеальными. Но мы оба же понимаем, что это только тормозило твой прогресс.
Успешный продукт — это результат коллективного труда, а не усилий одного "гения". Даже великие проекты, которые мы приписываем отдельным людям, на самом деле создавались командами. Работа в одиночку ограничивает твой рост и развитие проекта. А "гении", которые создали продукт, зачастую являются сильными бизнесменами и маркетологами.
Как преодолеть страх и начать работать в команде?
1. Расслабься. Пойми, что цель — не показать свою "гениальность", а создать лучший продукт вместе с командой.
2. Обратная связь. Не бойся показывать свой код и получать критику. Это возможность учиться и совершенствоваться.
3. Неудача == опыт. Ошибки — это нормально. Главное — учиться на них и двигаться дальше.
4. Будь открытым к новым идеям. Как бы это странно не звучало, но позволь другим влиять на твои решения. Ты и не заметишь, когда сам станешь генератором идей.
5. Практикуйся и делись знаниями. Чем больше ты взаимодействуешь с коллегами, тем быстрее растешь как профи.
А в какой момент вообще стоит показывать свой код, свой проект или делиться знаниями?
Не жди, пока проект станет идеальным. Если у тебя сформированы основные идеи, основная концепция, и еще есть пространство для развития - значит пора! Это поможет не только избежать ошибок, но и сделать проект лучше.
Итого:
Миф о гениальном программисте — всего лишь миф. Настоящий успех приходит через сотрудничество, открытость и готовность учиться у других. Не бойся делиться своими идеями и кодом.
Make code great again!
P.S. Исключения из правил есть, но они на то и исключения. Кроме того они связаны с огромными рисками, так что забываем про Stardew Valley )
#evolution
Синдром самозванца
Очевидно, что ты уже слышал об этом термине, но если вдруг нет — это явление, когда человек не может принять свои достижения и постоянно сомневается в своих способностях. И что самое интересное, этот синдром может проявляться у людей на любом этапе их карьеры, независимо от опыта, уровня знаний или статуса.
В разработке мы часто сталкиваемся с ошибками. Это абсолютно нормально, ведь наша работа — это процесс постоянного поиска решений. Но вот в чём проблема: люди с синдромом самозванца фокусируются только на своих неудачах, забывая о победах. Им кажется, что все вокруг намного лучше, а их собственные успехи — это просто везение.
Это приводит к тому, что "самозванцы" боятся делиться своими знаниями, избегают публичных выступлений и даже отказываются от возможностей карьерного роста. Представь, ты можешь быть отличным программистом, но боишься показать свои навыки, думая, что остальные увидят, какой ты «некомпетентный».
И это касается не только новичков. Я бы сказал, что в основном не новичков. Люди, которые у которых уже большое количество опыта, тоже страдают от синдрома самозванца. Многие из них думают, что они обманывают своих коллег, и однажды их «раскроют».
Однако есть способы борьбы с этим чувством. Один из них — окружить себя людьми, которые смогут дать конструктивную обратную связь и помочь увидеть твои настоящие достижения. И провалы. Важно научиться объективно оценивать свой прогресс, например, фиксировать свои успехи, ставить реальные цели и отмечать даже маленькие победы.
Ещё один полезный совет — помогать другим. Когда ты делишься своими знаниями и опытом, это не только помогает окружающим, но и укрепляет твою уверенность. Помни, что нет идеальных людей, и даже самые опытные разработчики делают ошибки.
Итого:
Веря в себя ты сможешь и расти как профессионал, и наслаждаться процессом. Главное — продолжать двигаться вперёд и не бояться ошибаться
#evolution
Очевидно, что ты уже слышал об этом термине, но если вдруг нет — это явление, когда человек не может принять свои достижения и постоянно сомневается в своих способностях. И что самое интересное, этот синдром может проявляться у людей на любом этапе их карьеры, независимо от опыта, уровня знаний или статуса.
В разработке мы часто сталкиваемся с ошибками. Это абсолютно нормально, ведь наша работа — это процесс постоянного поиска решений. Но вот в чём проблема: люди с синдромом самозванца фокусируются только на своих неудачах, забывая о победах. Им кажется, что все вокруг намного лучше, а их собственные успехи — это просто везение.
Это приводит к тому, что "самозванцы" боятся делиться своими знаниями, избегают публичных выступлений и даже отказываются от возможностей карьерного роста. Представь, ты можешь быть отличным программистом, но боишься показать свои навыки, думая, что остальные увидят, какой ты «некомпетентный».
И это касается не только новичков. Я бы сказал, что в основном не новичков. Люди, которые у которых уже большое количество опыта, тоже страдают от синдрома самозванца. Многие из них думают, что они обманывают своих коллег, и однажды их «раскроют».
Однако есть способы борьбы с этим чувством. Один из них — окружить себя людьми, которые смогут дать конструктивную обратную связь и помочь увидеть твои настоящие достижения. И провалы. Важно научиться объективно оценивать свой прогресс, например, фиксировать свои успехи, ставить реальные цели и отмечать даже маленькие победы.
Ещё один полезный совет — помогать другим. Когда ты делишься своими знаниями и опытом, это не только помогает окружающим, но и укрепляет твою уверенность. Помни, что нет идеальных людей, и даже самые опытные разработчики делают ошибки.
Итого:
Веря в себя ты сможешь и расти как профессионал, и наслаждаться процессом. Главное — продолжать двигаться вперёд и не бояться ошибаться
#evolution