S0ER

Принципы Рэя Далио: Придерживайтесь принципа абсолютной честности и предельной прозрачности 1. Не бойтесь правды - правда может быть горькой, но её лучше знать 2. Будьте последовательны и требуйте того же от остальных a) Не говорите о человеке того, что не осмелитесь сказать ему в лицо, и не обвиняйте заочно b) Не позволяйте лояльности к людям встать на пути объективности 3. Cоздайте среду, в которой у каждого есть право самостоятельно дойти до сути и никто не имеет права умалчивать, что придерживается иного мнения a) Высказывайтесь и несите ответственность или убирайтесь. Сотрудник не просто наделен правом высказывать собственное мнение и его отстаивать — он обязан так поступать. Особенно это касается принципов. b) Будьте предельно открыты. Обсуждайте спорные вопросы до тех пор, пока не достигнете согласия или пока не поймете позицию друг друга, а потом решайте, как поступать дальше c) Не будьте простофилей, когда вас обманывают. Люди лгут чаще, чем вы думаете 4. Придерживайтесь принципа предельной прозрачности a) Используйте принцип прозрачности для укрепления справедливости. Когда каждый имеет возможность следить за обсуждением, ведущим к принятию решения — поддерживать атмосферу справедливости в команде гораздо легче b) Рассказывайте о том, чем сложнее всего делиться. Всегда велик соблазн ограничить прозрачность теми темами, которые не задевают вас эмоционально c) Сведите исключения из принципа прозрачности к минимуму. В каждом правиле есть исключения: бывают очень редкие случаи, когда предельная прозрачность противопоказана. Например информация личного или конфиденциального характера или когда ценность распространения информации крайне низкая, а волнение, которое она может вызвать значительное d) Вы должны быть уверены, что сотрудники, получающие доступ к информации, осознают свою ответственность правильно использовать e) Обеспечивайте прозрачность информации сотрудникам, которые эффективно применяют этот принцип. Ограничивайте доступ людям, которые не умеют им пользоваться 5. Осмысленная работа и значимые отношения взаимно усиливают друг друга, особенно когда строятся на основе абсолютной честности и предельной прозрачности Наиболее значимые отношения формируются тогда, когда вы можете открыто говорить с другими о важных вещах, вместе учиться и осознавать необходимость стимулировать друг друга максимально реализовывать свой потенциал #принципы #Далио

Что вы несет такое, честное слово? Кто бизнесмен? Кто программист? Уилльям Гейтс? Детский сад какой-то. Он всего лишь икона, аватар бизнеса. Его задачи - представлять интересы определенного круга лиц, которые как говорил Эллиот, один процент из одного процента. То что он написал пару утилит в юношестве, потому что у него были на бабки на компьютер, которого у большинства людей не было, не говорит о том, что он программист. У меня отец тоже в универе писал на бейсике и фортране, потому что такое хреновое образование в совке было, всех подряд инженеров учили программировать, но он сам ни разу не программист. Леннарт Поттеринг - программист, очень крутой, и он точно не похож на Билла Гейтса. И он работает в Microsoft. Марк Руссинович - крутейший разраб, один из топов нашего времени - он тоже не бизнесмен, почему то, а работает в Microsoft) Мигель де Икаса - крутейший разраб, он основал проект Gnome и Mono, свободный .net - и он тоже не бизнесмен, а работает в Microsoft) Бизнесом занимаются совсем другие люди, они не ездят на *коны и митапы, они не участвуют в хакатонах и не пишут книги. Программист - это половая ориентация, это смысл жизни, это образ мышления, это религия в конце концов. Если ты не поклоняешься компьютеру - значит ты тут проездом. Как сказал один мой товарищ, он навсегда в плену розетки. Зайти в айти на полфедора - не получится. Не помогут никакие ваши аджайлы и чистые коды с паттернами. Кодить надо любить, или заниматься чем то другим. Сколько таких пассажиров было - сотни на моей памяти) Любишь пк, математику и железо - будешь программистом. А бизнес - это про бабки. Это про другое, и Билл Гейтс про другое, и не надо ставить его рядом с Стивом Джобсом - это слишком разные люди, с разных планет.

Забавно, судя по комментариям добрая половина людей, рассуждающая о том, что можно (а то и нужно, эффективность же ж!) писать без Clean Code, эмммм, понятия не имеют, что такое Clean Code, сводя всё к SOLID. Уохххх:) Книжки читать оно, конечно, прошлый век, видосики и корявые статьи-выжимки наше всё, но... Но Clean Code это SOLID процентов на, может, 5. В книге Clean Code даже нет ни главы, ни подзаголовка, ни вообще аббревиатуры SOLID. Да, там упоминаются некоторые из этих принципов — но даже не все. Цитата со стр. 38:

«В этой книге периодически встречаются ссылки на различные принципы проектирования . В частности, упоминается принцип единой ответственности (SRP), принцип открытости/закрытости (OCP) и принцип обращения зависимостей (DIP) . Все эти принципы подробно описаны в PPP.»

Упоминаются эти принципы. Из пяти SOLID-принципов упоминаются причём только три. Можно ли, исходя из этого, приравнивать Clean Code к SOLID? Алё:) А о чём же Clean Code? А он о том: — почему не надо писать код «на отвали» — почему качественный код это не равно «код работает» — о том, как качественно называть переменные, классы и методы — о том, как декомпозировать задачи, — как качественно писать функции, — как использовать исключения, — как писать комментарии, — как форматировать код и почему это важно, — как использовать абстракции данных для упрощения кода и увеличения его гибкости, — о связности кода, — об ООП и принципах проектирования классов, — об инкапсуляции, — о проведении границ в коде, — о тестах — ... и многом другом. Так в целом да, Clean code для лохов, профессионалы ориентированы чисто на высокоэффективный код.

def pv(v, p):
    print("start this shit")
    z = 127  # не удалять!
    if p == 'f' or True:
        try:
            return v >= 56.5  
        except Exception as e:
            print("something пошло не так")
            return pv(v-1, p+"")
    elif p == 'm':
        return v >= 61.5
    print("finish this shit")

Ура!

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

Среда 15:00 техток о пользе нетворкинга.💡 Расскажу как благодаря нетворкингу я смог добиться следующих целей: - развить ютуб и телеграм канал - получить работу архитектором - получить первую работу - как благодаря соер.клубу я регулярно знакомлюсь с крутыми чуваками Приходите и расскажите вашу историю. SOER | PRO | Boosty

В своей практике принцип KISS использую всегда только как аргумент в споре с коллегами, никогда не применял его в проектировании. Обычно я делаю решение отталкиваясь от функциональности, иду от общего к частному, получаю какое-то решение, с необходимым уровнем детализации, а потом ищу пути оптимизации (если есть необходимость). Я не представляю как можно сразу проектировать придерживаясь KISS. Т.е. нужно делать несколько предположений, выбирать из них наиболее простое, и надеяться, что комбинация таких решений даст оптимальный результат, соответствующий требованиям. Мне кажется, что такое упрощение промежуточных решений скорее приведет к несостоятельному конечному результату. Это как жигуль и какая-нибудь аналогичная иномарка, по устройству жигуль будет сильно проще, но абсолютно несостоятелен с позиции качества решения. #мысли

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

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

Три поколения развития архитектуры Развитие технологий и общества привели к возникновеню понятий "Веб 2.0" и "Веб 3.0" - идея в том, чтобы выделить новые подходы в построении программного обеспечения и выразить новые задачи, которые стоят перед обществом. Ровно таким же образом можно разделить архитектурные подходы на три волны: Архитектура 1.0: - рассмотрение модульности/монолитности; - масштабирование за счет вертикального роста; - исследование и декомпозиция программных систем; - балансировка нагрузки; - инфраструктура как ПО; - расширение за счет дублирования; - ACID. Архитектура 2.0: - горизонтальная масштабируемость; - процессный или сервисный подходы; - микромодульность; - инфраструктура как код (облака); - расширение за счет распределенных транзакций; - BASE. Архитектура 3.0: - децентрализация; - семантический веб; - блокчейн (web3); - токенизация. Архитектурные решения первой волны во многом заложены в код. Например, принципы построения программного обеспечения SOLID или GRASP, принципы границ на уровне кода (чистая архитектура и тому подобное), создание пакетов и модулей и т.д. Так как сейчас серьезно взялись за генерацию кода методами ИИ, то архитектура 1.0 уже заложена в эту генерацию. Предложенное разделение весьм условно, но без этого разделения попытки разговаривать про архитектуру современного ПО превращаются в кашу (я это остро чувствую в своих архитектурных видео), потому что делать софт в облаке и делать небольшой монолит с трехслойной архитектурой - это сильно разные вещи, и объединять их вместе не получается. Предложенное разделение помогает внести ясность в обсуждение, ровно таким же образом, как разделение веба на версии. Так же интересно, что есть два термина, которые могут запутать Web3 и Web3.0 в первом случае речь про новый децентрализованный интеренет и блокчейн технологии, второй про семантический веб. #мысли #архитектура

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

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

От себя скажу, что мне помогают: - проектирование и аналитика Я начинаю работу со сбора и анализа требований, потом всегда прикидываю решение, прежде чем писать код. Обычно использую бумагу чтобы что-то зафиксировать. Это помогает в реализации сложных фич, с большим количеством неизвестных. Если надо устранить баг, то как правило этого не требуется. - выделение интерфейсов и абстракций Вроде и не хардскил в привычном понимании, но я экономлю себе кучу времени на рефакторинге, тем что сразу уменьшаю количество открытых методов. Сужение (уменьшение) количества методов публичного интерфейса - это одна из вещей которая доставляет страшную боль на рефакторинге - теория программирования Это очень обширная вещь, сюда входят принципы (solid, grasp и т.д.), шаблоны, правила, "запахи", чистота кода и т.д. Общая идея опять же в том, чтобы изначально уменьшить объем работы. У Макконела есть информация о том как стоимость устранения дефекта растёт при позднем его выявлении. - парадигмы (ООП) Помогает при декомпозиции задачи. - язык программирования Как правило сильно глубокого знания ЯП мне не требуется, часто даже прошу ограничить специфичные конструкции языка другими разрабами, они могутт сильно усложнить сопровождение кода. Если нужно устранить что-то очень сложное, то проще найти специалиста который сделает специфчный анализ, чем сильно копать ЯП. - структуры данных, алгоритмы Тут сложно оценить, но заметил, что люди которые хорошо пишут код, как правило неплохо разбираются в алгоритмах.

Ребята, огромное спасибо за бусты, мы набрал уже 5ый уровень. Сегодня я хотел бы собрать ваши мнения по поводу такого вопроса: "какие хардскилы вам важны в вашей работе". Это будет тема одного из следующих стримов. Ваши ответы помогу многим разобраться и не тратить время на ненужные знания.

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

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

Как я проходил первый "стеклянный потолок" Случай всегда играет важную роль в жизни любого человека, мне в свое время очень помогли два совета: - Менеджеры продвигают себя, а не тебя. Если хочешь расти по ЗП и должности, то общайся с людьми которые принимают решения; - Специализируйся на проблемах, на которых никто другой не специализируется Первый мой стеклянный потолок случился в ЦБ, я дорос до руководителя группы, хорошо справлялся со своими обязанностями, регулярно получал премии и персональные надбавки. Но было две проблемы: доход не рос, расти дальше по карьере я не мог. Основная проблема - я был полностью изолирован от руководителей высшего звена, мой непосредственный руководитель презентовал достижения отдела как свои собственные. И продвигал себя. Любые мои достижения ухудшали ситуацию тем, что высшее руководство видело это так: "Я - хороший (очень хороший) исполнитель, а мой начальник - отличный руководитель". Значит меня нужно премировать, а руководителя двигать дальше. Отрицать реальность глупо, можно сколько угодно говорить, что это несправедливо, но от этого ничего не изменится. Поэтому я решил искать новую компанию. Но в другой компании я был бы так же исполнителем, потеряв все бонусы текущего места. И так как зарплата уже была выше среднего по рынку, то переход мог быть интересен только с потенциалом роста. Поэтому мне было интересно найти компанию, где будет контакт непосредственно с высшим руководством. Было два условно плохих варианта: - московские интеграторы (Фактор, ИБС и т.д.) - крупные вендоров (Microsoft, HP, IBM). С менеджерами и тех, и других я общался по работе. Но опять проблема - менеджер не будет тебя двигать. Третий вариант - растущие айти-компании, которые с нами сотрудничали. Там я мог спокойно обращаться к руководителю. Несмотря на то, что там так же были менеджеры, но у этих компании плечо принятия решения гораздо короче. Поэтому я взял за правило - общаться только с руководителем компании, а не менеджером. Второй момент - я знал специфику работы ЦБ, не тратил время на менеджеров при работе с подрядчиками, поэтому по своим задачам очень быстро закрывал вопросы. Благодаря этому подрядчик быстро закрывал договор и получал свою оплату. Короче говоря, я продвинул себя как очень эффективного сотрудника. В итоге, все сложилось вместе: - общался непосредственно с человеком принимающим решения; - помогал решать специфичные проблемы, для которых не так просто найти решение - технически развивался и был компетентен в техническом плане. Так как у компании с руководителем которой я работал, было много заказов кроме нашего управления, и ему было выгодно меня переманить к себе, то я получил предложение перейти к ним. Так как хантили точечно, то предложили очень хорошие условия: - высокая ЗП (в разы выше моей текущей) - должность зам. директора У меня со всеми коллегами сохранились отличные отношения, кроме непосредственного начальника, так как мой уход влиял непосредственно на его показатели. На новой должности я в том числе работал со своим старым руководителем, были моменты когда он пытался саботировать проекты которые я вел. Но это быстро прекратилось, так как я просто переключил его на работу через менеджеров и напрямую не общался. SOER | PRO | Boosty

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