Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "team lead" говорит о том, что он находится внутри команды.
Во вторых существует две крайности: не давать никому править свой код и придерживаться позиции "ну они же потратили время".
Ну потратили, дальше что? Да, компания заплатила за их время. И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид должен принимать решение исходя из того, насколько PR соответствует решению задачи в рамках архитектуры проекта. И всё. Ни потраченное время, ни личные предпочтения тут не должны играть роли. Это, конечно, утопия, но надо к этому стремиться.
Примерно лет 10 назад я работал в команде с одной девочкой. Очень продуктивная была. Так за примерно полгода работы она наворотила столько, что потом два года пришлось переписывать. Не потому, что я такой принципиальный. Просто по мере доработки различных частей системы я сталкивался с тем, что придётся сначала её код поправить, чтобы новая часть заработала. Я матерился, потому что у меня не было никакого желания переписывать этот код, но ничего поделать не мог.
Вот это - прожирание денег компании. Девочка сделала абы как, чтобы казаться полезной, а по итогу сожгла своё время и в два раза больше моего.
И я пожалел, что не был тем "Андреем", который вовремя заворачивает реквест и отправляет на доработку. Это сэкономило бы кучу времени и денег компании.
Я зашёл в ваш профиль, и увидел, что вы работаете тимлидом. Значит вы хорошо знаете на собственном опыте, где находится засада этой должности.
Для остальных: у тимлида нет никаких рычагов давления на "подчинённых". Да у него и нет фактически подчинённых. У него есть только ответственность за проект. Есть то же самое начальство, что и у всей команды. Есть спрос с него. Есть ответственность за проект, а полномочий нет. Только красивая лычка и возможность не принимать PR. Больше ничего. То есть проект пишет вся команда, а спрашивают с него.
Андрей прожирал ресурс компании, заставляя её оплачивать пустой труд
Ну всмысле прожирал ресурс? Он сам писал код, при этом находил время для ревью кода, объяснял что не так. Объяснял почему. Показывал как надо.
Я не буду исключать, что он мог где-то ошибаться или слишком ревностно относиться к кодовой базе. Но "прожирал ресурс" - это ну просто слишком.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Объективно стало лучше
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта.
Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.
А вот когда обычная сущность, лучше singular (единственное число)
Не лучше
Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers
Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.
Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.
Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.
Хотя бы чтоб перестать называть таблицу заказов как "order" в БД.
А что не так? Вроде устоявшийся термин, везде orders, во всех примерах. Есть purchase order как часть терминологии sap, например. Или то, что термин в единственном числе?
Я за последний месяц несколько раз себя поймал на мысли, что автодополнение сбивает с толку. Вот это, новое, ЛЛМное. Выдаёт какую-то херню, совершенно перпендикулярную мыслям, в которые я сейчас погружен. Да, иногда угадывает. А иногда "так, стоп, какой ещё SecondaryKey, в базах данных такого нет".
В дотнете нет никаких виртуалок. Там точно такое же компилирование в нативный исполняемый код, как и в крестах. Да, сборка мусора и прочий менеджмент памяти. А где менеджмента памяти нет?
Для того, чтобы заработать, нужно взять хорошую и проверенную игру. Поэтому почти все ремейки хороши. Если, конечно, не смогли игру испортить.
Я с удовольствием играл в d2: resurrected, re4 remake и другие. Отличные игры.
Потому что оригинал, как правило, создается от души, на вдохновенье.
Чтобы получилось хорошо, мало "создавать от души" и вдохновения не достаточно. Нужно много кропотливой, скучной и дорогой работы. Вот этим и занимаются ремейкеры. Берут "душу" и добавляют много работы за много денег.
Бессмысленность - это отличительная черта текстов этого автора. У него это уже третий (или четвёртый) аккаунт. И тексты были бессмысленными задолго до чатгпт.
Это всё крестики-нолики. Такого полно в гитхабе. Типа второго есть sharex, первых и третьих вообще тысячи.
Насчёт четвёртого не уверен, маршрутизация звучит серьёзно: это и картография и трассировка маршрута и предиктивный учёт изменений на основе статистики. Но скорее всего там дёргается яндекс-апи и на этом всё. Остальное - шаблоны страничек.
А ИИшка и сейчас не может написать более-менее сложную функцию меньше сотни строк. Какие модули, вы чего? Какие проекты?
ИИ хорошо пишет только там, где уже мясные программисты вдоль и поперёк выпахали поле. Тудушечку зафигачить на реакте? Да запросто. Крестики-нолики? Не вопрос. Простой платформер? Получите и распишитесь.
И вот статистика, которая меня самого удивила: 8-9 из 10 планов оказываются миражами на 40% или больше.
Это говорит о том, что вы не умеете программировать. Программирование - это не написание кода, как рисование - это не мазюкание кистью по холсту. Программирование - это понимание что ты делаешь и зачем. Представление, как это будет работать, до того, как это будет написано. Также, как художник представляет картину, до того, как она будет нарисована.
Это объясняет и вот такой вывод:
В какой-то момент я понял простую вещь: что бы я ни захотел сделать — функцию, рефакторинг, фикс — агент сделает это лучше, быстрее и надёжнее в 99% случаев
Есть люди, которые считают, что LLM пишет код лучше их, есть люди, которые считают, что LLM пишет код намного хуже их. И те и те правы.
Проблема в том, что сейчас человек, не умеющий программировать, учит людей, умеющих программировать.
А у меня, например, ситуация диаметрально противоположная. Всё, что затрагивает LLM, превращается в говно. Поэтому в код я его не допускаю. Может быть разве тесты, там какашки изолированы. Да и то, практика показывает, что это всё переписывается чуть более, чем полностью практически сразу.
У меня есть своё определение. Мудак - это человек, который в поступках получает для себя меньше выгоды, чем наносит вреда окружающим. Да, с зефирками это не стыкуется, там ССЗБ. А может даже не ССЗБ, а элементарный риск-менеджмент и здоровое недоверие обещаниям.
Я не претендую на точность своего определения, но абсолютно уверен, что термин "мудак" невозможен без социального взаимодействия.
Как это не работал? Он проводил код-ревью, обучал, объяснял, показывал. Это всё обязанности тимлида.
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "team lead" говорит о том, что он находится внутри команды.
Во вторых существует две крайности: не давать никому править свой код и придерживаться позиции "ну они же потратили время".
Ну потратили, дальше что? Да, компания заплатила за их время. И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид должен принимать решение исходя из того, насколько PR соответствует решению задачи в рамках архитектуры проекта. И всё. Ни потраченное время, ни личные предпочтения тут не должны играть роли. Это, конечно, утопия, но надо к этому стремиться.
Примерно лет 10 назад я работал в команде с одной девочкой. Очень продуктивная была. Так за примерно полгода работы она наворотила столько, что потом два года пришлось переписывать. Не потому, что я такой принципиальный. Просто по мере доработки различных частей системы я сталкивался с тем, что придётся сначала её код поправить, чтобы новая часть заработала. Я матерился, потому что у меня не было никакого желания переписывать этот код, но ничего поделать не мог.
Вот это - прожирание денег компании. Девочка сделала абы как, чтобы казаться полезной, а по итогу сожгла своё время и в два раза больше моего.
И я пожалел, что не был тем "Андреем", который вовремя заворачивает реквест и отправляет на доработку. Это сэкономило бы кучу времени и денег компании.
Я зашёл в ваш профиль, и увидел, что вы работаете тимлидом. Значит вы хорошо знаете на собственном опыте, где находится засада этой должности.
Для остальных: у тимлида нет никаких рычагов давления на "подчинённых". Да у него и нет фактически подчинённых. У него есть только ответственность за проект. Есть то же самое начальство, что и у всей команды. Есть спрос с него. Есть ответственность за проект, а полномочий нет. Только красивая лычка и возможность не принимать PR. Больше ничего. То есть проект пишет вся команда, а спрашивают с него.
Ну всмысле прожирал ресурс? Он сам писал код, при этом находил время для ревью кода, объяснял что не так. Объяснял почему. Показывал как надо.
Я не буду исключать, что он мог где-то ошибаться или слишком ревностно относиться к кодовой базе. Но "прожирал ресурс" - это ну просто слишком.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Ух, как быстро меняются приоритеты...
Девять. Второй отсутствует.
Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.
Не лучше
Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.
Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.
А что не так? Вроде устоявшийся термин, везде orders, во всех примерах. Есть purchase order как часть терминологии sap, например. Или то, что термин в единственном числе?
Я за последний месяц несколько раз себя поймал на мысли, что автодополнение сбивает с толку. Вот это, новое, ЛЛМное. Выдаёт какую-то херню, совершенно перпендикулярную мыслям, в которые я сейчас погружен. Да, иногда угадывает. А иногда "так, стоп, какой ещё SecondaryKey, в базах данных такого нет".
В дотнете нет никаких виртуалок. Там точно такое же компилирование в нативный исполняемый код, как и в крестах. Да, сборка мусора и прочий менеджмент памяти. А где менеджмента памяти нет?
Для того, чтобы заработать, нужно взять хорошую и проверенную игру. Поэтому почти все ремейки хороши. Если, конечно, не смогли игру испортить.
Я с удовольствием играл в d2: resurrected, re4 remake и другие. Отличные игры.
Чтобы получилось хорошо, мало "создавать от души" и вдохновения не достаточно. Нужно много кропотливой, скучной и дорогой работы. Вот этим и занимаются ремейкеры. Берут "душу" и добавляют много работы за много денег.
Бессмысленность - это отличительная черта текстов этого автора. У него это уже третий (или четвёртый) аккаунт. И тексты были бессмысленными задолго до чатгпт.
Глянул.
утилита для конвертации изображений в Windows
запись экрана и редактирование
утилита для ИИ-слоп-постинга
Это всё крестики-нолики. Такого полно в гитхабе. Типа второго есть sharex, первых и третьих вообще тысячи.
Насчёт четвёртого не уверен, маршрутизация звучит серьёзно: это и картография и трассировка маршрута и предиктивный учёт изменений на основе статистики. Но скорее всего там дёргается яндекс-апи и на этом всё. Остальное - шаблоны страничек.
А ИИшка и сейчас не может написать более-менее сложную функцию меньше сотни строк. Какие модули, вы чего? Какие проекты?
ИИ хорошо пишет только там, где уже мясные программисты вдоль и поперёк выпахали поле. Тудушечку зафигачить на реакте? Да запросто. Крестики-нолики? Не вопрос. Простой платформер? Получите и распишитесь.
Что-то особенное? Ой, всё.
Я и говорю, что дело во мне. Я умею программировать.
Это говорит о том, что вы не умеете программировать. Программирование - это не написание кода, как рисование - это не мазюкание кистью по холсту. Программирование - это понимание что ты делаешь и зачем. Представление, как это будет работать, до того, как это будет написано. Также, как художник представляет картину, до того, как она будет нарисована.
Это объясняет и вот такой вывод:
Есть люди, которые считают, что LLM пишет код лучше их, есть люди, которые считают, что LLM пишет код намного хуже их. И те и те правы.
Проблема в том, что сейчас человек, не умеющий программировать, учит людей, умеющих программировать.
А у меня, например, ситуация диаметрально противоположная. Всё, что затрагивает LLM, превращается в говно. Поэтому в код я его не допускаю. Может быть разве тесты, там какашки изолированы. Да и то, практика показывает, что это всё переписывается чуть более, чем полностью практически сразу.
У меня есть своё определение. Мудак - это человек, который в поступках получает для себя меньше выгоды, чем наносит вреда окружающим. Да, с зефирками это не стыкуется, там ССЗБ. А может даже не ССЗБ, а элементарный риск-менеджмент и здоровое недоверие обещаниям.
Я не претендую на точность своего определения, но абсолютно уверен, что термин "мудак" невозможен без социального взаимодействия.
Это такая же копипаста, как и два сообщения выше. Я думаю, что вопрос надо задавать оригиналу. Надо было.
Нет, не поэтому. Всё гораздо проще - нельзя кричать согласные буквы, механика человеческого звукоизвлечения тупо не успевает набрать амплитуду.