Почему так происходит?

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

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

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

Слушать надо свои ощущения, если что-то радует, то значит и ваше.

Чем больше разных мнений слушаешь, тем сильнее размывается свое собственное, растет неуверенность, энтропия.

Как я проходил первый "стеклянный потолок"

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

- Менеджеры продвигают себя, а не тебя. Если хочешь расти по ЗП и должности, то общайся с людьми которые принимают решения;

- Специализируйся на проблемах, на которых никто другой не специализируется

Первый мой стеклянный потолок случился в ЦБ, я дорос до руководителя группы, хорошо справлялся со своими обязанностями, регулярно получал премии и персональные надбавки. Но было две проблемы: доход не рос, расти дальше по карьере я не мог.

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

Любые мои достижения ухудшали ситуацию тем, что высшее руководство видело это так: "Я - хороший (очень хороший) исполнитель, а мой начальник - отличный руководитель". Значит меня нужно премировать, а руководителя двигать дальше.

Отрицать реальность глупо, можно сколько угодно говорить, что это несправедливо, но от этого ничего не изменится. Поэтому я решил искать новую компанию.

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

Поэтому мне было интересно найти компанию, где будет контакт непосредственно с высшим руководством.

Было два условно плохих варианта:

- московские интеграторы (Фактор, ИБС и т.д.)
- крупные вендоры (Microsoft, HP, IBM).

С менеджерами и тех, и других я общался по работе. Но опять проблема - менеджер не будет тебя двигать.

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

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

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

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

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

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

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

SOER | PRO | Boosty

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

Сегодня разыграл три подписки PRO на год

Победители:
- Vadim S.
- Ivane
- Igor P.

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

Всем скинул JSON токены в личку.

Ребята, сегодня стрим отменяется. Возникли срочные дела. Приношу свои извинения

Ребята, огромное спасибо за бусты, мы набрал уже 5ый уровень.

Сегодня я хотел бы собрать ваши мнения по поводу такого вопроса: "какие хардскилы вам важны в вашей работе".

Это будет тема одного из следующих стримов. Ваши ответы помогу многим разобраться и не тратить время на ненужные знания.

От себя скажу, что мне помогают:

- проектирование и аналитика

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

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

- выделение интерфейсов и абстракций

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

Сужение (уменьшение) количества методов публичного интерфейса - это одна из вещей которая доставляет страшную боль на рефакторинге

- теория программирования

Это очень обширная вещь, сюда входят принципы (solid, grasp и т.д.), шаблоны, правила, "запахи", чистота кода и т.д.

Общая идея опять же в том, чтобы изначально уменьшить объем работы. У Макконела есть информация о том как стоимость устранения дефекта растёт при позднем его выявлении.

- парадигмы (ООП)

Помогает при декомпозиции задачи.

- язык программирования

Как правило сильно глубокого знания ЯП мне не требуется, часто даже прошу ограничить специфичные конструкции языка другими разрабами, они могутт сильно усложнить сопровождение кода.

Если нужно устранить что-то очень сложное, то проще найти специалиста который сделает специфчный анализ, чем сильно копать ЯП.

- структуры данных, алгоритмы

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

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

Обожаю смотреть ролики Миши Фленова, недавно вышло интервью с Сергеем Беловым про безопасность. Я не безопасник, но работа "в защите" мне импонирует больше чем "в нападении". Приятно послушать грамотных инженеров. Спасибо, Михаилу за гостя!

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

Развитие технологий и общества привели к возникновеню понятий "Веб 2.0" и "Веб 3.0" - идея в том, чтобы выделить новые подходы в построении программного обеспечения и выразить новые задачи, которые стоят перед обществом.

Ровно таким же образом можно разделить архитектурные подходы на три волны:

Архитектура 1.0:
- рассмотрение модульности/монолитности;
- масштабирование за счет вертикального роста;
- исследование и декомпозиция программных систем;
- балансировка нагрузки;
- инфраструктура как ПО;
- расширение за счет дублирования;
- ACID.

Архитектура 2.0:
- горизонтальная масштабируемость;
- процессный или сервисный подходы;
- микромодульность;
- инфраструктура как код (облака);
- расширение за счет распределенных транзакций;
- BASE.

Архитектура 3.0:
- децентрализация;
- семантический веб;
- блокчейн (web3);
- токенизация.

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

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

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

#мысли #архитектура

Спасибо всем кто проголосовал.

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

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

В своей практике принцип KISS использую всегда только как аргумент в споре с коллегами, при подготовке первого драфта никогда не применял его в проектировании.

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

Я не представляю как можно сразу проектировать придерживаясь KISS.

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

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

#мысли

Есть ещё один метод применения KISS: - сокрытие под этой известной аббревиатурой использования костылей.

Впрочем, иногда вполне себе рабочих костылей ;) это может работать на уровне проекта, в местах, где аналитик чрезмерно отдохнул.

возвращаю пример :)
-=—=—
Свой опыт.

Как-то возникла идея в корпоративный таск-менеджер (собственной разработки) добавить чат к каждой задаче. Главный идеолог послал всех под лозунгом "тут надо подумать, а задача не приоритетная", параллельно подкинув идею ВЕСЬ чат одним текстовым бандлом прикреплять к сущности "задача", что, собственно, было реализовано за пару человеко-часов работы. В процессе эксплуатации выяснилось, что
- по каждой задаче средняя длина чата 2-5 кратких сообщений, редко 10-20
именно поэтому каких-либо проблем или неудобств пользователей попросту не возникало

Чаты оказались очень востребованы, особенно когда туда добавили перекрёстные ссылки на задач, когда запись в чате объявили легитимной, т.е. простой эл.подписью, и т.д. и т.п.

работает этот костыль KISS-решение уже лет десять, всех всё устраивает и, как уже упомянул, даже развивается в сторону расширения

что было не очевидно
1. "чатики" оказались востребованными и начали решать в том числе совсем иные пользовательские задачи, о которых на этапе анализа даже не догадались
2. "чатики" оказались именно чатиками - не "разрастались" до привычных размеров чатов, отчасти по той причине, что если задача оказывалась сложной, пользователи сами декомпозировали её на несколько и у каждой появлялся свой чатик

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