Женя Жданов начал вести канал на Ютубе, и записал видос про переработки. Несмотря на то, что я в индустрии уже давно, и большую часть советов я и сам понимаю и прочувствовал на себе много раз, однако даже меня заставило задуматься. Успеть к дедлайну - это прям классика, и иногда, бывает, работаю больше 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: они все равно набирают нужное им количество "точно умных", и им норм

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

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

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

https://www.youtube.com/watch?v=e4PUGpZlcIw

— Привет!

(проходит минута)

— Не занят?

(проходит две минуты)

— Можно вопрос?

Если этот фрагмент переписки до боли знаком, перешли своему коллеге короткое видео (53сек): https://youtu.be/E1MWhW219Rg

Я тут клип снял на песню. Космические бюджеты вбухал: почти 2 часа времени!!!!!!!11111одинодинодин
Так что лайк, шер и подписка обязательны ))
(in English)

https://www.youtube.com/watch?v=raJGZaIPhOc

вот как появляются новые релизы PHP

Вот что мне выдал https://deepai.org/machine-learning-model/3d-objects-generator по запросу "php 8.2 released, elephant".

Программисты скоро будут не нужны. Осталось только научить ChatGPT задавать уточняющие вопросы, и дело в шляпе )

csvq - SQL-like query language for csv
Продолжаем тему работы с данными в терминале. CSV - удобный формат, но еще удобнее работать с ним написав SQL запрос

https://github.com/mithrandie/csvq

Философия и технологии

Ядерная реакция может дать энергию и быть во благо, но может уничтожить планету.

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

И т.д.

Даже эти вопросы до конца не дорешали, хотя им сто лет в обед.

И ведь опять происходит какая-то такая херня, причем очень быстро.

Этот год, например, прям богат на прорывы в области нейросетей.

ChatGPT поддерживает беседу, сочиняет стихи и сценарии, переводит и пишет простые программы.

Dalle2, midjourney и тд уменьшили порог входа в графический дизайн почти до нуля

Copilot помогает писать код всё лучше и лучше

Даже на войне, говорят, используются интеллектуальные помощники по оптимальному управлению войсками.

И всё это проявилось за какой-то сраный год.

Опять философия отстаёт от технологий. Человечество наступает на все грабли, и лишь после этого думает о том, что будет дальше.

Правильная последовательность дйствий: сначала "зачем", потом "как".

Сейчас: сначала сделаем, а там посмотрим, что будет.

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

Если, предположим, какие-то ИИ-подходы радикально упростят или заменят сложные профессии ( программирование, бизнес, копирайтинг и тд), то что будут делать люди? Торговать пивом? Для чего?

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

Сейчас некому взвесить "за" и "против", а скорость изобретений зашкаливает.

Философы, где вы?

Чему учить детей сейчас, и какой в этом смысл?

Является ли человек венцом эволюции или же он лишь промежуточная ступень для алгоритмов?

Где общественная дискуссия на этот счет?

Может, эти вопросы надо задавать сразу боту chatGPT? :)

Если юзаете Gitlab, чекните бекапы, некотрые репозитории при бекапе помечаются как Empty и не попадают в бекап, хотя они не пустые. Можно неприятно удивиться.
Баг еще жив в версии 14 как минимум: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28854#note_24652059

Не моё (хз откуда оригинал), но гениально ))))

Хотелоь бы подискутировать, провалидировать мысли.

Имхо ORM в целом работают плохо. В веб-приложениях, интенсивно работающих с базой, часть бизнес-логики (условия, джойны, группировки) неизбежно встроена в SQL-запросы (а не только существует в коде приложения), поэтому в случае ORM происходит автогенерация сложных SQL, которая по любому работает через жопу, неоптимально, да еще и плохо дебажится. DBAшники не менее чем в 50% своих выступлений упомянают примеры SQL, порожденных ORM-ками (там обычно зло ацкой сотоны из чорного ада).

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

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

Поэтому лично я для себя пришел к такому выводу: везде стоит писать сырые запросы, кроме тех случаев, когда надо запрос собирать из частей. Но и в этом случае использвать условный Squirrel (query builder для Go), а не условный Gorm (ORM для Go). Да, писанины немного больше, но код становится при этом более понятный и поддерживаемый.

В мире Go вообще не оч принято использовать ORM, фреймворки и т.д., пара лишних строк кода - это всего лишь хорошее медитативное занятие (c)