Как же я ненавижу списывать время

Я не понимаю откуда это пошло, почему так популяризировалось и зачем до сих пор многие это используют. Эта процедура — тупая бюрократия, которая никак не помогает сотруднику в продуктивной работе. Она же и не помогает руководству объективно оценивать работу сотрудника. Нет, поймите меня правильно, я не имею ничего против бюрократии, не было бы ее, было бы сложно жить. Тем не менее каждый адекватный специалист даже если плохо поработал (например, приболел), то все равно может найти куда и как списать время, чтобы к нему не было вопросов. Также и человек, который продуктивно поработал, тупо также спишет время. По итогу что дает эта практика? Какие рабочие метрики она может дать не для галочки, а чтобы реально что-то можно было отслеживать?

Как по мне, это просто лишний стресс и негатив для сотрудника. И к тому же часто вызывают чувство слежки или ощущение отсутствия доверия руководства к тебе – «большой брат следит за тобой» 😎

Аналогично списаниям также забавно, когда следят за количеством закрытых задач. Тут начинается цирк с декомпозицией задач, микротасок на каждый пук и тд 🤡

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

Вместо того, чтобы быстро перекрасить кнопку/добавить текст/изменить картинку (все это делается реально буквально за 30-60мин с учетом разработки и деплоя, ну пусть будет день, с учетом тестирования, согласования и тд), на это может уйти неделя, ведь сотруднику нужно не кнопку покрасить, а списать время, он получает деньги не за решенные хотелки бизнеса, а за списанные часы. Почему ушла неделя? А потому что сначала 20 раз согласовывал, потом 20 созвонов было с уточнением требований, потом были проблемы с доступами, а потом баг пофиксил, который всплыл внезапно, ну и напоследок все-таки изменил rgb(0, 255, 0) на rgb(0, 240, 0)
😲😲

И тут еще есть 2 проблемы:
🟣 Эскалация обязательств. Есть некоторые задачи, которые нереально оценить даже примерно, но тебе приходится. А потом в конце спринта, когда стараешься изо всех сил не подвести любимую команду и закрыть задачу, приходится стрессовать. Сначала из-за того, что тратишь сильно больше сил, чем закладывал, а потом из-за того, что нужно все-таки перенести задачу в следующий спринт.
🟣 Синдром Паркинсона (не путать с болезнью). Ты в итоге тратишь столько времени на задачу, сколько на нее запланировал. И нет, это не про «попадание в оценку», это про то, что даже переоцененная задача в итоге выполняется за то время, на которое ее оценили. Ну и правильно, куда спешить-то?

👍 – ты че черт, я квалифаед скам мастер, списывай часы!
🙅‍♂️ – ты че черт, мы не квалифаед скам мастера тут, закрой задачу!

А вы списываете время? Как относитесь к этой практике?

А ты аналитик или айтишник?

Сегодня пятничный и немного мотиуационный пост 💪

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

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

Но что если я тебе скажу, что пока ты не понимаешь ничего в коде (потому что не царское дело лезть в код), не можешь запустить докер, не знаешь как в браузере пользоваться девтулзами, то ты очень многое теряешь.

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

А если бы ты знал хотя бы немного докер, то смог бы, например, локально потестить доработки, которые нельзя поставить на тест (или просто сделать это быстрее, не взаимодействуя с гитом, пайплайнами и тд). Смог бы посмотреть какие на самом деле приходят данные прямо в браузере, а не выискивая сваггер, логи или что-то еще, если бы умел в девтулзы. Если бы умел читать код, то смог бы описывать логику более четко, зная дополнительные нюансы, а еще смог бы понять как работает кусок процесса, не дергая других ребят из команды. Без всего этого, конечно, можно прожить, но с этим будет жить проще и интереснее.

Это всё про повышение автономности в работе и скорости выполнения задач за счет бОльшего числа «инструментов под рукой».

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

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

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

Кстати, именно поэтому в нейминге канала используется слово «Айтишник», а не «Аналитик» 🧠

🐳 — если ты тишейпед(T-shaped) или стримишься туда
👌 — не нужОн мне твой докер и коды
💪 — мотиуация надо подняяяяять

Как вообще думаете, насколько полезно уметь пользоваться/владеть всеми этими штуками? Может, я не прав и лучше расти как I-shaped специалист?

Начни этот понедельник правильно!

В этот первый осенний понедельник немного игривое настроение, поэтому...

У автолюбителей уже давно есть куча прозвищ и разделений. Есть заднеприводные, есть переднеприводные, заднемоторные, среднемоторные, петролхэды и электроводы члены запрещенного на территории РФ радужного сообщества.

Предлагаю срочно, здесь и сейчас написать в комменты все разделения для айтишников и за одно определиться кого мы гнобим, а кто почетный господин

Я начну с базовой базы: аналитики - душнилы. Если согласен - 😁
🐳- если понравилась картинка
🌟 - ацтань, дай спокойно погрустить с окончившегося лета


PS: кто будет пользоваться GPT, тот электровод!

Самое важное качество СА

Крутые СА НЕ те, кто самый хардскильный или софтскильный, или два в одном флаконе. Это НЕ человек с «системным мышлением», как это принято писать в вакансиях сайта с красно-белым лого (ХиХи.ру 🔎, а не алкомаркет 🍻). И это даже НЕ дотошность.

Самое главное качество — любопытство, нужно быть фанатом проекта, который реализует твоя команда. Должно быть максимально интересно всё то, что вы вместе делаете. Так и только так ты сможешь с повышенным энтузиазмом и дотошностью изучать варианты реализации, возможности системы, архитектуру и прочие занимательные штуки. Ты даже будешь сам искренне переживать, когда что-то идет не по плану, а не потому что тебя тимлид в чате пушит. Ты будешь не просто приходить на дейлик и «сдавать отчет», а будешь вовлеченно вслушиваться в рассказы твоих коллег, потому что для тебя всё интересно и важно, ведь ты видишь зависимости.

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

Бывают, конечно, уникумы с мощной дисциплиной и проактивной позицией, но это обычно приводит к выгоранию😩, потому что так ты работаешь через преодалевание самого себя.

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

К этому и стоит стремиться, если есть желание максимально активно развиваться, параллельно поднимаясь по карьерной лестнице.

А как ты думаешь, любопытство, действительно, самое важное качество? — 😏
Или фигня всё это, главное, чтобы норм бабки платили, а остальное дело наживное? — 😕

Хантинг в IT

Все, наверное, слышали о хантинге айтишников, но сталкивался ли кто-то с ним вживую? (Тут можно смело в комментах написать свою историю) Я думаю, что большая часть – нет, более того я долгое время думал, что это практика, которая на рынке РФ почти не используется.

И вот недавно, я узнал такую историю от товарища. Он работал айтишником в одном крупном банке, и в один момент руководитель их стрима пришел к ним с предложением перейти в новое место. Что произошло дальше я рассказывать не могу, однако, все всё и так поняли 😁

Я амбассадор тишейпед

Ни для кого тут не секрет, что я являюсь амбассадором понятия T-shaped (даже в названии канала фигурирует "Айтишник", а не "Аналитик"). И это очередное напоминание тебе о том, что за этим будущее.

Многие по старой памяти думают, что тишейпед это просто очередное умное слово для обозначения фулстек-специалиста. И будут правы 😬 Проблема только в том, что принято считать: fullstack = backend + frontend, ну или, например, бизнес + системный аналитик. Но это фулстек мамонтов, современный фулстек это разраб + тестер + девопс + аналитик. И именно поэтому мне так нравится формулировка T-shaped вместо фулстек.

Почему же за этим будущее?

Все очень просто, это выгодно бизнесу, а то, что выгодно бизнесу – имеет бОльшую ценность на рынке.

Вот два примера за последние пару месяцев из моего опыта:

🤍Мы разрабатывали новый раздел в админке. Очень простой и с минимальной функциональностью. Вместо того, чтобы снимать с серьезной задачи фронтенд разраба, версткой занимался бэкенд разраб. Помимо экономии человеческого ресурса, сэкономили еще и время за счет того, что fe-специалист не стал погружаться в новую задачу, пытаясь разобраться что необходимо ему реализовать. Но мы пошли еще дальше, и я сам делал небольшие правки, при изменениях в БТ. Почему? Потому что могу 🫠 Опять же, вместо того, чтобы дергать разраба, просить его поменять немного верстку или текстовки, что довольно просто делается, я внес изменения самостоятельно.

🤍Попалась мне задачка с проработкой контракта с «крутыми» смежниками. Они были настолько крутые, что положили 🟡🟡 на нормальные спеки, не было ни описания ответов, ни логических ошибок, ни корректно указанных адресов (всё как обычно крч 🌟). Еще «круче» их сделало то, что половина команды у ребят с часовым поясом +🐚 от Москвы. Мне буквально оставалось после дейлика 30-60мин на коммуникации. Но стоит отдать им должное, пример запроса они все-таки оставили (видимо для бедолаг вроде меня). Можно, конечно, поплакать, но давайте думать че тут можно сделать?
🐚) Попросить смежников доработать спеку.
🐚) Эскалировать проблемы руководству.
🐚) Тоже положить болт на спеку и кайфовать.
🐚) Стать certified women avoider QA и полезть в Postman.

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

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

А теперь по классике голосование:
💩 – ты меня не переубедишь, я на дуде игрец тебе чтоль??!?
😎 – тишейпед эта крута, норм айтишники(цы) уже давно на тишейпде двигаются
🐽 – тёрли свинки друг другу спинки, мыли хвостики-крючки, отмывали пятачки…

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

Координация повествований

🚨 ОСТОРОЖНО 🚨 Сейчас ты услышишь не самое популярное мнение! Микросервисы это уже не модно. Но до сих пор многие (и я в том числе) продолжают их везде юзать.
Потому что за столько лет все уже научились это делать хорошо и не за чем что-либо менять.

Но есть одна вещь, которую не все научились делать – это нормально координировать эти самые микросервисы.
В чем суть? У нас есть большой бизнес-процесс, в рамках него и статусная модель, и транзакции, и уведомления, и какие-то проверки, и прочие интеграции. И вот этот процесс нужно как-то координировать, это не бэкенд сайта с односложной задачей: купить, найти, добавить в корзину и тд. (хотя даже тут иногда нужно что-то координировать).

Почему же нужна координация?
А все очень просто. Когда приложение состоит из множества отдельных сервисов, легко положить забить на согласованность действий и транзакций между ними. Но это не правильно, так как часто изменение состояния одного сервиса должно привести к соответствующим изменениям в другом(их). И вот умные айтишники уже давно придумали два основных подхода в координации:
🐚Хореография
🐚Оркестрация

На самом деле есть еще два подхода:
🐚Полное отсуствие координации // Анархия – мать порядка
🐚Симбиоз из хореографии и оркестрации // I am Venom

Итак, хореография – это

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

По книге Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга»

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

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

Эту публикацию мы подготовили совместно с Александром. Прочитать про оркестрацию можете здесь

Кого больше в канале?
💃 – хореографы на месте
🎹 – оркестраторы в здании

Эффект Манделы

Звучит как что-то связаное с политикой, от части это правда. Был такой президент в ЮАР, о котором думали, что он умер в тюрьме в 1980-ых, на самом деле скончался он в 2013. Отсюда и одноименное название эффекта о коллективном искажении.

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

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

Для ленивых вроде меня 🧠:
Да, комп реально всё кушает в двоичном формате, но в компьютерный мир залетела СИ (международная система измерения) и вставила палки в колеса. Таким образом, килобайт это не 2^10=1024 байта, а 10^3=1000 байт, а мегабайт не 2^20, а 10^6.
2^10 это на самом деле кибибайт, а 2^20 мебибайт. Если вдруг вам совсем нечего делать, то можете подробнее почитать здесь 🤨

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

👉 – я честно знал про кибибайт и мебибайт
🥴 – ой, да какая вообще разница, форточку откройте, пж

Я был не прав!

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

Небольшая предЫстория. Мое высшее образование проходило в МИРЭА (здесь же я и встретил свою жену, но сейчас не об этом), причем и бакалавриат на программной инженерии, и магистратура на информатике и вычислительной технике. Конечно, не самый престижный ВУЗ России, но мне всё понравилось. Объективно, для тех, кто хочет чему-то научиться – есть все условия 😏

И вот помните мем с подсчетом древних русов?

Ноль
Целковый
Полушка
Четвертушка...

Герой мема – Юрий Рыбников, как раз преподавал в МИРЭА!!!
Так что вот, неправильно я все посчитал, не так нас учили...

Как правильно считать? Давайте уже определим коллективным разумом!
🏥 – ноль, целковый, пердушка, чекушка
😎 – кибибайт, мебибайт
👌 – один, два, три

Теория разбитых окон накопленных багов

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

«С большой силой приходит большая ответственность»
© Дядя Бен 🤣

Причем тут разбитые окна? Разбитые окна это иллюстрация, которая показывает как работает теория. Если в здании есть хотя бы одно разбитое окно, с которым ничего не делают, то рано или поздно будут разбиты все остальные. Ведь если окно не чинят, значит за зданием не следят, значит можно разбить и другие окна 🧠 (осуждаю).

Но это все фигня на самом деле, а вот что реально – это придуманная мной теория накопленных багов. Работает, в целом, по тому же принципу. Команда по-тихоньку забивает сначала на один баг (ну он же почти не воспроизводимый), потом на второй (ну камооон, кто в 2к25 сидит на древнем iOS 18, все давно уже на iOS 26 перешли), дальше ты как-то просыпаешься, а приложение лежит 😓

Самое отстойное – это впечатление пользователя, который пользуется таким «продуктом».

Даже если ты продаешь доширак, твоя точка входа к продукту должна работать безупречно. Если же это какие-то ультрапремиальные дома на Барвихе возле бутика Ferrari, то я вообще молчу. Поэтому когда я захожу в приложение или сайт (неважно чем занимается компания) и шарясь по нему нахожу несколько косяков, то у меня сразу складывается впечатление, что и сам продукт сделан через жепу пятую точку 🍑🍑🍑

Но есть и теории антогонисты, когда положительные действия копятся и приводят к чему-то хорошему. Например, деньги при накоплении спустя какое-то время начинают копиться сильно быстрее за счет сложного процента. Но вот самое крутое, что нужно копить – это ЗНАНИЯ (жаль, что в них нет сложного процента💀).

Поэтому если в 2025 году ты хочешь:
— научиться выбирать стиль интеграции под задачу
— начать проектировать с нуля и описывать интеграции (REST, SOAP, gRPC и других, + брокеры сообщений)
— узнать как правильно собирать требования и моделировать в UML
— подготовиться к собеседованию, решив более 100 заданий
— запустить свой API на Python

Тогда я смело рекомендую курс от @studyit_help_bot 👍

Скидка на курс от канала — 1 000₽ на Stepik по промокоду DEFAULT_CODE до 31 октября