S0ER

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

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

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

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

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

Канал в офисе выпустил интервью со мной. Еще раз повторюсь, меня там сильно повозили по политике, и я не смог грамотно аргументировать свои мысли в полном объеме. Но сказанных слов не выкинуть, поэтому как есть так и есть. https://www.youtube.com/watch?v=tP4v7jy4lJI

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

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

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

Опыт против знаний Опыт и знания – это две стороны одной медали, знания – нужны для того, чтобы наметить путь решения, а опыт помогает минимизировать количество ошибок, которые могут возникнуть на этом пути. Лучший способ приобрести опыт – это практика. Поэтому на рынке ценятся специалисты, которые имеют практический опыт разработки и хорошие теоретические знания, позволяющие решать принципиально новые задачи. В повседневной жизни мы привыкли к тому, что с опытом на достижение результата тратится меньше сил, а качество становится лучше. В программировании все немного иначе, многие программисты сталкиваются с ситуацией, когда приобретенный опыт за короткое время становится никому ненужными. Большая часть работы современного разработчика связана не с созданием новых алгоритмов, а с поиском готовых и наиболее подходящих решений, с последующей «подгонкой» результата к нуждам проекта. Существует огромное количество ресурсов, где готовый код решает поставленную задачу и все что требуется – это скопировать его в свой проект и адаптировать к своим условиям. Общество не стоит на месте, появляются новые требования, идеи и вызовы. Одна технология сменяется другой, появляются новые библиотеки и фреймворки, которые конкурируют между собой за долю на рынке. В какой-то момент возникает хрупкое равновесие, которое очень быстро нарушается появлением нового «игрока». В целом это напоминает игру «хозяин горы», когда ни один из участников не может задержаться на «вершине» слишком долго, так как его теснят другие участники. И здесь программисты оказываются в сложной ситуации – чтобы получить опыт работы, необходимо освоить новую технологию на практике, но скорость развития индустрии такова, что времени на это освоение практически нет. Путей решения в такой ситуации не так уж и много, я предложу всего два. Первый вариант заключается в том, чтобы остановиться на наиболее развитой технологии и сосредоточиться на ее изучении. При этом не тратить время на изучение альтернативных решений. На рынке всегда есть предложения для узких специалистов, которые работают со старым кодом. Обычно такие разработчики требуются в больших компаниях, где обновление кодовой базы идет медленно. В такой ситуации программист становится заложником своего опыта. И продолжая углубляться и развиваться по выбранному направлению он теряет новые знания, но продолжает приобретать опыт. Второй вариант заключается в постоянном развитии и изучении всего нового, частой смене проектов и ориентации на перспективные стартапы. В этом варианте недостаток опыта, компенсируется новыми знаниями. Ориентация на стартапы выбрана не случайно. Отличительной особенностью молодых проектов является использование современных решений и технологий. Обычно использование всего нового позиционируется как конкурентное преимущество. Так как на рынке нет в достаточном количестве разработчиков с опытом работы со всеми новыми решениями, появляется шанс попасть на работу обладая только знаниями, без опыта. Рано или поздно придется выбирать на какой технологии остановиться. Потому что прибывать в состоянии постоянного ученика очень некомфортно и со временем приводит к состоянию эмоционального выгорания. Наиболее удачной стратегией развития для программиста будет совмещение первого и второго варианта развития. Безусловного это требует постоянно держать «руку на пульсе», но если вы решили быть программистом, то нужно быть готовым к тому, что накопленный опыт постоянно обесценивается, как и приобретенные знания. Но если опыт постоянно обесценивается, то существует ли оптимальный стаж работы, который является преимуществом при устройстве в интересные проекты? В «зачет» идет не весь опыт, который есть у кандидата, но и полное отсутствие опыта не является плюсом. Обычно наиболее важными являются последние пять лет. Так, например, разработчик с десятилетним стажем практически не выигрывает на фоне разработчика с пятью годами работы за плечами.

Ответ на вопрос: Привет. Вопрос касается софт-скилов. Вводные: работаю в банковской сфере, нахожусь на позиции senior-backend разработчика. Последнее время стал больше интересоваться архитектурой и начал лидировать в этой теме в команде: больше обсуждать с аналитиками требования, проектировать архитектуру на различных уровнях, интеграции и пр. На одном из 1-1 с техлидом получил вводную, что слишком занимаюсь микроменеджементом: не даю развиваться членам команды, растягиваю CR и пр.. Вот я и задумался, насколько это действительно проблема и насколько на это надо обращать внимание? Не пониманию, как без доведения до коллег-бэкэндеров требований и схем, а так же соблюдения правил при реализации, поддерживать сервисы в адекватном состоянии? Можете поделиться как соблюдать баланс в этом вопросе? p.s. Не планируется добавлять на платформу кроме техники еще и темы, связанные с взаимодействием в команде, когда находишься не на позиции менеджмента и вроде как не можешь напрямую влиять на коллег, но при этом, на мой взгляд, архитектура это подразумевает? Столкнулся, что этого не хватает. RuTube | VK | Подкаст "S() Talks"

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

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

Ссылка на канал с анонсами от Димы https://t.me/ityoutubers_com

Погнали на стриме общаться

Запускаю сбор тем на субботний ЗЭН. Отберу три коммента с наибольшим количеством лайкосов. Только тематические комментарии.

Ветвление и линейность в коде Давайте немного поговорим о том, что такое вложенные конструкции чем они вредны для кода. И почему линейность помогает улучшить код. Под линейностью в коде программы обычно понимается последовательный вызов функции без условных переходов. Ветвлением же называют те места в коде, где дальнейшее поведение программы может пойти по разным путям. Ветвление делается с помощью операторов выбора if/then/else и по сути означает, что мы либо сворачиваем с "прямого пути", либо продолжаем двигаться дальше. На уровне машинного кода ветвление - это либо переход на следующий адрес, где расположена команда для выполнения, либо на какой-то произвольный адрес с командой. Если нужно сделать ветвление не из двух, а из большего количества вариантов, то мы просто располагаем друг за другом несколько операторов выбора. Каждый оператор является выбором из двух путей: продолжаем или переходим куда-то еще. Такая простая логика позволяет декомпозировать сложные условия на простые составляющие. Бывают ситуации, когда уже после перехода на другой адрес, нам нужно снова принять решение двигаться дальше или перейти еще куда-то, для этого так же используются операторы ветвления, но такие ситуации называют "вложенными" условиями. Чем больше вложенных операторов ветвления мы используем, тем сложнее проводить анализ кода, потому что каждое условие увеличивает количество возможных путей вдвое. Таким образом операции ветвления увеличивают сложность понимания кода. С ростом сложности кода растет риск возникновения ошибок и неожиданных результатов работы программы. Отсюда возникает хорошо известное правило: "плоское лучше вложенного". Оно говорит о том, что идеальным случаем для решения задачи является последовательное выполнение программы без использования условных переходов, потому что читать и анализировать такую программу гораздо проще. Достигнуть идеального случая сложно, поэтому нужно стремиться к уменьшению количества вложенных условий, в тех случаях где это возможно. Если уменьшить количество условий невозможно, то можно сделать код "визуально" прямым. Визуально означает, что мы используем ветвления не более чего с одним уровнем вложенности, а все ветки, которые возникают внутри условий, оборачиваются в подпрограммы, которые скрывают от программиста часть сложности, абстрагируясь от деталей реализации внутри условных переходов. Отсюда возникает правило: "вложенные условия декомпозируй в виде функции". Практика показывает, что декомпозиция программы на функции не только упрощает повторное использование кода, но и значительно упрощает восприятие и анализ. Отдельно нужно прорабатывать сами логические выражения, которые записываются внутри условия. Очень часто в условиях есть избыточность или неточность, а так же бывают из-за ошибки программиста условие может быть строго положительным, либо строго отрицательным. Чтобы код получился более читаемым и понятным нужно обратить внимание: на уровень вложенности - конструкции более двух уровней вложенности недопустимы; сложность выражений внутри условий - условия должны хорошо читаться и быть максимально простыми; декомпозицию содержимого if-ов с помощью функций, для визуального уменьшения вложенность программы.