Comments 40
Люди с избытком интеллекта играют в конкурентные игры, придумывают и решают математические задачи и пишут книги, чтобы ответить на абстрактные вопросы о человеческом естестве — и всё это бесплатно, только для удовольствия.Излишне смелое заявление — не все перечисленные проблемы мнимые. Например, вопрос о нашем «я» безумно важен в контексте цифровой версии нашего сознания. Или более приземлённый пример — физик Дэвид Дойч обосновал концепцию квантовых вычислений, решая проблему обоснования многомировой квантовой механики.
У людей, которых выводят, отбирают и поощряют искать сложные решенияХм, так и не понял фразы.
банковская экосистема действительно достигла совершенства в собственной иерархии присвоения денег. Её лидеры — это коррумпированные пиявки, которые присосались к телу общества
Аплодирую стоя!
лучше хрупкий костыль за день
Любой заказчик скажет, что ему нужно быстрее и дешевле, а на качество кода ему плевать. Но это не значит, что любому заказчику это РЕАЛЬНО нужно. Часто они мыслят категориями: «деньги и время — это моя проблема и программист хочет заниматься какой-то фигней за мои деньги и время». Но не способны посмотреть даже на шаг вперед и понять, что в среднесрочной перспективе деньги и время они так только потеряют. То есть нужно различать две разные «мне нужно быстро и дешево»:
— Мне нужно быстро, дешево и некачественно, всё-равно я эту штуку через две недели выкину, когда пройдет эвент, под который мы ее делаем
— Мне нужно быстро, дешево, но так, чтобы было и дешево всегда, потому что наша компания собирается ею пользоваться годами
Вот для первых — реально надо делать быстро и дешево, а вторые просто хотят переложить свое нежелание платить полную сумму на ответственность разработчика, когда он через полгода будет овертаймить из-за того, что наделал факапов, которых его просили наделать полгода назад.
Более того, есть ещё такое милое занятие как "аутсорсинг", которое позволяет юристам, программистам, рекламщикам и прочим работникам не делать НИЧЕГО — главное найти, кому слить задачу, оставив себе чуть-чуть (чуть-чуть может легко достигать 70%).
Главное — солидная вывеска! И умение участвовать в тендерах правильно.
Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Возможно речь идёт ни столько об усложнении простых и скучных задач, сколько об желании инженера создать свой инструмент для решения текущей задачи, потому что имеющийся не подходит по многим его критериям правильного ПО.
Это ведь элементарно: когда инженеру не нравится архитектура библиотеки для работы с HTTP, он начинает писать библиотеку с хорошей архитектурой, при этом не забыв запихнуть туда всё, что по его мнению должно там быть, не смотря на то, что в текущем проекте это не будет использовано — библиотека ведь должна отвечать критериям правильного ПО...
Хотя да, со стороны это выглядит как усложнение простых и скучных задач...
Это не только выглядит и крякает, как усложнение, но им и является. Потому, что функции данной библиотеки, которые не используются в данном проекте, будут забагованными и крайне неудобными в использовании, так, как тяжело написать что -либо стоящее, не понимая, как это будет использоваться, и тяжело написать что-либо безбажное, не проверив работу в проде.
в проде нужен доступ по HTTP, инженер стал пилить свою либу, за одно запилил поддержку SSL/TLS…
Тот, кто потом будет работать с этой либой, понимая, что либа проверена временем, и яляется частью успешного проекта, без тени сомнения использует ее для запросов по https, и даже не осознает, что, используя настолько протестированную либу, он является первым человеком, который в принципе запустил эту ветку кода…
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))
Пример утрированный, но в реальных проектах наблюдал раз 5. Потому, что это для автора библиотека универсальная, расширяемая, и просто достойная восхищения. А для тех, кому потом ею пользоваться — кусок недокументированного хз как работавшего
Нормальный вариант, если реально не разобраться «без поллитры» в предыдущей. Главное, если не выпилить её из проекта полностью, то задеприкейтить, чтобы новый код использовал только её, чтобы ни одна строчка + в диффах следующих коммитов не была со старой (в исключительных случаях можно, типа изменился ендпоинт очень важного внешнего API, который был захардкожен прямо в вызове)
Видал я таких программистов. Они пишут ужасный, запутанный, плохой код, который невозможно поддерживать. Скорость внедрения новых фич падает, количество багов — растет, а их фиксинг создает еще больше багов.
Потому что человеку не интересно это дело. И вместо того, чтобы подумать и понять корень ошибки — он ленится и выбирает самый быстрый способ. Вместо того, чтобы подумать, как переформатировать код так, чтобы те три почти одинаковых куска слить в один — он просто копипастит его в четвертый раз и бежит пить пивко.
Да, в этот день его менеджер похвалит, но никогда не сможет понять, почему цена поддержи и развития так
видел я таких… он просто копипастит его в четвертый раз и бежит пить пивко.
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.
когда он наелся программированием, и оно перестает его интересовать как таковоеТаких программистов я видал и о таких рассказал.
А вот таких программистов, которые не любят, не горят своей работой, относятся к ней как к должному и при этом стараются писать хороших, оптимизированный, расширяемый и продуманный код — таких не видал. И именно такие мне кажутся фантазией с внутренним противоречием. Взаимоисключающие вещи. Человек или горит и делает работу хорошо или сгорел и делает её на отъ…
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.
Среди горящих программистов я видел плохих и даже очень плохих. А еще видел хороших и просто звезд, которыми я восхищаюсь.
Среди потухших программистов я видел только плохих и очень плохих. Ну, может, с натяжкой, средних
Соглашусь с тем, что с опытом программист начинает искать
самые короткие пути достижения поставленных задач.
Больше времени уделяется составлению дорожных карт
,
ну или проработке ТЗ если хотите...
Ему лень писать код, поэтому он его копипастит. Видели такое.
habr.com/post/422679/#comment_19091403
или написание функционала, который уже есть в существующих библиотеках, а возможно даже в проекте.
То есть конкретные шаблоны предназначены для решения каких-то конкретных проблем способом, дающим какие-то «побочные» плюсы не важные здесь и сейчас. Можно решить эти же проблемы кучей других способов, которые могут быть эффективней по размеру кода, потребляемым ресурсам и т. п. в данных случаях, но проще применить шаблон, поскольку его код, как говорится, из под пальцев сам выскакивает, а над специфичным кодом думать надо, пускай и код с шаблонами будет более сложным формально, да и субъективно для человека незнакомого с данным шаблоном.
Первая часть — пересказ картинки программист_и_качели.жпг.
Вторая часть с первой плохо связана. В ней про то, что для зарабатывания денег можно и не упарываться в качество продукта. И это нехорошо, хотя многие так делают.
к нескольким письмам, которые разрушают жизнь бывшего сотрудника и заканчиваются странным самоубийством.
странная отсылка, Алейников жив вроде?
Мнимые проблемы — причина плохого софта