День 2165. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Начало
Если позволите, я тоже немного отдохну. Поэтому вот вам лёгкий лонгрид на праздники.
На заре распространения персональных компьютеров найти работу сисадмином или веб-дизайнером было проще простого. Если ты знал пяток команд командной строки и мог набросать простенькую HTML-форму, обязательно нашёлся бы тот, кто был согласен тебе платить. Не нужно было даже образования. Только настойчивость и желание работать. Сейчас это совсем не так.
В какой-то степени это всегда происходит, когда отрасль взрослеет. Ранние дни любой отрасли — это что-то вроде Дикого Запада, где ставки низкие, регулирование отсутствует, а стандарты только зарождаются. Это никогда не длится долго. Количество предварительных знаний и опыта, которые вам необходимо иметь, прежде чем вы сможете войти в отрасль, стремительно увеличивается. Растут ставки, масштабы и цена ошибок. Появляются сертификации, тренинги, стандарты, юридические процедуры. Мы спорим о том, являются ли инженеры-программисты на самом деле инженерами.
ПО - индустрия обучения
Сейчас никто не возьмёт недоучившегося студента в штат. Необходимые для входа в индустрию знания выросли, вы больше не можете научиться буквально всему на работе, как когда-то.
Но не похоже, что вы можете научиться всему и в вузе. Степень в области компьютерных наук обычно лучше готовит вас к жизни компьютерных исследователей, чем к жизни в качестве обычного инженера-программиста. Более практичным путём в индустрию может стать хороший учебный лагерь по кодированию с упором на решение проблем и изучение современного инструментария. В любом случае вы не столько узнаете, «как выполнять работу», сколько «узнаете достаточно основ, чтобы понимать и использовать инструменты, необходимые для изучения работы».
ПО — индустрия обучения. Вы не можете научиться быть инженером-программистом, читая книги. Вы можете учиться только делая… и делая, и ещё делая. Неважно, какое у вас образование, большая часть обучения происходит на работе… и никогда не заканчивается!
Требуется более 7 лет, чтобы выковать компетентного инженера-программиста (как в большинстве случаев называют, сеньора). Это много лет написания, проверки и развёртывания кода каждый день в команде вместе с более опытными инженерами.
Что значит быть «сеньором»?
Об этом есть целая серия постов на канале. Ищите по тэгу #КакСтатьСеньором
По поводу сроков есть очень много споров:
«7 лет?! Пфф, мне потребовалось 2 года!»
«Меня повысили до сеньора меньше, чем за 5 лет!»
Молодцы! Да, в 7 годах нет ничего волшебного. Но для того, чтобы стать опытным инженером, способным сплотить команду, требуются время и опыт. Более того, нужна практика.
Думаю, мы стали использовать слово «сеньор» как сокращение для инженеров, которые могут поставлять готовый чистый код и быть продуктивными, и кажется, что это огромная ошибка. Это подразумевает, что младшие инженеры менее продуктивны, что неверно. И это упускает из виду истинную природу работы по разработке ПО, в которой написание кода является лишь небольшой частью.
Быть сеньором — это не способность писать код. Это гораздо больше связано с вашей способностью понимать, поддерживать, объяснять и управлять большим объёмом ПО в производстве с течением времени, а также способностью переводить бизнес-потребности в техническую реализацию. Большая часть работы связана с созданием и курированием этих больших, сложных социотехнических систем, а код — это всего лишь одно из представлений этих систем. Это значит, что вы научились, прежде всего, учиться и учить; как держать эти модели в голове и рассуждать о них, и как поддерживать, расширять и эксплуатировать эти системы с течением времени. Это значит, что у вас есть здравый смысл и инстинкты, которым вы можете доверять.
Что подводит нас к вопросу об ИИ.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Начало
Если позволите, я тоже немного отдохну. Поэтому вот вам лёгкий лонгрид на праздники.
На заре распространения персональных компьютеров найти работу сисадмином или веб-дизайнером было проще простого. Если ты знал пяток команд командной строки и мог набросать простенькую HTML-форму, обязательно нашёлся бы тот, кто был согласен тебе платить. Не нужно было даже образования. Только настойчивость и желание работать. Сейчас это совсем не так.
В какой-то степени это всегда происходит, когда отрасль взрослеет. Ранние дни любой отрасли — это что-то вроде Дикого Запада, где ставки низкие, регулирование отсутствует, а стандарты только зарождаются. Это никогда не длится долго. Количество предварительных знаний и опыта, которые вам необходимо иметь, прежде чем вы сможете войти в отрасль, стремительно увеличивается. Растут ставки, масштабы и цена ошибок. Появляются сертификации, тренинги, стандарты, юридические процедуры. Мы спорим о том, являются ли инженеры-программисты на самом деле инженерами.
ПО - индустрия обучения
Сейчас никто не возьмёт недоучившегося студента в штат. Необходимые для входа в индустрию знания выросли, вы больше не можете научиться буквально всему на работе, как когда-то.
Но не похоже, что вы можете научиться всему и в вузе. Степень в области компьютерных наук обычно лучше готовит вас к жизни компьютерных исследователей, чем к жизни в качестве обычного инженера-программиста. Более практичным путём в индустрию может стать хороший учебный лагерь по кодированию с упором на решение проблем и изучение современного инструментария. В любом случае вы не столько узнаете, «как выполнять работу», сколько «узнаете достаточно основ, чтобы понимать и использовать инструменты, необходимые для изучения работы».
ПО — индустрия обучения. Вы не можете научиться быть инженером-программистом, читая книги. Вы можете учиться только делая… и делая, и ещё делая. Неважно, какое у вас образование, большая часть обучения происходит на работе… и никогда не заканчивается!
Требуется более 7 лет, чтобы выковать компетентного инженера-программиста (как в большинстве случаев называют, сеньора). Это много лет написания, проверки и развёртывания кода каждый день в команде вместе с более опытными инженерами.
Что значит быть «сеньором»?
Об этом есть целая серия постов на канале. Ищите по тэгу #КакСтатьСеньором
По поводу сроков есть очень много споров:
«7 лет?! Пфф, мне потребовалось 2 года!»
«Меня повысили до сеньора меньше, чем за 5 лет!»
Молодцы! Да, в 7 годах нет ничего волшебного. Но для того, чтобы стать опытным инженером, способным сплотить команду, требуются время и опыт. Более того, нужна практика.
Думаю, мы стали использовать слово «сеньор» как сокращение для инженеров, которые могут поставлять готовый чистый код и быть продуктивными, и кажется, что это огромная ошибка. Это подразумевает, что младшие инженеры менее продуктивны, что неверно. И это упускает из виду истинную природу работы по разработке ПО, в которой написание кода является лишь небольшой частью.
Быть сеньором — это не способность писать код. Это гораздо больше связано с вашей способностью понимать, поддерживать, объяснять и управлять большим объёмом ПО в производстве с течением времени, а также способностью переводить бизнес-потребности в техническую реализацию. Большая часть работы связана с созданием и курированием этих больших, сложных социотехнических систем, а код — это всего лишь одно из представлений этих систем. Это значит, что вы научились, прежде всего, учиться и учить; как держать эти модели в голове и рассуждать о них, и как поддерживать, расширять и эксплуатировать эти системы с течением времени. Это значит, что у вас есть здравый смысл и инстинкты, которым вы можете доверять.
Что подводит нас к вопросу об ИИ.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
5👍20👎1
День 2166. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
Нужно перестать каннибализировать наше будущее
Получить первую должность инженера очень сложно. Недостаточно окончить вуз по специальности. Сейчас написано множество статей о том, что начальные должности в различных отраслях заменяются ИИ. Любая работа, которая состоит из рутины, вроде преобразования документа из одного формата в другой, чтение и обобщение кучи текста и т.п., кажется довольно очевидно уязвимой. И это не так уж революционно, это просто часть бума автоматизации.
Однако в последнее время ряд руководителей и «лидеров мнений» в сфере технологий, похоже, убедили себя в том, что ИИ находится на грани замены всей работы, выполняемой джунами. Это говорит о глубоком непонимании того, чем на самом деле занимаются инженеры. Не нанимая и не обучая джунов, мы каннибализируем собственное будущее.
Писать код легко
Написание кода — самая лёгкая часть разработки ПО, и с каждым днём становится проще. Сложная часть — это эксплуатация, понимание, расширение и управление им на протяжении всего его жизненного цикла.
Джун начинает с того, что учится писать и отлаживать строки, функции и фрагменты кода. Затем - составлять системы из ПО и проводить их через волны изменений и трансформаций.
Социотехнические системы состоят из ПО, инструментов и людей; для их понимания требуется знакомство с взаимодействием между ПО, пользователями, производством, инфраструктурой и непрерывными изменениями с течением времени. Эти системы фантастически сложны и подвержены хаосу и непредсказуемому поведению. Если кто-то утверждает, что понимает систему, которую он разрабатывает и эксплуатирует, то либо система мала, либо (более вероятно) он недостаточно знает, чтобы знать, чего он не знает. Код прост, а системы сложны.
Текущая волна инструментов ИИ сделала многое, чтобы помочь нам быстро генерировать много кода. Простые части становятся ещё проще. Но она не сделала ничего, чтобы помочь в работе по управлению, пониманию или эксплуатации этого кода. Т.е. ИИ только усложнил сложную работу.
Сложно генерировать хороший код
У вас может возникнуть образ инженеров-программистов, весело создающих запросы к ChatGPT или использующих Copilot для генерации тонн кода, а затем отправляющих всё, что получается, в GitHub. Это не похоже на реальность.
Инструменты вроде Copilot больше похожи на причудливую функцию автодополнения или копирования-вставки результатов из Google «Мне повезёт». Эти инструменты лучше всего работают, когда уже есть аналогичный код, и вы хотите просто скопировать-вставить его с небольшими изменениями, или когда вы пишете тесты по шаблону.
Однако вы не можете доверять сгенерированному коду. Он всегда выглядит правдоподобно, но даже когда он как-то «работает», он редко соответствует вашим желаниям и потребностям. ИИ с радостью сгенерирует код, который не скомпилируется, придумает переменные, имена методов, вызовы функций; сгаллюцинирует поля, которых не существует. Код не будет следовать вашим практикам или соглашениям кодирования. Чем важнее, сложнее или значимее фрагмент кода, тем меньше вероятность того, что вы сгенерируете пригодный для использования артефакт с помощью ИИ.
Вы можете сэкономить время, не вводя код, но придётся пройтись по нему строка за строкой, исправляя их по ходу дела, прежде чем вы сможете отправить его в производство. Во многих случаях это займет столько же или даже больше времени, чем написание. Генерация кода, который может компилироваться, выполняться и проходить набор тестов, не так уж и сложна; сложная часть — это создание кодовой базы, на которую последующие поколения команд смогут полагаться и модифицировать в течение многих лет.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
Нужно перестать каннибализировать наше будущее
Получить первую должность инженера очень сложно. Недостаточно окончить вуз по специальности. Сейчас написано множество статей о том, что начальные должности в различных отраслях заменяются ИИ. Любая работа, которая состоит из рутины, вроде преобразования документа из одного формата в другой, чтение и обобщение кучи текста и т.п., кажется довольно очевидно уязвимой. И это не так уж революционно, это просто часть бума автоматизации.
Однако в последнее время ряд руководителей и «лидеров мнений» в сфере технологий, похоже, убедили себя в том, что ИИ находится на грани замены всей работы, выполняемой джунами. Это говорит о глубоком непонимании того, чем на самом деле занимаются инженеры. Не нанимая и не обучая джунов, мы каннибализируем собственное будущее.
Писать код легко
Написание кода — самая лёгкая часть разработки ПО, и с каждым днём становится проще. Сложная часть — это эксплуатация, понимание, расширение и управление им на протяжении всего его жизненного цикла.
Джун начинает с того, что учится писать и отлаживать строки, функции и фрагменты кода. Затем - составлять системы из ПО и проводить их через волны изменений и трансформаций.
Социотехнические системы состоят из ПО, инструментов и людей; для их понимания требуется знакомство с взаимодействием между ПО, пользователями, производством, инфраструктурой и непрерывными изменениями с течением времени. Эти системы фантастически сложны и подвержены хаосу и непредсказуемому поведению. Если кто-то утверждает, что понимает систему, которую он разрабатывает и эксплуатирует, то либо система мала, либо (более вероятно) он недостаточно знает, чтобы знать, чего он не знает. Код прост, а системы сложны.
Текущая волна инструментов ИИ сделала многое, чтобы помочь нам быстро генерировать много кода. Простые части становятся ещё проще. Но она не сделала ничего, чтобы помочь в работе по управлению, пониманию или эксплуатации этого кода. Т.е. ИИ только усложнил сложную работу.
Сложно генерировать хороший код
У вас может возникнуть образ инженеров-программистов, весело создающих запросы к ChatGPT или использующих Copilot для генерации тонн кода, а затем отправляющих всё, что получается, в GitHub. Это не похоже на реальность.
Инструменты вроде Copilot больше похожи на причудливую функцию автодополнения или копирования-вставки результатов из Google «Мне повезёт». Эти инструменты лучше всего работают, когда уже есть аналогичный код, и вы хотите просто скопировать-вставить его с небольшими изменениями, или когда вы пишете тесты по шаблону.
Однако вы не можете доверять сгенерированному коду. Он всегда выглядит правдоподобно, но даже когда он как-то «работает», он редко соответствует вашим желаниям и потребностям. ИИ с радостью сгенерирует код, который не скомпилируется, придумает переменные, имена методов, вызовы функций; сгаллюцинирует поля, которых не существует. Код не будет следовать вашим практикам или соглашениям кодирования. Чем важнее, сложнее или значимее фрагмент кода, тем меньше вероятность того, что вы сгенерируете пригодный для использования артефакт с помощью ИИ.
Вы можете сэкономить время, не вводя код, но придётся пройтись по нему строка за строкой, исправляя их по ходу дела, прежде чем вы сможете отправить его в производство. Во многих случаях это займет столько же или даже больше времени, чем написание. Генерация кода, который может компилироваться, выполняться и проходить набор тестов, не так уж и сложна; сложная часть — это создание кодовой базы, на которую последующие поколения команд смогут полагаться и модифицировать в течение многих лет.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
5👍8
День 2167. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО – индустрия обучения
2. Просто писать код, сложно писать хороший код
Как инженеры на самом деле используют ИИ
Вы можете сгенерировать много кода очень быстро, но вы не можете доверять тому, что получится. Однако есть некоторые примеры использования, в которых ИИ неизменно блистает:
1. Часто проще попросить ChatGPT сгенерировать пример кода с использованием незнакомых API, чем читать документацию по API.
2. Создание кода, который раздражает или утомителен для написания, но при этом имеет узкую область действия и легко объясняется. Чем более предсказуем сценарий, тем лучше эти инструменты пишут код за вас.
3. Написание небольших функций, чтобы делать что-то на незнакомых языках или в незнакомых сценариях. Если у вас есть фрагмент кода Python и вы хотите то же самое на Java, но вы не знаете Java, ИИ поможет.
Но, помните: вероятность того, что результат полностью выдуман, составляет 50/50. Всегда придется предполагать, что результаты неверны, пока вы не проверите их вручную.
ИИ немного похож на джуна
ИИ похож на младшего инженера в том, что вы не можете запустить его код в производство. Вы несёте за него ответственность — юридически, этически и практически. Всё равно нужно потратить время, чтобы понять код, протестировать, инструментировать, модифицировать стилистически и тематически, чтобы он соответствовал остальной части кодовой базы, и убедиться, что коллеги также могут его понимать и поддерживать.
Аналогия хорошая, только если ваш код одноразовый и самодостаточный, т.е. не предназначен для интеграции в более крупный объём работы или для выживания и чтения или изменения другими.
И есть такие уголки отрасли, где большая часть — одноразовый код. Есть компании, которые выпускают десятки одноразовых приложений в год, каждое из которых написано для конкретного запуска или маркетингового мероприятия, а затем выбрасывается. Но это не относится к большинству ПО.
Но ИИ не член вашей команды
ИИ похож на джуна, но во всех других отношениях аналогия не работает. В автоматической генерации кода нет обратной связи. Предоставление код-ревью младшему инженеру не похоже на редактирование сгенерированного кода. Это возможность передать уроки, которые вы усвоили в своей карьере. Да и само оформление обратной связи заставляет вас продумывать проблему более строго и помогает вам глубже понять материал. Время, которое вы вкладываете в помощь младшему инженеру в повышении уровня, может окупиться удивительно быстро.
Мы недооцениваем стоимость найма сеньоров и переоцениваем стоимость найма джунов
Люди часто думают, что как только вы нанимаете сеньора, вы можете поместить его в команду, и он сразу же станет продуктивным. Тогда как джун снизит производительность команды навсегда. Ни то, ни другое неверно. Большая часть работы, которую приходится выполнять большинству команд, не так уж сложна, если её разбить на составные части.
Существует множество способов, как человек может внести вклад в общую скорость команды. И множество способов, как он может высасывать энергию из команды или добавлять трения и помехи всем вокруг. Это не всегда коррелирует с уровнем человека.
Каждому нанятому инженеру требуется время на разгон, прежде чем он сможет внести свой вклад, независимо от его уровня. Сколько времени? Зависит от чистоты и организованности кодовой базы, прошлого опыта работы с вашими инструментами и технологиями и многого другого, но, скорее всего, 6-9 месяцев. Да, разгон будет дольше для джуна, и это потребует больше инвестиций от команды. Но не критически больше. Джун должен начать приносить пользу в течение примерно того же периода времени, и джуны развиваются гораздо быстрее, чем более опытные работники.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО – индустрия обучения
2. Просто писать код, сложно писать хороший код
Как инженеры на самом деле используют ИИ
Вы можете сгенерировать много кода очень быстро, но вы не можете доверять тому, что получится. Однако есть некоторые примеры использования, в которых ИИ неизменно блистает:
1. Часто проще попросить ChatGPT сгенерировать пример кода с использованием незнакомых API, чем читать документацию по API.
2. Создание кода, который раздражает или утомителен для написания, но при этом имеет узкую область действия и легко объясняется. Чем более предсказуем сценарий, тем лучше эти инструменты пишут код за вас.
3. Написание небольших функций, чтобы делать что-то на незнакомых языках или в незнакомых сценариях. Если у вас есть фрагмент кода Python и вы хотите то же самое на Java, но вы не знаете Java, ИИ поможет.
Но, помните: вероятность того, что результат полностью выдуман, составляет 50/50. Всегда придется предполагать, что результаты неверны, пока вы не проверите их вручную.
ИИ немного похож на джуна
ИИ похож на младшего инженера в том, что вы не можете запустить его код в производство. Вы несёте за него ответственность — юридически, этически и практически. Всё равно нужно потратить время, чтобы понять код, протестировать, инструментировать, модифицировать стилистически и тематически, чтобы он соответствовал остальной части кодовой базы, и убедиться, что коллеги также могут его понимать и поддерживать.
Аналогия хорошая, только если ваш код одноразовый и самодостаточный, т.е. не предназначен для интеграции в более крупный объём работы или для выживания и чтения или изменения другими.
И есть такие уголки отрасли, где большая часть — одноразовый код. Есть компании, которые выпускают десятки одноразовых приложений в год, каждое из которых написано для конкретного запуска или маркетингового мероприятия, а затем выбрасывается. Но это не относится к большинству ПО.
Но ИИ не член вашей команды
ИИ похож на джуна, но во всех других отношениях аналогия не работает. В автоматической генерации кода нет обратной связи. Предоставление код-ревью младшему инженеру не похоже на редактирование сгенерированного кода. Это возможность передать уроки, которые вы усвоили в своей карьере. Да и само оформление обратной связи заставляет вас продумывать проблему более строго и помогает вам глубже понять материал. Время, которое вы вкладываете в помощь младшему инженеру в повышении уровня, может окупиться удивительно быстро.
Мы недооцениваем стоимость найма сеньоров и переоцениваем стоимость найма джунов
Люди часто думают, что как только вы нанимаете сеньора, вы можете поместить его в команду, и он сразу же станет продуктивным. Тогда как джун снизит производительность команды навсегда. Ни то, ни другое неверно. Большая часть работы, которую приходится выполнять большинству команд, не так уж сложна, если её разбить на составные части.
Существует множество способов, как человек может внести вклад в общую скорость команды. И множество способов, как он может высасывать энергию из команды или добавлять трения и помехи всем вокруг. Это не всегда коррелирует с уровнем человека.
Каждому нанятому инженеру требуется время на разгон, прежде чем он сможет внести свой вклад, независимо от его уровня. Сколько времени? Зависит от чистоты и организованности кодовой базы, прошлого опыта работы с вашими инструментами и технологиями и многого другого, но, скорее всего, 6-9 месяцев. Да, разгон будет дольше для джуна, и это потребует больше инвестиций от команды. Но не критически больше. Джун должен начать приносить пользу в течение примерно того же периода времени, и джуны развиваются гораздо быстрее, чем более опытные работники.
Продолжение следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
👍16
День 2168. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
2. Просто писать код, сложно писать хороший код
3. ИИ похож на джуна
Не обязательно быть сеньором, чтобы добавлять ценность
С точки зрения написания и поставки функций, одни из самых продуктивных инженеров - мидлы. Они ещё не увязли во встречах, кураторстве, наставничестве, консультациях и архитектуре, их календари ещё не забиты прерываниями, они могут просто создавать вещи. Они надевают наушники утром, пишут код весь день и уходят вечером, достигнув невероятного прогресса.
Мидлы находятся в этом прекрасном временном состоянии, когда они достаточно хорошо разбираются в программировании, чтобы быть очень продуктивными, но всё ещё учатся создавать и обслуживать системы. Всё, что они делают, это пишут код, много кода.
И они полны энергии… вовлечены. Они получают удовольствие! Это обычно означает, что они будут делать работу лучше, особенно под руководством кого-то более опытного. Наличие в команде мидлов — это потрясающе. Единственный способ получить их — нанять джунов.
Почти все согласны, что нанимать джунов — это хорошо в долгосрочной перспективе… и это должен делать кто-то другой, т.к. «нам сейчас нужны сеньоры», «джунов долго обучать» и т.п. Долгосрочное мышление — не то, в чём компании или капитализм в целом обычно хороши. Компании гораздо более склонны выносить такие издержки за пределы компании. Но есть несколько аргументов в пользу найма джунов в краткосрочной перспективе.
Найм инженеров — это не процесс «выбора лучшего человека для работы». Это создание команд. Наименьшая единица владения ПО — не отдельный человек, а команда. Если бы найм инженеров был связан с выбором «лучших людей», имело бы смысл нанять самого «сеньористого» человека, которого вы можете получить за имеющиеся деньги, т.к. мы используем термин «сеньор» как синоним «производительности». Но производительность отдельного человека — не то, что мы должны оптимизировать. Производительность команды — вот, что имеет значение.
И лучшие команды всегда те, в которых есть разнообразие сильных сторон, перспектив и уровней знаний. Нужно нанимать джунов постоянно. Они остаются джунами всего пару лет, а мидлы превращаются в сеньоров. Самые опытные инженеры на самом деле не лучшие люди для наставничества джунов; самый эффективный наставник обычно тот, кто на один уровень выше, и помнит, каково это было на вашем месте.
Здоровая команда включает людей разных уровней
Вы не будете укомплектовывать команду по разработке продукта шестью экспертами по БД и одним мобильным разработчиком. Также нельзя включать в неё 6 сеньоров и 1 джуна. Существует не так много высокоуровневой архитектуры и планирования, не так много важных решений, которые нужно принять. Сеньоры будут проводить большую часть времени, выполняя работу, которая кажется им скучной и повторяющейся, поэтому будут оверинжинирить решения и/или экономить на них — иногда в одно и то же время. Они будут хронически недодокументировать и недоинвестировать в работу, которая делает системы простыми и управляемыми.
Команды, из инженеров одного уровня будут иметь разные патологии, но схожие проблемы с разногласиями и «слепыми пятнами». Сама работа имеет широкий диапазон сложности и трудности — от простых, узконаправленных функций до сложных, высокорискованных архитектурных решений. Лучшие команды — те, где никому не скучно, потому что каждый работает над чем-то, что бросает ему вызов и расширяет границы. Единственный способ добиться этого — иметь в команде разные уровни навыков.
Окончание следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Продолжение
1. ПО - индустрия обучения
2. Просто писать код, сложно писать хороший код
3. ИИ похож на джуна
Не обязательно быть сеньором, чтобы добавлять ценность
С точки зрения написания и поставки функций, одни из самых продуктивных инженеров - мидлы. Они ещё не увязли во встречах, кураторстве, наставничестве, консультациях и архитектуре, их календари ещё не забиты прерываниями, они могут просто создавать вещи. Они надевают наушники утром, пишут код весь день и уходят вечером, достигнув невероятного прогресса.
Мидлы находятся в этом прекрасном временном состоянии, когда они достаточно хорошо разбираются в программировании, чтобы быть очень продуктивными, но всё ещё учатся создавать и обслуживать системы. Всё, что они делают, это пишут код, много кода.
И они полны энергии… вовлечены. Они получают удовольствие! Это обычно означает, что они будут делать работу лучше, особенно под руководством кого-то более опытного. Наличие в команде мидлов — это потрясающе. Единственный способ получить их — нанять джунов.
Почти все согласны, что нанимать джунов — это хорошо в долгосрочной перспективе… и это должен делать кто-то другой, т.к. «нам сейчас нужны сеньоры», «джунов долго обучать» и т.п. Долгосрочное мышление — не то, в чём компании или капитализм в целом обычно хороши. Компании гораздо более склонны выносить такие издержки за пределы компании. Но есть несколько аргументов в пользу найма джунов в краткосрочной перспективе.
Найм инженеров — это не процесс «выбора лучшего человека для работы». Это создание команд. Наименьшая единица владения ПО — не отдельный человек, а команда. Если бы найм инженеров был связан с выбором «лучших людей», имело бы смысл нанять самого «сеньористого» человека, которого вы можете получить за имеющиеся деньги, т.к. мы используем термин «сеньор» как синоним «производительности». Но производительность отдельного человека — не то, что мы должны оптимизировать. Производительность команды — вот, что имеет значение.
И лучшие команды всегда те, в которых есть разнообразие сильных сторон, перспектив и уровней знаний. Нужно нанимать джунов постоянно. Они остаются джунами всего пару лет, а мидлы превращаются в сеньоров. Самые опытные инженеры на самом деле не лучшие люди для наставничества джунов; самый эффективный наставник обычно тот, кто на один уровень выше, и помнит, каково это было на вашем месте.
Здоровая команда включает людей разных уровней
Вы не будете укомплектовывать команду по разработке продукта шестью экспертами по БД и одним мобильным разработчиком. Также нельзя включать в неё 6 сеньоров и 1 джуна. Существует не так много высокоуровневой архитектуры и планирования, не так много важных решений, которые нужно принять. Сеньоры будут проводить большую часть времени, выполняя работу, которая кажется им скучной и повторяющейся, поэтому будут оверинжинирить решения и/или экономить на них — иногда в одно и то же время. Они будут хронически недодокументировать и недоинвестировать в работу, которая делает системы простыми и управляемыми.
Команды, из инженеров одного уровня будут иметь разные патологии, но схожие проблемы с разногласиями и «слепыми пятнами». Сама работа имеет широкий диапазон сложности и трудности — от простых, узконаправленных функций до сложных, высокорискованных архитектурных решений. Лучшие команды — те, где никому не скучно, потому что каждый работает над чем-то, что бросает ему вызов и расширяет границы. Единственный способ добиться этого — иметь в команде разные уровни навыков.
Окончание следует…
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
1👍17
День 2169. #Оффтоп #AI
ИИ не Заменит Команду Инженеров. Окончание
1. ПО - индустрия обучения
2. Просто писать код, сложно писать хороший код
3. ИИ похож на джуна
4. Здоровая команда включает людей разных уровней
Узкое место — найм, а не обучение
Узкое место сейчас — это предоставление джунам их первой работы. Оно в компаниях, которые видят в джунах издержки, а не инвестиции в своё будущее.
После первой работы инженер обычно может найти работу. Но получить первую работу практически невозможно, если только вы не окончили лучший вуз или у вас нет крутых связей.
Многие думают, что им не нужны джуны, но никто не говорит, что им нужно меньше сеньоров. Можно с уверенностью предположить, что всё детерминированное и автоматизируемое в итоге будет автоматизировано. Программная инженерия не исключение. Конечно, мы всегда ищем способы автоматизации и повышения эффективности, так и должно быть.
Но большие программные системы непредсказуемы. Само существование пользователей вносит хаос в систему. Компоненты можно автоматизировать, но сложностью можно только управлять.
Даже если бы системы можно было полностью автоматизировать и управлять ими с помощью ИИ, тот факт, что мы не можем понять, как ИИ принимает решения, является огромной, возможно, непреодолимой проблемой. Ведение бизнеса в системе, которую люди не могут отладить или понять, кажется риском настолько существенным, что ни одна служба безопасности, юридическая или финансовая служба никогда не одобрит этого. Может быть, какая-то версия этого будущего и наступит, но отсюда её трудно увидеть.
Нам нужны сеньоры, но единственный способ их получить – растить из джунов.
Должна ли каждая компания нанимать джунов?
Нет. Вот несколько факторов, которые не позволят компании нанимать джунов:
- Меньше двух лет работы;
- Команда постоянно находится в режиме пожаротушения;
- Нет опытных менеджеров;
- Нет дорожной карты продукта;
- Никто в команде не заинтересован в том, чтобы быть их наставником или руководителем.
Единственное, что хуже, чем вообще не нанимать джунов, — это нанимать их в ужасные условия, где они не смогут ничему научиться. Хотя большинство джунов скорее предпочтут паршивую первую работу, чем вообще ничего.
Удалённая работа лучше, чем ничего, но сильно сложнее. Джунам лучше искать работу в офисе, если возможно. Вы учитесь гораздо быстрее, когда можете впитывать неформальные разговоры и техническую болтовню, и вы теряете это, работая из дома. Удалённому работодателю придется работать усерднее, чтобы компенсировать это.
Никто не придёт решить наши проблемы за нас
В большинстве мест, где есть программа найма и обучения инженеров начального уровня, она есть только потому, что инженеры решили за неё бороться. Инженеры её создавали, выбивали ресурсы, разрабатывали программу, проводили собеседования и нанимали джунов и их наставников. Это вполне в пределах возможностей большинства мотивированных, опытных инженеров (и также полезно для вашей карьеры).
Финансы будут против. Руководители вряд ли вмешаются. Чем больше роль человека склоняет его относиться к инженерам как к взаимозаменяемым ресурсам, тем меньше вероятность, что он поймёт, почему это важно.
ИИ не решит все наши проблемы и не напишет весь код за нас. А даже если бы это было так, написание кода — лишь часть того, что делают профессиональные инженеры-программисты, и, возможно, самая простая часть. Только у нас есть контекст и авторитет, чтобы управлять изменениями, которые составляют основу для отличных команд и совершенствования как инженер.
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
ИИ не Заменит Команду Инженеров. Окончание
1. ПО - индустрия обучения
2. Просто писать код, сложно писать хороший код
3. ИИ похож на джуна
4. Здоровая команда включает людей разных уровней
Узкое место — найм, а не обучение
Узкое место сейчас — это предоставление джунам их первой работы. Оно в компаниях, которые видят в джунах издержки, а не инвестиции в своё будущее.
После первой работы инженер обычно может найти работу. Но получить первую работу практически невозможно, если только вы не окончили лучший вуз или у вас нет крутых связей.
Многие думают, что им не нужны джуны, но никто не говорит, что им нужно меньше сеньоров. Можно с уверенностью предположить, что всё детерминированное и автоматизируемое в итоге будет автоматизировано. Программная инженерия не исключение. Конечно, мы всегда ищем способы автоматизации и повышения эффективности, так и должно быть.
Но большие программные системы непредсказуемы. Само существование пользователей вносит хаос в систему. Компоненты можно автоматизировать, но сложностью можно только управлять.
Даже если бы системы можно было полностью автоматизировать и управлять ими с помощью ИИ, тот факт, что мы не можем понять, как ИИ принимает решения, является огромной, возможно, непреодолимой проблемой. Ведение бизнеса в системе, которую люди не могут отладить или понять, кажется риском настолько существенным, что ни одна служба безопасности, юридическая или финансовая служба никогда не одобрит этого. Может быть, какая-то версия этого будущего и наступит, но отсюда её трудно увидеть.
Нам нужны сеньоры, но единственный способ их получить – растить из джунов.
Должна ли каждая компания нанимать джунов?
Нет. Вот несколько факторов, которые не позволят компании нанимать джунов:
- Меньше двух лет работы;
- Команда постоянно находится в режиме пожаротушения;
- Нет опытных менеджеров;
- Нет дорожной карты продукта;
- Никто в команде не заинтересован в том, чтобы быть их наставником или руководителем.
Единственное, что хуже, чем вообще не нанимать джунов, — это нанимать их в ужасные условия, где они не смогут ничему научиться. Хотя большинство джунов скорее предпочтут паршивую первую работу, чем вообще ничего.
Удалённая работа лучше, чем ничего, но сильно сложнее. Джунам лучше искать работу в офисе, если возможно. Вы учитесь гораздо быстрее, когда можете впитывать неформальные разговоры и техническую болтовню, и вы теряете это, работая из дома. Удалённому работодателю придется работать усерднее, чтобы компенсировать это.
Никто не придёт решить наши проблемы за нас
В большинстве мест, где есть программа найма и обучения инженеров начального уровня, она есть только потому, что инженеры решили за неё бороться. Инженеры её создавали, выбивали ресурсы, разрабатывали программу, проводили собеседования и нанимали джунов и их наставников. Это вполне в пределах возможностей большинства мотивированных, опытных инженеров (и также полезно для вашей карьеры).
Финансы будут против. Руководители вряд ли вмешаются. Чем больше роль человека склоняет его относиться к инженерам как к взаимозаменяемым ресурсам, тем меньше вероятность, что он поймёт, почему это важно.
ИИ не решит все наши проблемы и не напишет весь код за нас. А даже если бы это было так, написание кода — лишь часть того, что делают профессиональные инженеры-программисты, и, возможно, самая простая часть. Только у нас есть контекст и авторитет, чтобы управлять изменениями, которые составляют основу для отличных команд и совершенствования как инженер.
Источник: https://stackoverflow.blog/2024/12/31/generative-ai-is-not-going-to-build-your-engineering-team-for-you
👍8
День 2178. #Оффтоп
Почему Открытый Код Важен и Бесплатный ли он? Начало
Какие из продуктов вы используете в своей личной или профессиональной работе: Serilog, Polly, PostgreSQL, Git, Curl, Jenkins, Blazor?
Скорее всего вы используете хотя бы один. Большинство ПО в той или иной степени построено на продуктах или библиотеках с открытым кодом. И часто они не поддерживаются большой компанией. Например, Log4J - самая известная библиотека логирования в экосистеме Java. Основная работа выполняется горсткой разработчиков без какой-либо финансовой поддержки. А она использовалась в Apple, Amazon, Steam, Alibaba и т.п.
Log4J / Log4Shell
Коротко напомню: специальный пользовательский ввод может привести к удалённому выполнению кода через сервер LDAP в контексте приложения. А удалённое выполнение кода – это большой красный флаг в сфере ПО. Проблема в том, как это было воспринято теми самыми компаниями, использовавшими Log4J. Согласно этой статье, мейнтейнеры библиотеки получили такое сообщение: «Мы обещаем сохранить это в тайне, пока не выйдет ваш официальный патч. Пожалуйста, поторопитесь.»
Понятно, что из-за такой уязвимости, возможно, придётся отключить затронутые сервисы. А для Amazon или Alibaba это может стоить миллионов и миллиардов дохода за очень короткое время. Мейнтейнеры написали в Твиттере о ситуации: «Сотрудники Log4j не покладая рук трудятся над мерами по смягчению последствий: исправлениями, документацией, CVE, ответами на запросы и т.д. Однако ничто не мешает людям критиковать нас за работу, за которую нам не платят, за функцию, которая нам всем не нравится, но которую необходимо сохранить из-за проблем с обратной совместимостью.»
Другие инциденты
LeftPad был пакетом NPM, который был удалён из-за спора между ментейнером, NPM и компанией. Суть: у мейнтейнера Azer был пакет под названием "kik". Также была компания "kik", которая хотела зарезервировать это имя для себя. Поскольку Azer уже занял это имя, были привлечены юристы. И NPM отдал имя компании. После этого Azer просто удалил свою наиболее используемую библиотеку "leftpad" (да, вы могли просто удалить пакеты из NPM). Конечно, если вы использовали "leftpad" напрямую или транзитивно, ваша сборка ломалась!
Moq — одна из самых известных библиотек в экосистеме dotnet. Создатель Дэниел Каццулино (более известный как kzu) попробовал альтернативный подход к монетизации: он разработал SponsorLink. По сути, в то время он проверял, сделал ли пользователь пожертвование на библиотеку, в которой используется SponsorLink. Он делал это, выполняя HTTP-запрос на какой-то сервер. Я описывал эту ситуацию подробно в этом посте.
Fluent Assertions — одна из популярнейших библиотек для утверждений в юнит-тестах начиная с версии 8 стала платной.
Эти инциденты вызвали довольно много негативной реакции, но все они показывают некоторые фундаментальные недостатки открытого кода:
- Проекты с открытым кодом считаются бесплатными.
- Монетизация — это сложно!
- Требуется поддержка проекта в рабочем состоянии в течение длительного периода
времени.
Продолжение следует…
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
Почему Открытый Код Важен и Бесплатный ли он? Начало
Какие из продуктов вы используете в своей личной или профессиональной работе: Serilog, Polly, PostgreSQL, Git, Curl, Jenkins, Blazor?
Скорее всего вы используете хотя бы один. Большинство ПО в той или иной степени построено на продуктах или библиотеках с открытым кодом. И часто они не поддерживаются большой компанией. Например, Log4J - самая известная библиотека логирования в экосистеме Java. Основная работа выполняется горсткой разработчиков без какой-либо финансовой поддержки. А она использовалась в Apple, Amazon, Steam, Alibaba и т.п.
Log4J / Log4Shell
Коротко напомню: специальный пользовательский ввод может привести к удалённому выполнению кода через сервер LDAP в контексте приложения. А удалённое выполнение кода – это большой красный флаг в сфере ПО. Проблема в том, как это было воспринято теми самыми компаниями, использовавшими Log4J. Согласно этой статье, мейнтейнеры библиотеки получили такое сообщение: «Мы обещаем сохранить это в тайне, пока не выйдет ваш официальный патч. Пожалуйста, поторопитесь.»
Понятно, что из-за такой уязвимости, возможно, придётся отключить затронутые сервисы. А для Amazon или Alibaba это может стоить миллионов и миллиардов дохода за очень короткое время. Мейнтейнеры написали в Твиттере о ситуации: «Сотрудники Log4j не покладая рук трудятся над мерами по смягчению последствий: исправлениями, документацией, CVE, ответами на запросы и т.д. Однако ничто не мешает людям критиковать нас за работу, за которую нам не платят, за функцию, которая нам всем не нравится, но которую необходимо сохранить из-за проблем с обратной совместимостью.»
Другие инциденты
LeftPad был пакетом NPM, который был удалён из-за спора между ментейнером, NPM и компанией. Суть: у мейнтейнера Azer был пакет под названием "kik". Также была компания "kik", которая хотела зарезервировать это имя для себя. Поскольку Azer уже занял это имя, были привлечены юристы. И NPM отдал имя компании. После этого Azer просто удалил свою наиболее используемую библиотеку "leftpad" (да, вы могли просто удалить пакеты из NPM). Конечно, если вы использовали "leftpad" напрямую или транзитивно, ваша сборка ломалась!
Moq — одна из самых известных библиотек в экосистеме dotnet. Создатель Дэниел Каццулино (более известный как kzu) попробовал альтернативный подход к монетизации: он разработал SponsorLink. По сути, в то время он проверял, сделал ли пользователь пожертвование на библиотеку, в которой используется SponsorLink. Он делал это, выполняя HTTP-запрос на какой-то сервер. Я описывал эту ситуацию подробно в этом посте.
Fluent Assertions — одна из популярнейших библиотек для утверждений в юнит-тестах начиная с версии 8 стала платной.
Эти инциденты вызвали довольно много негативной реакции, но все они показывают некоторые фундаментальные недостатки открытого кода:
- Проекты с открытым кодом считаются бесплатными.
- Монетизация — это сложно!
- Требуется поддержка проекта в рабочем состоянии в течение длительного периода
времени.
Продолжение следует…
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
👍19👎1
День 2179. #Оффтоп
Почему Открытый Код Важен? И Бесплатный ли он? Продолжение
Начало
Открытый код бесплатный?
Простой ответ: Да. Можно же просто скачать любой пакет и использовать его? Ну… и да, и нет. Конечно, это «бесплатно». В том смысле, что вы не платите за труд по написанию кода, но есть другие затраты: обслуживание и зависимости. Это звучит странно. Разве не поэтому люди используют библиотеки других людей - чтобы меньше обслуживать код?
Плата за обслуживание
Когда вы используете открытый код, вы наследуете не только его функции, но и его жизненный цикл. Библиотеки с открытым кодом со временем развиваются. У них могут быть критические проблемы, из-за которых вам придётся обновлять пакет. Критические изменения или другие вещи, из-за которых придётся проверять, всё ли ваше ПО по-прежнему делает то, что оно должно делать.
Некоторые проекты с открытым кодом со временем теряют активных мейнтейнеров. Если вы полагаетесь на такую библиотеку, у вас остаётся три варианта:
- Продолжить использовать устаревшую версию (риск безопасности).
- Перейти на альтернативу (может потребовать много усилий, не предоставив прямой ценности).
- Взять на себя обслуживание (сделать форк). Это затраты на обслуживания кода, который вам нужен, а может и не нужен или нужен не весь. Иногда библиотека, от которой вы зависите, не соответствует вашим потребностям, поэтому вам, возможно, придется её форкнуть. Теперь вы также «владеете» кодом со всеми его затратами, зависимостями и последствиями.
Во всех этих случаях вы платите, тратите время и деньги. Каждая зависимость, которую вы создаёте, будет иметь цену. Вам нужно взвесить, оправдана ли она. И эти затраты будут возникать время от времени, а не один раз за весь срок существования проекта. Это особенно важно, если вы используете много микробиблиотек, вроде Left Pad, которые чаще всего содержат не более 10 строк кода и выполняют элементарные функции. Еще один отличный пример: is-even и is-odd. У обеих до сих пор 200000 (да, двести тысяч) загрузок в неделю.
Так что нет, открытый код не бесплатный. Он бесплатный в том смысле, что не стоит денег, но почти всё имеет свою цену! Конечно, то же самое относится и к библиотекам с закрытым кодом, которые вы можете использовать. Они также стоят денег, но они стоят вам большую часть времени денег сверху, и вы не можете наблюдать за процессом разработки открыто.
Все инциденты, описанные ранее, известны и были быстро устранены, потому что всё происходило открыто и прозрачно. Это хорошо. Этим открытый код и прекрасен. И в заключении мы поговорим о другой стороне – мейнтейнерах.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
Почему Открытый Код Важен? И Бесплатный ли он? Продолжение
Начало
Открытый код бесплатный?
Простой ответ: Да. Можно же просто скачать любой пакет и использовать его? Ну… и да, и нет. Конечно, это «бесплатно». В том смысле, что вы не платите за труд по написанию кода, но есть другие затраты: обслуживание и зависимости. Это звучит странно. Разве не поэтому люди используют библиотеки других людей - чтобы меньше обслуживать код?
Плата за обслуживание
Когда вы используете открытый код, вы наследуете не только его функции, но и его жизненный цикл. Библиотеки с открытым кодом со временем развиваются. У них могут быть критические проблемы, из-за которых вам придётся обновлять пакет. Критические изменения или другие вещи, из-за которых придётся проверять, всё ли ваше ПО по-прежнему делает то, что оно должно делать.
Некоторые проекты с открытым кодом со временем теряют активных мейнтейнеров. Если вы полагаетесь на такую библиотеку, у вас остаётся три варианта:
- Продолжить использовать устаревшую версию (риск безопасности).
- Перейти на альтернативу (может потребовать много усилий, не предоставив прямой ценности).
- Взять на себя обслуживание (сделать форк). Это затраты на обслуживания кода, который вам нужен, а может и не нужен или нужен не весь. Иногда библиотека, от которой вы зависите, не соответствует вашим потребностям, поэтому вам, возможно, придется её форкнуть. Теперь вы также «владеете» кодом со всеми его затратами, зависимостями и последствиями.
Во всех этих случаях вы платите, тратите время и деньги. Каждая зависимость, которую вы создаёте, будет иметь цену. Вам нужно взвесить, оправдана ли она. И эти затраты будут возникать время от времени, а не один раз за весь срок существования проекта. Это особенно важно, если вы используете много микробиблиотек, вроде Left Pad, которые чаще всего содержат не более 10 строк кода и выполняют элементарные функции. Еще один отличный пример: is-even и is-odd. У обеих до сих пор 200000 (да, двести тысяч) загрузок в неделю.
Так что нет, открытый код не бесплатный. Он бесплатный в том смысле, что не стоит денег, но почти всё имеет свою цену! Конечно, то же самое относится и к библиотекам с закрытым кодом, которые вы можете использовать. Они также стоят денег, но они стоят вам большую часть времени денег сверху, и вы не можете наблюдать за процессом разработки открыто.
Все инциденты, описанные ранее, известны и были быстро устранены, потому что всё происходило открыто и прозрачно. Это хорошо. Этим открытый код и прекрасен. И в заключении мы поговорим о другой стороне – мейнтейнерах.
Окончание следует…
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
👍7
День 2180. #Оффтоп
Почему Открытый Код Важен? И Бесплатный ли он? Окончание
Начало
Продолжение
Нужно ли платить мейнтейнерам?
Не существует универсального решения. Это зависит от обстоятельств и индивидуальных целей в проекте. Как оправдать эти затраты? Должны ли вы лично донатить? Должна ли компания делать это?
С другой стороны, есть ли ожидания, связанные с этими деньгами? Представьте, что вы получаете $100 доната, и тот же человек лицо/компания открывает тикет или запрос функции, который вы считаете не очень важным. Заставит ли донат вас это реализовывать? Есть мейнтейнеры, которые не берут деньги именно по этой причине.
Не следует ожидать денег от создания ПО с открытым кодом (но получать их, конечно, приятно). По крайней мере, не за тот код, который вы публикуете. Есть компании, как UNO Platform, которые открыли код всех своих продуктов, но вы можете заплатить за контракт на корпоративное обслуживание. Так что, если вам понадобится помощь или функция, они вам помогут.
Приятно иметь стабильный доход от вашего вклада в открытый код, но для большинства проектов этого не будет. Пожертвования хороши, так как сопровождающие, по крайней мере, не терпят убытков в финансовом плане. Они могут нести расходы на серверы, сертификаты и т.д. Если вы цените проект, не стесняйтесь донатить.
Также важно отметить: со стороны мейнтейнеров нет никаких обязательств или гарантий предоставлять поддержку, обновления или определённую функциональность. Они часто работают над проектами в свободное время, движимые страстью или желанием отплатить сообществу. Использование ПО с открытым кодом подразумевает, что между разработчиком и пользователем нет формального контракта. ПО предоставляется «как есть» без гарантий надёжности или пригодности для какой-либо конкретной цели. Это часть стоимости, которую вы платите, если используете какую-либо зависимость.
Зачем вам поддерживать открытый код?
Главное: нет альтернативы, которая была бы лучше в большинстве случаев. У нас нет другой системы, которая бы приносила столько преимуществ по сравнению с недостатками.
Как поддержать открытый код и что я получу?
Самое простое решение (как и со многими проблемами в нашем мире): деньгами. Но это не единственный способ. Тот, кто тратит своё личное время и ресурсы, чтобы улучшить что-то общедоступное - лучше! Если вы создаёте библиотеку, и кто-то пишет вам либо отчёт об ошибке, либо запрос на функцию, либо подаёт пул-реквест, это часто одна из самых высоких наград, которые вы можете получить. Это значит, что кто-то может идентифицировать себя с тем, что вы создали. Мейнтейнеру открытого кода трудно найти кого-то, кто потратит своё время вместе с ним, поэтому время — самый ценный ресурс, который вы можете дать!
Если вы не знаете, как начать, лучше поддерживать небольшие библиотеки, поскольку когнитивная нагрузка для этого меньше. Есть даже целые сайты, такие как https://goodfirstissue.dev/, где вы можете поискать среди репозиториев, кого поддержать.
Что вы получите?
- Знания: изучение чужого кода и шаблонов мышления может помочь вам укрепить ваши собственные хард- и софт-скилы. И, возможно, это даже поможет вам найти работу.
- Нетворкинг: вы познакомитесь с замечательными людьми по всему миру только благодаря вкладам в открытый код.
- Альтруизм: вы делаете добро миру. Ваш код может прямо или косвенно помочь создавать замечательные вещи!
Но, возможно, самое важное. Если вы вносите свой вклад в любой проект с открытым кодом: будьте вежливы и постарайтесь не грубить. Человеческое сотрудничество — это не игра с нулевой суммой! Это совместный вклад в общий успех!
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
Почему Открытый Код Важен? И Бесплатный ли он? Окончание
Начало
Продолжение
Нужно ли платить мейнтейнерам?
Не существует универсального решения. Это зависит от обстоятельств и индивидуальных целей в проекте. Как оправдать эти затраты? Должны ли вы лично донатить? Должна ли компания делать это?
С другой стороны, есть ли ожидания, связанные с этими деньгами? Представьте, что вы получаете $100 доната, и тот же человек лицо/компания открывает тикет или запрос функции, который вы считаете не очень важным. Заставит ли донат вас это реализовывать? Есть мейнтейнеры, которые не берут деньги именно по этой причине.
Не следует ожидать денег от создания ПО с открытым кодом (но получать их, конечно, приятно). По крайней мере, не за тот код, который вы публикуете. Есть компании, как UNO Platform, которые открыли код всех своих продуктов, но вы можете заплатить за контракт на корпоративное обслуживание. Так что, если вам понадобится помощь или функция, они вам помогут.
Приятно иметь стабильный доход от вашего вклада в открытый код, но для большинства проектов этого не будет. Пожертвования хороши, так как сопровождающие, по крайней мере, не терпят убытков в финансовом плане. Они могут нести расходы на серверы, сертификаты и т.д. Если вы цените проект, не стесняйтесь донатить.
Также важно отметить: со стороны мейнтейнеров нет никаких обязательств или гарантий предоставлять поддержку, обновления или определённую функциональность. Они часто работают над проектами в свободное время, движимые страстью или желанием отплатить сообществу. Использование ПО с открытым кодом подразумевает, что между разработчиком и пользователем нет формального контракта. ПО предоставляется «как есть» без гарантий надёжности или пригодности для какой-либо конкретной цели. Это часть стоимости, которую вы платите, если используете какую-либо зависимость.
Зачем вам поддерживать открытый код?
Главное: нет альтернативы, которая была бы лучше в большинстве случаев. У нас нет другой системы, которая бы приносила столько преимуществ по сравнению с недостатками.
Как поддержать открытый код и что я получу?
Самое простое решение (как и со многими проблемами в нашем мире): деньгами. Но это не единственный способ. Тот, кто тратит своё личное время и ресурсы, чтобы улучшить что-то общедоступное - лучше! Если вы создаёте библиотеку, и кто-то пишет вам либо отчёт об ошибке, либо запрос на функцию, либо подаёт пул-реквест, это часто одна из самых высоких наград, которые вы можете получить. Это значит, что кто-то может идентифицировать себя с тем, что вы создали. Мейнтейнеру открытого кода трудно найти кого-то, кто потратит своё время вместе с ним, поэтому время — самый ценный ресурс, который вы можете дать!
Если вы не знаете, как начать, лучше поддерживать небольшие библиотеки, поскольку когнитивная нагрузка для этого меньше. Есть даже целые сайты, такие как https://goodfirstissue.dev/, где вы можете поискать среди репозиториев, кого поддержать.
Что вы получите?
- Знания: изучение чужого кода и шаблонов мышления может помочь вам укрепить ваши собственные хард- и софт-скилы. И, возможно, это даже поможет вам найти работу.
- Нетворкинг: вы познакомитесь с замечательными людьми по всему миру только благодаря вкладам в открытый код.
- Альтруизм: вы делаете добро миру. Ваш код может прямо или косвенно помочь создавать замечательные вещи!
Но, возможно, самое важное. Если вы вносите свой вклад в любой проект с открытым кодом: будьте вежливы и постарайтесь не грубить. Человеческое сотрудничество — это не игра с нулевой суммой! Это совместный вклад в общий успех!
Источник: https://steven-giesel.com/blogPost/591f2354-a205-4507-bbb2-7d88781e0563/why-is-open-source-important-and-is-it-free
👍13
День 2192. #Оффтоп
Когда Прекратится Поддержка .NET Framework?
Вы когда-нибудь задумывались, когда мы наконец избавимся от старого доброго .NET Framework? Короткий ответ: непонятно. Майкрософт обещают продолжать его поддерживать, но это ведь не может продолжаться бесконечно.
Если посмотреть официальную страницу, вы увидите табличку на картинке выше.
Итак, все версии выше .NET Framework 4.7 по-прежнему поддерживается (и даже у 4.6.2 всё ещё 2 года в запасе). Примечание: эти версии практически не имеют конфликтов, поэтому обновление с 4.6.2 до 4.8.1 не должно вызвать никаких проблем.
В любом случае, одним из основных факторов долговечности фреймворка является то, что он связан с Windows. Windows Server 2022 поставляется с .NET 4.8.1. Дата окончания поддержки Windows Server 2022 — октябрь 2031 года. И даже Windows Server 2025 (последняя версия) содержит фреймворк, а её расширенная поддержка заканчивается ещё через 3 года — в 2034 году.
Поэтому весьма вероятно, что .NET Framework 4.8.x будет существовать плюс-минус до этого момента. Возможно, будут выпущены более новые версии с исправлениями из-за проблем с безопасностью (например, SHA-2 устареет или в нём обнаружится уязвимость, и людям придётся перейти на что-то другое).
Конечно, для новой разработки следует использовать .NET 8 и более поздние версии, если возможно. Однако очень маловероятно, что .NET Framework перестанет работать в ближайшее время. Хорошо это или нет, решать вам.
Источник: https://steven-giesel.com/blogPost/6de02565-a08e-4968-b610-22826582c1f1/when-will-net-framework-retire
Когда Прекратится Поддержка .NET Framework?
Вы когда-нибудь задумывались, когда мы наконец избавимся от старого доброго .NET Framework? Короткий ответ: непонятно. Майкрософт обещают продолжать его поддерживать, но это ведь не может продолжаться бесконечно.
Если посмотреть официальную страницу, вы увидите табличку на картинке выше.
Итак, все версии выше .NET Framework 4.7 по-прежнему поддерживается (и даже у 4.6.2 всё ещё 2 года в запасе). Примечание: эти версии практически не имеют конфликтов, поэтому обновление с 4.6.2 до 4.8.1 не должно вызвать никаких проблем.
В любом случае, одним из основных факторов долговечности фреймворка является то, что он связан с Windows. Windows Server 2022 поставляется с .NET 4.8.1. Дата окончания поддержки Windows Server 2022 — октябрь 2031 года. И даже Windows Server 2025 (последняя версия) содержит фреймворк, а её расширенная поддержка заканчивается ещё через 3 года — в 2034 году.
Поэтому весьма вероятно, что .NET Framework 4.8.x будет существовать плюс-минус до этого момента. Возможно, будут выпущены более новые версии с исправлениями из-за проблем с безопасностью (например, SHA-2 устареет или в нём обнаружится уязвимость, и людям придётся перейти на что-то другое).
Конечно, для новой разработки следует использовать .NET 8 и более поздние версии, если возможно. Однако очень маловероятно, что .NET Framework перестанет работать в ближайшее время. Хорошо это или нет, решать вам.
Источник: https://steven-giesel.com/blogPost/6de02565-a08e-4968-b610-22826582c1f1/when-will-net-framework-retire
👍16
День 2299. #Оффтоп
Доброй субботы, дорогие подписчики. Давно не рекомендовал вам познавательных видосиков. Я обожаю истории про историю (извините за тавтологию) развития компьютеров и программирования. И сегодня порекомендую вам одну из таких ламповых – в прямом смысле – историй.
Как появились первые диоды и триоды? Почему алгебру логики называют булевой? Как «считают» компьютеры на самом нижнем уровне? Сколько энергии потреблял первый ЭНИАК?
Об этом и не только в видео с канала Veritasium. Приятного просмотра.
https://youtu.be/FU_YFpfDqqA
(видео с переводом на русский здесь)
А для тех, кому захочется ещё больше углубиться в историю и узнать про аналоговые компьютеры, вот видео в двух частях: часть 1, часть 2 (видео с переводом на русский: часть 1, часть 2).
Доброй субботы, дорогие подписчики. Давно не рекомендовал вам познавательных видосиков. Я обожаю истории про историю (извините за тавтологию) развития компьютеров и программирования. И сегодня порекомендую вам одну из таких ламповых – в прямом смысле – историй.
Как появились первые диоды и триоды? Почему алгебру логики называют булевой? Как «считают» компьютеры на самом нижнем уровне? Сколько энергии потреблял первый ЭНИАК?
Об этом и не только в видео с канала Veritasium. Приятного просмотра.
https://youtu.be/FU_YFpfDqqA
(видео с переводом на русский здесь)
А для тех, кому захочется ещё больше углубиться в историю и узнать про аналоговые компьютеры, вот видео в двух частях: часть 1, часть 2 (видео с переводом на русский: часть 1, часть 2).
YouTube
Why The First Computers Were Made Out Of Light Bulbs
How were the first computers made? Head to https://brilliant.org/veritasium to start your free 30-day trial, and the first 200 people get 20% off an annual premium subscription.
A huge thanks to David Lovett for showing me his awesome relay and vacuum tube…
A huge thanks to David Lovett for showing me his awesome relay and vacuum tube…
👍13
День 2333. #Оффтоп
Проклятие Знания или Исправляем Всё. Начало
Всё начинается невинно. Вы переименовываете пакет файлов с помощью короткого скрипта или создаёте псевдоним для обычной команды git, чтобы сэкономить два нажатия клавиш. Может быть, вы создаёте небольшую shell-функцию для форматирования JSON из буфера обмена.
Вы даже не пытаетесь умничать. Вы просто решаете мелкие проблемы. Заставляете машину делать то, что она должна была делать изначально. И тут что-то происходит. Вы пересекаете черту. Вы смотрите на свои инструменты, среду, ОС — даже на IDE — и внезапно всё становится объектом критики. Это можно было бы переделать, это можно бы улучшить… (если захотеть).
Затем кто-то бросает вам вызов. Возможно, в качестве троллинга, возможно, шутки ради, но также с долей надежды. И тут что-то меняется. Внезапно всё переходит в разряд «Вы должны». И с этого момента мир ломается новыми и специфическими способами, которые можете видеть только вы.
Технические возможности как моральный груз
До того, как я научился программировать, сломанное ПО раздражало, но это можно было игнорировать. Годами я просто «использовал» компьютер, как потребитель. Я был тем, кого компании пытались обманом заставить купить их продукты или подписаться на услуги. Но не техническим гиком.
А сейчас я стал видеть закономерности, которые я бы не хотел видеть, находить упущения, которые я могу приписать определённому пониманию (или отсутствию такового) определённой концепции, и я могу слышать те голоса, что были в голове того компьютерно-безграмотного человека, создавшего программу, которую мне нужно отладить.
Я замечаю недостатки, как хороший хирург замечает хромоту. Какого черта этот сайт отправляет 10 Мб JavaScript кода для статической страницы? Почему вывод CLI не парсится awk? Почему эта конфигурация жёстко закодирована, когда она могла бы быть декларативной? Это не просто вопросы, это обвинения. И, к сожалению, они не прекращаются.
Теперь, когда я научился замечать это, моё восприятие ПО полностью изменилось:
- Каждая часть ПО становится списком TODO.
- Каждая система становится основой для лучшей.
- Каждое неудобство становится обвинением в бездействии.
Нужно представить себе Сизифа счастливым
Как Сизиф, мы обречены толкать камень наших систем в гору — одно исправление, один рефакторинг, один скрипт за раз. Но в отличие от истории о Сизифе, проклятие не наложено на вас каким-то богом. Мы сами создали этот камень. И мы продолжаем полировать его по пути наверх.
Я потерял счёт проектам, начатым с мысли, типа «я мог бы сделать это лучше»:
- Генератор статических веб-страниц, потому что существующие переусложнены.
- Инструмент для заметок, потому что мне не нравилось, как другие структурировали метаданные.
- Исполнитель заданий CLI, потому что Make — это что-то непонятное, а Taskfile — это ад YAML.
Список можно продолжать.
Да, я решал реальные, невинные проблемы. Но оглядываясь назад, я также подпитывал кое-что еще: навязчивое желание установить контроль. Каждый новый инструмент, который я создавал, был песочницей, которой я владел. Никаких странных ошибок. Никаких ограничений старых фреймворков. Никаких решений, с которыми я не был бы полностью согласен. Пока, конечно, все эти проекты не устаревали сами.
Кафка однажды написал, что «клетка отправилась на поиски птицы». Вот чем могут стать эти проекты. Пустые системы, которые мы продолжаем строить, ожидая цели, ясности,… спасения? Я не уверен, как ещё можно назвать это стремление создавать их.
Продолжение следует…
Источник: https://notashelf.dev/posts/curse-of-knowing
Проклятие Знания или Исправляем Всё. Начало
Всё начинается невинно. Вы переименовываете пакет файлов с помощью короткого скрипта или создаёте псевдоним для обычной команды git, чтобы сэкономить два нажатия клавиш. Может быть, вы создаёте небольшую shell-функцию для форматирования JSON из буфера обмена.
Вы даже не пытаетесь умничать. Вы просто решаете мелкие проблемы. Заставляете машину делать то, что она должна была делать изначально. И тут что-то происходит. Вы пересекаете черту. Вы смотрите на свои инструменты, среду, ОС — даже на IDE — и внезапно всё становится объектом критики. Это можно было бы переделать, это можно бы улучшить… (если захотеть).
Затем кто-то бросает вам вызов. Возможно, в качестве троллинга, возможно, шутки ради, но также с долей надежды. И тут что-то меняется. Внезапно всё переходит в разряд «Вы должны». И с этого момента мир ломается новыми и специфическими способами, которые можете видеть только вы.
Технические возможности как моральный груз
До того, как я научился программировать, сломанное ПО раздражало, но это можно было игнорировать. Годами я просто «использовал» компьютер, как потребитель. Я был тем, кого компании пытались обманом заставить купить их продукты или подписаться на услуги. Но не техническим гиком.
А сейчас я стал видеть закономерности, которые я бы не хотел видеть, находить упущения, которые я могу приписать определённому пониманию (или отсутствию такового) определённой концепции, и я могу слышать те голоса, что были в голове того компьютерно-безграмотного человека, создавшего программу, которую мне нужно отладить.
Я замечаю недостатки, как хороший хирург замечает хромоту. Какого черта этот сайт отправляет 10 Мб JavaScript кода для статической страницы? Почему вывод CLI не парсится awk? Почему эта конфигурация жёстко закодирована, когда она могла бы быть декларативной? Это не просто вопросы, это обвинения. И, к сожалению, они не прекращаются.
Теперь, когда я научился замечать это, моё восприятие ПО полностью изменилось:
- Каждая часть ПО становится списком TODO.
- Каждая система становится основой для лучшей.
- Каждое неудобство становится обвинением в бездействии.
Нужно представить себе Сизифа счастливым
Как Сизиф, мы обречены толкать камень наших систем в гору — одно исправление, один рефакторинг, один скрипт за раз. Но в отличие от истории о Сизифе, проклятие не наложено на вас каким-то богом. Мы сами создали этот камень. И мы продолжаем полировать его по пути наверх.
Я потерял счёт проектам, начатым с мысли, типа «я мог бы сделать это лучше»:
- Генератор статических веб-страниц, потому что существующие переусложнены.
- Инструмент для заметок, потому что мне не нравилось, как другие структурировали метаданные.
- Исполнитель заданий CLI, потому что Make — это что-то непонятное, а Taskfile — это ад YAML.
Список можно продолжать.
Да, я решал реальные, невинные проблемы. Но оглядываясь назад, я также подпитывал кое-что еще: навязчивое желание установить контроль. Каждый новый инструмент, который я создавал, был песочницей, которой я владел. Никаких странных ошибок. Никаких ограничений старых фреймворков. Никаких решений, с которыми я не был бы полностью согласен. Пока, конечно, все эти проекты не устаревали сами.
Кафка однажды написал, что «клетка отправилась на поиски птицы». Вот чем могут стать эти проекты. Пустые системы, которые мы продолжаем строить, ожидая цели, ясности,… спасения? Я не уверен, как ещё можно назвать это стремление создавать их.
Продолжение следует…
Источник: https://notashelf.dev/posts/curse-of-knowing
👍19
День 2334. #Оффтоп
Проклятие Знания или Исправляем Всё. Продолжение
Начало
Энтропия непобедима
А теперь вернёмся назад. Назад, когда мы не знали, что можно лучше. ПО не остаётся сделанным. Каждое написанное вами решение начинает гнить в тот момент, когда оно появляется. Не сейчас, не потом, но в итоге. Библиотеки устаревают. API меняются. Происходит регресс производительности. Ваш некогда идеальный инструмент тихо ломается, потому что libfoo.dll с тех пор сменила десяток версий.
У меня были скрипты, которые молча давали сбой, потому что веб-сайт менял свой HTML-макет.
У меня были форматы конфигурации, которые ломались из-за изменения версий библиотек.
У меня были контейнеры Docker, которые умирали, потому что изменялся URL зеркала Alpine Linux.
В каждом случае немедленной эмоциональной реакцией было не просто неудобство, а что-то, что больше напоминало чувство вины. Я создал это, и я лучше знаю. Как я мог этого не предвидеть? Пора это исправить.
Если вы замените каждую часть системы с течением времени, это всё тот же инструмент? Он все ещё служит той же цели? А вы?
Иллюзия завершённости
Я думаю, мы лжём себе:
«Если я просто правильно настрою эту программу, мне больше никогда не придётся к ней прикасаться»
«Если я просто напишу этот инструмент, мой рабочий процесс станет безупречным»
«Если я автоматизирую это, я сэкономлю время навсегда»
«Напиши один раз, запусти везде». Ну да, конечно.
Признаю, это соблазнительная ложь. Она представляет программирование как своего рода завоевание. Серию сражений, в которых вы побеждаете, или испытаний, которые вы проходите. Но воображаемая война никогда не заканчивается. Вы не строите замок. Вы роете траншеи. И они затапливаются каждый раз, когда идет дождь. Испытания никогда не завершаются.
Техническая работа как эмоциональная регуляция
- Марк Аврелий
Но программирование соблазняет нас, заставляя верить, что мы можем контролировать внешние события. Вот где начинаются страдания. Здесь происходит что-то более глубокое. Это касается не только ПО.
Я считаю, что иногда создание вещей — это способ самоуспокоения. Мы пишем новый инструмент или сценарий, потому что отчаянно нуждаемся в маленькой победе. Мы пишем новый инструмент, потому что мы подавлены. Рефакторим его не потому, что код в беспорядке, а потому, что наша жизнь в беспорядке. Мы гонимся за идеальной системой, потому что она даёт нам что-то, за что можно ухватиться, когда все остальное рушится.
Я писал целые приложения, чтобы не думать о том, почему я был несчастлив. Программирование даёт вам мгновенную обратную связь. Вы запускаете что-то, и оно работает. Или не работает, и вы это исправляете. В любом случае, вы что-то делаете.
Такого рода деятельность вызывает привыкание. Особенно, когда остальная жизнь не даёт удовлетворения. Мы программируем, потому что можем, даже когда не должны. Потому что, по крайней мере, это даёт нам что-то, что можно исправить.
Окончание следует…
Источник: https://notashelf.dev/posts/curse-of-knowing
Проклятие Знания или Исправляем Всё. Продолжение
Начало
Энтропия непобедима
А теперь вернёмся назад. Назад, когда мы не знали, что можно лучше. ПО не остаётся сделанным. Каждое написанное вами решение начинает гнить в тот момент, когда оно появляется. Не сейчас, не потом, но в итоге. Библиотеки устаревают. API меняются. Происходит регресс производительности. Ваш некогда идеальный инструмент тихо ломается, потому что libfoo.dll с тех пор сменила десяток версий.
У меня были скрипты, которые молча давали сбой, потому что веб-сайт менял свой HTML-макет.
У меня были форматы конфигурации, которые ломались из-за изменения версий библиотек.
У меня были контейнеры Docker, которые умирали, потому что изменялся URL зеркала Alpine Linux.
В каждом случае немедленной эмоциональной реакцией было не просто неудобство, а что-то, что больше напоминало чувство вины. Я создал это, и я лучше знаю. Как я мог этого не предвидеть? Пора это исправить.
Если вы замените каждую часть системы с течением времени, это всё тот же инструмент? Он все ещё служит той же цели? А вы?
Иллюзия завершённости
Я думаю, мы лжём себе:
«Если я просто правильно настрою эту программу, мне больше никогда не придётся к ней прикасаться»
«Если я просто напишу этот инструмент, мой рабочий процесс станет безупречным»
«Если я автоматизирую это, я сэкономлю время навсегда»
«Напиши один раз, запусти везде». Ну да, конечно.
Признаю, это соблазнительная ложь. Она представляет программирование как своего рода завоевание. Серию сражений, в которых вы побеждаете, или испытаний, которые вы проходите. Но воображаемая война никогда не заканчивается. Вы не строите замок. Вы роете траншеи. И они затапливаются каждый раз, когда идет дождь. Испытания никогда не завершаются.
Техническая работа как эмоциональная регуляция
«У вас есть власть над своим разумом, а не над внешними событиями. Осознайте это, и вы обретёте силу.»
- Марк Аврелий
Но программирование соблазняет нас, заставляя верить, что мы можем контролировать внешние события. Вот где начинаются страдания. Здесь происходит что-то более глубокое. Это касается не только ПО.
Я считаю, что иногда создание вещей — это способ самоуспокоения. Мы пишем новый инструмент или сценарий, потому что отчаянно нуждаемся в маленькой победе. Мы пишем новый инструмент, потому что мы подавлены. Рефакторим его не потому, что код в беспорядке, а потому, что наша жизнь в беспорядке. Мы гонимся за идеальной системой, потому что она даёт нам что-то, за что можно ухватиться, когда все остальное рушится.
Я писал целые приложения, чтобы не думать о том, почему я был несчастлив. Программирование даёт вам мгновенную обратную связь. Вы запускаете что-то, и оно работает. Или не работает, и вы это исправляете. В любом случае, вы что-то делаете.
Такого рода деятельность вызывает привыкание. Особенно, когда остальная жизнь не даёт удовлетворения. Мы программируем, потому что можем, даже когда не должны. Потому что, по крайней мере, это даёт нам что-то, что можно исправить.
Окончание следует…
Источник: https://notashelf.dev/posts/curse-of-knowing
👍27
День 2335. #Оффтоп
Проклятие Знания или Исправляем Всё. Окончание
Начало
Продолжение
Выгорание, которого вы не ожидали
Выгорание происходит не только от переутомления. Оно происходит от чрезмерной ответственности. А программирование, если оно достаточно глубоко усвоено, заставляет всё казаться вашей ответственностью. Раздутый веб-сайт. Неэффективный скрипт. Неуклюжий процесс адаптации на вашей работе. Вы можете это исправить. Так почему же вы этого не делаете?
Правда, которую вы прекрасно знаете, заключается в том, что вы не можете исправить всё. Вы знаете это, вы всегда это знали, независимо от вашего уровня мастерства. Но попробуйте сказать это той части вашего мозга, которая видит любую неэффективность как моральный провал.
Ницше предупреждал о том, что не стоит слишком долго смотреть в бездну. Но он не предупреждал, что произойдет, если бездна — это Makefile или проект из 30 тыс. строк кода.
Учимся отпускать
Так где же выход? Это похоже на описание ада Сартром, где ад — это другие люди и то, как они взаимодействуют с вашим ПО? Или это какой-то странный ад, где люди создают ПО, с которым вам приходится взаимодействовать?
Первый шаг — признать, что не всё сломанное можно исправить.
Не каждый инструмент нужно заменять.
Не каждый плохой опыт — это призыв к действию.
Иногда нормально просто использовать вещь. Иногда достаточно знать, почему она сломалась, даже если вы её не почините. Иногда самое дисциплинированное, что вы можете сделать, — это уйти от проблемы, которую знаете, как решить. В этом есть какая-то сила.
Не апатия, нет. И не лень. Просто… некоторая сдержанность.
Новый вид навыка
А что, если настоящий навык — это не техническое мастерство? Или, ещё лучше, если это эмоциональная ясность?
- Знать, какие проблемы стоят вашей энергии.
- Знать, какие проекты стоит поддерживать.
- Знать, когда вы создаёте, чтобы помочь, а когда вы создаёте, чтобы превозмочь.
- Знать, когда остановиться.
Это то, чему я пытаюсь научиться сейчас. После волнения. После одержимости. После выгорания. Я пытаюсь позволить вещам оставаться немного сломанными. Потому что я понял, что не хочу всё чинить. Я просто хочу чувствовать себя хорошо в мире, который часто не идеален. Я могу что-то исправить, но не всё.
Вы учитесь программировать. Вы учитесь чинить вещи. Но самое трудное, чему вы когда-либо научитесь, — это знать, когда оставить их сломанными.
И, возможно, это самый важный навык из всех.
Источник: https://notashelf.dev/posts/curse-of-knowing
Проклятие Знания или Исправляем Всё. Окончание
Начало
Продолжение
Выгорание, которого вы не ожидали
Выгорание происходит не только от переутомления. Оно происходит от чрезмерной ответственности. А программирование, если оно достаточно глубоко усвоено, заставляет всё казаться вашей ответственностью. Раздутый веб-сайт. Неэффективный скрипт. Неуклюжий процесс адаптации на вашей работе. Вы можете это исправить. Так почему же вы этого не делаете?
Правда, которую вы прекрасно знаете, заключается в том, что вы не можете исправить всё. Вы знаете это, вы всегда это знали, независимо от вашего уровня мастерства. Но попробуйте сказать это той части вашего мозга, которая видит любую неэффективность как моральный провал.
Ницше предупреждал о том, что не стоит слишком долго смотреть в бездну. Но он не предупреждал, что произойдет, если бездна — это Makefile или проект из 30 тыс. строк кода.
Учимся отпускать
Так где же выход? Это похоже на описание ада Сартром, где ад — это другие люди и то, как они взаимодействуют с вашим ПО? Или это какой-то странный ад, где люди создают ПО, с которым вам приходится взаимодействовать?
Первый шаг — признать, что не всё сломанное можно исправить.
Не каждый инструмент нужно заменять.
Не каждый плохой опыт — это призыв к действию.
Иногда нормально просто использовать вещь. Иногда достаточно знать, почему она сломалась, даже если вы её не почините. Иногда самое дисциплинированное, что вы можете сделать, — это уйти от проблемы, которую знаете, как решить. В этом есть какая-то сила.
Не апатия, нет. И не лень. Просто… некоторая сдержанность.
Новый вид навыка
А что, если настоящий навык — это не техническое мастерство? Или, ещё лучше, если это эмоциональная ясность?
- Знать, какие проблемы стоят вашей энергии.
- Знать, какие проекты стоит поддерживать.
- Знать, когда вы создаёте, чтобы помочь, а когда вы создаёте, чтобы превозмочь.
- Знать, когда остановиться.
Это то, чему я пытаюсь научиться сейчас. После волнения. После одержимости. После выгорания. Я пытаюсь позволить вещам оставаться немного сломанными. Потому что я понял, что не хочу всё чинить. Я просто хочу чувствовать себя хорошо в мире, который часто не идеален. Я могу что-то исправить, но не всё.
Вы учитесь программировать. Вы учитесь чинить вещи. Но самое трудное, чему вы когда-либо научитесь, — это знать, когда оставить их сломанными.
И, возможно, это самый важный навык из всех.
Источник: https://notashelf.dev/posts/curse-of-knowing
👍20
День 2387. #Оффтоп
Давно не рекомендовал вам видео. А тут вчера у Дудя вышло прекрасное интервью с Андреем Дороничевым. Это своего рода сиквел популярного фильма Дудя про Кремниевую долину. Андрей с тех пор ушёл из гугла и создал стартап, где использует ИИ для решения разных больших задач (в данный момент – лекарство от рака). В интервью не только про него самого, но и 100500 "тупых вопросов" про ИИ (что он уже может и сможет в будущем, под угрозой ли наши профессии, будет ли восстание машин и т.п.), а также про личностный рост и про IT сферу вообще.
Мне очень понравилось, поэтому делюсь. Выделите 2 часа 40 минут в своём графике. Это интересно.
https://youtu.be/1SLvIof4-Zw
Давно не рекомендовал вам видео. А тут вчера у Дудя вышло прекрасное интервью с Андреем Дороничевым. Это своего рода сиквел популярного фильма Дудя про Кремниевую долину. Андрей с тех пор ушёл из гугла и создал стартап, где использует ИИ для решения разных больших задач (в данный момент – лекарство от рака). В интервью не только про него самого, но и 100500 "тупых вопросов" про ИИ (что он уже может и сможет в будущем, под угрозой ли наши профессии, будет ли восстание машин и т.п.), а также про личностный рост и про IT сферу вообще.
Мне очень понравилось, поэтому делюсь. Выделите 2 часа 40 минут в своём графике. Это интересно.
https://youtu.be/1SLvIof4-Zw
YouTube
Чипы Маска, восстание машин и лекарство от рака / вДудь
Более 1700 компаний уже выбрали Astana Hub для выхода на глобальный рынок — присоединяйтесь:
https://astanahub.com/ru/l/kak-otkryt-it-kompanyiu-v-kazakhstane?utm_source=youtube&utm_medium=vdud&utm_campaign=visa
Программы для фаундеров, digital-кочевников…
https://astanahub.com/ru/l/kak-otkryt-it-kompanyiu-v-kazakhstane?utm_source=youtube&utm_medium=vdud&utm_campaign=visa
Программы для фаундеров, digital-кочевников…
👎30👍17
День 2412. #Оффтоп
Berghain-Челлендж
Вот такой мистический билборд увидели на улицах Сан-Франциско. Попробуйте расшифровать.
Если у вас (как и у меня) ничего не получилось, то, видимо, вы мало знаете про AI 😊 На самом деле, это набор o200k токенов, которые все вместе складываются в URL listenlabs.ai/puzzle
Там вас ждёт следующий челлендж.
Berghain*-Челлендж
Berghain — ночной техно-клуб в Берлине. Вы — вышибала в ночном клубе. Ваша цель — заполнить заведение N=1000 людьми, соблюдая ограничения, например, «не менее 40% местных жителей Берлина» или «не менее 80% одеты в чёрное». Люди приходят по одному, и вам нужно сразу же решить, впускать их или нет. Ваша задача — заполнить заведение, получив как можно меньше отказов, соблюдая при этом все минимальные требования.
Как это работает
- Люди приходят последовательно с бинарными признаками (например, женщина/мужчина, молодой/старый, постоянный/новичок).
- Вы должны немедленно принимать решения о принятии/отклонении.
- Игра заканчивается, когда:
(a) заведение заполнено (1000 человек).
(b) вы отклонили 20 000 человек.
Сценарии и подсчёт очков
Возможно 3 различных сценария. Для каждого из них вам предоставляется список ограничений и статистика распределения признаков. Можно предположить, что участники отбираются независимо друг от друга, то есть распределение характеристик не изменится в течение вечера. Вы знаете общую относительную частоту встречаемости каждой характеристики и корреляцию между ними. Точное распределение вам неизвестно.
Ваш результат — это количество людей, которым вы отказали до заполнения площадки (чем меньше, тем лучше).
Приз
Человек, занявший первое место в таблице лидеров на 15 сентября в 6:00 по тихоокеанскому времени, станет победителем и получит билет в Berghain за счёт оргазизаторов! Также вы сможете пройти собеседование с Listen.
Все подробности тут.
PS: Если вдруг кто решит принять участие, пожалуйста, отпишитесь в комментариях о результатах.
Berghain-Челлендж
Вот такой мистический билборд увидели на улицах Сан-Франциско. Попробуйте расшифровать.
Там вас ждёт следующий челлендж.
Berghain*-Челлендж
Berghain — ночной техно-клуб в Берлине. Вы — вышибала в ночном клубе. Ваша цель — заполнить заведение N=1000 людьми, соблюдая ограничения, например, «не менее 40% местных жителей Берлина» или «не менее 80% одеты в чёрное». Люди приходят по одному, и вам нужно сразу же решить, впускать их или нет. Ваша задача — заполнить заведение, получив как можно меньше отказов, соблюдая при этом все минимальные требования.
Как это работает
- Люди приходят последовательно с бинарными признаками (например, женщина/мужчина, молодой/старый, постоянный/новичок).
- Вы должны немедленно принимать решения о принятии/отклонении.
- Игра заканчивается, когда:
(a) заведение заполнено (1000 человек).
(b) вы отклонили 20 000 человек.
Сценарии и подсчёт очков
Возможно 3 различных сценария. Для каждого из них вам предоставляется список ограничений и статистика распределения признаков. Можно предположить, что участники отбираются независимо друг от друга, то есть распределение характеристик не изменится в течение вечера. Вы знаете общую относительную частоту встречаемости каждой характеристики и корреляцию между ними. Точное распределение вам неизвестно.
Ваш результат — это количество людей, которым вы отказали до заполнения площадки (чем меньше, тем лучше).
Приз
Человек, занявший первое место в таблице лидеров на 15 сентября в 6:00 по тихоокеанскому времени, станет победителем и получит билет в Berghain за счёт оргазизаторов! Также вы сможете пройти собеседование с Listen.
Все подробности тут.
PS: Если вдруг кто решит принять участие, пожалуйста, отпишитесь в комментариях о результатах.
👍5
День 2428. #Оффтоп
Странная Ошибка Компиляции
Пишу экспорт отчёта в CSV. До этого использовали библиотеку EPPlus (её же используем для экспорта в Excel), но из-за большого размера отчёта оно периодически падает с Out of memory.
Свойства объектов экспортируемой коллекции помечены атрибутами EPPlus для форматирования. Типа
Понятно, что EPPlus при экспорте сам эти атрибуты обрабатывает, а мне в самодельном экспорте надо их ручками вытягивать через рефлексию. См. вторую картинку. Обращаюсь через
или
И вот когда в
В обоих файлах ссылка на нугет есть, юзинг неймспейса есть. И
Предложения по исправлению ничем не помогают. Там только что-то в духе «Создать новый класс 'EpplusTableColumn'…».
Есть предположения, в чём проблема?
Чуть позже выложу ответ.
UPD: довольно быстро догадались, ответ в комментариях.
Странная Ошибка Компиляции
Пишу экспорт отчёта в CSV. До этого использовали библиотеку EPPlus (её же используем для экспорта в Excel), но из-за большого размера отчёта оно периодически падает с Out of memory.
Свойства объектов экспортируемой коллекции помечены атрибутами EPPlus для форматирования. Типа
[EpplusIgnore] для игнорирования свойства, [EpplusTableColumn(Header="Заголовок", Order = 1)] - для имени заголовка колонки и порядка. См. первую картинку.Понятно, что EPPlus при экспорте сам эти атрибуты обрабатывает, а мне в самодельном экспорте надо их ручками вытягивать через рефлексию. См. вторую картинку. Обращаюсь через
Attribute.GetCustomAttribute(prop, typeof(…))
или
prop.CustomAttributes.Any(a => a.AttributeType == typeof(…))
И вот когда в
typeof(…) кидаю EpplusIgnore, всё работает, а когда кидаю EpplusTableColumn - пишет The type or namespace name 'EpplusTableColumn' could not be found (are you missing a using directive or an assembly reference?)
В обоих файлах ссылка на нугет есть, юзинг неймспейса есть. И
EpplusIgnore, и EpplusTableColumn находятся в одной сборке, в одном неймспейсе, и как атрибуты модели работают прекрасно.Предложения по исправлению ничем не помогают. Там только что-то в духе «Создать новый класс 'EpplusTableColumn'…».
Есть предположения, в чём проблема?
Чуть позже выложу ответ.
UPD: довольно быстро догадались, ответ в комментариях.
👍2