Вы слышали, как отовсюду трубят о том, что вот-вот начнутся массовые сокращения? А если не массовые, то обязательно какие-то. И что зарплаты будут расти медленнее, а работу найти — сложнее? В целом нарратив зависит от компетентности ученого и обидчивости журналиста.
Что же мы, простые труженики клавиатуры, можем противопоставить этому нагнетающему инфополю?
Наш ответ — система ГУС: «Готов к увольнению и собеседованиям».
Комплексная система технико-психологической подготовки, которая включает:
Подкладывание подушки — накопить 3–6 окладов и не потратить.
Спринт по собеседованиям — пройти 5 созвонов за неделю и не сгореть.
Удержание оффера — получить оффер с +10% к текущей ЗП на фоне «мы все держимся».
Как бы выглядел оффер с релокацией образца XIX века.
Во второй половине XIX века десятки тысяч китайских рабочих были завлечены в США для строительства железных дорог, особенно Тихоокеанской трансконтинентальной магистрали. Им обещали высокие заработки и «новую жизнь», но по факту ждали ужасные условия труда, дискриминация, долговая кабала и невозможность вернуться домой. Это было де-факто рабство, замаскированное под трудовую миграцию.
А как бы выглядел такой оффер сегодня, если бы его постили в LinkedIn?
----
🚢🔥 Горячая вакансия! Релокация в США! 🔥🚢
Привет! Мы — динамично развивающаяся железнодорожная корпорация с офисами по всему Западу Америки. В связи с масштабным инфраструктурным проектом (🚄 Transcontinental Railroad) открываем набор на позицию Railway Infrastructure Engineer (Junior).
Что предлагаем:
📍 Калифорния, onsite
💼 Офер: вилка обсуждается, если не можешь есть руками
✈️ Полная релокация: парусник за наш счёт
🛏 Корпоративное жильё: земля, палатка, иногда яма
👥 Комьюнити: более 12 000 талантливых специалистов из провинций Гуандун и Фуцзянь
Что будет входить в задачи:
Прокладывание рельсов сквозь скалистые горы
Требования:
Умение работать 20 часов в сутки, не задавая вопросов
Устойчивость к взрывам, змеям, дизентерии и белым начальникам
Желание «изменить жизнь к лучшему» (не свою)
Английский не нужен, рот открывать не потребуется
Приятные бонусы:
🍚 Питание: рис, иногда тёплый
Нет налогов (и прав тоже)
✉️ Не упусти шанс! Присылай свою анкету (имя, возраст, пригодность к физическому труду) ближайшему рекрутеру в порту Гуанчжоу. Количество мест ограничено.
Почему нам стыдно верить в астрологию, а в программирование — нет?
Вот вам два примера:
Это Сергей. Он — архитектор, скорпион с асцендентом в раке и Кету в первом доме. Уверен, что ретроградный Меркурий влияет на то, когда нужно проводить встречи.
Это Николай. Он — бэкенд-разработчик, пишет коннекторы к месседж-брокеру в платёжном агрегаторе. Утверждает, что настоящий программист должен знать Таненбаума и делать всё по SOLID.
Современный, считающий себя прогрессивным человек посмеётся над Сергеем и кивнёт Николаю. Потому что держит в руках айфон — и он как-то работает, значит, эти «технологии» не вымысел. Хотя сам вряд ли объяснит, как это происходит.
Из этих двоих чаще оказывается прав именно Сергей — по крайней мере, он точно знает, когда не стоит катить на прод. А Николай… он не может объяснить, почему всё падает после его деплоя.
Но в общем и целом: Николай знает, как работает код — пока он работает. А вот почему он не работает, когда падает — уже нет. Сергей знает, как система должна работать, но не знает, как она работает на самом деле. И все мы делаем вид, что во всём разбираемся и только Меркурий — честно ретрограден.
Я внедрил скрам и не могу закончить ремонт на балконе.
Начинал всё по уму: разбил эпик на задачи, расставил приоритеты. Какие-то оценил сам, по другим — созвал консилиум. Привлек электрика: в команде не было экспертизы, хотя сын уверенно заявил, что справится. Оставим это на его совести — еще вчера он пытался вставить батарейку в игрушку вверх ногами, но делал это с таким выражением лица, что потенциал сеньора виден невооружённым глазом.
Проект, конечно, со спецификой: параллелить задачи сложно. Идею "я утепляю, а жена в это время красит обои, а потом как-нибудь сольем" мы отвергли сразу — архитектура не позволяла.
Поначалу шло бодро: за первый месяц 30% задач закрыто — утепление, 3 из 4 стен покрашены. Но как водится, наступил кризис ресурсов - внезапно вышел Kingdom Come: Deliverance II и съел все капасити ведущего разработчика. Прогресс застопорился.
Ретроспективы с женой проходят регулярно: я зажигаю команду речами о важности коммитмента, о наших ценностях и цели. Но стена всё еще не покрашена.
Дополнительные таски множатся: надо помыть окна по всей квартире, разобраться с дверцей шкафа, которая теперь открывается строго по фазе луны. Думаю, пора внедрять SAFe — горизонт проектов растёт.
P.S. Прогресса по основной задаче нет, но радует, что бизнес пока не планирует резать косты.
Вы наконец победили. Потратив большую часть карьеры на охоту за багами, вы достигли невозможного: багов нет. Вообще. Пусто. Доска с багами пуста, QA тихо плачет в углу, а CI-сервер бездельничает, ровно светясь скучно-зелёным цветом. Но вместо того чтобы попасть в рай, вы оказываетесь в лимбе. Если вы играли в игры начала нулевых, это похоже на выход за границы карты: голый ландшафт, странная геометрия и надпись от разработчика: «Ты не должен был оказаться здесь. Но раз уж оказался — молодец, конечно, только смысла в этом нет».
Что происходит дальше? Ничего хорошего. Первый сюрприз — вас никто не похвалит. Бонуса нет, промоушена тоже. Менеджер лениво листает ваш performance-review, хмурится и спрашивает: «А что ты делал весь квартал?» Ты отвечаешь: «Я избавил нас от багов». Он пожимает плечами: «Так они и раньше вроде не были критичными».
Кто-то бросится чинить метрики, и начнётся новый головняк, потому что вы уж слишком постарались. «Багов не может не быть, значит, сломана метрика», — уверены все. Предлагаете метрику «отсутствие багов» — слышите в ответ: «Недоказуемо, выборка мала!»
Вы думали, что победа откроет двери в рай, а распахнули портал в лимб, где невозможно доказать собственную полезность. Пару поколений инженеров мы упорно объясняли бизнесу, что «баги бывают, это нормально». Благодаря нам продакт-оунеры научились бравировать SLA с допуском на косяк. Мы воспели «умеренное количество дефектов» как здоровый холестерин IT-организма — и вдруг вы свели холестерин к нулю.
Парадокс: все процессы настроены на борьбу, а не на мир. Метрике нужен враг, а процессу — вызов. Без них графики плоские, алерты молчат. Добро пожаловать туда, где ваши достижения стоят ровно ничего. Вся организационная религия строилась на борьбе с багами. Уничтожив последний баг, вы «убили бога» процесса. Всё, что давало смысл (defect-метрики, ретро-ритуалы, баг-баунти), обесценивается; наступает инженерный нигилизм. Великая битва окончена, триумфаторов нет, система сломана. Баг умер — и ты его убил!
Совет: в следующий спринт оставьте пару багов — ради здоровья экосистемы.
Про Яндекс Практикум. Пришло от них письмо с предложением пройти тест на хард и софт скилы для работы в бигтеке. Пошёл проходить. Из языков выбрал С#, из технологий (множественный выбор) выбрал backend, SQL, API, git и ещё что-то.. НЕ выбрал JavaScript, он был в опциях по технологиям. В итоге, все вопросы с кодом были на JavaScript (!) и ни одного по C#, SQL, git и чему-то там ещё.
За хард получил 33%, за софт 100%. Их вывод был такой: для бигтека вы ещё не готовы, но вы уже на верном пути! Это я ещё не готов, который в бигтеке проработал лет 20 или больше)
Яндексяне, скажите мне, какой чудак пишет эти ваши интерактивные тесты? И кто их тестирует перед публикацией? А?)
Попытка залогиниться на "Хабр" практически всегда наталкивается на запрос решения капчи. Сейчас это настолько модно, что не только "Хабр", но, наверное, каждый второй сайт показывает капчу. Обычно, простую от Cloudflare. Но на "Хабре" капчи становятся всё сложнее и сложнее. Или - забавнее и забавнее. В пост нельзя добавить несколько изображений, поэтому вот один, но зато свежий, пример:
Это в чём-то лучше, чем другие варианты, где в качестве образца указаны наборы клякс из теста Роршаха, которые требуется угадать и сопоставить с размытыми картинками. Но, всё же, чем же из изображённых предметов можно писать? Может, бургером? Выдавливая соус?
Да, да, имелась в виду клавиатура. Для мощной LLM это, скорее всего, очевидно. Но не для роботов человеков-пользователей.
В старом саду росло гигантское древо, дававшее сладкие плоды. Садовники много лет ухаживали за ним просто как умели.
Пришел новый управляющий, полный желания помочь. Он видел, как садовники работают по наитию, и решил: "Нужен порядок!"
Сначала он ввел записи - когда поливать, сколько обрезать, как удобрять. Садовники послушно записывали, но стали меньше смотреть на само дерево.
Потом он стал собирать совещания для согласования каждого действия, для планирования каждого сезона. Садовники стали больше времени проводить на собраниях, и меньше в саду.
Наконец он решил что за состоянием дерева важно следить и придумал проверки - испытывать почву, пробовать на вкус воду для полива. Садовники старательно выполняли процедуры, но им некогда стало слушать шепот листьев и любоваться красотой молодых веточек.
Через год дерево стало чахнуть.
"Почему?" - спросил управляющий у старого садовника.
"Ты дал нам много мудрых правил," - ответил тот, "но мы забыли главное правило: любить дерево."
Как изменилось российское IT-сообщество за последние три года?
Продолжаем заниматься социокультурными исследованиями российского сообщества IT-специалистов. Сегодня поднимаем достаточно "острую" и для кого-то болезненную тему.
Сениор - это когда он 15 минут на стендапе рассказывает, как неминуемое стечение обстоятельств не позволило ему завершить задачу, но вопреки всему он сохранил способность рационально мыслить и не потерялся в лабиринте сложностей. Лишь его безграничный профессионализм позволил углядеть скрытые проблемы. Он начал их решать до того, как они явили себя и стали бы помехой любому менее профессиональному специалисту. И вот теперь он, уставший, но не сломленный, озарил наши серые будни своим присутствием и осветил нам путь своей мудростью.
Прогресса по задаче нет, но иного исхода было бы глупо ожидать в такой ситуации. Иные бы просто умерли там, где он не просто выжил, но и смог донести до нас информацию.
Пока мы, простые смертные, перекладываем json, он парит на шаг впереди всех и решает все будущие проблемы. Никто не будет выяснять, насколько они вероятны, ибо ущерб от них настолько велик, что все молча внимают. И способность выслушать его - это лишь малая дань его величию. А усомниться - значит расписаться в собственной некомпетентности и неспособности узреть очевидное совершенство.
Если ты допустил ошибку, он будет 10 минут красочно расписывать, на сколько поколений вперед проклянет нас бизнес. Если ошибку допустил он, то простите, это не ошибка, это или неминуемое стечение обстоятельств, которое было невозможно предусмотреть никому из живых. Или это не ошибка, а открывшаяся возможность для роста.
И самое обидное - у него совершенно не хватает времени на задачи, потому что 90% времени он самоотверженно тушит пожары, разгоревшиеся от искры говнокода других.
Если сотрудник работает сверхурочно, потому что хочет продемонстрировать лояльность и ценность, логичнее сделать так, чтобы единственный результат переработки — это деньги, а не карьерные бонусы. Тогда переработки станут осознанным выбором, а не скрытым способом выслужиться.
"О, великие принципы SOLID, благословите мой код на чистоту и ясность. Пусть функции мои будут едины в своей ответственности, как воины в строю, и не возьмут на себя бремя чужих забот. Пусть классы мои будут открыты для расширения, но закрыты для изменения, как крепость, стойкая против врага. Да не нарушит новый код работу старого! Пусть заменяются мои подтипы без нарушения порядка, как звенья одной цепи. Пусть интерфейсы будут разделены, как ветви дерева, и зависимости инверсированы, как отражение в зеркале. Пусть будет так, как завещал Мартин, и код мой будет чист, как ряса, как помыслы мои."
Все знают про канареечные релизы (canary deployment). Это когда новую версию сначала выкатывают на небольшую группу пользователей, чтобы проверить, не задохнется ли канарейка. Но что делать, когда нужно релизить много и регулярно? Тут нам на помощь приходят петушиные релизы!
Что такое петушиные релизы?
Петушиные релизы - это когда все обновления выкатываются рано утром, пока пользователи еще спят. Как петух, который встает с первыми лучами солнца, команда разработки поднимается засветло, чтобы подготовить свежую версию продукта к началу рабочего дня.
Преимущества подхода:
Более высокий когнитивный ресурс у инженера с утра - "утро вечера мудренее"
Минимальное влияние на пользователей (они еще спят)
Время на "настаивание" релиза перед началом активного использования
Возможность быстро откатиться, если что-то пошло не так
Предсказуемый график релизов
Возможность обновить все сервисы системы одновременно в тихий утренний час (даже если релиз не будет бесшовным, это вряд ли кто-то заметит - все полусонные)
Когда это особенно полезно?
Когда бизнесу нужны новые фичи "еще вчера"
При работе с микросервисной архитектурой
Когда команда распределена по разным часовым поясам
Исторический контекст
Как петухи исторически помогали людям вовремя просыпаться и спасали от пожаров своим криком, так и петушиные релизы помогают командам поддерживать здоровый баланс между скоростью доставки и стабильностью системы.
И помните: лучше регулярные петушиные релизы, чем ждать, пока жареный петух клюнет!
Позвольте представить вам концепцию эллинского подхода в архитектуре.
Она черпает вдохновение из древнегреческих устных традиций и философского подхода к обмену знаниями. Как известно, Сократ выступал против письменной фиксации философских идей, полагая, что письмо не может передать всю глубину и сложность мысли так, как это делает устное общение.
Вот некоторые потенциальные преимущества такого подхода в контексте программной архитектуры:
Личное взаимодействие: Устный обмен информацией подразумевает тесное общение, что может способствовать лучшему пониманию и командной работе.
Гибкость: Отсутствие строгой документации может сделать процесс более адаптивным и гибким.
Быстрое принятие решений: Устное общение обычно быстрее письменного, что может ускорить процесс принятия решений.
Фокус на главном: Отсутствие необходимости в документации может позволить команде сосредоточиться непосредственно на разработке.
Представьте, какими чудесными были бы наши рабочие встречи! Никаких утомительных записей - только живой диалог в лучших традициях античной Греции.
Однажды Диоген увидел, как разработчик читает требования и плачет, а слёзы смывают грязь с его лица. Диоген перестал ходить к реке умываться, сказав: «Мальчик превзошёл меня в простоте жизни».
В мире разработки программного обеспечения, как и в философии, существуют различные школы мысли, подходы и мировоззрения. Каждый архитектор и разработчик — осознанно или нет — следует определённым принципам, которые, для нужд этой статьи, удивительным образом перекликаются с древними философскими учениями. Давайте рассмотрим эти параллели.
Я нагуглил некоторое количество философских школ и спешу предложить вам такую аналогию:
Киники — просто и минималистично.
Платоники — невыносимо сложно и идеалистично.
Стоики — надёжно, но рано или поздно всё упадёт.
Софисты — красиво, но непрактично.
Прагматики — работает, и ладно.
Схоласты — бесконечные обсуждения архитектуры, но ни одной строчки кода.
Теперь давайте остановимся подробнее на каждой школе мысли.
Киники
«Зачем нам фреймворк? Есть же bash!»
Документация? «Читайте код».
CI/CD? git push --force решает все проблемы.
Docker? systemd нам в помощь.
Намеренно пишут неортодоксальный код, чтобы «встряхнуть» команду.
Проводят демонстрации багов прямо на проде.
Платоники
Реальный код — это лишь несовершенная тень идеального дизайна.
Каждый баг — это лишь тень несовершенства реального кода.
Нам нужен ещё один слой абстракции между абстракциями.
Простое решение не может быть правильным по определению.
В идеальном мире каждый метод — это интерфейс.
Настоящая архитектура существует только в UML-диаграммах.
Стоики
Падение прода неизбежно, а каждая ошибка может стать последней.
Стремление важнее результата — «Ничего не получилось, но мы сильно старались».
Никто не ощущает баги — о них только думают.
Не облекай свой код в пышные абстракции.
Люди пишут код с багами невольно.
Являюсь ли я частью проблемы или её решения?
Если вы слышите, как кто-то читает молитву о безмятежности, то перед вами стоик: «Боже, дай мне душевный покой принять тот код, который я не могу изменить, мужество изменить тот, что могу, и мудрость отличить одно от другого».
Софисты
Красота кода важнее его практичности.
На код-ревью больше обсуждают стиль, чем функциональность.
«Да, это медленнее работает, зато посмотрите, какая архитектура!»
Могут убедить заказчика, что баг — это фича.
На код-ревью побеждает не самый правый, а самый красноречивый.
Прагматики
«Работает? Не трогай. Не работает? Почини как можешь».
Документация? «Код сам себя документирует».
Архитектура — это то, что получилось в итоге.
Технический долг? «Будущие проблемы решим в будущем».
«Лучшее — враг хорошего, а рефакторинг — враг работающего».
Схоласты
Команда может месяцами обсуждать «идеальную архитектуру».
Создаются сложные диаграммы и документация.
Проводятся бесконечные митинги по дизайну.
Каждое решение требует согласования на архитектурном комитете.
Но реальный код так и не пишется.
Заключение
Возможно, главный урок, который мы можем извлечь из этой аналогии — это то, как много вокруг людей с неправильными подходами и мировоззрениями. Но не унывайте и помните мудрые слова Марка Аврелия:
Сегодня мне придётся столкнуться с людьми навязчивыми, неблагодарными, заносчивыми, коварными, завистливыми, неуживчивыми. Эти свойства проистекают от незнания ими добра и зла. Я же, познавший прекрасную природу добра и постыдную — зла, понимаю и природу тех, кто заблуждается.
Здравствуйте, дорогие хабрачане! Недавно закрылся Хабр Фриланс, возможно единственной фриланс-площадкой с адекватным комьюнити. Итак я предлагаю вместо неё другое решение больше подходящие тематике сайта (т.к. в основном здесь сидят программисты-энтузиасты описывающие свои ощущения) и возможно, представляющая другой подход к экономике как например эта
В современном мире, где информационный шум и высокая конкуренция становятся неотъемлемой частью нашей жизни, найти единомышленников и ресурсы для реализации своих идей становится настоящим вызовом. Каждый день мы сталкиваемся с потоком информации, который затрудняет поиск тех, кто разделяет наши ценности и стремления. Гении, творцы и новаторы часто остаются непризнанными, их идеи теряются в океане шума, а талант — не находит должного признания.
Представляю вам уникальную площадку startdelu.ru, созданную моим знакомым специально для энтузиастов у кого есть много свободного времени, но не знает как эффективно его потратить не только для себя, но и для пользы всего сообщества, кто ищет поддержку и вдохновение. Здесь вы сможете не только найти единомышленников, но и привлечь необходимые ресурсы для реализации своих проектов, указав что у вас уже имеется, а что ещё нужно привлечь.
Делается это просто. Регистрируемся на сайте. Выбираем тип идеи (коммерческая или некоммерческая/волонтёрская). Описываем свою идею и указываем свои свои "способности и потребности". Дизайн сайта настолько прост, что с ним справится может даже ребёнок! Ещё одной отличительной особенностью сайта есть наличие личных сообщений с автором поста, что делает его своего рода социальной сетью.
Пока у сайта небольшое комьюнити состоящая только из знакомых его автора, да и он ещё сырой и нуждается в доработке, например, отображение статуса текущего проекта и т.п. Но я думаю что он не умрёт и ещё заслужит нашего внимания, пока существуем мы!
