Комментарии 54
«Я всегда буду искать ленивого человека — он найдёт лёгкий путь решить задачу».
Искать он может кого угодно. Наймет лучшего из 100. А чем ленивее программист, тем он меньше знает и ему можно меньше платить.
А чем ленивее программист, тем он меньше знает
Не путайте ленивого и невежду.
Ну кстати я действительно не очень понимаю, как ленивый программист может стать хорошим программистом.
Неленивый программист напишет свой плеер и будет знать, как пишутся плееры. Ленивый прикрутит чей-нибудь чужой и будет знать, как прикручиваются чужие плееры.
Написанный плеер будет иметь кучу детских болячек, в то время как прикрученный чужой может просто работать.
Ленивый программист и так уже знает, как пишется плееры. Потому что ему интересно. Ему просто западло писать 100500й плеер.
Велосипеды писать стоит в двух случаях
для обучения написания велосипедов, но это не в прод, просто для себя
если во всех имеющихся велосипедах нет нужного набора педалей, и прикрутить их не получится
Просто писать в проде велосипед только оттого что захотелось сделать самому - это как минимум непрофессионально, это трата денег работодателя на свои развлечения, причем это для работодателя в будущем может вылиться в массу проблем с поддержкой этого велосипеда.
Лень(всмысле, не обычная лень, а хорошая програмерская лень о коей идёт речь в статье) не распространяется на знания, она только про продукт. Несомненно, если для программиста цель узнать и понять, как пишутся плееры, здесь лениться всё же нельзя. А вот если говорить про прод, где нужно просто сделать так, чтобы фича была сделана максимально быстро и качественно, то тут лучше использовать чужие плееры.
Исходя из текста все же говорится об оптимизации работы, ведь для того что бы поехать куда-то мы не собираем с нуля автомобиль, выплавляя корпус из кричного железа.
И да в этом программист ленив. А как пишутся плееры при интересе можно и в свободное время узнать.
Образец трудолюбия - это индусы пишущие тысячи строк кода в день.
А результат трудолюбия - это рухнувший Боинг https://habr.com/ru/post/458224/
Это же просто красивое выражение, в котором, как и в каждой шутке, есть некая доля шутки, и некая доля правды.
Если бы в МС работали только ленивые программисты, они бы не выпустили с десяток операционок и тонну другого софта.
Да. Однако, я всё же сначала отнёсся к этому буквально и не понимал как так вообще может быть. Также думаю, что кто-то реально мог намотать это на ус и начать лениться в привычном понимании этого слова. Так что после разбирательства "что и как" сформулировал хоть и сухое и бесвкусное, но более точное прилагательное -- "Эффективный".
Ну софт они обычно покупают вместе с компаниями, начиная с MS DOS. Менеджеры как-раз не ленивые )
Судя по качеству их софта...то у них не ленивые маркетологи, а программисты именно лентяи
У слова день есть определенное значение, которое за ним закреплено уже много веков. Согласно словарю Ожегова лень это отсутствие желания трудится. Сейчас часто можно услышать, когда словом лень называют что то совсем другое - желание сделать работу наиболее эффективным путем. Какая же это лень? Это высшая форма трудолюбия - не просто сделать дело, но и сделать его в кратчайшие сроки, с опережением графика, чтобы поскорее взяться за новую работу. Лень же это другое: когда человек либо вообще не делает работу, либо делает ее по принципу "и так сойдёт".
Отстуствие лени это когда индус пишет десять тысяч строк кода за десять часов работы с ежедневными переработками на радость менеджерам,
и эти десять тысяч строк когда делают абсолютно то же самое, что десять строк кода написанных лентяем за несколько минут.
Отсуствие лени радует тех "эффективных" менеджеров, кто считает, что плац нужно подметать ломиками с утра до поздней ночи, потому что нужен не результат, а чтобы все максимально задолбались и показали своё трудолюбие.
Он что случайно по клавиатуре левой ногой постучал и получил эти гениальные 10 строк кода? Для этого надо было предварительно 10000 часов усердно учиться, практиковаться, не лениться изучать математику, алгоритмы, структуры данных, парадигмы и шаблоны разработки, а также многие существующие фреймворки и библиотеки, да и ещё английский язык, чтобы иметь возможность изучать вышеперечисленное. Это не лень.
Статья напомнила мне одну очень древнюю цитату. Не ручаюсь за точность, но что-то вроде
такого: "одно и тоже высказывание из уст цезаря звучит как что-то гениальное, а из уст плебея как глупость". Наверное, чтобы проверить гениальность идеи использования ленивого (по Ожегову ) программиста, нужно было привести эту мысль без упоминания Гейтса ;)
Larry Wall обосновал и сделал хорошо известной эту мысль в Programming Perl (1st edition, 1991, Oreilly.).
"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
И, немного (?) не в тему, но Ваш КПДВ напомнил:
god is Real;
unless it declared Integer;
Лень и эффективность - близнецы братья ?!
Разве эффективно не значит - дорого ? Не значит.
( Сам сейчас решаю задачу недорого светильника для теплиц с эффективностью более 200 Лм\Вт )
Мне кажется, здесь имеет место быть путаница понятий. Ленивый человек не станет писать документацию, чтобы потом его не дёргали вопросами. Он постарается не делать вообще ничего, и это настолько иррационально, что его бездействие сейчас может привести к куда большим трудозатратам в будущем - но ему не хочется об этом думать. Как с зубами - человек тянет до последнего, хотя сходить сейчас, и сходить через месяц, когда уже прям болит - усилия одинаковые, только во втором случае проблем будет больше.
"Хороший ленивый" человек, о котором вы пишите, ищет наименее энергозатратную траекторию в пространстве вариантов своих действий. Назвать это ленью едва ли можно. Что-то даже слово на ум не идёт. Ленивый в классическом смысле - это тот, кто ищет наименее энергозатратную деятельность в текущем моменте, не думая о будущем. Лежать на печи, если можно, даже если это приведёт к проблемам, на решение которых потребуются силы. А тот программист, который напишет свой велосипед - это, по сути, человек с большим количеством энергии, совершенно не смотрящий в будущее. Он готов делать что-то энергозатратное в здесь и сейчас, не пытаясь найти более оптимальный путь к результату. Полная противоположность ленивого человека, который в здесь и сейчас стремится к бездействию. А тот "хороший ленивый", вовсе не ленивый, в настоящем моменте у него может быть много или мало сил, его основное качество - дальновидность.
Тут уже написали, как впрочем и в статье это раскрыто, что речь скорее об эффективности, а не о лени.
Я отмечу еще один момент. В неэффективно построенной рабочей среде, даже классическая лень может оказаться эффективной. Это неплохо иллюстрируется мемасиком про "эффективную улиточку"
некоторые программисты настолько ленивы, что сразу пишут рабочий код (с)
Какой-то не очень ленивый программист. Если прикручено готовое решение для видеопроигрывателя, можно же вместо написания документации дать ссылки на документацию этого решения
Он сначала, вероятно, напишет документацию в нужных местах
А на следующий день требования к видеопроигрывателю чуть-чуть поменяются, и придется переписывать половину кода, и документация естественно устареет. Нет уж, лучше чуть подождать. К томуже, хороший код - самодокументирующийся код. А получая вопросы от коллег, можно найти места, где можно улучшить
Хороший программист создан автоматизировать,
Действительно, зачем тратить полчаса на выполнение операции, если можно потратить десяток увлекательных часов в поиске бага в скрипте автоматизации?
А на следующий день требования к видеопроигрывателю чуть-чуть поменяются, и придется переписывать половину кода, и документация естественно устареет. Нет уж, лучше чуть подождать. К томуже, хороший код - самодокументирующийся код. А получая вопросы от коллег, можно найти места, где можно улучшить
Соглашусь, это звучит ещё ленивее. Нет предела совершенства для лени.
Действительно, зачем тратить полчаса на выполнение операции, если можно потратить десяток увлекательных часов в поиске бага в скрипте автоматизации?
Угу, когда я видел в других статьях фразу аля "Если вам приходится делать это дважды, то это необходимо автоматизировать.", то тоже недоумевал. Я всё же предполагаю, что автоматизация нужна, когда ожидается что это действие будет проделываться много и много раз. Например каждый день... на протяжении многих лет. Тут уже банальная математика. Что лучше? - 10 ч * 1раз против 0,5 ч * 999раз.
Ленивый программист - жадный программист!
Лень — мать всех пороков и сестра всех достоинств. Ленивый, но скилованный человек не будет тратить энергию на всё подряд и меньше подвержен скоротечному хайпу, потому что она работает как тормоз желаний. Лень может быть полезной только в сочетании с остальными скилами, а обычные лентяи никому не нужны :)
ИМХО статья с приветом капитану Очевидность. Много софта не пишут с нуля и, даже, статьи на Хабр подкрепляют цитатами (как обсуждаемая). Игра со значением слова "лень" и не больше.
В основном смысл статьи как раз по игре со значением слова "лень", да.
Однако, между тем тут ещё и говорится о самом посыле этой фразы, который всё же может быть для многих полезным. Например для меня, я считаю, что я могу работать ленивее и эффективнее, но редко когда обращаюсь за решением на гитхаб или в библиотеки - постоянно делаю всё сам, что забирает уйму времени.
Я думаю(и надеюсь), что я всё же не один такой, так что для тех, кто ещё вообще не знаком с этой цитаткой Гейтса и статьям по теме, это будет также полезно.
постоянно делаю всё сам, что забирает уйму времени.
Какая от этого польза?
Предположим такую ситуацию. Молодой инженер окончил вуз и устроился работать на велосипедный завод. Начал изобретать с нуля велосипед. Через пару месяцев, а может и раньше, начальник скажет ему: кончай дурью маяться, пройдись по заводу и посмотри, что мы уже делаем.
PS Очевидно, что можно придумать много способов, как бесполезно тратить время. — С приветом капитану Очевидность.
Конечно, если настолько всё преувеличивать, то оно выглядит очевидно. Однако, вопрос в том, насколько много надо лениться?
До уровня использования высокоуровневых языков для создания сайтиков, вместо того, чтобы юзать Ассемблер. Или до уровня использования готовых устоявшихся БД аля SQL, вместо того, чтобы делать с нуля свою?
Понятно что все эти базовые вещи никто не пишет с нуля, но вот все ли понимают, что для создания обычной нейросети по распознованию буковок НЕ в учебных целях куда эффективнее использовать готовые библиотеки.
Какая от этого польза?
Ну, когда я садился писать велики, я думал такие мысли: В решении вряд ли есть решение, коие мне нужно и мне его не повернуть в нужную мне сторону. Там будет лишний код, из-за которого будет полнеть кодовая база и программа станет медленнее... и всё в таком духе. Сейчас я, конечно, пытаюсь откинуть эти мысли и искать готовые решения, однако, судя по всему, мои гугловские скиллы всё же не настолько прокачены - очень не часто удаётся найти решения, которые бы меня устраивали.
Добавлю пару ленивых практик от себя.
Когда я занимаюсь багфиксом и идендифицировал причину бага - я проверяю не создан ли он недавно за счёт того, что IDE выводит даты последних изменений в этом фрагменте кода. Я много раз сталкивался со случаями когда багу день-два и можно по горячим следам найти его создателя и задать вопросы, а не фиксить самому и не факт, что не добавить больше багов.
Я настолько ленив, что перед тем что б что-то пушить я делаю базовое регрессионное тестирование и гоняю тесты, добиваю покрытие. Заодно мне позже сломают функционал с меньшим шансом ибо я покрыл тестами.
Я ленив и не верю ни себе не окружаюшим на 100%. Мои IDE начинены различными средствами подсветки синтаксиса, проверки грамматики, SAST, сниппетами и т.п. Одна из первых вещей которые я делаю приходя в новую компанию - конфигурирую мои настройки автоформатирования кода под код стайл новой компании. И само собой я не говорю о чём то столь примитивном как функционал автоформатирования visual studio, который, как по мне, до неловкого примитивен. Мне лень иметь не консистентное форматирование кода которое замедлит его чтение, а тем более руками форматировать код.
Когда я верстаю - я стараюсь не использовать margin и border, предпочитая им padding и outline. Это вызвано большим количеством responsive багов которые мне приходилось подчищать за другими разработчиками.
Если нет нужной мне документации - я ищу исходные коды на гитхабе использующие нужные мне элементы. Мне проще пробежаться глазами по тому как сделали другие чем тратить время на поиск своего решения.
Я люблю DAST решения в пайплайне ведь это фактически тестирование API набором дефолтных тестов, в том числе на некорректные значения, пускай и результаты таких тестов требуют некоторой квалификации, что б знать, что ложное срабатывание, а что нет.
Я трачу время на изучение хороших практик, держу руку на пульсе state of art, ведь мне лень писать неэффективно.
Я люблю держать хорошие отношения с тестерами. Это позволяет мне эффективно коммуницировать с ними, тем самым упрощая себе и им жизнь. У меня как у ленивого программиста выработалось чутьё на баги, по этому, когда я листаю код я переодически вижу возможные баги, спрашиваю тесторов нет ли у них сценария на такое-то стечение обстоятельств и часто действительно обнаруживается баг.
Пока ты спишь технический долг растёт. Пока ты ешь технический долг растёт. Пока ты кодишь технический долг растёт. Пока технический долг растёт технический долг растёт. Я вкладываю некоторые силы в рефакторинг и улучшение фрагмента кода с которым я работаю, если вижу, что это окупится. Мне абсолютно не хочется потом разгребать пахучий bus factor код, проще потихоньку сейчас его менять.
Самое эффективное выполнение задачи - это то для которого не пришлось ничего делать либо решить минимумом ресурсов. Есть куча способов это достичь, и зависит от контекста. Очень часто это переиспользование уже существующих элементов.
Лень - она разная бывает :)
Я в первый раз дзен ленивости программиста осознал ещё в школе, в 91-м. У нас тогда уже второй поток осваивал программирование в рамках информатики (я был в первом потоке). И вот, как-то раз, зайдя между делом в компьютерный класс, я наблюдал как десятиклассники пишут лабораторку, в которой надо было на бейсике нарисовать шахматную доску с шашками (схематично, квадратики, кружочки, не более). Мимоходом глянув в мониторы я узрел очень неленивого программиста - весь его экран был заполнен командами вида "draw_rect(12,24,24,36)". А ещё у него на столе лежала тетрадка, где на одной половине были расчёты, а на второй - выписаны цифры... Я бы так никогда не смог :)
Собственно, моя программа годовалой давности состояла примерно из трёх циклов.
Для меня ленивый программист - это не тот, кому лень работу работать, а тот, который стремится сэкономить силы при решении задачи "сегодня, завтра и послезавтра", т.е., условно, во временя непостредственного решения задачи, при дальнейшем сопровождении, и при будущем развитии.
Парадокс в том, что ленивость требует предусмотрительности, вдумчивости и знаний. И именно это делает такого программиста хорошим.
Я слишком ленив, чтобы делать какую-то задачу больше 0 раз, если её в принципе можно не делать. В крайнем случае могу сделать максимум 1 раз, если вариант с 0 не подходит.
Да, такой пунктик тоже был в статейках:
Еще трудолюбивый программист может неэффективно расходовать свое время, делая работу, о которой его не просили. Например, если для некоторых данных требуется предусмотреть API создания и обновления, трудолюбивый программист может проявить инициативу и также написать API для удаления этих данных. Совершенно лишний API, который никто не просил, и который, скорее всего, никто и никогда не будет использовать! Мало того, что было потрачено время на написание этого API, так его еще нужно и поддерживать. Ленивый программист никогда не допустит такой ужасной ошибки.
(откуда цитата я уже указал ссылку в посте: https://eax.me/lazy/)
Однако, он мне показался немного очевидным, так что я не стал его включать.
Лень, нетерпеливость и высокомерие - три главных достоинства программиста, как говаривал небезызвестный Ларри Уолл.
Примеры -странные))) писать свой видеопроигрыватель? Вы ваще всерьёз? А чо не начать уж с написания своей jvm? Ну или там браузер свой накропать? Ну а чо уж юзать хром? Лучше ж свой написать, сделанный для твоего сайта.
Писать документацию? Я за 8 лет ни разу документацию не писал. Что ваще за пример? И ни разу не видел нормальной))
Просто по примерам видно, что автор жутчайший зануда и к проду его подпускать не стоит. Тем более человек он видать неленивый и велоспидов накропает много и быстро.
Что касается моего мнение 95 процентов фич идут в утиль, и 95процентов проектов туда же. Рассказать Вам как дейтвительно умный программист поступит с кодом?
Вы таки удивитесь, но ситуации бывают разные. Мне однажды пришлось разрабатывать свой видеопроигрыватель, ибо ни в одном из существующих не было возможностей, критически важных для заказчика.
И документацию я писал не мало, хотя, конечно, за последние 10 лет существенно меньше, чем за предыдущие 10. Пишу тогда, когда она необходима, и получаю за неё благодарность... Но вы же, наверняка, видели всю на свете документацию и точно знаете что нормальной не бывает?
Лично моё мнение, судя по вашим печальным цифрам успеха - только 5% полезного труда, либо вы где-то не там, либо как-то не так работаете... Может не стоит масштабировать свой опыт на всю индустрию?
Расскажу одну историю. Проект реализован на .Net Framework. Тимлид задумал переводить всё на Core. Просит разрешение у заказчика, говорит нужно 2 недели, но сам понимает, что уйдёт больше времени. Заказчик сказал, что подумает. Тем временем, тимлид начал миграцию проекта в январские выходные. Все выходят после выходных. Заказчику говорят, что почти всё готово.
Станет ли ленивый программист проявлять инициативу и работать в свои выходные?
Ленивый программист — хороший программист?