Главный элемент в работе разработчика — это прогресс. Нужно обязательно выдавать хоть какой-то результат работы, который бы ощутимо приближал к поставленной цели. Если человек не может раз, скажем, в месяц или два выдавать результат, то его работу очень сложно оценить и поэтому доверие к нему со стороны менеджмента будет падать. Нельзя жить в коконе, а телепатия не работает — менеджер не может, не хочет и не имеет возможности вникать в самую суть программерской работы. Разработчик обязательно должен уметь рассказывать, чем именно он занимается, как далеко продвинулся и продемонстрировать это. Менеджеры — не телепаты.

Не понимаю, почему люди так псят на КриптоПро CSP — это качественный отечественный продукт с отличной поддержкой и документацией. Это не распильно-откатный проект, он действительно работает.

http://maximilyahov.ru/blog/all/je-suis-krasavchik/

Когда человек откликается на вакансию, он ошибочно думает так: «Я должен показать, какой я крутой. Чем более крутым я себя покажу, тем больше вероятность, что меня наймут».

Это заблуждение по двум причинам.

Дальше по ссылке, очень толковый текст.

Не могу до сих пор отделаться от стойкого убеждения, что философия — это в целом bullshit. Там есть отдельные прикладные направления, но в остальном — это замкнутое на самое себя словоблудие, разбитое на враждующие между собой кластеры.

У прокрастинации есть один плюс: завершённое дело вызывает небывалый кайф, нормальным людям не понять.

У книг с большим количеством иллюстраций есть одна огромная проблема: картинки и текст, который их использует, находятся на разных страницах. Это вроде бы мелочь, но когда иллюстраций несколько сотен и они все важные, необходимость скроллить туда-сюда начинает в итоге выбешивать.

И вроде совсем базовое правило оформления книг, а всё равно на эти грабли авторы продолжают наступать.

Бигдата

Среди айтишников существует популярная идея, что «заказная» и «продуктовая» разработка фундаментально различаются, что люди, привыкшие к одной из систем, не могут работать в другой. И это очень печально, поскольку фундаментально разницы там особо нет. А неспособность людей работать в другой области проистекает от бардака, царящего в продуктовой разработке.

Да-да, дети, в заказной разработке порядка в целом больше. Человек, привыкший к чётким форумлировкам, ТЗ и системе контроля качества, не хочет работать в продуктовом хаосе. И наоборот, привыкший работать в мутных водах продуктовой разработки, не может приспособиться к «адской бюрократии» в заказной.

А вот если в продуктовой среде всё чётко: ТЗ, архитектура, контроль качества, стейкхолдеры и отчёты, то миграция происходит легко и безболезненно.

Нунчапельник

Любят программисты аналогии. А ещё они любят считать себя инженерами, а программы — результатом работы. И вот тут возникает нежданчик: Что является результатом работы «настоящего» инженера? Некий физический продукт, скажем, автомобиль или дом, или мост. Не абстрактный, а совершенно конкретный с конкретным серийным номером, адресом и географическими координатами. И с этим вроде бы все согласны и это вроде бы очевидно: сначала идёт проектирование, затем конструирование (то есть сборка, производство), контроль качества и приём в эксплуатацию.

У ненастоящих же инженеров названия некоторых из этих этапов притащены в их предметную область и они даже любят рассказывать о проектировании софта, разработке и приёме в эксплуатацию. Вот только процентный баланс в этих этапах кардинально иной.

К примеру, производство физического объекта занимает существенное время и требует существенных ресурсов; аналог же производства в программировании — это вовсе не написание кода, как многие считают! Производство программы — это компиляция и сборка! При этом результат компиляции — это ещё не финальный результат работы, а лишь артефакт для этапов тестирования и внедрения. И вот уже результат внедрения в виде конкретной работающей программы/системы на конкретном компьютере — вот это настоящий результат.

А что же такое проектирование и написание кода? А оба этих этапа мапятся на один — проектирование физического объекта. При этом исходный код — это по сути детальная документация по созданию программы, по этой документации другие системы (компилятор и система сборки) изготавливают бинарные файлы.

В итоге получаем такое. Для физических объектов на стадии проектирование—производство—тестирование—внедрение тратится примерно одинаковое время (скажем, по 25% для простоты), при этом на производство ещё и физические ресурсы уходят. А для программных объектов на этап проектирования уходит 70%, 1% на производство (=компиляция и сборка) и 20% на тестирование и 9% на внедрение.

Именно дешевизна производства (по сути просто копирование байтов) и является действующим фактором т.н. «софтварного пиратства». Производство софтварного продукта не стоит ничего, а проектирование стоит ВСЁ.

Когда кто-то сравнивает строительство дома и написание кода, плюйте ему в лицо. Строительство дома (укладывание кирпичей итп) нужно сравнивать с компиляцией. А вот написание кода надо сравнивать с работой архитектора зданий. Но поскольку строительство — это долго и затратно, архитектор зданий не беспокоится о частой тотальной переделке всего, в отличие от программиста, для которого вполне норма «снести здание программы» и построить его заново.

В этом и есть ключевое отличие производства физических объектов от производства софта.

Никогда больше не куплю домой роутер микротик. Инфернальное мерзейшее поделие для цискозадротов и линуксовых админов, у которых борода из витой пары уже растёт. Мучительный процесс конфигурации этого адского изделия приводит в бешенство.

Текущий роутер я даже не буду никому дарить, а просто выброшу, люди не должны с этим пересекаться.

На работе отжал себе кронштейн для монитора и это настолько офигенно, что уже хочу домой такой же. Наконец-то смог поднять монитор на удобную для меня высоту, а также сэкономил место на столе, которое занимает подставка.

Эксперимент с Adobe Reader на макоси закончился — глючная тормозная параша, некоторые баги совсем невыносимы (например, на больших файлов при скроллинге в нижнем правом углу постоянно возникает непонятный прогрессбар, который сильно раздражает и отвлекает), поэтому переключился на Foxit Reader.

Отличный цикл статей про мифы reusablity:

* https://www.ufried.com/blog/reusability_fallacy_1/
* https://www.ufried.com/blog/reusability_fallacy_2/
* https://www.ufried.com/blog/reusability_fallacy_3/

Один момент прям отдельно нужно выделить:

First of all, reusability is a deeply industrial belief. In the physical world, reusability is mostly interchangeable with standardization. Standardized parts support building the product at a lower price and can easily be reused in multiple products. On the other hand, any part that is designed with reusability in mind is a candidate for becoming a standardized part.

Ну и вдогонку к https://t.me/fieryfiles/245 продолжаю утверждать, что аналогии между физическим миром и программированием не работают, как бы красиво они ни выглядели.

Мы сейчас наблюдаем в очень интересный случай — взрывной рост популярности продукта и вытекающие из этого проблемы. Речь, конечно, про софт для видеоконференций zoom.

Вплоть до последних недель это был нишевый корпоративный продукт, достаточно популярный, но не слишком. Но всё изменилось с коронакризисом, популярность взлетела буквально взрывным образом, и на сервис пристальное внимание обратили хкаеры и медиа-падальщики (журналисты). Из-за возросшей популярности вселенная резко потребовала возврата технического долга: принятые когда-то решения внезапно очень больно взорвались, когда хакеры начали находить уязвимости и разоблачать маркетинговый булшит, который раньше никем особо не замечался, а теперь вдруг на волне интереса все стали детально всё исследовать. Медиа-падальщики, естественно, мимо такого пройти не могли, а так как новости про чужие проблемы «продаются» лучше, все стервятники бросились писать про уязвимости и баги.

А если бы не коронакризис, то zoom бы развивался потихоньку, хакеры тихо эксплуатировали уязвимости, а сми писали умеренные статьи про сервис раз в год. Компания явно оказалась не подготовлена к популярности.

У концепта knowledge base есть один трудный момент — это сложно, очень сложно. Сложно писать, сложно читать, сложно сопровождать (то есть поддерживать в актуальном виде). Полноценное использование KB подразумевает обученность пользователя, он должен уметь правильно спросить, чтобы получить нужный ответ. И вот эти когнитивно-психологические нюансы сильно сложнее технической сложности при реализации системы. И эта когнитивно-психологическая сложность концептуальная — в принципе невозможно сделать систему, которая будет читать мысли пользователя, чтобы понять, что именно ему нужно.

Как некоторую аналогию можно рассмотреть реляционные базы данных и SQL. Если вы не понимаете язык, то вы ответ никогда не получите. А если попытаетесь транслировать естественный язык в SQL, то получите неправильный ответ. Клиент должен уметь чётко и однозначно формулировать запросы.