Оказалось, что видео со встречи с Антоном Назаровым я не вывел в стрим... Сорян!

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

Ответ на вопрос:

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

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

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

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

RuTube | VK | Подкаст "S() Talks"

#вопрос #видео

Опыт против знаний

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

Лучший способ приобрести опыт – это практика.

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

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

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

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

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

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

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

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

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

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

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

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

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

Но если опыт постоянно обесценивается, то существует ли оптимальный стаж работы, который является преимуществом при устройстве в интересные проекты?

В «зачет» идет не весь опыт, который есть у кандидата, но и полное отсутствие опыта не является плюсом. Обычно наиболее важными являются последние пять лет. Так, например, разработчик с десятилетним стажем практически не выигрывает на фоне разработчика с пятью годами работы за плечами.

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

#мысли #опыт

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

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

Второй вариант - можно сделать донат от 300р. на https://donate.s0er.ru/ и в комментарии написать "ЗЭН: текст вопроса", все вопросы из донатов попадут на стрим в приоритетном порядке. Донатить можно в любое время начиная с "сейчас" и до запуска стрима.

Канал в офисе выпустил интервью со мной. Еще раз повторюсь, меня там сильно повозили по политике, и я не смог грамотно аргументировать свои мысли в полном объеме. Но сказанных слов не выкинуть, поэтому как есть так и есть.

https://www.youtube.com/watch?v=tP4v7jy4lJI

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

И мы в эфире https://youtube.com/live/j0FqpElgDQ4?feature=share

Для подписки STREAM и выше выпустил архитектурный видос по "Подсистеме логирования" смотреть последние видео теперь стало удобнее, есть специальный раздел на платформе - https://platform.soer.pro/#!/pages/overview/latest
Постарался разобраться основные моменты - что должно быть в логах, как они должны сегментироваться и т.д.

Понравился канал "девочка из айти" - https://t.iss.one/itdevgrl пока постов мало, но вайб тех постов что есть прям как бальзам на душу - уважуха.

Хочу инвайт в GigaChat... Может кто знает короткий путь?

Еще раз о том почему полезно читать код

Помните слова Торвальдса: "Talk is cheap. Show me the code"? Сегодня еще раз убедился в их справедливости - нашел интересный плагин для OBS, который извлекает из изображения человека, а фон либо размывает, либо полностью убирает - https://github.com/royshil/obs-backgroundremoval штука прикольная, но модели, которые используются для удаления фона, не очень хорошие. Поэтому использовать их для моих целей не получилось.

Но сам код - кладезь полезной информации.

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

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

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

Начинаю приём вопросов на субботний ЗЭН. Вопросы писать в комментариях к посту, выберу три вопроса (чем больше лайков, тем больше шансов).

Если оставить донат от 300р. С пометкой ЗЭН и вопросом в комментарии на donate.s0er.ru то он попадёт в ЗЭН точно (если будет соответствовать тематике канала).

Слона нужно есть по-кусочкам

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

Архитектура на уровне кода помогает "причесать" проект, понятно разделить логику и провести границы, уменьшить зависимости и увеличить связность и т.д. Такой взгляд на архитектуру приносит разработчикам наибольшую пользу. Мы с патронами недавно обсуждали базу для чистой архитектуры с доменной моделью, один из участников скинул классную ссылку - https://github.com/Sairyss/domain-driven-hexagon на мой взгляд очень круто, когда разрабы могут четко сформулировать свои мысли с позиции архитектуры и показать их в виде вот такого гайда.

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

Это можно было сделать проще/лучше

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

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

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

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

Поэтому "сломать в себе перфекциониста" - это первый шаг в карьере любого специалиста.

P.S> как вы догадались, пытаюсь убедить себя не переделывать кусок старой и привычной логики на более "лучший" вариант.

https://www.youtube.com/watch?v=grZHTZhTZTQ

Виндертон вернулся.... но мы готовы.

Через полчаса начинаем - https://youtube.com/live/6opSSjokwm4?feature=share

Совершенно согласен, проебал в ВУЗе лучших пять лет своей жизни, вот на работе, где с утра до вечера и без выходных мы делали всякую дичь даже близкого такого не было. А вот ВУЗ, с его особым вайбом, студенческой тусовкой, интересными преподами и всякими другими ништякам - это просто потерянное время! Не идите в ВУЗ, сразу гоу покупать курсы за 300кк и в FAANG, иначе всю жизнь будете жалеть о потраченных 5 годах впустую!