Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "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, первых и третьих вообще тысячи.
Насчёт четвёртого не уверен, маршрутизация звучит серьёзно: это и картография и трассировка маршрута и предиктивный учёт изменений на основе статистики. Но скорее всего там дёргается яндекс-апи и на этом всё. Остальное - шаблоны страничек.
А ИИшка и сейчас не может написать более-менее сложную функцию меньше сотни строк. Какие модули, вы чего? Какие проекты?
ИИ хорошо пишет только там, где уже мясные программисты вдоль и поперёк выпахали поле. Тудушечку зафигачить на реакте? Да запросто. Крестики-нолики? Не вопрос. Простой платформер? Получите и распишитесь.
Мне даже добавить нечего
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Номер статьи хороший, вы специально подбирали? )
Да
Как это не работал? Он проводил код-ревью, обучал, объяснял, показывал. Это всё обязанности тимлида.
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "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, первых и третьих вообще тысячи.
Насчёт четвёртого не уверен, маршрутизация звучит серьёзно: это и картография и трассировка маршрута и предиктивный учёт изменений на основе статистики. Но скорее всего там дёргается яндекс-апи и на этом всё. Остальное - шаблоны страничек.
А ИИшка и сейчас не может написать более-менее сложную функцию меньше сотни строк. Какие модули, вы чего? Какие проекты?
ИИ хорошо пишет только там, где уже мясные программисты вдоль и поперёк выпахали поле. Тудушечку зафигачить на реакте? Да запросто. Крестики-нолики? Не вопрос. Простой платформер? Получите и распишитесь.
Что-то особенное? Ой, всё.