Моя прошлая статья о поиске самозванцев среди программистов оказалась наиболее успешной по количеству положительных оценок за всю мою историю публикаций, и на втором месте по количеству просмотров (больше читали только "текстового Бэдкомедиана" на Гиктаймсе). Немало было и отрицательных оценок, дорогими читателями было предъявлена масса претензий и задано множество возмущенных вопросов; не забывали одноременно уработать карму, чтобы я не мог на них ответить в коментах под собственной статьей. А что приятно удивило, большинство действительно развернутых и качественных комментариев было в мою поддержку (или плюс-минус нейтральными) - что мотивирует к продолжению данной тематики. Например, оказалось, что мне это все не причудилось:
Но не многие поняли, что писал я, в том числе, о себе: я занимаюсь профессиональной разработкой ПО почти 20 лет (и продолжаю сам писать код в настоящее время), и большая часть пороков из той таблицы в той или иной степени была в разное время применима ко мне. Почему это оказалось неочевидным?.. Подмечено, что стоит упомянуть директорскую должность, классовая ненависть мешает вдумчиво прочитать текст, и человек сразу переходит к написанию гневного комментария "как этот чужак посмел тронуть нашу священную корову? да еще на нашем техническом Хабре?!".
И особое место заняла попытка оспорить право программиста развлекаться на рабочем месте - хотя я говорил об этом только применительно к ситуации, когда не сделана работа. Давайте теперь подумаем, откуда вообще возникает это право (кражи у работодателя оплаченного им времени), насколько это справедливо по отношению к другим профессиям, честно по отношению к работодателю, и действительно ли такое являение на пользу самому работнику.
Для начала о воровстве - хотя воров МЦ среди программистов намного меньше чем среди сисадминов, но вынос планок памяти и откаты за заправку картриджей мы рассматривать не будем. Сисадмину, кстати, не зазорно развлекаться на его дежурстве, но вы же претендуете на звание программистов, это другие обязанности и другие з/п.
А в реальности в позднем СССР имело место массовое воровство и приписки , когда люди пытались компенсировать социальное неравенство с правящим партийным классом, и для оправдания напридумывали прибауток в стиле "тащи с работы каждый гвоздь, ты здесь хозяин а не гость", "сколько у государства не воруй, все равно своего не вернешь", но нельзя забывать декларации о гегемонии рабочего класса, в соответствии с которыми должен был, например, последовательно сокращаться рабочий день (еще при Сталине - до 5 часов, но что-то пошло не так). Ну а раз лозунги об улучшении жизни не очень исполнялись, "гегемон" компенсировал это низкой дисциплиной, пьянством на работе, невыполнением норм и массовым браком - ну и конечно, оплаченными прогулами и воровством.
Когда-то давно я читал про некие исследования, которые утверждают, что из 10 человек найдется:
1 честный который не украдет, даже при минимальном риске быть пойманным,
1 порочный который попытается украсть даже при максимальном риске,
8 человек с гибкой психикой, которые поступят по ситуации - будут воровать, если этим занимаются все вокруг, и не будут, если недавно вора наказали на их глазах.
Так происходит по причине того, что помимо формализированных законов, существует так называемое "право обычая", в соответствии с которым, например, у народа вызовет возмущение застройка пустыря, через который все ходили и на котором парковали машины - хотя данный участок в законной собственности у какого-то гражданина. Убеждая друг друга в верховенстве данного "права обычая" над законом, и получая друг от друга сигналы солидарности, особо одаренные граждане, могут, например, попытаться прогнать строительную бригаду с "общественного" участка, повредить технику, совершить вандализм, поджог, нанести побои - в общем все то, что имеет мало общего с настоящими нормами закона, и за что придется отвечать.
Впрочем, может быть и по-другому: испугавшить резонанса, администрация может пойти навстречу большинству и к выборам привести формальное состояние права к фактическому, сформированному "правом обычая" - например, выкупив участок и разбив на нем парк.
Постепенно, пролетариат в СССР приобрел и закрепил "право" пить на работе и гнать брак - а современные программисты приобрели и закрепили "право" развлекаться в оплаченное время.
Поэтому, давайте рассмотрим ряд ситуаций, когда "право" тратить рабочее время на свои нужды может устоятся на современном капиталистическом предприятии, в уставе которого обычно значится получение прибыли, а не благотворительность в пользу нанятых работников. Начнем с идеальной ситуации, которую я описывал прошлой статье (цитирую):
Ситуация: Сотрудник отлично выполняет свою работу, придраться не к чему | Рекомендация: Просто ничего не трогайте, но не забывайте индексировать з/п, и отмечать заслуги сотрудника на формальных мероприятиях |
Если дела обстоят так, значит, "право обычая" может быть следующим:
Работа выполнена вся, и имеет место "простой по вине работодателя", который не предоставляет новых задач, и это устраивает обе стороны.
Нет возможности денежного премирования сотрудника за хорошую работу в прошлом, поэтому оно осуществляется путем снижения будущих норм и увеличения интервалов отдыха.
Лично я считаю такое положение дел самым маленьким грехом, на грани чувствительности грехометра; единственное, что тут можно сказать - лучше дать ценному сотруднику провести это время как он хочет - за пределами офиса, поскольку его развлечения будут демотивировать других.
Вместе с тем, на протяжении трудовой деятельности приходилось сталкиваться и с другими, более негативными ситуациями:
Причина появления "права обычая": | Негативное влияние: |
Сотрудник взрастил в себе уникальные компетенции, которые не стремится никому передавать; психологическое преимущество "без меня все развалится", позволяет ему навязывать бизнесу свои условия - зачастую это одновременно и зарплата выше рынка, и отдых на рабочем месте. Нередко уникальных компетенций по факту не имеется, просто сотрудник счел, что исходный код - его собственность (безотносительно его юридического статуса по договору), или попросту запаролил и зашифровал все что можно | Помимо условной переплаты за меньшее количество выполненной работы (что субъективно, поскольку новый специалист будет низкоэффективен на время погружения в процесс), имеется огромный риск - если внезапно случится утрата данного кадра (авария, инсульт, ...), а у него зашифрован жесткий диск с исходниками - на всякий случай, чтоб не отпихнули от кормушки, бизнес на ровном месте получит существенный урон. Просто потому что руководитель не предусмотрел данный риск и не обеспечил взаимозаменяемость специалистов и должное хранение НМА |
Сверхквалифицированного сотрудника держат "про запас", на случай, когда возникнет по-настоящему сложная задача (либо ответственный "пресейл" в аутсорсинге), поэтому он пользуется привилегиями | В случае, если данный сотрудник получает оклад, имеет место неэффективное расходование средств; совершенно не факт, что он не уволится именно в момент появления сложной задачи - возможно, именно от скуки. В целом же получать з/п "за то что я такой красивый" в отрасли считается нормой - но неплохо бы поддерживать эту сверхквалификацию, иначе через пару лет может выяснится, что она уже миф. |
Сотруднику фактически вменили чужие обязанности, в обмен на которые он получил привилегии. Самый очевидный пример с программистами 1С - на половине предприятий они занимаются анализом и исправлением ошибок учета на закрытии месяца вместе с бухгалтерами. Когда аврал спадает, сотрудник предается отдыху. | Причина имеет черты предыдущих двух, и вроде бы ничего плохого в помощи коллегам нет - но когда программисту просто сядятся на шею, в ущерб его обязанностям создавать или модернизировать ПО, и при этом он получает привилегию по увеличению отдыха, это как-то странно. Встает вопрос - а профпригодны ли те, кому постоянно требуется помощь, и как возникают регулярные авралы? |
Сотрудник попросту психологически подавляет руководителя и/или имеет на него какое-либо неформальное влияние (через родственников, обладая каким-то компроматом, и т.д.), поэтому получает необоснованные привилегии | Нетребовательный и слабый руководитель - гораздо большая проблема для организации, чем неэффективный рядовой сотрудник - от него больше экономический ущерб. Следует задуматься, а подходите ли вы для данной должности, способны ли обеспечить результаты. Если ради того, чтобы не заходить в конфликт с подчиненными, результаты можно поставить под угрозу, то не очень. |
Имеют место технически обусловленные паузы, во время которых нельзя продолжить заниматься работой программиста - поэтому сотрудник отдыхает и развлекается | Вроде бы, это неизбежная вещь: программы требуется компилировать, прогонять тесты, сервисные процедуры с базами данных типа реструктуризаций или перестроек индексов. Но не все так однозначно |
В принципе, все кроме последнего пункты относятся к организационным вопросам, а вот последний (технически обусловленные паузы) стоит рассмотреть повнимательнее. И если вы вдруг узнаете какую-то свою ситуацию, знайте, что я не запрещаю вам обманывать работодателя, можете врать ему, можете врать мне, прошу лишь об одном - не врите хотя бы себе!
Итак, долгая компиляция.
Испокон веков человечество пыталось изобрести способ ускорить сборку проекта: например, добавляя в название компилятора слова - ускорители: turbo pascal, quick basic , turbo c, turbo delphi (особенно преуспела в ускорении фирма Borland). Но все равно сколь-нибудь сложный монолитный проект наращивает кодовую базу, тянет к себе кучу ресурсов, библиотек - и в конце на одну лишь его сборку может уходить по часу и более.
Особенно в плане сборки отличались проекты на C++, последний серьезный эпизод промышленной разработки на котором у меня был более 15 лет назад, но недавно мне потребовалось собрать речевой анализатор CMU Sphinx, и на этой простой операции я чуть не обломал зубы. Я всегда с пониманием относился к тяжелым проектам на нем - если собирается час, так надо. Каково же было мое удивление, когда я узнал что компиляцию 1 проекта можно ловко распараллелить, причем не только по ядрам процессора, но и по машинам локальной сети.
Компиляция Java - лично я столкнулся с этой болью, когда получил задачу разработать плагин для Jira. С помощью штатной команды проект поднимался для проверки работы кода порядка 25 минут на моей машине средней паршивости. Вроде бы именно тогда я и купил первый PCI-E SSD, потому что невозможно было заниматься этой задачей, нужно было хоть как-то ускорить сборку. За 25 минут отдыха (я как и все, занимал его развлекаловом), что ни о каком состоянии потока и сохранении контекста речи просто не шло. Еще хуже было то, что при нахождении Runtime ошибки, я не особо вдумчиво анализировал способ ее устранения - делал первое что приходило в голову, запускал компиляцию и опять проваливался в новости и развлекательные сайты на 25 мин. Поймав себя на мысли, что мне уже не особо-то и хочется делать ее и работать с этим заказчиком, я нашел способ подгружать плагин динамически (хотя параметры его поменять в этом случае было нельзя) - это ускорило сборку до 5 минут, что тоже много, но ситуацию спасло.
И в моем проекте биржевого торгового робота на Scala (которая славится своей тормознутой компиляцией), я поступил также - для бектестирования стратегии основной проект не пересобирается и не перезапускается, вместо этого стратегии вынесены в отдельный подпроект, в build.sbt по которому написано:
example in run := Def.task[Unit] {
import scalaj.http.{Http, HttpOptions}
println("COPY to server dir")
val id = UUID.randomUUID()
IO.copyFile(new File(s"""strategy/target/scala-2.13/strategy_2.13-0.1.0-SNAPSHOT.jar"""),new File(s"""loadInRuntime/$id.jar"""))
scalaj.http.Http(s"http://192.168.122.210:8080/runstrategytest?id=$id&t1=20210101000000&t2=20210101000000&name=com.robot.Strategy1").asString
}.triggeredBy(packageBin in Compile).value
команда package в sbt исполняется менее 5 секунд (при том, что основной проект разросся более 1ГБ и собирается довольно долго), после чего ClassLoader динамически загружает класс в уже прогретую jvm, а в ее хипе уже лежат вычитанные из БД рыночные данные для бэктестирования торговой стратегии - его можно запустить мгновенно. Профессиональный же программист средней руки, не озабоченный своей производительностью, счел бы время сборки всего проекта неизбежными издержками, и с чистой совестью мог бы отдыхать или перекуривать - если не прочитал бы этот текст, теперь его совесть чиста не будет.
Если у вас в сборке ВСЕГДА включены ВСЕ возможные тесты, я думаю, вы и так понимаете, что необходимость этого - лукавство. Но скипнуть их при отладке конкретной задачи - значит лишить себя пятиминутного просмотра мемо-сайтиков, именно этого так боятся многие "сеньеры" в каментах.
Многие знают, что Jenkins агенты следует располагать на серверах не лучше 386DX-33, и заряжать туда сотню-другую автотестов, каждый из которых открывает свою ssh сессию, и деплоить таким образом на тестовый стенд мануального тестирования каждую мелкую таску по отдельности (а ну как QA в них запутается).
Добавлю еще несколько кейсов по 1С:
объективно, в 2005г. конфигурация УПП на топовом железе открывала толстый клиент десяток минут, потому что все метаданные вычитывались в RAM (и, видимо, еще как-то обрабатывались), а обновлялась по полдня от нажатия кнопки до окончания операции
любое обновление в цикле большого регистра со включенными итогами могло длится часами (их следует выключать и включать после операции)
перепроведение документов для партионного учета - вообще длилось целыми днями, если пришлось править давний документ, а потом "догонять" текущий день, восстанавливая последовательность
но появился РАУЗ, который тоже создает иллюзию необходимости авралов и переработок, если не догадаться закрывать месяц на копии базы, а потом переносить результат в рабочую
В связи с этими длительными операциями, у программиста 1С намного больше шансов свалиться в деградацию, если он предпочитает образованию в технические паузы развлечения. Однажды мне довелось рассматривать резюме кандидата, с которым мы работали за 10 лет до этого. Что меня изумило, просидев 10 лет на неком заводе, за это время товарищ не получил ни одного нового сертификата, не изучил ни одной новой технологии, связанной с 1С, или иной, даже ВО и то не завершил (я уже получил второе, хотя не особо напрягался) - как будто его заморозили в капсуле на это время.
Печальна судьба специалистов, которым когда-то все равно приходится искать работу, а их стек устарел, и стоимость на рынке на уровне джуниоров. Но они сами выбирают развлечения, а не повышение квалификации типа той же Coursera или Stepik - и мозг попросту отвыкает учиться.
Кстати, удаленка существенно повышает риск именно такого выбора. Один коллега задолго до ковида попал на удаленку, и стал "фоном" смотреть Дом 2. Мало того, что есть исследования о падении производительности при любых посторонних звуках (даже звуках природы), с этим еще ладно. Но он действительно стал сопереживать героям, погружаться в их жизнь - и при случае, заводил с коллегами обсуждения Дома 2, встречая полное непонимание.
А наиболее проблемные кадры, как и во времена СССР - это, конечно, пьющие. По совпадению или нет, именно те, от кого поутру несет перегаром, хуже всех и решают производственные задачи. Такой товарищ как-то отработал в нашем отделе примерно год; как можете догадаться, за этот год как специалист спрогрессировал примерно никак.
Следующая стадия - употреблять прямо на работе, и такой случай тоже знаю, когда я преподавал программирование в учебном центре, был один преподаватель, закидывающий за воротник. Народ, кстати, ему симпатизировал, хотя он, зачастую, в таком "приподнятом" настроении приходил на чужие уроки, садился позади, и отпускал различные ценные реплики, дополняя урок. Лично я бы выставил такого из класса, чтоб не смущал студентов. Но уволили его, если не ошибаюсь, за некие реплики по пьяни в официальных группах в соцсетях, а вовсе не за пьяное преподавание.
В видео, помимо данного материала, я не удержался и рассказал еще несколько баек про программистов в деле:
