Давайте переформулируем вопрос в текстовом виде. Я соберу самые частые варианты из коментов и запущу опрос уже с чекбоксами.
Итак, как вы считаете, какой ЯП подойдет в качестве первого языка программирования?

Go 1.18 с поддержкой дженериков в бете!

Посмотреть детали/скачать можно тут: https://go.dev/blog/go1.18beta1

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

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 денег в секунду - иногда выгоднее отложить ВСЕ планы и забить на ВСЕ инструкции (качество кода, тестирование, даже безопасность) и херачить прямо в прод

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