Теоретик Антон
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.
В этом посте я буду защищать позицию теоретика, а именно: инструкцию читать всё же иногда надо.
Наверное, каждый программист проходил через этот цикл: скопировал кусок кода со stackoverflow или "hello, world"-туториала, чуть допилил напильником - и заработало. “Ура, я знаю новую технологию!” Это окрыляет, и кажется, что теперь можно всё изучать сразу на практике.
Однако это работает мягко говоря не всегда. Прямо скажем, это ОК только для простых и средне-простых задач. Возьмём, к примеру, Rust, и его заморочки с памятью. При разработке вы сразу столкнетесь с выбором. Что использовать: &T или &mut T? А может, Cell<T>? Box<T>? Rc<Refcell<T>> ? А чем Mutex<T> отличается от Arc<Mutex<T>>? Тысячи их, таких вопросов.
Т.е. на практике это будет выглядеть так: вы пробуете что-то написать, компилятор Rust говорит “ты дебил”. Пробуете другое - компилятор говорит, что всё равно дебил, попробуй еще раз. Stackoverflow поможет очень слабо. Нужно читать Rust Book, без вариантов.
Еще пример. Вы захотели написать свой язык программирования. Где-то слышали, что надо сначала сделать парсер, который преобразует текст в AST-дерево. Попробуйте это сделать интуитивно, без теории. Это совсем непросто. Как описать грамматику? Что такое сканнер (токенайзер)? Как сделать сканнер быстрым? Там огромное количество вопросов, которые придется переизобретать. Гораздо быстрее будет прочесть книжку, например от создателя Dart: https://craftinginterpreters.com/contents.html
Вообще, в сложных задачах есть всего два пути, изобретать самому или пользоваться изобретениями других людей. Изобретать самому интереснее, но в 100 раз дольше.
Иногда нужно знать теорию в смежных областях, не только в самой IT. Взять, например, математическую статистику. Сколько нужно экспериментов, чтобы достоверно сказать, что такой способ размещения рекламы на сайте наиболее выгоден?
Некоторые вещи не столь конкретны, но не менее важны. Например, куча говнокода возникает только из-за того, что человек не удосужился прочесть ни одной книги про качество кода. Ты с ним говоришь как будто на разных языках. Даже очевидные вещи, например, god object или слишком большой и запутанный метод, могут вызывать споры на тему “а надо ли это упрощать”.
В общем, рано, рано еще теорию списывать со счетов. Без теории запросто можно красить кнопки, но вот создать что-то по настоящему сложное или ответственное - увы.
Ошибка выжившего в ИТ
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.
Что это такое?
Википедия говорит, что систематическая ошибка выжившего — разновидность систематической ошибки отбора, когда по одной группе объектов данных много, а по другой — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших».
Где это в ИТ?
Да почти везде. Почти любой хайп вокруг технологии и рабочих процессов пляшет на ошибке выжившего. А множественные конференции и доклады задают ритм.
Ведь конференции - это в большинстве своем истории успеха:
- Мы перешли на микросервисы и волосы стали шелковистые;
- Мы внедрили скрам и стали работать в 7.5 тысяч раз лучше;
- Мы переписали всё на реакт и теперь сайт открывается быстрее, чем вы успели об этом подумать.
Всё это искажает у слушателя объективное представление о плюсах и минусах, заставляя его верить, что если у кого-то получилось (у кого-то в другой команде, компании, стране, проекте, и т. д.), то и у него 146% получится.
Что делать?
Я не спорю с тем, что истории успеха важны, нужны и бывают полезны.
Просто хочется, чтобы почаще рассказывали на конференциях еще и истории неудач, как микросервисы завалили проект (кстати про микросервисы один хороший доклад, рассматривающий обильно негативные стороны, я видел), как скрам накрутил бюрократизации и истрепал нервы команде, как говнокод, на что бы ни был переписан, всё равно остается говнокодом.
А еще неплохо было бы нам всем постараться критически мыслить, стараясь продумать, разглядеть и спрогнозировать возможные подводные камни, а не просто слепо доверять какому-то докладчику и кидаться повторять всё 1 в 1.
Пример
Знаю компанию, где выписали себе за дорого аджайл коуча / скрам мастера, который на волне хайпа и успешных историй про скрам пришел, срубил кучу денег, переформатировал команды, процессы, навел шороху и… в результате стало как минимум не лучше. Time to market не увеличился, пропускная способность разработки не выросла, touch time не вырос. Только еще и команда теперь недовольна.
Итог
Как всегда, я выступаю за критическое мышление и анализ вашей конкретной ситуации, а не просто бездумное повторение за кем-то.
Ну и, если у вас есть истории фейлов – не бойтесь ими делиться. Возможно, вы кому-то этим сильно поможете.
О моем консалтинге
Чуть меньше года назад я анонсировал свои услуги по консалтингу https://antonov-dev.ru/consulting и сегодня хотел бы немного рассказать о том, что из этого получается.
Почему я это начал?
Помогать людям разрешать их проблемы, если у меня есть для этого необходимые знания, мне всегда нравилось. Постоянно в тех или иных комьюнити я старался отвечать людям на вопросы, давать какие-то советы, помогать по мере возможностей.
Например, еще задолго до консалтинга я в этих своих альтруистических порывах помог со сменой работы на более интересную/высокооплачиваемую примерно десятку человек.
Где-то помогал рекомендациями (если искренне мог порекомендовать человека), где-то советами куда пойти, как торговаться, сколько просить и т. д.
По мере своего профессионального развития, приобретения житейского опыта и прыгания по граблям эта потребность и возможность помогать вышла на более, так скажем, качественный уровень.
Однако появилась и проблема.
Часто, желая лучшего, вкладываешь кучу времени и сил в добрые дружеские советы, а в результате человек относится к такой халяве как к чему-то несерьезному. В итоге получается, что время и силы я потратил, а толковые советы выкинули в мусорку.
И я взял на себя смелость попробовать (после пары-тройки бесплатных демо консультаций) сделать это в платном серьезном формате.
Результат меня очень приятно удивил. Люди, приходящие на платные консультации, оказались очень мотивированными. Не просто на халяву послушал, поныл, пожаловался, забил и пошел дальше ныть и жаловаться.
Те, кто тратит деньги на консультацию, больше ценят всё то, что им дается, больше следуют советам, более деятельные и настроены на результат. И определенный позитивный результат они получают, что меня несказанно радует.
Сочиняешь тоже. Небось гребешь баблище, инфоцыган
Откровенно говоря, заработок с моих консультаций пока невелик. Куда больше моё сердечко греет то, что я помогаю людям разбираться с их проблемами и двигаться к лучшей жизни, чем небольшие деньги, которые я заработал.
Конечно, я надеюсь, что когда-то этот доход ощутимо вырастет, но пока что есть, то есть.
Не инфоцыганю
Так как консалтинг – это, в первую очередь, моя репутация в профессии, то я отношусь к этому очень внимательно и ответственно.
Всегда перед консультацией стараюсь понять проблему человека, чтобы прикинуть, смогу ли я ему/ей быть полезен. Никогда не беру никакой предоплаты вперед. Всегда утверждаю, что если наше общение оказалось бесполезным, я не смог никак помочь с проблемой, то могу просто не брать деньги за консультацию.
Я ценю консалтинг, как оплачиваемую помощь в решении проблем. Где-то это могут быть конкретные рецепты, где-то советы, в какую сторону копать, где-то рекомендации куда слать резюме, где-то сведение контактов с нужными людьми, потенциальными работодателями, исполнителями и т. д. Для меня главное, чтобы это была какая-то реальная помощь, чтобы человек не ушел с мыслью «блин, зря деньги потратил, ничего полезного». За безрезультатную работу не считаю этичным брать деньги (привет, остеопат, к которому я ходил прошлым летом).
Ну и реальные отзывы о своей работе так же размещаю у себя на страничке про консалтинг.
Чтобы понятно было, что примерно на консультациях творится, а при каких-то сомнениях – обратиться к моим клиентам и спросить у них, что и как, стоило ли оно того, и вообще реальный это отзыв или фейк.
Итог
Пока мне нравится то, что я делаю и куда это всё движется. Нравится, что есть хоть небольшая, но финансовая отдача (это не может не мотивировать), нравится, что люди довольны и отзываются позитивно (привет, Олег, увеличивший зп сначала в 3 раза, а потом еще в полтора). Когда рекомендуют мои услуги своим знакомым – я начинаю думать, что ну прям точно делаю это не зря🙂
В обозримом будущем напишу пост о статистике (конечно же анонимной) того, кто по каким вопросам обращается и как часто, сколько это занимает времени, чем в среднем заканчивается и т. д.
Чуть меньше года назад я анонсировал свои услуги по консалтингу https://antonov-dev.ru/consulting и сегодня хотел бы немного рассказать о том, что из этого получается.
Почему я это начал?
Помогать людям разрешать их проблемы, если у меня есть для этого необходимые знания, мне всегда нравилось. Постоянно в тех или иных комьюнити я старался отвечать людям на вопросы, давать какие-то советы, помогать по мере возможностей.
Например, еще задолго до консалтинга я в этих своих альтруистических порывах помог со сменой работы на более интересную/высокооплачиваемую примерно десятку человек.
Где-то помогал рекомендациями (если искренне мог порекомендовать человека), где-то советами куда пойти, как торговаться, сколько просить и т. д.
По мере своего профессионального развития, приобретения житейского опыта и прыгания по граблям эта потребность и возможность помогать вышла на более, так скажем, качественный уровень.
Однако появилась и проблема.
Часто, желая лучшего, вкладываешь кучу времени и сил в добрые дружеские советы, а в результате человек относится к такой халяве как к чему-то несерьезному. В итоге получается, что время и силы я потратил, а толковые советы выкинули в мусорку.
И я взял на себя смелость попробовать (после пары-тройки бесплатных демо консультаций) сделать это в платном серьезном формате.
Результат меня очень приятно удивил. Люди, приходящие на платные консультации, оказались очень мотивированными. Не просто на халяву послушал, поныл, пожаловался, забил и пошел дальше ныть и жаловаться.
Те, кто тратит деньги на консультацию, больше ценят всё то, что им дается, больше следуют советам, более деятельные и настроены на результат. И определенный позитивный результат они получают, что меня несказанно радует.
Сочиняешь тоже. Небось гребешь баблище, инфоцыган
Откровенно говоря, заработок с моих консультаций пока невелик. Куда больше моё сердечко греет то, что я помогаю людям разбираться с их проблемами и двигаться к лучшей жизни, чем небольшие деньги, которые я заработал.
Конечно, я надеюсь, что когда-то этот доход ощутимо вырастет, но пока что есть, то есть.
Не инфоцыганю
Так как консалтинг – это, в первую очередь, моя репутация в профессии, то я отношусь к этому очень внимательно и ответственно.
Всегда перед консультацией стараюсь понять проблему человека, чтобы прикинуть, смогу ли я ему/ей быть полезен. Никогда не беру никакой предоплаты вперед. Всегда утверждаю, что если наше общение оказалось бесполезным, я не смог никак помочь с проблемой, то могу просто не брать деньги за консультацию.
Я ценю консалтинг, как оплачиваемую помощь в решении проблем. Где-то это могут быть конкретные рецепты, где-то советы, в какую сторону копать, где-то рекомендации куда слать резюме, где-то сведение контактов с нужными людьми, потенциальными работодателями, исполнителями и т. д. Для меня главное, чтобы это была какая-то реальная помощь, чтобы человек не ушел с мыслью «блин, зря деньги потратил, ничего полезного». За безрезультатную работу не считаю этичным брать деньги (привет, остеопат, к которому я ходил прошлым летом).
Ну и реальные отзывы о своей работе так же размещаю у себя на страничке про консалтинг.
Чтобы понятно было, что примерно на консультациях творится, а при каких-то сомнениях – обратиться к моим клиентам и спросить у них, что и как, стоило ли оно того, и вообще реальный это отзыв или фейк.
Итог
Пока мне нравится то, что я делаю и куда это всё движется. Нравится, что есть хоть небольшая, но финансовая отдача (это не может не мотивировать), нравится, что люди довольны и отзываются позитивно (привет, Олег, увеличивший зп сначала в 3 раза, а потом еще в полтора). Когда рекомендуют мои услуги своим знакомым – я начинаю думать, что ну прям точно делаю это не зря🙂
В обозримом будущем напишу пост о статистике (конечно же анонимной) того, кто по каким вопросам обращается и как часто, сколько это занимает времени, чем в среднем заканчивается и т. д.
antonov-dev.ru
ИТ консультации
Евгений Антонов. ИТ консультации
❤1
Тимлид, делегируй!
Очень часто сталкиваюсь с неумением/нежеланием тимлидов делегировать свои вчерашние дела с прошлой должности. Особенно у начинающих ребят.
Суть проблемы
В большинстве случаев тимлид – это вчерашний хороший разработчик. Он годами писал много кода и релизил конкретные фичи.
Сегодня ему говорят: «Ты теперь тимлид и не просто точишь одну гайку как раньше, а шурупишь весь механизм. ВПЕРЕД!». В его мозгу это звучит как «делать надо еще больше, фронт работ еще шире».
В итоге он продолжает писать код и релизить важные фичи, а под вечер грустить, что менеджерские задачи никак не продвигаются.
Дальше особо ответственные понимают, что можно же просто овертаймить, чтобы уж точно всё успеть (а всё не успеешь никогда).
Это ведет к моральному и физическому истощению, выгоранию и, возможно, вчерашний хороший разработчик, уставший сегодня от такого темпа, завтра покинет компанию.
Что делать?
Одно из действенных средств – делегировать. И понимать, что вас сделали тимлидом для того, чтобы вы решали в первую очередь задачи этой позиции. Код писать может любой из ваших коллег, а тимлид – он один на команду и должен сосредоточиться на своих задачах.
Следовательно, нужно освободить себе время для этого, делегировав уже не такие важные рутинные дела другим сотрудникам.
Это поможет и вам сосредоточиться на нужной работе, и в других сотрудниках будет взращивать больше самостоятельности и ответственности: если раньше какими-то задачами занимались только вы, а теперь вы научили других, то теперь они смогут справляться сами (возможно не сразу).
Пример
Недавно консультировал свежеиспеченного тимлида. Он весь в огне, мало что успевает, делает 100% руками того, что делал, и еще хотел бы 100% лидовских дел успевать.
Порекомендовал ему побольше делегировать и сосредоточиться на той работе, для которой его и сделали лидом. В итоге рутину он делегировал, начал разгребать лидские дела, всё перестало гореть так сильно. В целом он доволен результатом 🙂
Итог
Не бойтесь чуть-чуть отпустить контроль всех на свете задач. Делегируйте, освобождайте себе время, помогайте другим расти, сосредоточьтесь на тех обязанностях, ради которых вас и сделали тимлидом.
Помните, что делегировать – это не стыдно, не зазорно, и это не перекладывание проблем на других людей. Это хорошее, полезное дело, если употребляется осознанно и добросовестно.
Не загоняйте себя и помните, что нельзя сделать все дела, которые хочется сделать. Однако можно выбрать и сделать самые важные из них.
Очень часто сталкиваюсь с неумением/нежеланием тимлидов делегировать свои вчерашние дела с прошлой должности. Особенно у начинающих ребят.
Суть проблемы
В большинстве случаев тимлид – это вчерашний хороший разработчик. Он годами писал много кода и релизил конкретные фичи.
Сегодня ему говорят: «Ты теперь тимлид и не просто точишь одну гайку как раньше, а шурупишь весь механизм. ВПЕРЕД!». В его мозгу это звучит как «делать надо еще больше, фронт работ еще шире».
В итоге он продолжает писать код и релизить важные фичи, а под вечер грустить, что менеджерские задачи никак не продвигаются.
Дальше особо ответственные понимают, что можно же просто овертаймить, чтобы уж точно всё успеть (а всё не успеешь никогда).
Это ведет к моральному и физическому истощению, выгоранию и, возможно, вчерашний хороший разработчик, уставший сегодня от такого темпа, завтра покинет компанию.
Что делать?
Одно из действенных средств – делегировать. И понимать, что вас сделали тимлидом для того, чтобы вы решали в первую очередь задачи этой позиции. Код писать может любой из ваших коллег, а тимлид – он один на команду и должен сосредоточиться на своих задачах.
Следовательно, нужно освободить себе время для этого, делегировав уже не такие важные рутинные дела другим сотрудникам.
Это поможет и вам сосредоточиться на нужной работе, и в других сотрудниках будет взращивать больше самостоятельности и ответственности: если раньше какими-то задачами занимались только вы, а теперь вы научили других, то теперь они смогут справляться сами (возможно не сразу).
Пример
Недавно консультировал свежеиспеченного тимлида. Он весь в огне, мало что успевает, делает 100% руками того, что делал, и еще хотел бы 100% лидовских дел успевать.
Порекомендовал ему побольше делегировать и сосредоточиться на той работе, для которой его и сделали лидом. В итоге рутину он делегировал, начал разгребать лидские дела, всё перестало гореть так сильно. В целом он доволен результатом 🙂
Итог
Не бойтесь чуть-чуть отпустить контроль всех на свете задач. Делегируйте, освобождайте себе время, помогайте другим расти, сосредоточьтесь на тех обязанностях, ради которых вас и сделали тимлидом.
Помните, что делегировать – это не стыдно, не зазорно, и это не перекладывание проблем на других людей. Это хорошее, полезное дело, если употребляется осознанно и добросовестно.
Не загоняйте себя и помните, что нельзя сделать все дела, которые хочется сделать. Однако можно выбрать и сделать самые важные из них.
T-shape за свой счет
Иногда ко мне за консультациями обращаются не рядовые специалисты или менеджеры, а владельцы бизнеса. В них меня очень приятно удивляет и даже восхищает их желание и умение разбираться во всём на свете, что хоть как-то связано с их бизнесом.
Это не программерский «илитный» тишейп, когда «я знаю бэкенд, могу написать вью компонент, а еще ансибл скрипт по перекладыванию файлов написал».
Это когда человек знает всё от логистики и бухучета, до ИТ и стратегии развития компании в целом.
Скорее всего, сейчас придут небожители и скажут: «Да что он там в ИТ понимает? Я вон какой класс написал, смотри, какие методы, SRP тут у меня, а еще DI и интерфейсами обмазано. Вот где тру ИТ».
Но, думаю, в целом меня поймут всё же правильно🙂
Наёмный менеджер / программист
Знает свою гаечку, её точит, не шибко хочет смотреть по сторонам.
Бывает, правда, и такое, что смотрит по сторонам, но кругозор у него искусственно ограничен. Ну смотрит он не просто на код, а на проект в целом. Уже хорошо. Тем не менее, всё, что за рамками этого проекта, скрыто, и потрогает он это вряд ли.
Владелец бизнеса
Смотрит на весь бизнес в целом, несет за него ответственность, пытается вникнуть сразу во всё на свете.
У тех людей, что обращались непосредственно ко мне, это в той или иной мере получалось. Не встречались мне пока такие овнеры, которые бы говорили: «Это фигня какая-то, разбираться в этом не хочу, сделай так, чтобы всё было зашибись. Мне наплевать, как ты это будешь делать».
Почему так?
На мой взгляд, одна из главных причин: владелец бизнеса делает всё это за свой счет, а наемные работники – за дядькины денежки.
Если что-то пойдет не так, владелец теряет свои деньги, а программист просто пойдет в другую компанию послезавтра устроится, где еще овнер не обанкротился.
Итог
Никакого мудрого итога тут нет. Просто поделился с вами своим приятным удивлением от общения с людьми такой категории. Моё искреннее уважение.
Иногда ко мне за консультациями обращаются не рядовые специалисты или менеджеры, а владельцы бизнеса. В них меня очень приятно удивляет и даже восхищает их желание и умение разбираться во всём на свете, что хоть как-то связано с их бизнесом.
Это не программерский «илитный» тишейп, когда «я знаю бэкенд, могу написать вью компонент, а еще ансибл скрипт по перекладыванию файлов написал».
Это когда человек знает всё от логистики и бухучета, до ИТ и стратегии развития компании в целом.
Скорее всего, сейчас придут небожители и скажут: «Да что он там в ИТ понимает? Я вон какой класс написал, смотри, какие методы, SRP тут у меня, а еще DI и интерфейсами обмазано. Вот где тру ИТ».
Но, думаю, в целом меня поймут всё же правильно🙂
Наёмный менеджер / программист
Знает свою гаечку, её точит, не шибко хочет смотреть по сторонам.
Бывает, правда, и такое, что смотрит по сторонам, но кругозор у него искусственно ограничен. Ну смотрит он не просто на код, а на проект в целом. Уже хорошо. Тем не менее, всё, что за рамками этого проекта, скрыто, и потрогает он это вряд ли.
Владелец бизнеса
Смотрит на весь бизнес в целом, несет за него ответственность, пытается вникнуть сразу во всё на свете.
У тех людей, что обращались непосредственно ко мне, это в той или иной мере получалось. Не встречались мне пока такие овнеры, которые бы говорили: «Это фигня какая-то, разбираться в этом не хочу, сделай так, чтобы всё было зашибись. Мне наплевать, как ты это будешь делать».
Почему так?
На мой взгляд, одна из главных причин: владелец бизнеса делает всё это за свой счет, а наемные работники – за дядькины денежки.
Если что-то пойдет не так, владелец теряет свои деньги, а программист просто пойдет в другую компанию послезавтра устроится, где еще овнер не обанкротился.
Итог
Никакого мудрого итога тут нет. Просто поделился с вами своим приятным удивлением от общения с людьми такой категории. Моё искреннее уважение.
Помни, каким ты был джуном
Иногда часто замечаю проблему в коммуникациях опытных разработчиков и джуниоров.
Матерым ребятам кажется, что всё понятно, очевидно и даже не стоит останавливаться на каких-то им понятных деталях. А молодые специалисты прям сильно за ними не успевают. И в лучшем случае они переспросят 146 раз, а в худшем просто покивают головой, скажут, что всё понятно и уйдут тихонько в угол грустить о том, как тяжело работать и какая сложная задача.
Что было со мной
Когда я был совсем джуном, мне тоже было очень тяжело просить помощи у старших товарищей. Не потому, что я стеснялся, а просто потому что я не очень хорошо схватываю информацию налету.
У меня был один коллега – очень умный чувак. Его мастерство вызывало искреннее восхищение. Даже сейчас, когда я уже стал опытнее, то всё равно считаю его тот уровень – весьма хорошим. Не знаю, что с ним сейчас, может он стал еще умнее и круче.
Но каждый раз, когда я просил у него помощи, было прям оооочень сложно. Он довольно быстро говорил и особо не парился, насколько я понимаю те или иные концепции. Просто вопрос – мгновенный ответ. Если ответ был на уровне «да или нет», то всё ок, а если он пускался в долгие размышления, то я терял мысль в первые 10 минут и дальше просто кивал как дурачок, запоминая знакомые слова. Результат такой помощи был, пожалуй, не самым продуктивным.
Что я предлагаю
Всегда нужно помнить, что ты тоже был джуном, плохо понимающим, что творится вокруг. Помнить уровень своего разумения и того, как тяжело тебе дается информация.
И если уж выпало помогать такому, то разговаривать с ним на его языке. Объяснять попроще, без наездов, уточнять, всё ли понятно, попросить объяснить своими словами, как он понял и что он планирует делать.
Джуны, бывает, с поиском элемента в двумерном массиве могут полдня просидеть, просто запутавшись, что там за индексы и кто где запрятан (это я). Не надо им без каких-либо пояснений про кворум и уровни изоляции транзакций.
Плюс скорее всего джуниор и в рамках проекта новенький. Так что он эту вашу текущую бизнес логику, сленг и прочее подобное тоже не разумеет. Добивайтесь одинаковой трактовки терминов.
Итог
Если ты старший товарищ – объясняй попроще, помни, что всё очевидное тебе не обязательно очевидно другим.
Если ты юный специалист – не стесняйся признаться, что тебе непонятно и не бойся переспросить.
Иногда часто замечаю проблему в коммуникациях опытных разработчиков и джуниоров.
Матерым ребятам кажется, что всё понятно, очевидно и даже не стоит останавливаться на каких-то им понятных деталях. А молодые специалисты прям сильно за ними не успевают. И в лучшем случае они переспросят 146 раз, а в худшем просто покивают головой, скажут, что всё понятно и уйдут тихонько в угол грустить о том, как тяжело работать и какая сложная задача.
Что было со мной
Когда я был совсем джуном, мне тоже было очень тяжело просить помощи у старших товарищей. Не потому, что я стеснялся, а просто потому что я не очень хорошо схватываю информацию налету.
У меня был один коллега – очень умный чувак. Его мастерство вызывало искреннее восхищение. Даже сейчас, когда я уже стал опытнее, то всё равно считаю его тот уровень – весьма хорошим. Не знаю, что с ним сейчас, может он стал еще умнее и круче.
Но каждый раз, когда я просил у него помощи, было прям оооочень сложно. Он довольно быстро говорил и особо не парился, насколько я понимаю те или иные концепции. Просто вопрос – мгновенный ответ. Если ответ был на уровне «да или нет», то всё ок, а если он пускался в долгие размышления, то я терял мысль в первые 10 минут и дальше просто кивал как дурачок, запоминая знакомые слова. Результат такой помощи был, пожалуй, не самым продуктивным.
Что я предлагаю
Всегда нужно помнить, что ты тоже был джуном, плохо понимающим, что творится вокруг. Помнить уровень своего разумения и того, как тяжело тебе дается информация.
И если уж выпало помогать такому, то разговаривать с ним на его языке. Объяснять попроще, без наездов, уточнять, всё ли понятно, попросить объяснить своими словами, как он понял и что он планирует делать.
Джуны, бывает, с поиском элемента в двумерном массиве могут полдня просидеть, просто запутавшись, что там за индексы и кто где запрятан (это я). Не надо им без каких-либо пояснений про кворум и уровни изоляции транзакций.
Плюс скорее всего джуниор и в рамках проекта новенький. Так что он эту вашу текущую бизнес логику, сленг и прочее подобное тоже не разумеет. Добивайтесь одинаковой трактовки терминов.
Итог
Если ты старший товарищ – объясняй попроще, помни, что всё очевидное тебе не обязательно очевидно другим.
Если ты юный специалист – не стесняйся признаться, что тебе непонятно и не бойся переспросить.
Делаю сложные дела утром
Часто замечаю, что многие люди (как и я раньше) попадают в ситуацию, когда надо бы сделать сегодня что-то сложное, но хочется сначала выполнить простенькое, разобраться с мелочами, вдохновиться легкими победами.
Я считаю это большой ошибкой. Рассмотрим две стратегии поведения: сначала легкое или сначала сложное.
Делаем сначала легкое
В этом варианте мы утром, пока еще коллеги входят в рабочий режим, спокойно, без отвлекающих факторов садимся и разгребаем легкие задачки.
Ко второй половине дня мы их разгребли и вроде как немного даже воодушевились результатами, пусть и мелкими, легко доставшимися.
А потом у нас после обеда продуктивность естественным образом снижается, плюс накапливается усталость от того, что мы уже наработали, плюс активизируются желающие или поболтать, или посовещаться (иногда это почти одно и то же), коллеги. В итоге до сложного мы доберемся ближе к концу дня и уже не в форме. Что-то, может, и начнем, потом забьем, потому что сегодня уже сложно, завтра сделаю нормально. А завтра цикл повторится с тем же результатом.
В итоге всю неделю делаем мелочевку, а серьезные вещи надкусаны, но так и не готовы.
Делаем сначала сложное
Можно утром, пока есть силы и нет отвлекающих факторов, приняться за сложную работу. Шанс, что мы её сделаем, существенно выше, чем в первом случае.
А потом ко второй половине дня, когда снижается продуктивность и мы уже сделали самое важное, можем уделить время и мелочам. Да, мы можем не успеть столько мелочей, как в первом случае. Ну так на то они и мелочи, что их можно делать атомарно, без особой когнитивной нагрузки, не сильно забуриваясь в контекст.
В итоге сделали всё важное, плюс часть мелких задачек. Если сравнивать результат с первым вариантом, то, на мой взгляд, лучше уж сложное успеть, чем выполнить больше маленьких легких вещей. Меня же в первую очередь работодатель держит, наверное, не чтобы я легкотню щелкал.
Как это выглядит у меня
Так как сейчас я в роли тимлида наполовину менеджер, а наполовину разработчик, то я беру самые когнитивно сложные задачи (внезапно это оказываются инженерные задачи, а не написание писем) и делаю их. Пишу код, проектирую архитектуру.
Во второй половине дня переключаюсь на документотворчество, созвоны, помощь коллегам по разным вопросам, согласования всякие и т. д.
Пробовал с утра делать менеджерскую работу, а после обеда разрабатывать – результат мне не понравился. Оказалось, что менеджмент я могу делать примерно одинаково производительно в любое время дня, а вот код продуктивно писать, только когда есть ментальные силы и нет регулярных отвлекающих факторов.
Итог
Мой пример, конечно, может вам и не подойти. Но попробуйте сами и посмотрите на результат.
Вдруг кому-то это правда поможет делать больше важных вещей, а в моральном плане меньше уставать и корить себя за то, что опять сегодня вон ту важную сложную штуку так и не начал, погрязнув в мелочах.
Часто замечаю, что многие люди (как и я раньше) попадают в ситуацию, когда надо бы сделать сегодня что-то сложное, но хочется сначала выполнить простенькое, разобраться с мелочами, вдохновиться легкими победами.
Я считаю это большой ошибкой. Рассмотрим две стратегии поведения: сначала легкое или сначала сложное.
Делаем сначала легкое
В этом варианте мы утром, пока еще коллеги входят в рабочий режим, спокойно, без отвлекающих факторов садимся и разгребаем легкие задачки.
Ко второй половине дня мы их разгребли и вроде как немного даже воодушевились результатами, пусть и мелкими, легко доставшимися.
А потом у нас после обеда продуктивность естественным образом снижается, плюс накапливается усталость от того, что мы уже наработали, плюс активизируются желающие или поболтать, или посовещаться (иногда это почти одно и то же), коллеги. В итоге до сложного мы доберемся ближе к концу дня и уже не в форме. Что-то, может, и начнем, потом забьем, потому что сегодня уже сложно, завтра сделаю нормально. А завтра цикл повторится с тем же результатом.
В итоге всю неделю делаем мелочевку, а серьезные вещи надкусаны, но так и не готовы.
Делаем сначала сложное
Можно утром, пока есть силы и нет отвлекающих факторов, приняться за сложную работу. Шанс, что мы её сделаем, существенно выше, чем в первом случае.
А потом ко второй половине дня, когда снижается продуктивность и мы уже сделали самое важное, можем уделить время и мелочам. Да, мы можем не успеть столько мелочей, как в первом случае. Ну так на то они и мелочи, что их можно делать атомарно, без особой когнитивной нагрузки, не сильно забуриваясь в контекст.
В итоге сделали всё важное, плюс часть мелких задачек. Если сравнивать результат с первым вариантом, то, на мой взгляд, лучше уж сложное успеть, чем выполнить больше маленьких легких вещей. Меня же в первую очередь работодатель держит, наверное, не чтобы я легкотню щелкал.
Как это выглядит у меня
Так как сейчас я в роли тимлида наполовину менеджер, а наполовину разработчик, то я беру самые когнитивно сложные задачи (внезапно это оказываются инженерные задачи, а не написание писем) и делаю их. Пишу код, проектирую архитектуру.
Во второй половине дня переключаюсь на документотворчество, созвоны, помощь коллегам по разным вопросам, согласования всякие и т. д.
Пробовал с утра делать менеджерскую работу, а после обеда разрабатывать – результат мне не понравился. Оказалось, что менеджмент я могу делать примерно одинаково производительно в любое время дня, а вот код продуктивно писать, только когда есть ментальные силы и нет регулярных отвлекающих факторов.
Итог
Мой пример, конечно, может вам и не подойти. Но попробуйте сами и посмотрите на результат.
Вдруг кому-то это правда поможет делать больше важных вещей, а в моральном плане меньше уставать и корить себя за то, что опять сегодня вон ту важную сложную штуку так и не начал, погрязнув в мелочах.
Делал-делал, а что сделал?
Нам часто приходится отчитываться о проведенной работе в той или иной форме. Это ежедневные стендапы, ретроспективы, просто какие-то встречи, планерки, отчеты.
Нередко я вижу одну и ту же ошибку в подходе к описанию проведенных работ.
У самурая нет цели, только путь
Есть категория людей, которая любит в красках рассказывать о том, что они делали. И каждый отчет у них - «я делал то, я изучал это, я проверял пятое, я копал десятое». В итоге слушаешь, читаешь и не понимаешь, а что в результате сделано-то?
Нам на работе платят денежки в надежде, что мы выдадим результат. Поэтому концентрация на процессе исполнения — это путь в никуда. Главное, что конкретно ты сделал.
Если человек изо дня в день, из недели в неделю, из месяца в месяц отчитывается о том, как он что-то делал, не представляя конкретных результатов, то, на мой взгляд, это тревожный звоночек.
- Может быть, всё в порядке, просто человек не умеет доносить результаты своего труда. Тогда достаточно просто попросить, чтобы он выражался более конкретно.
- Может быть, у человека затруднения, если он буксует в процессе делания, а до результата не доходит. Надо выяснить, что идет не так, и помочь.
- Может быть, человек забил на результат и в целом ему комфортно бумажку с одной стороны стола на другую перекладывать, ведь платят-то оклад в любом случае. Тут требуется уже серьезная беседа
- Может, человек не умеет декомпозировать задачи. И у него каждый день просто одна и та же мегазадача «сделать весь проект от и до идеально». И вот он её делает. Тут тоже можно помочь разобраться, как разбить задачу, как найти конкретные цели, какими путями к ним идти.
- Может, у человека какие-то психологические комплексы, он недохвален и пытается к себе привлечь внимание или похвалу, каждый день сообщая как он героически что-то делает. Ведь достичь результат – это вспышка. Бац, момент славы наступил, тут же угас и надо следующий результат достигать. А ГЕРОИЧЕСКОЕ ДЕЛАНИЕ – оно каждый день, каждый миг.
Я сделал
Сам я за собой тоже замечаю иногда такое. Хочется вещать и вещать, как я что-то делаю.
Но самодисциплина и понимание того, зачем именно я нанят на работу, стимулируют меня выныривать из этого потока и приносить в итоге конкретный результат.
Стараюсь думать о том, что нужно достичь определенную цель, а сколько я при этом буду или страдать, или расслабляться – уже мало кого, кроме меня, волнует.
Итог
Помните в первую очередь о цели вашей работы. Чем яснее вы её видите и чаще вспоминаете, тем конкретнее будут ваши шаги к достижению результата.
И у вашего руководителя будет меньше вопросов и сомнений при чтении ваших более конкретных отчетов о результатах вашей работы.
Нам часто приходится отчитываться о проведенной работе в той или иной форме. Это ежедневные стендапы, ретроспективы, просто какие-то встречи, планерки, отчеты.
Нередко я вижу одну и ту же ошибку в подходе к описанию проведенных работ.
У самурая нет цели, только путь
Есть категория людей, которая любит в красках рассказывать о том, что они делали. И каждый отчет у них - «я делал то, я изучал это, я проверял пятое, я копал десятое». В итоге слушаешь, читаешь и не понимаешь, а что в результате сделано-то?
Нам на работе платят денежки в надежде, что мы выдадим результат. Поэтому концентрация на процессе исполнения — это путь в никуда. Главное, что конкретно ты сделал.
Если человек изо дня в день, из недели в неделю, из месяца в месяц отчитывается о том, как он что-то делал, не представляя конкретных результатов, то, на мой взгляд, это тревожный звоночек.
- Может быть, всё в порядке, просто человек не умеет доносить результаты своего труда. Тогда достаточно просто попросить, чтобы он выражался более конкретно.
- Может быть, у человека затруднения, если он буксует в процессе делания, а до результата не доходит. Надо выяснить, что идет не так, и помочь.
- Может быть, человек забил на результат и в целом ему комфортно бумажку с одной стороны стола на другую перекладывать, ведь платят-то оклад в любом случае. Тут требуется уже серьезная беседа
- Может, человек не умеет декомпозировать задачи. И у него каждый день просто одна и та же мегазадача «сделать весь проект от и до идеально». И вот он её делает. Тут тоже можно помочь разобраться, как разбить задачу, как найти конкретные цели, какими путями к ним идти.
- Может, у человека какие-то психологические комплексы, он недохвален и пытается к себе привлечь внимание или похвалу, каждый день сообщая как он героически что-то делает. Ведь достичь результат – это вспышка. Бац, момент славы наступил, тут же угас и надо следующий результат достигать. А ГЕРОИЧЕСКОЕ ДЕЛАНИЕ – оно каждый день, каждый миг.
Я сделал
Сам я за собой тоже замечаю иногда такое. Хочется вещать и вещать, как я что-то делаю.
Но самодисциплина и понимание того, зачем именно я нанят на работу, стимулируют меня выныривать из этого потока и приносить в итоге конкретный результат.
Стараюсь думать о том, что нужно достичь определенную цель, а сколько я при этом буду или страдать, или расслабляться – уже мало кого, кроме меня, волнует.
Итог
Помните в первую очередь о цели вашей работы. Чем яснее вы её видите и чаще вспоминаете, тем конкретнее будут ваши шаги к достижению результата.
И у вашего руководителя будет меньше вопросов и сомнений при чтении ваших более конкретных отчетов о результатах вашей работы.
👍1
Улиточка – сотрудник месяца
Наверное, каждый из нас сталкивался с ситуацией, когда прибегает менеджер/заказчик и в суете кричит, что срочно что-то надо сделать. Мы тут же подрываемся, быстро делаем, а потом через час этот же менеджер опять приходит и говорит, что концепция поменялась и надо переделать. Мы переделываем. А закончиться всё это может тем, что придется всё вернуть в исходное состояние.
Мемы по этому поводу
Мой любимый - https://pikabu.ru/story/tikho_tikho_polzi_ulitka_po_sklonu_fudzi_6817642
И еще мудрый давний выпуск «Фитиля» - https://www.youtube.com/watch?v=eYBwY6zKSNk
Что делать?
Не буду рассматривать перевоспитание таких менеджеров, которые сначала другим подкидывают работу, а потом только думать начинают. Это тема для отдельной беседы, возможно, научно-фантастической.
Хотелось бы понять, что делать человеку, который работает в роли исполнителя?
Если вы посмотрели выпуск «Фитиля», то там всё, в общем-то, и показано🙂
- Выявляете ненадежных людей, кто грешит подобным поведением.
- Не реагируете сразу и не несетесь сломя голову выполнять поручение.
- По возможности разбираетесь в ситуации и уточняете, а точно ли так надо, именно это надо, всё ли со всеми согласовано, когда именно дедлайн, что будет, если прям вот через 7.5 секунд не успеем сделать эту «срочнейшую» задачу и т. д.
- Если были многократные рецидивы, когда человек уверял, что да, точно надо, точно срочно, а потом оказывалось, что и не срочно, и не надо, и вообще концепция изменилась, то дайте себе и заказчику немного времени на то, чтобы еще раз подумать. Не торопитесь, ведь двойную работу потом делать
вам, а не ему.
Что делать, если вы такой человек?
Вряд ли вы такой человек, потому что у вас НЕТ ВРЕМЕНИ ЧИТАТЬ ЭТОТ КАНАЛ, У ВАС ЕСТЬ СРОЧНАЯ РАБОТА!!!
Но если вдруг это всё же вы, то постарайтесь разобраться, почему так происходит.
Обычно у таких людей аргументы на уровне «это просто сфера работы такая» или «это не от меня зависит».
Аргумент «это не от меня зависит» отдает нежеланием попытаться добиться какого-то порядка от предыдущего звена, передающего работу. Это такое перекладывание ответственности, типа «я делаю плохо, но я не виноват, это другой дяденька, или тетенька плохие». Думаю, вы сами уже поняли, что звучит это оправдание довольно сомнительно.
Аргумент «просто сфера работы такая» - еще хуже выглядит. Это значит не то, что кто-то там еще другой косячит, а вы просто сами не можете свою работу организовать нормально, поэтому и ваш труд погряз в бесполезной суете, и других еще напрягаете.
Как ни крути, все варианты ведут к тому, что можно попытаться организовать свою работу и работу окружающих каким-то более-менее нормальным образом.
Многие этого не делают, потому что это сложно. Надо думать, менять что-то, разбираться, разговаривать, выяснять, договариваться, привыкать и т. д. Но мне хочется верить, что в конечном счете те, кто не в состоянии думать, трудиться, меняться, уступят свои места более вдумчивым и ответственным работникам.
Итог
Знайте ненадежных заказчиков, не ведитесь на их суету.
Думайте о своей работе, организуйте её нормально, цените труд и время других людей.
Наверное, каждый из нас сталкивался с ситуацией, когда прибегает менеджер/заказчик и в суете кричит, что срочно что-то надо сделать. Мы тут же подрываемся, быстро делаем, а потом через час этот же менеджер опять приходит и говорит, что концепция поменялась и надо переделать. Мы переделываем. А закончиться всё это может тем, что придется всё вернуть в исходное состояние.
Мемы по этому поводу
Мой любимый - https://pikabu.ru/story/tikho_tikho_polzi_ulitka_po_sklonu_fudzi_6817642
И еще мудрый давний выпуск «Фитиля» - https://www.youtube.com/watch?v=eYBwY6zKSNk
Что делать?
Не буду рассматривать перевоспитание таких менеджеров, которые сначала другим подкидывают работу, а потом только думать начинают. Это тема для отдельной беседы, возможно, научно-фантастической.
Хотелось бы понять, что делать человеку, который работает в роли исполнителя?
Если вы посмотрели выпуск «Фитиля», то там всё, в общем-то, и показано🙂
- Выявляете ненадежных людей, кто грешит подобным поведением.
- Не реагируете сразу и не несетесь сломя голову выполнять поручение.
- По возможности разбираетесь в ситуации и уточняете, а точно ли так надо, именно это надо, всё ли со всеми согласовано, когда именно дедлайн, что будет, если прям вот через 7.5 секунд не успеем сделать эту «срочнейшую» задачу и т. д.
- Если были многократные рецидивы, когда человек уверял, что да, точно надо, точно срочно, а потом оказывалось, что и не срочно, и не надо, и вообще концепция изменилась, то дайте себе и заказчику немного времени на то, чтобы еще раз подумать. Не торопитесь, ведь двойную работу потом делать
вам, а не ему.
Что делать, если вы такой человек?
Вряд ли вы такой человек, потому что у вас НЕТ ВРЕМЕНИ ЧИТАТЬ ЭТОТ КАНАЛ, У ВАС ЕСТЬ СРОЧНАЯ РАБОТА!!!
Но если вдруг это всё же вы, то постарайтесь разобраться, почему так происходит.
Обычно у таких людей аргументы на уровне «это просто сфера работы такая» или «это не от меня зависит».
Аргумент «это не от меня зависит» отдает нежеланием попытаться добиться какого-то порядка от предыдущего звена, передающего работу. Это такое перекладывание ответственности, типа «я делаю плохо, но я не виноват, это другой дяденька, или тетенька плохие». Думаю, вы сами уже поняли, что звучит это оправдание довольно сомнительно.
Аргумент «просто сфера работы такая» - еще хуже выглядит. Это значит не то, что кто-то там еще другой косячит, а вы просто сами не можете свою работу организовать нормально, поэтому и ваш труд погряз в бесполезной суете, и других еще напрягаете.
Как ни крути, все варианты ведут к тому, что можно попытаться организовать свою работу и работу окружающих каким-то более-менее нормальным образом.
Многие этого не делают, потому что это сложно. Надо думать, менять что-то, разбираться, разговаривать, выяснять, договариваться, привыкать и т. д. Но мне хочется верить, что в конечном счете те, кто не в состоянии думать, трудиться, меняться, уступят свои места более вдумчивым и ответственным работникам.
Итог
Знайте ненадежных заказчиков, не ведитесь на их суету.
Думайте о своей работе, организуйте её нормально, цените труд и время других людей.
Пикабу
Тихо, тихо ползи, улитка, по склону Фудзи
Автор: Proidemtes
Типичная вакансия тимлида
Если посмотреть на российский рынок тимлидских вакансий, то в подавляющем большинстве случаев мы можем увидеть примерно одинаковую картину. Я понимаю, почему она складывается. Иногда я даже не против. Но есть ряд замечаний, которые нанимающая сторона должна понимать.
И швец, и жнец, и на дуде игрец
Классика!
- Тимлид должен быть самым опытным разработчиком, умеющим запрограммировать самые сложные части приложения.
- Тимлид должен быть хорошим менеджером, чтобы хорошо управляться с командой разработчиков, грамотно управляться с процессом производства программного продукта и найти к каждому, от рядового сотрудника, до топ-менеджмента, свой индивидуальный подход.
- Тимлид должен быть мудрейшим рекрутером, чтобы генерить правильные вакансии, проводить лучшие собеседования, придумать класснейшие онбординг процессы.
- Тимлид даже должен быть немножко продактом, чтобы не бездумно исполнять, что скажет менеджмент, а вникать в предметную область, бизнес процессы, анализировать разные подходы к решению проблем и предлагать свои варианты.
Время не бесконечное
Пожалуй, не буду сейчас вдаваться в подробное обсуждение каждого пункта, ибо этот разговор явно не уместится в один пост.
Довольно частая ошибка, которая встречается повсеместно – ложные ожидания по трудозатратам. Если вы нанимаете человека, как полуменеджера / полуразработчика, то не надо ожидать, что он будет выполнять 100% работы разработчика, и еще 100% работы менеджера. Он даже по 50% выполнять это не сможет. В лучшем случае он будет по 40% тем и этим, а оставшиеся 20% он потратит в никуда на переключение между этими двумя ролями.
Зачем же он такой нужен?
Замечательный вопрос. Особенно у тех, кто никогда не сталкивался с ситуацией, когда менеджеры с разработчиками воюют, каждый гнет свою линию и в итоге вся команда и весь проект работают в режиме «лебедь, рак и щука».
Тут-то вам швец-жнец-тимлид и пригодится, чтобы всю эту компанию понять, подружить, направить по единому пути.
Что делать с вакансией?
Тут единого ответа у меня нет. Надо смотреть по ситуации.
Там, где маленькая команда, небольшой проект, то я бы нанимал тимлида по такой вот классической малоприятной схеме. Ибо при небольшой численности коллектива он будет в бОльшей степени разрабом и опытным товарищем, а в меньшей - менеджером (а там много и не надо).
Но есть и другие варианты, где больше команды, сложнее процессы, большее количество проектов – тут вариантов великое множество. Где-то тимлид – почти фултайм менеджер, где-то он внезапно техлид / архитектор, который отдает почти целиком менеджерскую часть другому человеку, а сам принимает функцию главного всея технаря. На таких масштабах роли начинают расслаиваться, бюджеты позволяют нанимать под определенные аспекты разных людей.
Итог
Найм тимлида – сложная и неоднозначная штука. Серебряной пули тут нет. Надо отталкиваться от текущей ситуации с командой, проектом, процессами. Главное – понимать, что существует ограниченный лимит времени + переключение между ролями тоже съедают какую-то его часть.
Если посмотреть на российский рынок тимлидских вакансий, то в подавляющем большинстве случаев мы можем увидеть примерно одинаковую картину. Я понимаю, почему она складывается. Иногда я даже не против. Но есть ряд замечаний, которые нанимающая сторона должна понимать.
И швец, и жнец, и на дуде игрец
Классика!
- Тимлид должен быть самым опытным разработчиком, умеющим запрограммировать самые сложные части приложения.
- Тимлид должен быть хорошим менеджером, чтобы хорошо управляться с командой разработчиков, грамотно управляться с процессом производства программного продукта и найти к каждому, от рядового сотрудника, до топ-менеджмента, свой индивидуальный подход.
- Тимлид должен быть мудрейшим рекрутером, чтобы генерить правильные вакансии, проводить лучшие собеседования, придумать класснейшие онбординг процессы.
- Тимлид даже должен быть немножко продактом, чтобы не бездумно исполнять, что скажет менеджмент, а вникать в предметную область, бизнес процессы, анализировать разные подходы к решению проблем и предлагать свои варианты.
Время не бесконечное
Пожалуй, не буду сейчас вдаваться в подробное обсуждение каждого пункта, ибо этот разговор явно не уместится в один пост.
Довольно частая ошибка, которая встречается повсеместно – ложные ожидания по трудозатратам. Если вы нанимаете человека, как полуменеджера / полуразработчика, то не надо ожидать, что он будет выполнять 100% работы разработчика, и еще 100% работы менеджера. Он даже по 50% выполнять это не сможет. В лучшем случае он будет по 40% тем и этим, а оставшиеся 20% он потратит в никуда на переключение между этими двумя ролями.
Зачем же он такой нужен?
Замечательный вопрос. Особенно у тех, кто никогда не сталкивался с ситуацией, когда менеджеры с разработчиками воюют, каждый гнет свою линию и в итоге вся команда и весь проект работают в режиме «лебедь, рак и щука».
Тут-то вам швец-жнец-тимлид и пригодится, чтобы всю эту компанию понять, подружить, направить по единому пути.
Что делать с вакансией?
Тут единого ответа у меня нет. Надо смотреть по ситуации.
Там, где маленькая команда, небольшой проект, то я бы нанимал тимлида по такой вот классической малоприятной схеме. Ибо при небольшой численности коллектива он будет в бОльшей степени разрабом и опытным товарищем, а в меньшей - менеджером (а там много и не надо).
Но есть и другие варианты, где больше команды, сложнее процессы, большее количество проектов – тут вариантов великое множество. Где-то тимлид – почти фултайм менеджер, где-то он внезапно техлид / архитектор, который отдает почти целиком менеджерскую часть другому человеку, а сам принимает функцию главного всея технаря. На таких масштабах роли начинают расслаиваться, бюджеты позволяют нанимать под определенные аспекты разных людей.
Итог
Найм тимлида – сложная и неоднозначная штука. Серебряной пули тут нет. Надо отталкиваться от текущей ситуации с командой, проектом, процессами. Главное – понимать, что существует ограниченный лимит времени + переключение между ролями тоже съедают какую-то его часть.
Что значит задача сделана?
Иногда сталкиваюсь с недопониманием между разработчиками, тестировщиками и менеджерами по поводу термина «задача сделана». Это может приводить к неприятным последствиям.
Суть проблемы
На переднем краю проблемы выступает разработчик. Он написал код, отправил в тестирование и доложил «задача готова». Хотя, как она готова, если она даже не протестирована?
Ну такой подход из серии «с моей стороны пули вылетели».
А если нет отдела тестирования, который эти пули хоть как-то может притормозить в случае чего, то разраб написал код, отправил в деплой и с чувством выполненного долга пошел делать другую задачу. Заодно менеджеру рассказал, что всё готово. А если менеджер бестолковый и не перепроверил, так и вообще, получается, на проде непонятно что лежит и неизвестно как работает.
В этом случае главный тестировщик и валидатор качества реализации – разгневанный пользователь, который непременно маякнет в случае чего.
Другой подход
Лично мне нравится идея, которую высказывали на одном из докладов (если я ничего не перепутал) в Badoo.
Когда разработчик занимается задачей «на полную катушку». Пишет код, участвует в тестировании, контролирует деплой и последующую жизнь этой своей фичи некоторое время. Мониторит, метрики собирает. И когда всё тоооочно нормально, тогда считается, что его задача сделана.
Критика такого подхода
Я уверен, что найдется много людей, которые искренне полагают, что их задача – ТОЛЬКО НАПИСАТЬ КОД, а для других стадий жизненного цикла фичи есть другие люди, и это их работа дальше вылетевшие пули контролировать, чтобы прилетели, куда надо.
Я это понимаю. Понимаю, что при очень хорошей, точной настройке процессов, когда у вас слаженная команда и каждый хорошо и ответственно делает свой кусочек работы - это вполне эффективная стратегия. И по ней легко и приятно работать.
Однако, стоит отметить, что если в цепочке, например, из 4х человек всё не совсем гладко и надежность каждого из них по отдельности – 0.95, то надежность всей цепочки (если я правильно считаю) будет уже 0.95*0.95*0.95*0.95 = 0.81.
Так что там про «задача сделана»?
К сожалению, я отвлекся от основной темы и начал рассуждать про то, как именно лучше сделать задачу. А что это значит – не сказал.
Так вот на мой взгляд, задача сделана – это когда выяснили, что она нужна, её разработали, протестировали, отладили, релизнули и посмотрели, что с ней в проде всё хорошо.
По крайней мере с точки зрения бизнеса – вот теперь она сделана. И менеджера, как представителя бизнес стороны, должно волновать всё это в комплексе.
А как там программисты для себя решают сделали они или не сделали задачу – это уже плавающий от компании к компании вопрос организации труда.
Итог
Позаботьтесь о том, чтобы задача была по-настоящему "сделана".
Если можете так организовать работу, чтобы каждый сделал свой маленький кусочек, то и замечательно. А если не получается - уменьшайте количество ответственных в этой цепочке.
Бонусный контент
Мы с Никитой Хромушкиным договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://news.1rj.ru/str/product_developer/27
Иногда сталкиваюсь с недопониманием между разработчиками, тестировщиками и менеджерами по поводу термина «задача сделана». Это может приводить к неприятным последствиям.
Суть проблемы
На переднем краю проблемы выступает разработчик. Он написал код, отправил в тестирование и доложил «задача готова». Хотя, как она готова, если она даже не протестирована?
Ну такой подход из серии «с моей стороны пули вылетели».
А если нет отдела тестирования, который эти пули хоть как-то может притормозить в случае чего, то разраб написал код, отправил в деплой и с чувством выполненного долга пошел делать другую задачу. Заодно менеджеру рассказал, что всё готово. А если менеджер бестолковый и не перепроверил, так и вообще, получается, на проде непонятно что лежит и неизвестно как работает.
В этом случае главный тестировщик и валидатор качества реализации – разгневанный пользователь, который непременно маякнет в случае чего.
Другой подход
Лично мне нравится идея, которую высказывали на одном из докладов (если я ничего не перепутал) в Badoo.
Когда разработчик занимается задачей «на полную катушку». Пишет код, участвует в тестировании, контролирует деплой и последующую жизнь этой своей фичи некоторое время. Мониторит, метрики собирает. И когда всё тоооочно нормально, тогда считается, что его задача сделана.
Критика такого подхода
Я уверен, что найдется много людей, которые искренне полагают, что их задача – ТОЛЬКО НАПИСАТЬ КОД, а для других стадий жизненного цикла фичи есть другие люди, и это их работа дальше вылетевшие пули контролировать, чтобы прилетели, куда надо.
Я это понимаю. Понимаю, что при очень хорошей, точной настройке процессов, когда у вас слаженная команда и каждый хорошо и ответственно делает свой кусочек работы - это вполне эффективная стратегия. И по ней легко и приятно работать.
Однако, стоит отметить, что если в цепочке, например, из 4х человек всё не совсем гладко и надежность каждого из них по отдельности – 0.95, то надежность всей цепочки (если я правильно считаю) будет уже 0.95*0.95*0.95*0.95 = 0.81.
Так что там про «задача сделана»?
К сожалению, я отвлекся от основной темы и начал рассуждать про то, как именно лучше сделать задачу. А что это значит – не сказал.
Так вот на мой взгляд, задача сделана – это когда выяснили, что она нужна, её разработали, протестировали, отладили, релизнули и посмотрели, что с ней в проде всё хорошо.
По крайней мере с точки зрения бизнеса – вот теперь она сделана. И менеджера, как представителя бизнес стороны, должно волновать всё это в комплексе.
А как там программисты для себя решают сделали они или не сделали задачу – это уже плавающий от компании к компании вопрос организации труда.
Итог
Позаботьтесь о том, чтобы задача была по-настоящему "сделана".
Если можете так организовать работу, чтобы каждый сделал свой маленький кусочек, то и замечательно. А если не получается - уменьшайте количество ответственных в этой цепочке.
Бонусный контент
Мы с Никитой Хромушкиным договорились написать пост на эту тему, каждый у себя в канале. Его вариант здесь https://news.1rj.ru/str/product_developer/27
Внимательно смотри на коллег и руководителей
Недавно ко мне приходил на консультацию человек, карьерный путь которого начался довольно стремительно и успешно. Он очень вдумчиво относится к работе и высказывает много хороших мыслей.
Одной из них я с вами с удовольствием поделюсь, ибо это всё вроде очевидно, но тем не менее далеко не все об этом задумываются.
Типичная ошибка
Часто бывает так, что человек устраивается в компанию, планируя профессиональный и карьерный рост, но не очень внимательно приглядывается к своим старшим товарищам.
Он сосредотачивается на себе, на своих скиллах, на том, что ему в идеале нужно прокачать для успешной работы в абстрактной сферической компании в вакууме. Посмотрел много конференций и исследований рынка, узнал что модно, что в тренде, чего ждет индустрия и забуривается в это.
И это всё вроде верно, план прокачки должен обязательно быть.
Проблема только в том, что вы работаете прямо сейчас в конкретной компании с конкретными процессами и с конкретными перспективами. Да, в некоторых случаях на это можно повлиять и поменять, но в среднем случае вас просто засосет в текущую систему as is.
Что делать
Если вы интересуетесь хард скиллами, смотрите на сениоров, которые работают с вами. В большинстве случаев это то, что вас ожидает в этой компании в будущем.
Если там супер умные головастые ребята – поздравляю, при должном напоре и старании вы сможете многому научиться.
А если сидят мидлы с лычками сениоров и делают типовые банальные штуки день за днем, скорее всего перспективы вас ждут такие же, БЕГИТЕ.
Если вас интересуют софт скиллы и управление, то посмотрите на своего руководителя (тимлида, менеджера) и прикиньте, насколько он загружен, насколько он адекватен, насколько с ним прилично обращаются бизнес и заказчики.
Почувствовали тревожные звоночки? Узнали, что это негласная норма? БЕГИТЕ.
Итог
Я, конечно, искренне верю, что при должном старании можно многое поменять.
У меня было такое, что я годами что-то менял и оно менялось, но это потому что в целом в компании сошлось много положительных факторов, и оно того стоило, чтобы стараться, вкладывать труд и нервы.
Но это скорее исключение, чем правило. Ибо сейчас рынок труда для ИТ специалистов такой, что если ваши изменения мало кто в компании приветствует, то вам намного быстрее и проще сменить компанию на более подходящую, чем уговаривать кого-то годами что-то изменить.
Так что всегда внимательно присматривайтесь в своей компании к тому, кто уже прошел определенный путь до вас.
Если вы смотрите на человека и думаете «а он крутой и ему тут хорошо», то это хороший знак. А если вы видите от него коммиты в 2 часа ночи, а уже утром в 8 вы видите, как его отчитывает руководство, то подумайте, может быть стоит БЕЖАТЬ.
Недавно ко мне приходил на консультацию человек, карьерный путь которого начался довольно стремительно и успешно. Он очень вдумчиво относится к работе и высказывает много хороших мыслей.
Одной из них я с вами с удовольствием поделюсь, ибо это всё вроде очевидно, но тем не менее далеко не все об этом задумываются.
Типичная ошибка
Часто бывает так, что человек устраивается в компанию, планируя профессиональный и карьерный рост, но не очень внимательно приглядывается к своим старшим товарищам.
Он сосредотачивается на себе, на своих скиллах, на том, что ему в идеале нужно прокачать для успешной работы в абстрактной сферической компании в вакууме. Посмотрел много конференций и исследований рынка, узнал что модно, что в тренде, чего ждет индустрия и забуривается в это.
И это всё вроде верно, план прокачки должен обязательно быть.
Проблема только в том, что вы работаете прямо сейчас в конкретной компании с конкретными процессами и с конкретными перспективами. Да, в некоторых случаях на это можно повлиять и поменять, но в среднем случае вас просто засосет в текущую систему as is.
Что делать
Если вы интересуетесь хард скиллами, смотрите на сениоров, которые работают с вами. В большинстве случаев это то, что вас ожидает в этой компании в будущем.
Если там супер умные головастые ребята – поздравляю, при должном напоре и старании вы сможете многому научиться.
А если сидят мидлы с лычками сениоров и делают типовые банальные штуки день за днем, скорее всего перспективы вас ждут такие же, БЕГИТЕ.
Если вас интересуют софт скиллы и управление, то посмотрите на своего руководителя (тимлида, менеджера) и прикиньте, насколько он загружен, насколько он адекватен, насколько с ним прилично обращаются бизнес и заказчики.
Почувствовали тревожные звоночки? Узнали, что это негласная норма? БЕГИТЕ.
Итог
Я, конечно, искренне верю, что при должном старании можно многое поменять.
У меня было такое, что я годами что-то менял и оно менялось, но это потому что в целом в компании сошлось много положительных факторов, и оно того стоило, чтобы стараться, вкладывать труд и нервы.
Но это скорее исключение, чем правило. Ибо сейчас рынок труда для ИТ специалистов такой, что если ваши изменения мало кто в компании приветствует, то вам намного быстрее и проще сменить компанию на более подходящую, чем уговаривать кого-то годами что-то изменить.
Так что всегда внимательно присматривайтесь в своей компании к тому, кто уже прошел определенный путь до вас.
Если вы смотрите на человека и думаете «а он крутой и ему тут хорошо», то это хороший знак. А если вы видите от него коммиты в 2 часа ночи, а уже утром в 8 вы видите, как его отчитывает руководство, то подумайте, может быть стоит БЕЖАТЬ.
Антон Околелов, ведущий подкаста Цинковый Прод, не так давно завел телеграм канал.
Там он пишет про всякое про софт и про хард. Это могут быть свои мысли, или комментарии интересных новостей, или какие-то полезные ссылки.
Мне нравится как он пишет. Тексты получаются живые и с душой. Даже когда я не согласен с его мнением - мне всё равно интересно их читать🙂
Вот пример такого поста, ради которого я подписан на его канал https://news.1rj.ru/str/crossjoin/32
Там он пишет про всякое про софт и про хард. Это могут быть свои мысли, или комментарии интересных новостей, или какие-то полезные ссылки.
Мне нравится как он пишет. Тексты получаются живые и с душой. Даже когда я не согласен с его мнением - мне всё равно интересно их читать🙂
Вот пример такого поста, ради которого я подписан на его канал https://news.1rj.ru/str/crossjoin/32
Telegram
Cross Join - канал о разработке
Недавно Фил Ранжин написал в твиттере тредик, что мол все аджайл-практики и книги по ним - говно, и только мудрый руководитель на опыте может всё разрулить.
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь.…
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь.…
Прыгуны - это хорошо или плохо?
Недавно поступил вопрос:
«Что делать, если сменил пяток компаний из-за неподходящих условий, и теперь твое резюме кричит "я работаю недолго в компаниях", что читается HR'ами как "я от бабушки ушел и от дедушки ушел и от тебя уйду"?»
Хотелось бы рассмотреть несколько вариаций данной ситуации.
Вы по резюме прыгун, но таким быть не хотите
Если вы не хотите быть прыгуном, но на неделе вы каждые полгода-год меняете работу, то тут надо внимательно посмотреть, почему так получилось. Возможно, вам просто кажется, что вы не такой, а вы такой.
А возможно, просто обстоятельства сложились неудачным образом, и с вами произошла череда неудачных совпадений.
Если это совпадения, то вам надо объясниться, почему факты таковы, что про вас можно подумать не то, что вам бы хотелось.
Если вы уже дошли до собеса, то объяснять это надо, но аккуратно. Не поливайте никого грязью и не рассказывайте, какие все дураки и кидалы. Это создаст о вас негативное впечатление и покажется, что вы так будете про всех своих работодателей думать и говорить. Тем не менее надо спокойно объяснить, что так совпало, что устраивался туда, где, например, договоренности не соблюдались, а вы человек порядочный и так не можете работать, когда какая-то из сторон необязательная.
Правда, иной раз можно до собеса и не дойти, а пропасть на этапе эйчар фильтра. Так что пишите какое-то пояснительное письмо при отклике, или в графе «о себе» что-то такое поясняющее пишите, что ищете постоянную комфортную работу и прыгать без нужды не хотите.
Есть шанс, что часть эйчаров не дочитает до этого момента, но тут уже мало что можно поделать. Старайтесь по возможности обойти этот фильтр и заходить куда-то напрямую к нанимающим менеджерам через знакомства и рекомендации.
На крайний случай есть не очень честный лайфхак, но тут уж вам решать, использовать его или нет. Сократите количество прыжков и растяните сроки в резюме. Эйчар фильтр пройдете, на собес попадете, а когда уже вы понравитесь людям, то мелкие нестыковки уже в понимающей обстановке объясните. Тем более сразу с порога трудовую никто не просит предъявить, чтобы всё сверить.
Вы прыгун, ну и что?
Это вполне нормально. Есть куча мест, где нужны работники на короткий срок, или где готовы к постоянной ротации. Плюс есть мнение (я не согласен, что оно единственно верное), что так легче себе набить хорошую зарплату.
Да, определенный класс долгосрочных вакансий для вас, скорее всего, будет закрыт (ну я бы для долгосрочного сотрудничества прыгуна не рассматривал), но, наверное, это не такая большая трагедия и потеря.
Итог
Рынок сейчас таков, что заботиться надо не о строчках с мест работы, а о своих профессиональных навыках. Были бы нормальные скиллы, а работа и денежки найдутся.
Главное, сами поймите, в каком формате вам хочется работать и на каких условиях. Ну и работодателю всё это понятно донесите.
Недавно поступил вопрос:
«Что делать, если сменил пяток компаний из-за неподходящих условий, и теперь твое резюме кричит "я работаю недолго в компаниях", что читается HR'ами как "я от бабушки ушел и от дедушки ушел и от тебя уйду"?»
Хотелось бы рассмотреть несколько вариаций данной ситуации.
Вы по резюме прыгун, но таким быть не хотите
Если вы не хотите быть прыгуном, но на неделе вы каждые полгода-год меняете работу, то тут надо внимательно посмотреть, почему так получилось. Возможно, вам просто кажется, что вы не такой, а вы такой.
А возможно, просто обстоятельства сложились неудачным образом, и с вами произошла череда неудачных совпадений.
Если это совпадения, то вам надо объясниться, почему факты таковы, что про вас можно подумать не то, что вам бы хотелось.
Если вы уже дошли до собеса, то объяснять это надо, но аккуратно. Не поливайте никого грязью и не рассказывайте, какие все дураки и кидалы. Это создаст о вас негативное впечатление и покажется, что вы так будете про всех своих работодателей думать и говорить. Тем не менее надо спокойно объяснить, что так совпало, что устраивался туда, где, например, договоренности не соблюдались, а вы человек порядочный и так не можете работать, когда какая-то из сторон необязательная.
Правда, иной раз можно до собеса и не дойти, а пропасть на этапе эйчар фильтра. Так что пишите какое-то пояснительное письмо при отклике, или в графе «о себе» что-то такое поясняющее пишите, что ищете постоянную комфортную работу и прыгать без нужды не хотите.
Есть шанс, что часть эйчаров не дочитает до этого момента, но тут уже мало что можно поделать. Старайтесь по возможности обойти этот фильтр и заходить куда-то напрямую к нанимающим менеджерам через знакомства и рекомендации.
На крайний случай есть не очень честный лайфхак, но тут уж вам решать, использовать его или нет. Сократите количество прыжков и растяните сроки в резюме. Эйчар фильтр пройдете, на собес попадете, а когда уже вы понравитесь людям, то мелкие нестыковки уже в понимающей обстановке объясните. Тем более сразу с порога трудовую никто не просит предъявить, чтобы всё сверить.
Вы прыгун, ну и что?
Это вполне нормально. Есть куча мест, где нужны работники на короткий срок, или где готовы к постоянной ротации. Плюс есть мнение (я не согласен, что оно единственно верное), что так легче себе набить хорошую зарплату.
Да, определенный класс долгосрочных вакансий для вас, скорее всего, будет закрыт (ну я бы для долгосрочного сотрудничества прыгуна не рассматривал), но, наверное, это не такая большая трагедия и потеря.
Итог
Рынок сейчас таков, что заботиться надо не о строчках с мест работы, а о своих профессиональных навыках. Были бы нормальные скиллы, а работа и денежки найдутся.
Главное, сами поймите, в каком формате вам хочется работать и на каких условиях. Ну и работодателю всё это понятно донесите.
👍2
Поменяй компанию, или поменяй компанию
Думаю, все мы так или иначе работали в ситуациях, когда вроде бы в целом в работе неплохо, но есть какие-то моменты, которые прям конкретно не нравятся.
Что же делать, как же быть?
Эскапизм
В ИТшной среде, особенно на позиции рядовых разработчиков, или менеджеров низшего уровня, эскапизм является довольно популярной практикой.
Рынок труда такой, что, если ты более-менее нормальный специалист, умеешь делать работу, можешь написать своё имя без ошибок и не ходишь под себя – тебе всегда найдется место в другой компании.
Зачем бороться с трудностями, когда от них можно просто убежать?
В принципе, стратегия рабочая, но есть нюансы.
Трудности есть на любой работе и далеко убежать не получится. Плюс, убегая от известных трудностей, вы бежите в неизвестные, про которые вам на собеседовании вряд ли расскажут. Уже по факту, когда вы придете в новую компанию, вам скажут «нуууу…. просто так исторически сложилось».
Инициатива и изменение
Более трудный и боевой вариант – взять дело в свои руки и сделать из всего плохого всё хорошее.
Тоже хорошая стратегия, но есть нюансы.
Усилий и времени придется затратить много, а результат может оказаться плохим. В итоге силы, время, нервы впалили, а карьера простаивает, вы профессионально стагнируете и вообще света белого впереди не видно.
Срединный путь
Лично я придерживаюсь того, что если мне в целом комфортно работается и я вижу определенные перспективы для себя и для компании, то я выбираю путь инициативы и изменения.
Как это делать – это, наверное, тема для отдельного поста. А по-хорошему, и отдельной книги. Например, я сейчас читаю М. Уоткинс «Первые 90 дней», и там вся книга про то, как производить изменения в компании на разных её стадиях, при этом не выстрелив себе в ногу.
Однако, если я увижу, что уже потратил достаточное количество сил и времени, а результат так и остается недостижим, то тогда я выберу эскапизм. Жизнь у меня одна и тратить её на борьбу с ветряными мельницами я не готов.
В моей практике было так, что многое получалось изменить, а бывало, что приходилось сменить саму компанию. Выбор я старался делать осознанный. Не скажу, что он был идеален, но в целом – ни о чем не жалею.
Итог
Постарайтесь после первых проблем не впадать в крайности, а всё взвесить и хорошенько проанализировать. С холодной головой прикиньте, выгодно ли вам сбегать или производить серьезные изменения.
Ведь побег - это легко, но оставляет вас на том же уровне, а изменения – трудно, но позволяет вам расти.
Думаю, все мы так или иначе работали в ситуациях, когда вроде бы в целом в работе неплохо, но есть какие-то моменты, которые прям конкретно не нравятся.
Что же делать, как же быть?
Эскапизм
В ИТшной среде, особенно на позиции рядовых разработчиков, или менеджеров низшего уровня, эскапизм является довольно популярной практикой.
Рынок труда такой, что, если ты более-менее нормальный специалист, умеешь делать работу, можешь написать своё имя без ошибок и не ходишь под себя – тебе всегда найдется место в другой компании.
Зачем бороться с трудностями, когда от них можно просто убежать?
В принципе, стратегия рабочая, но есть нюансы.
Трудности есть на любой работе и далеко убежать не получится. Плюс, убегая от известных трудностей, вы бежите в неизвестные, про которые вам на собеседовании вряд ли расскажут. Уже по факту, когда вы придете в новую компанию, вам скажут «нуууу…. просто так исторически сложилось».
Инициатива и изменение
Более трудный и боевой вариант – взять дело в свои руки и сделать из всего плохого всё хорошее.
Тоже хорошая стратегия, но есть нюансы.
Усилий и времени придется затратить много, а результат может оказаться плохим. В итоге силы, время, нервы впалили, а карьера простаивает, вы профессионально стагнируете и вообще света белого впереди не видно.
Срединный путь
Лично я придерживаюсь того, что если мне в целом комфортно работается и я вижу определенные перспективы для себя и для компании, то я выбираю путь инициативы и изменения.
Как это делать – это, наверное, тема для отдельного поста. А по-хорошему, и отдельной книги. Например, я сейчас читаю М. Уоткинс «Первые 90 дней», и там вся книга про то, как производить изменения в компании на разных её стадиях, при этом не выстрелив себе в ногу.
Однако, если я увижу, что уже потратил достаточное количество сил и времени, а результат так и остается недостижим, то тогда я выберу эскапизм. Жизнь у меня одна и тратить её на борьбу с ветряными мельницами я не готов.
В моей практике было так, что многое получалось изменить, а бывало, что приходилось сменить саму компанию. Выбор я старался делать осознанный. Не скажу, что он был идеален, но в целом – ни о чем не жалею.
Итог
Постарайтесь после первых проблем не впадать в крайности, а всё взвесить и хорошенько проанализировать. С холодной головой прикиньте, выгодно ли вам сбегать или производить серьезные изменения.
Ведь побег - это легко, но оставляет вас на том же уровне, а изменения – трудно, но позволяет вам расти.
SDCast
Есть хороший и очень уважаемый мной подкаст - SDCast. Он выходит в формате интервью с одним гостем.
Слушаю его с интересом уже лет 5, да и с Костей лично давненько уже знаком.
Как я там побывал
Недавно мне довелось побывать там гостем. В своей голове я представлял, что я приду, мы о многом поговорим (ибо во многом схожи по интересам), и будет круто, весело, интересно и полезно.
В реальности вышло немного не так🙂 Помимо того, что я трудноватый собеседник, так я еще и излишне заволновался, видимо, из-за особо теплого отношения к подкасту.
В итоге я скомкано и много набуробил по разным темам, не успевая никуда погрузиться достаточно глубоко. Как дед, который забыл принять таблетки, и решил всем окружающим рассказать всю свою жизнь: как рос, как учился, как работал, как консалтингом занимался и т.д.😀
Так что в целом для обычной беседы по куче разных интересов, наверное, мои рассказы вполне сгодятся. Для раскрытия какой-то темы полностью – этого точно будет маловато. Но столько тем в разумное время чисто физически раскрыть нормально бы и не получилось. Иными словами, я бил по площадям
Если в результате прослушивания вам не понравятся слова-паразиты, сбивчивость и скакание с темы на тему – сорян, уже ничего не изменить. Я для себя сделал выводы, что надо работать над собой, над планом выступления, над умением чутко слушать собеседника, больше практиковаться и т.д.
А если вам хочется обсудить какие-то конкретные темы подробнее, то приходите в чат подкаста https://news.1rj.ru/str/SDCast , где я тоже состою, там и обсудим.
Спасибо Косте
Костя делает замечательное дело уже много лет, и я ему искренне благодарен за это.
Итог
Слушайте выпуск со мной по ссылке https://sdcast.ksdaemon.ru/2021/04/sdcast-131/. Надеюсь кому-то будет интересно и/или полезно. Задавайте вопросы, дискутируйте. Я всегда открыт к общению.
Бонусные ссылки примерно про одно и то же на разных платформах:
https://www.patreon.com/posts/49781483
https://www.youtube.com/watch?v=HbCZwpj7qGs
https://twitter.com/SDCast_podcast/status/1380144615764987904
https://twitter.com/KSDaemon/status/1380145775762620428
https://vk.com/feed?w=wall-194574132_36
https://www.facebook.com/SDCastPodcast/posts/284904473207097
Есть хороший и очень уважаемый мной подкаст - SDCast. Он выходит в формате интервью с одним гостем.
Слушаю его с интересом уже лет 5, да и с Костей лично давненько уже знаком.
Как я там побывал
Недавно мне довелось побывать там гостем. В своей голове я представлял, что я приду, мы о многом поговорим (ибо во многом схожи по интересам), и будет круто, весело, интересно и полезно.
В реальности вышло немного не так🙂 Помимо того, что я трудноватый собеседник, так я еще и излишне заволновался, видимо, из-за особо теплого отношения к подкасту.
В итоге я скомкано и много набуробил по разным темам, не успевая никуда погрузиться достаточно глубоко. Как дед, который забыл принять таблетки, и решил всем окружающим рассказать всю свою жизнь: как рос, как учился, как работал, как консалтингом занимался и т.д.😀
Так что в целом для обычной беседы по куче разных интересов, наверное, мои рассказы вполне сгодятся. Для раскрытия какой-то темы полностью – этого точно будет маловато. Но столько тем в разумное время чисто физически раскрыть нормально бы и не получилось. Иными словами, я бил по площадям
Если в результате прослушивания вам не понравятся слова-паразиты, сбивчивость и скакание с темы на тему – сорян, уже ничего не изменить. Я для себя сделал выводы, что надо работать над собой, над планом выступления, над умением чутко слушать собеседника, больше практиковаться и т.д.
А если вам хочется обсудить какие-то конкретные темы подробнее, то приходите в чат подкаста https://news.1rj.ru/str/SDCast , где я тоже состою, там и обсудим.
Спасибо Косте
Костя делает замечательное дело уже много лет, и я ему искренне благодарен за это.
Итог
Слушайте выпуск со мной по ссылке https://sdcast.ksdaemon.ru/2021/04/sdcast-131/. Надеюсь кому-то будет интересно и/или полезно. Задавайте вопросы, дискутируйте. Я всегда открыт к общению.
Бонусные ссылки примерно про одно и то же на разных платформах:
https://www.patreon.com/posts/49781483
https://www.youtube.com/watch?v=HbCZwpj7qGs
https://twitter.com/SDCast_podcast/status/1380144615764987904
https://twitter.com/KSDaemon/status/1380145775762620428
https://vk.com/feed?w=wall-194574132_36
https://www.facebook.com/SDCastPodcast/posts/284904473207097
Telegram
SDCast discussions
Обсуждаем выпуски подкаста, делимся впечатлениями и предлагаем гостей! Сайт: sdcast.ksdaemon.ru
В группе включены одобрения ибо спаммеры задолбали.
В группе включены одобрения ибо спаммеры задолбали.
Байкшеддинг
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
🔥2
Менеджеры с техническим бэкграундом
Хороший менеджер с внятным техническим бэкграундом – человек редкий. И скорее всего далеко не каждому удалось с таким поработать. Однако те, кто с подобными ребятами сталкивался, отмечают их разумность, эффективность и быстроту результатов.
В чем разница с гуманитариями?
Как показывает моя и чужая практика – ощутимая разница присутствует. Она начинает проявляться, как только дело касается какой-то инженерной практики, разработки, инфраструктуры и т. д.
Можно сколько угодно говорить про то, что менеджер не должен разбираться в деталях, он должен только подбирать крутую команду и направлять её. Однако эти лидерские разговоры быстро разбиваются о быт инженерных задач.
Да, конечно, менеджеру не надо прям в деталях знать, как их делать, но, если он в целом более-менее компетентен, можно сэкономить море времени на обсуждениях, согласованиях и даже разоблачении обманщиков. Сэкономить и время, и нервы, и трудозатраты.
А если вы подрядчик, то, выставляя вперед такого толкового менеджера, можно сразу заработать побольше авторитета в глазах заказчика.
Осторожнее с менеджерами-технарями
Звучит всё вышесказанное так, как будто прямо сейчас надо всех программистов перевести в менеджеры и наступит счастье. Однако это не так. Очень часто бывает, что хороший программист становится плохим менеджером, который приносит боль себе и коллегам.
Всё, что я говорил выше, относится к сравнению хороший менеджер без технического бэкграунда vs хороший менеджер с оным.
А в общем случае, конечно, лучше хороший менеджер-гуманитарий, чем плохой менеджер-технарь
Я перестаю быть крутым инженером, а менеджеров много
Оооочень частая проблема технарей – боязнь обесцениться в рядового менеджера, каких много.
Поэтому я этот пост и пишу. Не надо бояться. Если у вас правда получится стать толковым менеджером, то у вас будет очевидный плюс среди моря гуманитариев в менеджменте.
Кто знает в этом толк – вас с руками оторвет, не переживайте.
Итог
Если вы столкнулись с толковым менеджером технарем – радуйтесь и держите его.
Если видите, что человек может и хочет расти в менеджмент, а сейчас простой инженер – помогите ему, возможно, у вас
получится вырастить очень ценного сотрудника.
Если вы не хотите быть менеджером, то и не будьте🙂 Хорошие инженеры тоже очень нужны, важны и востребованы.
Хороший менеджер с внятным техническим бэкграундом – человек редкий. И скорее всего далеко не каждому удалось с таким поработать. Однако те, кто с подобными ребятами сталкивался, отмечают их разумность, эффективность и быстроту результатов.
В чем разница с гуманитариями?
Как показывает моя и чужая практика – ощутимая разница присутствует. Она начинает проявляться, как только дело касается какой-то инженерной практики, разработки, инфраструктуры и т. д.
Можно сколько угодно говорить про то, что менеджер не должен разбираться в деталях, он должен только подбирать крутую команду и направлять её. Однако эти лидерские разговоры быстро разбиваются о быт инженерных задач.
Да, конечно, менеджеру не надо прям в деталях знать, как их делать, но, если он в целом более-менее компетентен, можно сэкономить море времени на обсуждениях, согласованиях и даже разоблачении обманщиков. Сэкономить и время, и нервы, и трудозатраты.
А если вы подрядчик, то, выставляя вперед такого толкового менеджера, можно сразу заработать побольше авторитета в глазах заказчика.
Осторожнее с менеджерами-технарями
Звучит всё вышесказанное так, как будто прямо сейчас надо всех программистов перевести в менеджеры и наступит счастье. Однако это не так. Очень часто бывает, что хороший программист становится плохим менеджером, который приносит боль себе и коллегам.
Всё, что я говорил выше, относится к сравнению хороший менеджер без технического бэкграунда vs хороший менеджер с оным.
А в общем случае, конечно, лучше хороший менеджер-гуманитарий, чем плохой менеджер-технарь
Я перестаю быть крутым инженером, а менеджеров много
Оооочень частая проблема технарей – боязнь обесцениться в рядового менеджера, каких много.
Поэтому я этот пост и пишу. Не надо бояться. Если у вас правда получится стать толковым менеджером, то у вас будет очевидный плюс среди моря гуманитариев в менеджменте.
Кто знает в этом толк – вас с руками оторвет, не переживайте.
Итог
Если вы столкнулись с толковым менеджером технарем – радуйтесь и держите его.
Если видите, что человек может и хочет расти в менеджмент, а сейчас простой инженер – помогите ему, возможно, у вас
получится вырастить очень ценного сотрудника.
Если вы не хотите быть менеджером, то и не будьте🙂 Хорошие инженеры тоже очень нужны, важны и востребованы.
🔥6
Максимальная утилизация ресурсов - это плохо
Есть совершенно понятная и очевидная каждому, не шибко разбирающемуся менеджеру мысль – все должны быть при деле.
Есть команда, есть рабочие руки, и все их надо нагрузить. И запланировать работу так, чтобы как только они освободятся, работа уже их ожидала: без отрыва от производства, так сказать.
Где-то тут могут крыться неочевидные проблемы. Давайте поищем.
Простои и ожидания
Если бестолковый менеджер всё-таки углубится в то, как его команда работает, то он обнаружит, что задачи часто не изолированные, а один работник сначала пилит свой кусочек задачи, затем отдает его другому, тот работает с ним и своей частью, передает дальше.
И вот чем дольше простои между тем, как один другому передал, а другой от чего-то левого освободился, принял задачу и начал свою часть пилить, тем медленнее задача завершится. А чем медленнее задачи завершаются, тем длиннее копится очередь этих задач.
А чем нагруженнее параллельными задачами каждый работник в этой цепи, тем дольше эти простои. Ой, оказывается, если нагрузить людей морем параллельной работы, она быстро не сделается, вот это лайфхак!
Вот вам замечательное видео с визуализацией по этому поводу https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy
Отряд замечает потерю бойца
Если в такой высоконагруженной команде с морем параллельных дел, когда все «при деле» (читай «работают изо всех сил не особо успевая»), выбывает хотя бы один человек, всё может резко усугубиться. Хотя бы одно звено в еле работающей цепи вываливается, и в этом месте скапливаются такие горы работы, которые сложно будет разгрести.
А выбыть может человек по сотне причин, в то время как успешный эффективный менеджер и не представляет, что его люди могут болеть, увольняться, ходить в отпуск, выгорать и прочим образом терять эффективность.
Какие новые идеи?
Потеря времени и способностей для креативного мышления – еще один отрицательный фактор для перегруженных команд. Некогда придумывать новые решения, некогда разбираться в новых технологиях и том, как их адаптировать для своих процессов, некогда даже проанализировать свои процессы на предмет разумности и эффективности.
Некогда точить пилу, когда всё время надо пилить.
Итог
Понятно, что бездельничать люди не должны, но при этом надо тщательно подходить к объему работы. И объему параллельной работы.
Не стоит думать, что если команда не успевает N задач делать, то чтобы повысить эффективность, надо им дать 2N задач и сказать, чтобы они «просто делали параллельно».
Подумайте об этом сами, покажите статью и видео эффективным менеджерам.
Есть совершенно понятная и очевидная каждому, не шибко разбирающемуся менеджеру мысль – все должны быть при деле.
Есть команда, есть рабочие руки, и все их надо нагрузить. И запланировать работу так, чтобы как только они освободятся, работа уже их ожидала: без отрыва от производства, так сказать.
Где-то тут могут крыться неочевидные проблемы. Давайте поищем.
Простои и ожидания
Если бестолковый менеджер всё-таки углубится в то, как его команда работает, то он обнаружит, что задачи часто не изолированные, а один работник сначала пилит свой кусочек задачи, затем отдает его другому, тот работает с ним и своей частью, передает дальше.
И вот чем дольше простои между тем, как один другому передал, а другой от чего-то левого освободился, принял задачу и начал свою часть пилить, тем медленнее задача завершится. А чем медленнее задачи завершаются, тем длиннее копится очередь этих задач.
А чем нагруженнее параллельными задачами каждый работник в этой цепи, тем дольше эти простои. Ой, оказывается, если нагрузить людей морем параллельной работы, она быстро не сделается, вот это лайфхак!
Вот вам замечательное видео с визуализацией по этому поводу https://www.youtube.com/watch?v=CostXs2p6r0&ab_channel=crispagileacademy
Отряд замечает потерю бойца
Если в такой высоконагруженной команде с морем параллельных дел, когда все «при деле» (читай «работают изо всех сил не особо успевая»), выбывает хотя бы один человек, всё может резко усугубиться. Хотя бы одно звено в еле работающей цепи вываливается, и в этом месте скапливаются такие горы работы, которые сложно будет разгрести.
А выбыть может человек по сотне причин, в то время как успешный эффективный менеджер и не представляет, что его люди могут болеть, увольняться, ходить в отпуск, выгорать и прочим образом терять эффективность.
Какие новые идеи?
Потеря времени и способностей для креативного мышления – еще один отрицательный фактор для перегруженных команд. Некогда придумывать новые решения, некогда разбираться в новых технологиях и том, как их адаптировать для своих процессов, некогда даже проанализировать свои процессы на предмет разумности и эффективности.
Некогда точить пилу, когда всё время надо пилить.
Итог
Понятно, что бездельничать люди не должны, но при этом надо тщательно подходить к объему работы. И объему параллельной работы.
Не стоит думать, что если команда не успевает N задач делать, то чтобы повысить эффективность, надо им дать 2N задач и сказать, чтобы они «просто делали параллельно».
Подумайте об этом сами, покажите статью и видео эффективным менеджерам.
YouTube
The resource utilization trap
Henrik Kniberg explains the resource utilization trap, how it impacts our ability to deliver and what we can do about it.
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
👍2
Некогда точить пилу, надо пилить!
Мудрый анекдот
Мужик пилит дерево, к нему подходит другой и говорит:
— Мужик, давно пилишь?
— 3 дня.
— А может тебе пилу заточить?
— Некогда мне, пилить нужно.
В реальной жизни
Эта абсурдная ситуация окружает нас сплошь и рядом. Порой в это даже сложно поверить.
- Есть рутинные ежедневные действия, которые вы делаете руками, но не автоматизировали до сих пор? Некогда точить пилу!
- Есть коллеги, у которых каждый день пожары, и они просто занимаются их тушением, никак не пытаясь разобраться в первопричинах? Некогда точить пилу!
- Есть желание вайти вайти, но при этом вы не занимаетесь изучением базовых фундаментальных принципов, а заучиваете что будет, если в реакте написать так, или сяк? Некогда точить пилу!
- Есть желание похудеть к лету, но вы не разбираетесь в питании, тренировках, а просто прочитали в яндекс.дзене, что если делать 100 скручиваний на пресс каждый день, то будет зашибись. Некогда точить пилу!
Остановитесь
Прекратите тратить время и генерировать сумбурный бесполезный труд. Остановитесь, подумайте о том, где действительно корень проблемы и вдумчиво разберитесь с этим. Локально вы потеряете чуть больше времени, но глобально вы сильно выиграете и по времени, и по качеству результатов своего труда.
Итог
Постоянно помните мудрый анекдот, и при малейших признаках того, что вы закрутились в суете, берите паузу для анализа ситуации.
Помогите сначала себе, потом своим товарищам осознать проблему и найти разумное решение.
Наточите, блин, уже свою пилу!
Мудрый анекдот
Мужик пилит дерево, к нему подходит другой и говорит:
— Мужик, давно пилишь?
— 3 дня.
— А может тебе пилу заточить?
— Некогда мне, пилить нужно.
В реальной жизни
Эта абсурдная ситуация окружает нас сплошь и рядом. Порой в это даже сложно поверить.
- Есть рутинные ежедневные действия, которые вы делаете руками, но не автоматизировали до сих пор? Некогда точить пилу!
- Есть коллеги, у которых каждый день пожары, и они просто занимаются их тушением, никак не пытаясь разобраться в первопричинах? Некогда точить пилу!
- Есть желание вайти вайти, но при этом вы не занимаетесь изучением базовых фундаментальных принципов, а заучиваете что будет, если в реакте написать так, или сяк? Некогда точить пилу!
- Есть желание похудеть к лету, но вы не разбираетесь в питании, тренировках, а просто прочитали в яндекс.дзене, что если делать 100 скручиваний на пресс каждый день, то будет зашибись. Некогда точить пилу!
Остановитесь
Прекратите тратить время и генерировать сумбурный бесполезный труд. Остановитесь, подумайте о том, где действительно корень проблемы и вдумчиво разберитесь с этим. Локально вы потеряете чуть больше времени, но глобально вы сильно выиграете и по времени, и по качеству результатов своего труда.
Итог
Постоянно помните мудрый анекдот, и при малейших признаках того, что вы закрутились в суете, берите паузу для анализа ситуации.
Помогите сначала себе, потом своим товарищам осознать проблему и найти разумное решение.
Наточите, блин, уже свою пилу!
👍1
Инфантил расправил плечи
Сегодня хочется поговорить о довольно скользкой теме.
Скользкая, потому что есть в ней и полезное зерно, но в глобальном смысле много бед может приключиться.
Успешная инфосекта
Существует ряд мотивационной хрени в разной форме: книги, курсы, видео, организации. И ладно бы, если бы это была просто абстрактная мотивация что-то созидать, но там в подавляющем большинстве случаев всё завязано на деньги. А в идеале не просто деньги, а легкие деньги от бездумного действия.
Вам там расскажут, что каждый может стать миллиардером, регулярно летающем на своем бизнес джете на Мальдивы просто, чтобы выпить тропический коктейль.
И главное, что для этого нужно сделать – ВИЗУАЛИЗИРОВАТЬ И ДЕЙСТВОВАТЬ. Обратите внимание, что про подумать, проанализировать, прикинуть риски, составить хороший план и так далее, там не очень-то говорится. Это ведь скучно, сложно и не каждый захочет заморачиваться.
Ожидание
Я реально знаю таких людей, которые начитались подобной литературы, напосещались таких тренингов.
Вот немного реальных примеров того, что они ожидают:
- Личный розовый кадиллак за год (это не шутка) с продажи косметики и бытовой химии.
- Новенький феррари за год с продажи оконных рам и входных дверей.
- Доход от 150к рублей в месяц после двух месяцев прохождения копеечных курсов по инстацыганству.
- Не работать никогда на дядю, будучи фрилансером, работая с солнечных пляжей по всему миру (про такое катастрофическое заблуждение в ИТ я отдельный пост напишу).
- Много денег и успеха, если всего лишь произносить каждое утро перед зеркалом аффирмации про деньги и успех.
А если обобщить, то это бизнес атлант, расправляющий плечи и летящий на крыльях мечты к заветным миллиардам и широкому общественному признанию.
Реальность
Начитавшиеся вдохновляющей литературы инфантилы начинают бездумно делать какие-то действия, при этом ожидая только самого успешного успеха.
В результате они тратят кучу времени, сил, остатков денег и нервов своих близких людей, при этом не получая ничего толкового в результате. Итог – разочарование, злость, депрессия, свистящая фляга.
При этом никому не приходит в голову, что если бы действительно был легкий рецепт успешного успеха, то уже все вокруг были бы суперзвездами.
Какая реальная польза?
Реальная польза в такой мотивации для умных людей существует. Зарядить человека на деятельность - это хорошо и полезно. А умный уже сам поймет, что надо не просто действовать абы как, а рационально и запланировано.
Итог
Будьте осторожны и вдумчивы. Критически мыслите, анализируя прочитанное и просмотренное.
Не гонитесь за легким и сказочным успехом.
Помните, что в большинстве случаев успеху сопутствует огромный труд и подготовка.
Сегодня хочется поговорить о довольно скользкой теме.
Скользкая, потому что есть в ней и полезное зерно, но в глобальном смысле много бед может приключиться.
Успешная инфосекта
Существует ряд мотивационной хрени в разной форме: книги, курсы, видео, организации. И ладно бы, если бы это была просто абстрактная мотивация что-то созидать, но там в подавляющем большинстве случаев всё завязано на деньги. А в идеале не просто деньги, а легкие деньги от бездумного действия.
Вам там расскажут, что каждый может стать миллиардером, регулярно летающем на своем бизнес джете на Мальдивы просто, чтобы выпить тропический коктейль.
И главное, что для этого нужно сделать – ВИЗУАЛИЗИРОВАТЬ И ДЕЙСТВОВАТЬ. Обратите внимание, что про подумать, проанализировать, прикинуть риски, составить хороший план и так далее, там не очень-то говорится. Это ведь скучно, сложно и не каждый захочет заморачиваться.
Ожидание
Я реально знаю таких людей, которые начитались подобной литературы, напосещались таких тренингов.
Вот немного реальных примеров того, что они ожидают:
- Личный розовый кадиллак за год (это не шутка) с продажи косметики и бытовой химии.
- Новенький феррари за год с продажи оконных рам и входных дверей.
- Доход от 150к рублей в месяц после двух месяцев прохождения копеечных курсов по инстацыганству.
- Не работать никогда на дядю, будучи фрилансером, работая с солнечных пляжей по всему миру (про такое катастрофическое заблуждение в ИТ я отдельный пост напишу).
- Много денег и успеха, если всего лишь произносить каждое утро перед зеркалом аффирмации про деньги и успех.
А если обобщить, то это бизнес атлант, расправляющий плечи и летящий на крыльях мечты к заветным миллиардам и широкому общественному признанию.
Реальность
Начитавшиеся вдохновляющей литературы инфантилы начинают бездумно делать какие-то действия, при этом ожидая только самого успешного успеха.
В результате они тратят кучу времени, сил, остатков денег и нервов своих близких людей, при этом не получая ничего толкового в результате. Итог – разочарование, злость, депрессия, свистящая фляга.
При этом никому не приходит в голову, что если бы действительно был легкий рецепт успешного успеха, то уже все вокруг были бы суперзвездами.
Какая реальная польза?
Реальная польза в такой мотивации для умных людей существует. Зарядить человека на деятельность - это хорошо и полезно. А умный уже сам поймет, что надо не просто действовать абы как, а рационально и запланировано.
Итог
Будьте осторожны и вдумчивы. Критически мыслите, анализируя прочитанное и просмотренное.
Не гонитесь за легким и сказочным успехом.
Помните, что в большинстве случаев успеху сопутствует огромный труд и подготовка.
👍2