Биткоин пробил 53000$ и все такие "ах если бы я знал, то сейчас был миллионером".

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

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

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

Миф: соеров не любят в командах

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

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

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

Часто соеры выступают на митапах, конференция и выступают в роли менторов для коллег.

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

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

#миф #соер

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

В субботу планируется премьера на субботнем стриме. С докладом-гайдом о том как решать литкод выступит Маргарита.
Так что в 10 часов по Мск жду всех!
Многие ждали и мечта сбылась

/\ /\
= × × =
*

Эффект Манделы у Соера

Все таки я искажаю суть OpenSource термина, когда говорю, что он появился до OSI, он вообще не использовался до 97 в контексте ПО. Здесь, я признаю правоту людей, которые ссылаются на Open Source Initiative которые начали продвигать этот термин как торговую марку исходя из Open Source Definition.

При этом пост, написанный выше, не нарушает OSD, и в комментариях к посту я объяснил почему. Искажение, о котором я говорю, лежит в области "свободы" разработчиков. Я привык думать, что OpenSource более свободная чем Free Software, и у меня сформировались ложные воспоминания о том, что термин использовался до 97 года.

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

UPD. На субботнем стриме вместе прочитаем OSD.

Ставлю жирную точку в споре про OpenSource, а так же разбираю Open Source Definition - https://www.youtube.com/watch?v=kCbAdRg6iVI

И да, я давно не снимал ролики. И вот опять...

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

Напоминаю, что полный архив стримов доступен на soer.pro, на бусти делаю реплику.

Подкаст 001.
Сегодня поговорим про Rust, удаленную работу и профессиональные скилы.
#подкаст

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

Типовые проблемы в архитектуре стартапов

За последний год провел 17 консультаций организаций малого бизнеса (размер организаций 15-100 человек). Обычно просят сделать анализ архитектуры на уровне кода, чтобы повысить скорость выхода на рынок и оптимизировать затраты на сопровождение.

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

1. Проблема номер раз - технический долг. Обычно никто его не измеряет, в лучшем случае определяют "на глазок", а в худшем вообще не определяют. Предлагаю сделать простейший анализ, получаем цифры 60-70%. Для себя эмпирически установил, что при уровне техдолга 25-35% качество разработки становится заметно лучше.

2. Проблемы автоматизации и организации процессов. Например, в процессе разработки не используются фичи гита или не реализован CI/CD, нет автоматического тестирования, нет стат анализа, нет динамического анализа и т.д. Непонятно кто за что отвечает, кто что делает.
Обычно жалуются, что организовать процессы сложно и дорого. В качестве контраргумента я привожу в пример NarisApp, где процессы работают на голом энтузиазме и если бы не они, то проект давно закрылся.

3. Деньги не мотивируют. Я много раз убеждался, что в теории люди могут знать кучу всего хорошего, а на практике ничего не применять. Просто потому что "а зачем?". Я несколько раз проводил анкетирование, и оказывалось, что знания есть, а просишь показать примеры в коде, где эти знания применяются, показать не могут.
При этом если внедрить ревью кода, начать стимулировать разрабов писать код обдуманно, то увеличивается вовлечение в проект, и результат становится лучше.

4. Найм новых сотрудников не улучшает ситуацию, так как на рынке дефицит квалифицированных кадров. Эта прямо "проблема проблем". На рынке нет нужных кадров. Проще выращивать специалистов самим, чем нанимать.
Ситуация усугубляется тем, что как только человек получает опыт, он уходит на лучшие условия, как правило, в большую компанию, удаленка этому сильно способствует.
Получается, что маленькие компании, которые хотят удержать своих сотрудников, должны с одной стороны развивать их сами, с другой мотивировать остаться в компании.

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

В NarisApp закончился подготовительный этап, набрал 9 человек.

Сейчас начали этап формирования пула задач и обсуждение эпиков. Их в этом наборе будет два.

Мне кажется важно вовлекать сразу всех участников в обсуждение и максимально прорабатывать пользовательские истории до формирования ADR.

Искусственный интеллект умудрился набрать 101 балл в тесте на IQ. Я вот даже не знаю, радоваться или нас скоро всех заменят?

Субботний стрим 09.03 10:00

Начинаю сбор вопросов на стрим, напоминаю, что у нас будет четыре секции:

- Зачем это надо? (ЗЭН)
- Сплетни нашего ютуба (как мне Антон за слова предъявлял)
- Донаты решают

В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.

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

Небольшое изменение на завтра, у меня будет гость на стриме, который расскажет историю о том как он решил бросить ММА и начать заниматься АйТи.
Поэтому секции ЗЭН не будет.

Многие пренебрежительно относятся к MySQL, но не я. Мне понравилась статья от GitHUB о построении кластера под высокую нагрузку на базе MySql, как говорится важен не размер, а умение.

Взгляд на Архитектуру с позиции кода. Мне не всегда понятно почему люди уделяют такое большое внимание нюансам построения архитектуры на уровне кода, в большинстве случаев это выглядит как "неправильно ты дядя Федор бутерброд ешь". Вот, например, статья про Заблуждения Clean Architecture вроде и по делу, но на практике никак не будет влиять на код небольшого приложения, а в большом такие мелочи, как описаны в статье, нельзя учесть.

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

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

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

https://blog.bytebytego.com/p/ep68-top-architectural-styles

Сегодня в клубе Марго подняла отличную тему про индексы в базе данных, обменялись полезной информацией. Спешу поделиться ссылкой на ламповое выступление с вами - https://youtu.be/ju9F8OvnL4E?si=vEekMN8pnMvX7U7N