Моя прошлая статья о поиске самозванцев среди программистов оказалась наиболее успешной по количеству положительных оценок за всю мою историю публикаций, и на втором месте по количеству просмотров (больше читали только "текстового Бэдкомедиана" на Гиктаймсе). Немало было и отрицательных оценок, дорогими читателями было предъявлена масса претензий и задано множество возмущенных вопросов; не забывали одноременно уработать карму, чтобы я не мог на них ответить в коментах под собственной статьей. А что приятно удивило, большинство действительно развернутых и качественных комментариев было в мою поддержку (или плюс-минус нейтральными) - что мотивирует к продолжению данной тематики. Например, оказалось, что мне это все не причудилось:
Иными словами, половина собеседующихся пытаются обмануть работодателя уже при первой встрече
Но не многие поняли, что писал я, в том числе, о себе: я занимаюсь профессиональной разработкой ПО почти 20 лет (и продолжаю сам писать код в настоящее время), и большая часть пороков из той таблицы в той или иной степени была в разное время применима ко мне. Почему это оказалось неочевидным?.. Подмечено, что стоит упомянуть директорскую должность, классовая ненависть мешает вдумчиво прочитать текст, и человек сразу переходит к написанию гневного комментария "как этот чужак посмел тронуть нашу священную корову?.
И особое место заняла попытка оспорить право программиста развлекаться на рабочем месте - хотя я говорил об этом только применительно к ситуации, когда не сделана работа. Давайте теперь подумаем, откуда вообще возникает это право (кражи у работодателя оплаченного им времени), насколько это справедливо по отношению к другим профессиям, честно по отношению к работодателю, и действительно ли такое являение на пользу самому работнику.
Для начала о воровстве - хотя воров МЦ среди программистов намного меньше чем среди сисадминов, но вынос планок памяти и откаты за заправку картриджей мы рассматривать не будем. Сисадмину, кстати, не зазорно развлекаться на его дежурстве, но вы же претендуете на звание программистов, это другие обязанности и другие з/п.
Как нужно жить и трудиться, но это в теории
А в реальности в позднем СССР имело место массовое воровство и приписки , когда люди пытались компенсировать социальное неравенство с правящим партийным классом, и для оправдания напридумывали прибауток в стиле "тащи с работы каждый гвоздь, ты здесь хозяин а не гость", "сколько у государства не воруй, все равно своего не вернешь", но нельзя забывать декларации о гегемонии рабочего класса, в соответствии с которыми должен был, например, последовательно сокращаться рабочий день (еще при Сталине - до 5 часов, но что-то пошло не так). Ну а раз лозунги об улучшении жизни не очень исполнялись, "гегемон" компенсировал это низкой дисциплиной, пьянством на работе, невыполнением норм и массовым браком - ну и конечно, оплаченными прогулами и воровством.
Когда-то давно я читал про некие исследования, которые утверждают, что из 10 человек найдется:
Впрочем, может быть и по-другому: испугавшить резонанса, администрация может пойти навстречу большинству и к выборам привести формальное состояние права к фактическому, сформированному "правом обычая" - например, выкупив участок и разбив на нем парк.
Постепенно, пролетариат в СССР приобрел и закрепил "право" пить на работе и гнать брак - а современные программисты приобрели и закрепили "право" развлекаться в оплаченное время.
Поэтому, давайте рассмотрим ряд ситуаций, когда "право" тратить рабочее время на свои нужды может устоятся на современном капиталистическом предприятии, в уставе которого обычно значится получение прибыли, а не благотворительность в пользу нанятых работников. Начнем с идеальной ситуации, которую я описывал прошлой статье (цитирую):
Если дела обстоят так, значит, "право обычая" может быть следующим:
Вместе с тем, на протяжении трудовой деятельности приходилось сталкиваться и с другими, более негативными ситуациями:
В принципе, все кроме последнего пункты относятся к организационным вопросам, а вот последний (технически обусловленные паузы) стоит рассмотреть повнимательнее. И если вы вдруг узнаете какую-то свою ситуацию, знайте, что я не запрещаю вам обманывать работодателя, можете врать ему, можете врать мне, прошу лишь об одном - не врите хотя бы себе!
Итак, долгая компиляция.
Испокон веков человечество пыталось изобрести способ ускорить сборку проекта: например, добавляя в название компилятора слова - ускорители: 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/runstra...00&t2=20210101000000&name=com.robot.Strategy1").asString
}.triggeredBy(packageBin in Compile).value
команда package в sbt исполняется менее 5 секунд (при том, что основной проект разросся более 1ГБ и собирается довольно долго), после чего ClassLoader динамически загружает класс в уже прогретую jvm, а в ее хипе уже лежат вычитанные из БД рыночные данные для бэктестирования торговой стратегии - его можно запустить мгновенно. Профессиональный же программист средней руки, не озабоченный своей производительностью, счел бы время сборки всего проекта неизбежными издержками, и с чистой совестью мог бы отдыхать или перекуривать - если не прочитал бы этот текст, теперь его совесть чиста не будет.
Если у вас в сборке ВСЕГДА включены ВСЕ возможные тесты, я думаю, вы и так понимаете, что необходимость этого - лукавство. Но скипнуть их при отладке конкретной задачи - значит лишить себя пятиминутного просмотра мемо-сайтиков, именно этого так боятся многие "сеньеры" в каментах.
Многие знают, что Jenkins агенты следует располагать на серверах не лучше 386DX-33, и заряжать туда сотню-другую автотестов, каждый из которых открывает свою ssh сессию, и деплоить таким образом на тестовый стенд мануального тестирования каждую мелкую таску по отдельности (а ну как QA в них запутается).
Добавлю еще несколько кейсов по 1С:
С пользой проводим время, 10 лет как 1 минута
Печальна судьба специалистов, которым когда-то все равно приходится искать работу, а их стек устарел, и стоимость на рынке на уровне джуниоров. Но они сами выбирают развлечения, а не повышение квалификации типа той же Coursera или Stepik - и мозг попросту отвыкает учиться.
Кстати, удаленка существенно повышает риск именно такого выбора. Один коллега задолго до ковида попал на удаленку, и стал "фоном" смотреть Дом 2. Мало того, что есть исследования о падении производительности при любых посторонних звуках (даже звуках природы), с этим еще ладно. Но он действительно стал сопереживать героям, погружаться в их жизнь - и при случае, заводил с коллегами обсуждения Дома 2, встречая полное непонимание.
А наиболее проблемные кадры, как и во времена СССР - это, конечно, пьющие. По совпадению или нет, именно те, от кого поутру несет перегаром, хуже всех и решают производственные задачи. Такой товарищ как-то отработал в нашем отделе примерно год; как можете догадаться, за этот год как специалист спрогрессировал примерно никак.
Лекция по программированию начнется через 10 минут, "энергетик" как раз подействует
Следующая стадия - употреблять прямо на работе, и такой случай тоже знаю, когда я преподавал программирование в учебном центре, был один преподаватель, закидывающий за воротник. Народ, кстати, ему симпатизировал, хотя он, зачастую, в таком "приподнятом" настроении приходил на чужие уроки, садился позади, и отпускал различные ценные реплики, дополняя урок. Лично я бы выставил такого из класса, чтоб не смущал студентов. Но уволили его, если не ошибаюсь, за некие реплики по пьяни в официальных группах в соцсетях, а вовсе не за пьяное преподавание.
Иными словами, половина собеседующихся пытаются обмануть работодателя уже при первой встрече
Но не многие поняли, что писал я, в том числе, о себе: я занимаюсь профессиональной разработкой ПО почти 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/runstra...00&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 (и, видимо, еще как-то обрабатывались), а обновлялась по полдня от нажатия кнопки до окончания операции
- любое обновление в цикле большого регистра со включенными итогами могло длится часами (их следует выключать и включать после операции)
- перепроведение документов для партионного учета - вообще длилось целыми днями, если пришлось править давний документ, а потом "догонять" текущий день, восстанавливая последовательность
- но появился РАУЗ, который тоже создает иллюзию необходимости авралов и переработок, если не догадаться закрывать месяц на копии базы, а потом переносить результат в рабочую
Печальна судьба специалистов, которым когда-то все равно приходится искать работу, а их стек устарел, и стоимость на рынке на уровне джуниоров. Но они сами выбирают развлечения, а не повышение квалификации типа той же Coursera или Stepik - и мозг попросту отвыкает учиться.
Кстати, удаленка существенно повышает риск именно такого выбора. Один коллега задолго до ковида попал на удаленку, и стал "фоном" смотреть Дом 2. Мало того, что есть исследования о падении производительности при любых посторонних звуках (даже звуках природы), с этим еще ладно. Но он действительно стал сопереживать героям, погружаться в их жизнь - и при случае, заводил с коллегами обсуждения Дома 2, встречая полное непонимание.
А наиболее проблемные кадры, как и во времена СССР - это, конечно, пьющие. По совпадению или нет, именно те, от кого поутру несет перегаром, хуже всех и решают производственные задачи. Такой товарищ как-то отработал в нашем отделе примерно год; как можете догадаться, за этот год как специалист спрогрессировал примерно никак.
Следующая стадия - употреблять прямо на работе, и такой случай тоже знаю, когда я преподавал программирование в учебном центре, был один преподаватель, закидывающий за воротник. Народ, кстати, ему симпатизировал, хотя он, зачастую, в таком "приподнятом" настроении приходил на чужие уроки, садился позади, и отпускал различные ценные реплики, дополняя урок. Лично я бы выставил такого из класса, чтоб не смущал студентов. Но уволили его, если не ошибаюсь, за некие реплики по пьяни в официальных группах в соцсетях, а вовсе не за пьяное преподавание.
Как программисты обманывают работодателя, отдыхают на работе, и десятилетиями не повышают квалификацию
Моя прошлая статья о поиске самозванцев среди программистов оказалась наиболее успешной по количеству положительных оценок за всю мою историю публикаций, и на втором месте по количеству просмотров...
habr.com