Итак, путем пересечения опросов (белого и черного списка) получился такой рейтинг языков в качестве первого языка программирования:

1) Python (39)
2) Pascal (16)
3) Go (13)
4) Java/Kotlin (12)
5) С (9)

а и всё, больше ни одного нет. Ни js, ни Rust, ни Haskell не втиснулись.

Свежая кровь

Некоторое время назад я писал пост про добавочную стоимость старожилов https://news.1rj.ru/str/general_it_talks/135
В этот раз хочется рассмотреть ситуацию почти обратную, и обсудить ценность новых сотрудников.

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

Однако в этот добрый предпраздничный день хочется не концентрироваться на заунывном негативе, а рассмотреть и позитивные аспекты.

Новые сотрудники – это свежесть и бодрость (не всегда)
Если вам очень повезло и вы наняли того, кто будет не просто жопочасы отсиживать, а прям активно хочет что-то делать хорошее, доброе, полезное, то вот в чем я вижу профит от нового человека (видел это не раз на практике):

⁃ Взбадривает болото. Порой с низкой ротацией в коллективе или несколько вязкими процессами со временем складывается более-менее равновесная ситуация, где всем норм, и никто никаких активных действий совершать не хочет. И вот свежий человек способен сгенерировать какие-то новые идеи, взяться за их реализацию.
Я сам не из тех, кто постоянно кричит про выход из зоны комфорта. Я люблю что-то комфортное и стабильное, однако очень радуюсь, если приходит человек с разумным, осознанным энтузиазмом и приносит новые идеи. Готов всегда идти навстречу, обсуждать, пробовать.
Конечно, я не имею в виду случаи, когда приходит новый разработчик и с порога говорит: «Тут всё фигня и надо переписать на svelte». Или новый менеджер, который говорит: «Вы что, без скрама и сторипоинтов вообще жизнь – не жизнь! Жду вас завтра на ретро!»
⁃ У него нет выученной беспомощности. Про это я тоже писал пост https://news.1rj.ru/str/general_it_talks/66
Т.е. человек еще не обескровлен скрипучими процессами и инертностью коллектива. Он не живет в позиции «Ой, да тут никому ничего не надо, не стоит даже пытаться».
⁃ Приносит новый опыт, которого у вас в команде нет. Вы же берете человека откуда-то. Он там работал, чего-то видал, чего-то делал. Интеграция чужого опыта тоже может быть очень полезна. Особенно если к найму подойти осознанно и не набирать людей глупее себя, чтобы они тебя не подсидели (да, такое бывает регулярно), а целенаправленно подумать, какой экспертизы не хватает команде и попытаться нанять человека, который бы её принес.

Итог
Желаю вам в новом году хороших, бодрых, профессиональных коллег.
Всех поздравляю с наступающим праздником🥳 Успехов вам!💪

Иногда я задаюсь вопросом: почему мы продолжаем писать бизнес-приложения на PHP с бексконечными CRUD/REST. Почему бы не взять Low-code/No-code систему типа Airtable или Fibery? Вот почему (картинка):

Говорят, что Bolt перешел на четырехдневную рабочую неделю. После трехмесячного эксперимента провели опрос среди сотрудников, и выяснилось, что у абсолютного большинства людей выросла продуктивность и, понятное дело, улучшился work-life баланс. Интересно, есть ли там вакансии Go-шников? ))

https://www.businessinsider.com/ecommerce-unicorn-bolt-adopts-4-day-week-after-productivity-improved-2022-1

На Хабре появилась очередная статья о том, как php пытаются натянуть на хайлоад, используя для этого костыли swoole.

Статья потрясающая, ведь в ней перечислены все минусы этого подхода по сравнению с Go, Node и т.д., а выводы сделаны противоположные здравому смыслу.

В статье api, которое пишет в базу, нагрузка всего 300rps.

1) Приложение жрет 2 гига памяти и 8 ядер cpu. Ну хз, Go сожрало бы в несколько раз меньше. У меня микросервисы обычно потребляют в разы меньше при гораздо большей нагрузке. Хотя, конечно, зависит от конкретики приложения.

2) раздел "простота инфраструктуры", цитирую:

"...внутри контейнера будет всего 11 процессов: 1 tini (supervisor)+entrypoint, 1 master процесс, 1 manager процесс и 8 worker процессов."

Вы чо, ребят? Какая тут простота? Особенно учитывая, что они зачем-то перезапускают процессы воркеров раз в час.

Image весит всего 120 мегабайт. Ну неплохо, но если это так важно, то в Go можно оставить вообще один бинарник (FROM scratch), и образ будет весить по сути вообще около нуля.

3) чтобы добиться постоянного соединения к бд и редису, пришлось написать несколько оберток к библиотекам и драйвер к doctrine.

4) 4ms уходит на обработку запроса без логики (пустой запрос или даже 404). Сорян, но это очень много.

5) в течение месяца после выкатки они вылавливали странные ситуации. Что-то там текло при коннекте к посгресу и тд.

Итог) Вывод делают такой: php закапывать рано, все норм.

Блин. Если бы в статье был упор на удобство написания кода, то я бы это купил и пошарил бы везде. Синтаксис php во многом удобнее. Но статья про хайлоад и производительность, блин.

Отдельно хочу заметить, что описанное в статье могла намутить только команда прокачанных php-синьоров, которые готовы ловить и фиксить необычные проблемы. А на Go с задачей "highload api, которое лезет в базу" справился бы начинающий по стандартному мануалу. И у него не возникло бы ни одной серьёзной проблемы.

Ребята из Data Egret попросили разместить их вакансию. Что ж, они меня часто выручали в сложных ситуациях с Postgres, так что теперь моя очередь. Data Egret ищет DBA

https://dataegret.ru/#_vacancy2

Непонятно, нафига такое вообще сделали

https://twitter.com/Randomazer/status/1495131345328222208?t=V6rm4UhemxFgdd-ndFkioQ&s=19

Наисал статью тут на выходных
https://habr.com/ru/company/karuna/blog/663906/

написал на хабр про advisory locks
https://habr.com/ru/company/karuna/blog/674730/

Женя Жданов начал вести канал на Ютубе, и записал видос про переработки. Несмотря на то, что я в индустрии уже давно, и большую часть советов я и сам понимаю и прочувствовал на себе много раз, однако даже меня заставило задуматься. Успеть к дедлайну - это прям классика, и иногда, бывает, работаю больше 8 часов в день. Хотя казалось бы, должен уже соображать.

В общем, посмотрите, и, конечно помогите пацану лайками и подписками, канал совсем новый
https://youtu.be/cG5XDmer1zI

Если у вас gitlab, то можно создавать Merge Request автоматически при пуше в git. Для этого достаточно добавить парметр

git push -o merge_request.create

Ну и можно добавлять разные свойства MR, типа
-o merge_request.remove_source_branch
-o merge_request.target=master
и т.д.

для удобства лучше создать алиас, например git mr, чтобы сразу пушило с созданием MR и нужными опциями

$ cat ~/.gitconfig
# This is Git's per-user configuration file.
[alias]
mr = push -o merge_request.create -o merge_request.remove_source_branch --set-upstream origin HEAD

Минусы скрама

1) Считается, что команда "комитится", что сделает всё запланированное на спринт. Однако точно угадать сроки невозможно никогда, в жизни не видел еще точно угаданных сроков.
А перерабатывать по ночам, чтобы успеть в спринт, никто не будет, да и плохо это, ведет к выгоранию. Так в чем же тогда "комитмент"? Просто со временем развивается пофигизм. Ну продолбали и продолбали, дальше чо

2) Если пункт 1 верен, то тратить столько времени на скурпулезную оценку сроков каждой задачи (и потом скурпулезное выяснение почему продолбали) - просто бессмысленно.

3) Стремление уложиться в спринт может привести к срезанию углов и снижению качества там, где это не стоило делать.

4) Некоторые разработчики испытывают чувство вины от того, что не успели в спринт; иногда продакт смотрит на них, как на говно. И когда сроки продолбаны не из-за лени, а из-за неправильной оценки (а оценить все зависимости и случайности очень сложно), это приводит к выгоранию.

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

6) Цель спринта считается очень важной, но к сожалению в реальности зачастую спринт - это или куча задач, которые не объединить общей целью, или одна большая задача, которая принесет ценность только после нескольких спринтов, и тогда цель выглядит туповато: "Поработать над задачей X"

7) Оценка в сторипоинтах - это неведомая хрень. Которую никто не понимает нормально. Это не время, но всё же сторипоинты надо уместить во временные рамки (2 недели). Так время или нет? Лайфхак: сторипоинтами считать количество дней, округленных до фибоначи в большую сторону. Это уже лучше, но всё равно непонятно, нафига это всё.

Буду рад, если кто-то развеет мои сомнения.

Я в целом согласен с Женей. Хочу только сказать, что предсказуемость предсказуемостью, но на планы также надо уметь и забивать, при необходимости.

Упал прод и идет потеря 100500 денег в секунду - иногда выгоднее отложить ВСЕ планы и забить на ВСЕ инструкции (качество кода, тестирование, даже безопасность) и херачить прямо в прод

Короче, предсказуемость - прекрасно, но жизнь бывает непредсказуема, и к этому надо быть готовым

Важность предсказуемости

Сегодня хочу поговорить о такой простой вещи, как предсказуемость.

Часто нам показывают образ программиста или менеджера как человека супер творческого, непредсказуемого, проходящего через череду взлетов и падений, но в итоге поднимающего бизнес в небывалые выси.
Многие любят смотреть на Стива Джобса, или Линуса Торвальдса и представлять, что вот бы и они такими стали когда-нибудь.

Но, как говорил в «Бойцовском клубе» Тайлер Дерден, «Телевидение внушило нам, что все мы станем миллионерами, звездами кино и рок-н-ролла. Все вранье. И мы начали это осознавать» (там, правда, было еще продолжение, что это приводит нас в ярость, но это тема для другого поста 🙂)

Стивы Торвальдсы
Это действительно важные и нужные люди. Порой они одни и правда могут своим решением или привести компанию к краху, или возвысить её до небес.

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

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

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

Особенно это всё важно в условиях командной работы. А я уверен, что сейчас практически все мы с вами работаем именно в команде над проектами.

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

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

Информационное постоянство
Может быть, я такой занудный, но мне и в телеграм-каналах нравится читать такие, у которых есть понятная периодичность. Не так, что канал может месяц молчать, а потом 3 поста в день сделать, а раз в какое-то понятное время выпускает, и я читаю. Последнее время так радуюсь, что Рома Ивлиев у себя в канале стал стабильно в конце пятницы писать пост 🙂
То же касается и подкастов, и ютуб-каналов. Стабильность позволяет мне примерно рассчитывать свое время и силы на потребление нужной информации так, чтобы я знал, что и нужное я получу, и при этом в размеренном темпе, чтобы голова не закипела или бэклог не разорвался.

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

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

Но это же логично. И совершенно неважно, придется применять на практике эти знания или нет.

Всё просто:

Если ты всё порешал, прошел несколько этапов с задачками, то ты точно умный.

Если нет - то хз, может умный, может нет

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

При этом конкретные технологии знать не надо, и даже конкретный язык программирования не важен. Любой норм. Если ты разобрался со всей этой мудрёной галиматьёй с литкода, то и питон/джаву/го как-нибудь осилишь, даже с нуля.

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

Поэтому или работать в нераскрученных компаниях, или велком ту литкод.

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