🧪 Исследование для backend-разработчиков
Алексей Жидков (Эргономичный код) и коллеги проводят исследование, посвящённое поддерживаемости кода backend-ов: какие из известных подходов к разработке действительно упрощают жизнь разработчиков.
Если вы работали хотя бы три месяца над зрелым проектом, находившимся в разработке не менее полугода до вашего прихода — поучаствуйте, пожалуйста, в опросе.
📋 Это займет около 20 минут.
Ваши ответы помогут всему сообществу разработчиков лучше понять, что действительно влияет на поддерживаемость кода — вне зависимости от языка и фреймворка.
📊 Результаты исследования будут опубликованы осенью 2025 года на сайте: https://maintable-backends.tilda.ws/
👉 Принять участие: https://forms.yandex.ru/cloud/685ccc62eb614635657832a4
Будет круто, если вы поучаствуете в исследовании!
Алексей Жидков (Эргономичный код) и коллеги проводят исследование, посвящённое поддерживаемости кода backend-ов: какие из известных подходов к разработке действительно упрощают жизнь разработчиков.
Если вы работали хотя бы три месяца над зрелым проектом, находившимся в разработке не менее полугода до вашего прихода — поучаствуйте, пожалуйста, в опросе.
📋 Это займет около 20 минут.
Ваши ответы помогут всему сообществу разработчиков лучше понять, что действительно влияет на поддерживаемость кода — вне зависимости от языка и фреймворка.
📊 Результаты исследования будут опубликованы осенью 2025 года на сайте: https://maintable-backends.tilda.ws/
👉 Принять участие: https://forms.yandex.ru/cloud/685ccc62eb614635657832a4
Будет круто, если вы поучаствуете в исследовании!
Telegram
Эргономичный код
Канал о разработке поддерживаемых бакэндов - про классическую школу TDD, прагматичное функциональное программирование и архитектуру и немного DDD.
Группа: https://www.tgoop.com/+QJRqaHI8YD
https://azhidkov.pro
Группа: https://www.tgoop.com/+QJRqaHI8YD
https://azhidkov.pro
👍7🤮4👎3💩2👌2🌭1
Итак, на днях мыл посуду и течение принесло меня в твиттер, а там я обнаружил некий твит, который коротко звучал как: айтишные сеньоры кто они и что такое сеньорство.
Пройти мимо было сложно и я большим пальцем что есть сил вжал кнопку Ответить. Прошли сутки и я решил порассуждать, а что такое сеньорство реально (нейроны добежали только)
Кто-то там отвечал про зарплату, кто-то про то, что у вас (как у сеньора) есть джуны, но это все не интересно. На самом деле сеньоры или там мидлы везде разные. Последние компании, где я работал всегда выступали с заявлениями, что у нас нет джунов - только мидлы (редко) и сеньоры. Так вот, несмотря на это, на мой взгляд были и джуны, и даже тот, кто называл там себя лид бэкенда не был, на мой взгляд, этим самым лидом.
И вот для меня сеньор. - это инженер, способный сделать любую задачу на проекте под ключ, в задаче может быть, а может и не быть большая степень неопределенности, код или не код, это не важно. Это как в Call of Duty: Гоуст, на связи? Да, сэр. Проблемы есть? Никак нет, сэр. Ты либо решишь проблему, либо предложишь решение - а мы уже будем решать, насколько это нам подойдет и дорого или нет.
На мой взгляд, сеньор в целом не должен считать что-то не выполнимым. Выполнимо все, вопрос лишь в цене. И вот тут на сцену (какую сцену?) выходит как раз цена и качество. И вот сеньорское проявление - это найти баланс тут и предложить/сделать в балансе. Там где мидл увидит Кафку и микросервисы, сеньор может вполне предложить и монолит модульный и прочие вещи иногда непопулярные.
Второй (как будто первый был) важный момент - это то, что сеньор должен после себя оставлять понимание того, какие решения и почему были приняты, должна быть прозрачность в его действиях. Т.е. на таком уровне человек уже должен думать о том, что и как будет понятно другим - при чем не всегда даже на уровне кода. А на уровне проекта. Это может быть документация, может быть качественный код с тестами - не важно. Артефакт, опираясь на который уже такую задачу сможет пройти и менее грейдовый человек.
Третий момент (крутящий), который я бы выделил, это умение спорить и аргументировано отстаивать свою точку зрения. Т.е. в рамках выполнения задачи не всегда вы будете согласны с решениями тимлида, техлида (кого тех? все тут) или там даже архитектора (если такие водятся у вас). И вот тут сеньор должен уметь договориться и даже где-то сказать нет. При этом сейчас мир агрессивный и горячий мидл+ на вас тоже может прыгнуть с "универсальным" сервисом и пеной у рта. И вот сеньор как должен уметь держать удар от сильных мира сего, так и не скатываться в кровавую поножовщину за гаражами с мидлами или такими же сеньорами.
Четвертый момент, это, конечно, ответственность. За решение и понимание уже эксплуатации (потому что какая еще ответственность может быть без эксплуатации решения?). Это понимание что мы делаем, если что-то пошло не так. Где-то должно быть принятие рисков, а где-то, прости господи, митигация (чуть не стошнило сейчас).
Сейчас из зала летит помидор (закуска) и вопрос - а что тогда принципал? А в целом то же, но с более широкой областью - уже на уровне юнита, команд, ТРАЙБОВ (больно просто такое вспоминать, потому капсом).
При этом могут быть и команды из только сеньоров, вполне. Потому что главное - это решение проблем. И чем бОльшие проблемы ты можешь решить (а не заговорить тысячей встреч и не открыть свое РЕТРО ФМ) - тем выше ты и сильнее, вот ты и сеньор!
Адиос, скажет джун
Hasta luego, крикнет миддл
Hasta la vista, бросит сеньор
Пройти мимо было сложно и я большим пальцем что есть сил вжал кнопку Ответить. Прошли сутки и я решил порассуждать, а что такое сеньорство реально (нейроны добежали только)
Кто-то там отвечал про зарплату, кто-то про то, что у вас (как у сеньора) есть джуны, но это все не интересно. На самом деле сеньоры или там мидлы везде разные. Последние компании, где я работал всегда выступали с заявлениями, что у нас нет джунов - только мидлы (редко) и сеньоры. Так вот, несмотря на это, на мой взгляд были и джуны, и даже тот, кто называл там себя лид бэкенда не был, на мой взгляд, этим самым лидом.
И вот для меня сеньор. - это инженер, способный сделать любую задачу на проекте под ключ, в задаче может быть, а может и не быть большая степень неопределенности, код или не код, это не важно. Это как в Call of Duty: Гоуст, на связи? Да, сэр. Проблемы есть? Никак нет, сэр. Ты либо решишь проблему, либо предложишь решение - а мы уже будем решать, насколько это нам подойдет и дорого или нет.
На мой взгляд, сеньор в целом не должен считать что-то не выполнимым. Выполнимо все, вопрос лишь в цене. И вот тут на сцену (какую сцену?) выходит как раз цена и качество. И вот сеньорское проявление - это найти баланс тут и предложить/сделать в балансе. Там где мидл увидит Кафку и микросервисы, сеньор может вполне предложить и монолит модульный и прочие вещи иногда непопулярные.
Второй (как будто первый был) важный момент - это то, что сеньор должен после себя оставлять понимание того, какие решения и почему были приняты, должна быть прозрачность в его действиях. Т.е. на таком уровне человек уже должен думать о том, что и как будет понятно другим - при чем не всегда даже на уровне кода. А на уровне проекта. Это может быть документация, может быть качественный код с тестами - не важно. Артефакт, опираясь на который уже такую задачу сможет пройти и менее грейдовый человек.
Третий момент (крутящий), который я бы выделил, это умение спорить и аргументировано отстаивать свою точку зрения. Т.е. в рамках выполнения задачи не всегда вы будете согласны с решениями тимлида, техлида (кого тех? все тут) или там даже архитектора (если такие водятся у вас). И вот тут сеньор должен уметь договориться и даже где-то сказать нет. При этом сейчас мир агрессивный и горячий мидл+ на вас тоже может прыгнуть с "универсальным" сервисом и пеной у рта. И вот сеньор как должен уметь держать удар от сильных мира сего, так и не скатываться в кровавую поножовщину за гаражами с мидлами или такими же сеньорами.
Четвертый момент, это, конечно, ответственность. За решение и понимание уже эксплуатации (потому что какая еще ответственность может быть без эксплуатации решения?). Это понимание что мы делаем, если что-то пошло не так. Где-то должно быть принятие рисков, а где-то, прости господи, митигация (чуть не стошнило сейчас).
Сейчас из зала летит помидор (закуска) и вопрос - а что тогда принципал? А в целом то же, но с более широкой областью - уже на уровне юнита, команд, ТРАЙБОВ (больно просто такое вспоминать, потому капсом).
При этом могут быть и команды из только сеньоров, вполне. Потому что главное - это решение проблем. И чем бОльшие проблемы ты можешь решить (а не заговорить тысячей встреч и не открыть свое РЕТРО ФМ) - тем выше ты и сильнее, вот ты и сеньор!
Адиос, скажет джун
Hasta luego, крикнет миддл
Hasta la vista, бросит сеньор
🔥40👍18🏆7❤6❤🔥2🫡1
В пятницу резко встал со стула и потемнело в глазах настолько, что в коленке стрельнуло и в голову пришла мылсь про, прости Господи, ИНЖЕНЕРНУЮ КУЛЬТУРУ
Тема острая, пока думал, я даже порезался, но все же. Все компании (большие и маленькие) всегда говорят про инженерную культуру, дескать вот У НАС культура, ощущаешь даже когда мимо офиса проходишь, а уж по видеосвязи в голову дает так, что потом не встанешь без нашатыря
И вот я подумал (редкое явление), а что реально такое - инженерная культура? Вот есть у вас проект, вы планируете запуск и понимаете, что ну не более 2 RPS там будет нагрузка по началу. И вот вы думаете, эта задача решается одним сервисом, такую нагрузку потянет кто угодно. Но 1 сервис - это не солидно же. Да и засмеют в курилке. Потом вы смотрите на матрицу компетенций в компании (а там вам мистер Смит и Нео улыбаются) и понимаете, что ну это не просто не серьезно, а прямо таки опасно для карьеры. И вот вы уже как будто бы операцию по улучшению зрения сделали и сейчас видно лучше, что тут не 1, тут минимум 4 надо - тут есть что распилить по доменам. При этом продукт для вас новый и домены вы не знаете - это все вы закладываете 'на будущее'. Потом, когда RPS будет больше IQ вашего тимлида (около 80), вот там то это все и пригодится. Дело осложняется еще тем, что вы в целом реально сообразительный малый, вы понимаете, что ну сделать 4 сервиса это не так сложно - ну недельку посидеть. Потом, конечно, оказывается, что и тестировать такое сложнее, и вообще в целом когнитивная сложность увеличивается, но это проблемы QA (кто квакает?).
И вот высокая это инженерная культура? Или низкая? Но ведь реально делают же, да и наверняка неплохо делают. Чуть дольше срок, потом многое можно выкинуть или ОТРЕФАКТОРИТЬ, но зато масштаб!
А о чем мысль то? Потерял, но наступил. Во всех этих Бигтехах, как будто, вот оно - матрица, руководитель, все тебя накачивает идти в ту сторону.
Это как в анекдоте:
- А у меня отец машину поднять может!
- А у меня автобус!
- А у меня, вот у меня, дед землю двигает и звезды видел!
- А вот он звезды видел, какие они?
- Ну они такие теплые, круглые...
- Это были яйца моего деда
И вот вроде есть и тимлид, и руководители там на всех категориях, но как будто бы, есть такая мысль, что ты один на один с этой матрицей и мыслью, что надо минимум 5к микросервисов, чтобы вкрутить лампочку.
А всего то и надо, чтобы кто-то просто сказал, старина, у. тебя 5 RPS в пике (пика пика).
Так к чему я все это? Инженерная культура! Когда у вас много сервисов - показательно. Но при этом, как будто, со всех сторон, даже в минус.
И когда нибудь, видит Бог, введут целый раздел во всех ADR, TDR, ArchDoc и прочему - ОБОСНОВАНИЕ для нового сервиса. Не нагрузку, не область задач, а именно обоснование.
А потом и вовсе оверинжинирнг будет минусом для пересомтра.
Кстати, забавный факт, если не переключить раскладку и начать писать create - то получится скуф
Тема острая, пока думал, я даже порезался, но все же. Все компании (большие и маленькие) всегда говорят про инженерную культуру, дескать вот У НАС культура, ощущаешь даже когда мимо офиса проходишь, а уж по видеосвязи в голову дает так, что потом не встанешь без нашатыря
И вот я подумал (редкое явление), а что реально такое - инженерная культура? Вот есть у вас проект, вы планируете запуск и понимаете, что ну не более 2 RPS там будет нагрузка по началу. И вот вы думаете, эта задача решается одним сервисом, такую нагрузку потянет кто угодно. Но 1 сервис - это не солидно же. Да и засмеют в курилке. Потом вы смотрите на матрицу компетенций в компании (а там вам мистер Смит и Нео улыбаются) и понимаете, что ну это не просто не серьезно, а прямо таки опасно для карьеры. И вот вы уже как будто бы операцию по улучшению зрения сделали и сейчас видно лучше, что тут не 1, тут минимум 4 надо - тут есть что распилить по доменам. При этом продукт для вас новый и домены вы не знаете - это все вы закладываете 'на будущее'. Потом, когда RPS будет больше IQ вашего тимлида (около 80), вот там то это все и пригодится. Дело осложняется еще тем, что вы в целом реально сообразительный малый, вы понимаете, что ну сделать 4 сервиса это не так сложно - ну недельку посидеть. Потом, конечно, оказывается, что и тестировать такое сложнее, и вообще в целом когнитивная сложность увеличивается, но это проблемы QA (кто квакает?).
И вот высокая это инженерная культура? Или низкая? Но ведь реально делают же, да и наверняка неплохо делают. Чуть дольше срок, потом многое можно выкинуть или ОТРЕФАКТОРИТЬ, но зато масштаб!
А о чем мысль то? Потерял, но наступил. Во всех этих Бигтехах, как будто, вот оно - матрица, руководитель, все тебя накачивает идти в ту сторону.
Это как в анекдоте:
- А у меня отец машину поднять может!
- А у меня автобус!
- А у меня, вот у меня, дед землю двигает и звезды видел!
- А вот он звезды видел, какие они?
- Ну они такие теплые, круглые...
- Это были яйца моего деда
И вот вроде есть и тимлид, и руководители там на всех категориях, но как будто бы, есть такая мысль, что ты один на один с этой матрицей и мыслью, что надо минимум 5к микросервисов, чтобы вкрутить лампочку.
А всего то и надо, чтобы кто-то просто сказал, старина, у. тебя 5 RPS в пике (пика пика).
Так к чему я все это? Инженерная культура! Когда у вас много сервисов - показательно. Но при этом, как будто, со всех сторон, даже в минус.
И когда нибудь, видит Бог, введут целый раздел во всех ADR, TDR, ArchDoc и прочему - ОБОСНОВАНИЕ для нового сервиса. Не нагрузку, не область задач, а именно обоснование.
А потом и вовсе оверинжинирнг будет минусом для пересомтра.
Кстати, забавный факт, если не переключить раскладку и начать писать create - то получится скуф
🔥21👍11😁8❤🔥3❤2✍1🤯1
This media is not supported in your browser
VIEW IN TELEGRAM
Общение с юристами и безопасниками по новым фичам мне всегда напоминает это.
😁34💯3
Вчера почти весь день шел дождь и количеством осадков вымыло ко мне твит.
В комментариях там еще достаточно большое количество людей писало, что вот я тимлид, но в код и прочее лезть не хочу - реально сложно найти работу.
Ну и я не мог проплыть мимо. И вот я думаю, что это наоборот признак хороший, что 'просто менеджеров' уже не ждут.
На моем опыте, чтобы быть 'только про людей' и быть тимлидом - надо быть невероятно крутым психологом. И я таких встречал только одного за всю карьеру. И эточеловек, ставший при жизни легендой. Народный артист Советского Союза, России скорее исключение, чем правило.
Тимлид, который боится кода или у которого рвотный порыв при открытии IDE снимается только уколом - это, для меня, очень плохой тимлид.
И речь тут не про то, что человек в соло должен закрывать таски, но банально понимать что происходит, на мой взгляд, надо уметь или мочь разобраться.
Тимлид, который построил процесс разработки, но сам в разработку боится даже глянуть и только через обратную связь спрашивает - ну как там? Лучше? Это вообще нонсенс.
Тимлид не должен быть лучшим разработчиком, да и входить в топ-3 коммитера тоже не надо. Но воспользоваться СВОИМ же процессом не хотеть?
Вообще, для меня тимлид - это роль, которая решает проблемы команды и проекта. Проблемы могут быть разные, но мы, блин, про разработку же - значит и в разработке надо понимать, не отпускать руки от клавиатуры.
Вот на уровне выше (тимлид тимлидов там) - там уже понятно, что уровен абстракции совсем иной, но и вы не разработкой проекта занимаетесь на этой позиции.
Поэтому мой совет - это каким бы вы тимлидом не были, то не забывайте иногда работать руками, проверять свои же процессы и задачи, хоть чуть-чуть, даже при сложностях, но выделяйте время 'растрясти жирок'. И если вы тимлид - стараться надо развиваться (кмк) и горизонтально - чтобы больше понимать о разработке проекта и того, что в нем применяется.
В комментариях там еще достаточно большое количество людей писало, что вот я тимлид, но в код и прочее лезть не хочу - реально сложно найти работу.
Ну и я не мог проплыть мимо. И вот я думаю, что это наоборот признак хороший, что 'просто менеджеров' уже не ждут.
На моем опыте, чтобы быть 'только про людей' и быть тимлидом - надо быть невероятно крутым психологом. И я таких встречал только одного за всю карьеру. И это
Тимлид, который боится кода или у которого рвотный порыв при открытии IDE снимается только уколом - это, для меня, очень плохой тимлид.
И речь тут не про то, что человек в соло должен закрывать таски, но банально понимать что происходит, на мой взгляд, надо уметь или мочь разобраться.
Тимлид, который построил процесс разработки, но сам в разработку боится даже глянуть и только через обратную связь спрашивает - ну как там? Лучше? Это вообще нонсенс.
Тимлид не должен быть лучшим разработчиком, да и входить в топ-3 коммитера тоже не надо. Но воспользоваться СВОИМ же процессом не хотеть?
Вообще, для меня тимлид - это роль, которая решает проблемы команды и проекта. Проблемы могут быть разные, но мы, блин, про разработку же - значит и в разработке надо понимать, не отпускать руки от клавиатуры.
Вот на уровне выше (тимлид тимлидов там) - там уже понятно, что уровен абстракции совсем иной, но и вы не разработкой проекта занимаетесь на этой позиции.
Поэтому мой совет - это каким бы вы тимлидом не были, то не забывайте иногда работать руками, проверять свои же процессы и задачи, хоть чуть-чуть, даже при сложностях, но выделяйте время 'растрясти жирок'. И если вы тимлид - стараться надо развиваться (кмк) и горизонтально - чтобы больше понимать о разработке проекта и того, что в нем применяется.
👍31💯10❤7🏆3
Тренировал большой палец правой руки (так как спорт - это жизнь) и листал ленту, снова попался твит, который я решил обсудить с вами (кто вы кто вы я один тут).
Изначально речь шла о том, что вот вы тимлид и не надо сильно вмешиваться, подстраховывать вечно всех и человек (по видимому, довольно опасный для Дим) написал, что он узнал себя - а что делать дескать?
На мой взгляд, рассуждения, что вот он там страдают - это неверно. Все же вы спланировали какой-то объем работ и каждый на старте взял свою часть - чтобы сделать ее самому (ну плюс минус). Если ты сделал свою часть быстрее/лучше/сильнее - это не значит, что надо идти и подтягивать тех, кто забуксовал. Можно о таком подумать, если вы прямо понимаете, что цель вашего там спринта (или просто ваша цель) под угрозой - тут уже надо думать об общей выживаемости, что называется. Но если плюс-минус все под контролем, то вмешиваться не стоит, кмк. Вы молодец - вы сделали быстрее. Но дайте и другим быть молодцами, стать ими - сделать свою часть, на которую все и комитились. Победить в своей битве с задачами. Вообще, человеку очень важны победы - от них многое идет в мотивацию и продуктивность, когда же вы побеждаете всегда с кем-то (будь то тимлид, брат, сват или там батя) - рано или поздно начнет накапливаться проблема. Она может выражаться в том, что человек может начать просто уже ждать вашей помощи (снизив требования к себе), может выражаться в том, что уверенность снизится и начнет пасовать перед многими задачами уже он, да много в чем может быть проблема. Это же и есть тот рост, о котором говорят - он в том числе и про преодоление.
Еще есть такой момент, что иногда люди намеренно не хотят делать что-то слишком быстро: где-то человек понимает, что тогда дадут еще задачу и зачем торопиться? Где-то просто такой подход к работе может быть. И вот такие врывы-подключения тимлида также могут быть негативно восприняты даже. Не говоря уже о том, что это довольно плохая метрика, что вот всегда надо врываться.
Зачастую даже (если позволяет проект) лучше прямо не сделать что-то (явно потом разобрав почему так получилось), чем вот все закрывать и делая такие мнимые победы. Но опять же, бывают проекты, где выполнение целей - вопрос выживаемости, тут не до учебы на ошибках так явно.
В целом, кстати, тут можно вообще покрутить эту скорость: типа если человек в плане все что надо сделал, заранее прямо за, пусть будет, день, то можно не просто давать ему очередную таску из очереди, а, например, дать прямо явно дей оф, или там попробовать в это время попросить его поискать проблемы проекта, что-то решить из области, где ему давно хотелось покопаться там, короче сделать такой вот момент часто бывает полезнее намного, чем следующая таска: так как и позволяет чуть уйти от 'конвеера' в котором многим тяжело, сделать так, чтобы хоть как-то нивелировать те самые настроения 'зачем делать быстрее - все равно снова дадут задачу'.
Короче мысль простая: тимлид он про команду и достижение целей командой. Как писали на зеленой карточке: я - лидер, мы - команда, все для клиента.😊
Изначально речь шла о том, что вот вы тимлид и не надо сильно вмешиваться, подстраховывать вечно всех и человек (по видимому, довольно опасный для Дим) написал, что он узнал себя - а что делать дескать?
На мой взгляд, рассуждения, что вот он там страдают - это неверно. Все же вы спланировали какой-то объем работ и каждый на старте взял свою часть - чтобы сделать ее самому (ну плюс минус). Если ты сделал свою часть быстрее/лучше/сильнее - это не значит, что надо идти и подтягивать тех, кто забуксовал. Можно о таком подумать, если вы прямо понимаете, что цель вашего там спринта (или просто ваша цель) под угрозой - тут уже надо думать об общей выживаемости, что называется. Но если плюс-минус все под контролем, то вмешиваться не стоит, кмк. Вы молодец - вы сделали быстрее. Но дайте и другим быть молодцами, стать ими - сделать свою часть, на которую все и комитились. Победить в своей битве с задачами. Вообще, человеку очень важны победы - от них многое идет в мотивацию и продуктивность, когда же вы побеждаете всегда с кем-то (будь то тимлид, брат, сват или там батя) - рано или поздно начнет накапливаться проблема. Она может выражаться в том, что человек может начать просто уже ждать вашей помощи (снизив требования к себе), может выражаться в том, что уверенность снизится и начнет пасовать перед многими задачами уже он, да много в чем может быть проблема. Это же и есть тот рост, о котором говорят - он в том числе и про преодоление.
Еще есть такой момент, что иногда люди намеренно не хотят делать что-то слишком быстро: где-то человек понимает, что тогда дадут еще задачу и зачем торопиться? Где-то просто такой подход к работе может быть. И вот такие врывы-подключения тимлида также могут быть негативно восприняты даже. Не говоря уже о том, что это довольно плохая метрика, что вот всегда надо врываться.
Зачастую даже (если позволяет проект) лучше прямо не сделать что-то (явно потом разобрав почему так получилось), чем вот все закрывать и делая такие мнимые победы. Но опять же, бывают проекты, где выполнение целей - вопрос выживаемости, тут не до учебы на ошибках так явно.
В целом, кстати, тут можно вообще покрутить эту скорость: типа если человек в плане все что надо сделал, заранее прямо за, пусть будет, день, то можно не просто давать ему очередную таску из очереди, а, например, дать прямо явно дей оф, или там попробовать в это время попросить его поискать проблемы проекта, что-то решить из области, где ему давно хотелось покопаться там, короче сделать такой вот момент часто бывает полезнее намного, чем следующая таска: так как и позволяет чуть уйти от 'конвеера' в котором многим тяжело, сделать так, чтобы хоть как-то нивелировать те самые настроения 'зачем делать быстрее - все равно снова дадут задачу'.
Короче мысль простая: тимлид он про команду и достижение целей командой. Как писали на зеленой карточке: я - лидер, мы - команда, все для клиента.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10❤🔥10👍6🔥1🤮1💩1🖕1
This media is not supported in your browser
VIEW IN TELEGRAM
Как я вижу фразу «Надо пройти селф-ревью»
😁38💯5❤3🐳1
Когда собака какает - она смотрит на хозяина, так как находится в беззащитном положении, показывая, что доверяет ему и ожидая, что в случае опасности ее защитят.
Ровно это я подумал, когда во время деплоя в прод на меня смотрел джун.
Ровно это я подумал, когда во время деплоя в прод на меня смотрел джун.
😁73🔥11🎉5
Всем привет!
Давно меня не было в уличных гонках -задержался на питстопе.
Давеча мимо меня проехал вот такй пулл реквест и я подумал (что вообще редкость в последние дни): вот это памятник программисту.
Понятное дело, что времена нынче нелегкие и цены в магазинах тоже плавают, но вот такое меня всегда как-то триггерило.
И даже откинув все сомнения, можно оценить масштаб: что называется каждый найдет у нас что-то для себя.
Ставлю этому пуллреквесту 9.99 по шкале Пятерочки.
Давно меня не было в уличных гонках -задержался на питстопе.
Давеча мимо меня проехал вот такй пулл реквест и я подумал (что вообще редкость в последние дни): вот это памятник программисту.
Понятное дело, что времена нынче нелегкие и цены в магазинах тоже плавают, но вот такое меня всегда как-то триггерило.
И даже откинув все сомнения, можно оценить масштаб: что называется каждый найдет у нас что-то для себя.
Ставлю этому пуллреквесту 9.99 по шкале Пятерочки.
😁22👍4👌2🔥1
Выгорание - это когда на надпись «Jira испытывает трудности в работе» думаешь: а давно Jira ходила в отпуск и отдыхала?
😁48💯3🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Менторы в АйТи стажировки раньше: вот печеньки, да, это почти гарантия трудоустройства, давай поставим нам 1-1 каждый день, конечно, не расстраивайся, если что-то не успел!
Менторы сейчас:
Менторы сейчас:
😁28💯10🔥4👍1
Разработчик закрыл половину спринта за ночь.
Спросил - а че случилось и откуда такая продуктивность? Оказалось, что он поссорился с девушкой и на эмоциях сел и затащил.
Но уже помирился!
Планирую написать его девушке «Я люблю Лешу - дай нам наконец-то быть счастливыми» и закрыть этот спринт.
Спросил - а че случилось и откуда такая продуктивность? Оказалось, что он поссорился с девушкой и на эмоциях сел и затащил.
Но уже помирился!
Планирую написать его девушке «Я люблю Лешу - дай нам наконец-то быть счастливыми» и закрыть этот спринт.
😁76💘10🤣5💔4❤3