Никита Шпилевой | Про ИТ, ИИ, итд

2022-11-29 13:51:16 Сколько языков нужно знать разработчику

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

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

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

На самом деле может даже и да. Есть пара самых попсовых языков Python & JavaScript, которые, мне кажется, были портированы уже на абсолютно любую платформу и любое НЛО поддерживает их из коробки, и есть много open source библиотек для разработки игр, графики, blockchain на Python/JS, хотя они, очевидно, для этого совершенно не предназначены, на том же Python можно хоть frontend писать через WASM. Но успех таких проектов довольно редок, и “можно” не значит “нужно”.

Приведу свой личный пример: у меня в стеке 3 языка, это Python, Go и C++. У каждого есть свое назначение: Python для данных, Go для backend, C++ для мат вычислений и совсем высоконагруженных штук. Я бы сказал, что это даже много, потому что бывает за год делается упор на 2 из них, и третий начинает забываться, из чего кажется 2 это оптимальное число, чтобы не налетать на все и сразу и уметь закрыть какие-то дополнительные задачи.

Еще один довод за то, что пробовать другие языки — это банальное расширение кругозора. Я даже не знаю, что можно ловить в ИТ, не имея какой-то банальной любознательности и не смотреть что вообще происходит в мире, не хотеть попробовать что-то новое. Для senior разработчиков я расцениваю знание 2–3 языков как плюс. Джунам и начинающим мидлам я бы не советовал, так как сначала освоить как следует один язык.

А теперь последний довод, который я лично считаю самым важным: а как понять, что выбранный язык лучше остальных? На чем базировать свой выбор писать до конца жизни на $LanguageName?
На советах коллег? (они никогда не ошибаются)
На маркетинговых бюллетенях? (они никогда не врут)
На том чему научили в вузе? (везде же самая современная программа)

Итак, мы разобрались почему хороший senior и выше должен знать / проявлять интерес к чему-то, кроме того, чему его научили деды в предыдущей компании. Какие аргументы против? Я вижу только один — это “распыление”, выделение малого количества времени на все подряд сделает вас “мастером ничего” (англ. идиома jack of trades master of none). Так что сами решайте, сколько языков иметь в стеке.

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

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

2022-11-24 14:53:34 Будьте экспертами в своей области, а не гонитесь за популярными направлениями

Последние годы замечаю некий упадок в “престижности” профессии разработчика. Сейчас вроде как модно быть Data Scientist’ом, разрабатывать искусственный интеллект итд. За последний год я, наверное, раз 30 уже отвечал на вопрос как из разработчика перейти в Data Science/Data Engineering/что угодно еще где есть слово Data. И ответ всегда один - начать с того, что ответить на вопрос зачем это нужно?

Начнем с того, что любая специализация в ИТ имеет абсолютно разный набор используемых технологий и требуемых скиллов для специалиста. Если вы уже работаете разработчиком/тестировщиком/devops/итд, то значит с какой-то целью эти навыки вы изучили и освоили. А если вы потратили больше всего времени на навыки, релевантные для вашей специальности, скорее всего именно они вам и интересны?

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

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

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

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

TLDR
Не гонитесь за популярными направлениями, становитесь экспертами в своем направлении. Человек, входящий в топ 10% своей специализации всегда будет зарабатывать намного больше и жить интереснее, чем человек входящий в топ 70% чего-то хайпового. Открыть/Комментировать

2022-11-21 13:16:04 Как просить повышение зарплаты?

Очень деликатная тема, которой я, вероятно, посвящу несколько постов или буду возвращаться время от времени.

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

Допустим, у нас с этим всё хорошо, и мы идём к руководителю, чтобы запросить повышение. Руководитель, скорее всего, это не тимлид, а тот, кто стоит выше, потому что тимлиды крайне редко заведуют деньгами (только в совсем мелких компаниях). Тем не менее после вашего разговора, первое что сделает руководитель, это запросит вашу характеристику у тимлида. Можно сказать, что решение наполовину зависит от тимлида.

И теперь самый важный момент. Мы дошли до руководителя (неважно онлайн или офлайн) и высказали свои пожелания. Самый очевидный вопрос, который вы получите - на чём основан ваш запрос на повышение. И для вашего успеха, лучше иметь хороший ответ на этот вопрос.

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

На что мне руководитель ответил фразой, которую я осознаю только спустя несколько лет, когда у меня появятся свои первые подчинённые: “Зарплата растёт с повышением ответственности. Я такой молодец и всё делаю хорошо - это плохое объяснение для повышения”.

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

TLDR
Хотите получать больше - берите больше ответственности. Это самый железобетонный аргумент, который вы можете предъявить. Не забудьте заслужить доверие, иначе ответственность вам не доверят. Открыть/Комментировать

2022-11-17 15:17:50 Есть ли смысл проходить онлайн курсы?

Начнем с того, что такое курс? Это упакованная коллекция материалов, таких как видео, текст, тесты, задачи, итд. Является что-то из этого вредным/бесполезным? При хорошем качестве материала - нет. Так как может являться собранная и обернутая коллекция материалов (которые не плохи сами по себе) бесполезной?

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

Можно ли стать разработчиком пройдя курс? Нелепый вопрос, точно такой же, как и “Можно ли стать разработчиком прочитав книгу?”. Пройдя одну единицу любого материала, вы получите один или несколько навыков на базовом уровне. Откройте вакансию и посмотрите сколько и каких навыков ожидает работодатель. Каким образом вы их будете получать, из университета/курсов/книг/фильмов про хакеров итд, нанимающему совершенно безразлично. Главное, чтобы вы могли выполнять свою работу.

Есть ли смысл тем, кто на позиции Senior/Lead/и выше проходить онлайн курсы? По своей “специальности” - скорее всего нет, так как большинство курсов — это продукт массовый и рассчитанный на низкий порог входа. Это странно видеть, что Senior Python Developer со стажем 6 лет, полгода назад окончил курс “Python для начинающих”. С другой стороны, если вы хотите вкатиться в новую область (например, Blockchain) или изучить что-то непрофильное (например, DevOps) то почему нет? Открыть/Комментировать

2022-11-13 16:12:42 Как разработчику выделиться среди равных?

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

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

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

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

Что это даст? Банально, выделит из серой массы. Большинство откликантов, даже на senior уровне, не имеют ничего из списка. Если прямо сейчас, сесть и составить план на год: написать 2 статьи, сделать 2 проекта, снять 2 видеоролика итд (вроде не звучит как непомерная нагрузка на год?), это увеличит вероятность приглашения на интервью. А вот на интервью, уже будет возможность показать какие мы умные. И даже там, добавит пару лишних баллов, может именно это перевесит чашу весов между вами и другим кандидатом, а может позволит выторговать большую зарплату.

Так что, ищите подтверждение своим компетенциям. Никто не оценит вашу гениальность, пока сидите в пещере и смотрите очередной сезон сериала. Открыть/Комментировать

2022-11-11 14:27:40 Среди питонистов самая жесткая конкуренция за рабочее место

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

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

Ради эксперимента, мы запустили на hh одновременно 2 вакансии уровня Middle на Python и Go, с +/- одинаковым описанием. За сутки, мы получили 13 откликов на Go, и ~150 на Python. Разница более чем в 10 раз, при том что если сравнить количество вакансий на том же hh, то вакансий по Go всего в полтора раза меньше чем на Python.

Чем это объясняется? Я подозреваю виной всему онлайн курсы “Стань Data Scientist’ом за 1 неделю и начни зарабатывать шестизначные суммы сразу после стажировки”. В итоге имеем армию бедолаг, которые хоть какую работу найти не могут. Что характерно, на уровне Senior/Lead подобный перевес уже не наблюдается, но это отдельная история, хантинг сеньоров всегда был особым челленджем.

Что с этим делать? Если вы junior/middle питонист, то возможно стоит присмотреться к другим backend языкам, таким как Go или Rust. Это конечно не касается Data Scientist’ов, у них спорт основывается на алгоритмах и знаниях предметной области. Ну а если вы уже senior, то радуйтесь что эта дичь вас не касается, хотя знать дополнительный язык программирования всегда полезно, хотя бы для расширения кругозора. Открыть/Комментировать

2022-11-09 18:13:00 Рекомендую книгу: Концепции операционных систем (Ави Зильбершатц, Питер Гэлвин и Грег Ганье)

На английском: Operating System Concepts (Abraham Silberschatz, Peter Baer Galvin)

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

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

100% это поможет пройти следующее техническое интервью и блеснуть своими знаниями. Открыть/Комментировать

2022-11-02 14:37:41 Как выбрать облачную CI/CI платформу

Мой чеклист при выборе платформы для нового проекта. На неделе постараюсь сделать детальный обзор платформ, с их + и -.

𝟭. 𝗖𝗜/𝗖𝗗 должен поддерживать интеграцию с вашими репозиториями

Репозитории необходимы для CI и CD. Репозитории программного обеспечения являются не только конечной точкой процесса регистрации и тестирования, но и предпочтительным местом для хранения скриптов CI, а также файлов конфигурации. Да, многие платформы CI/CD могут хранить скрипты и другие файлы внутри, но обычно лучше иметь их в системе управления версиями вне инструмента.

𝟮. Ваш CD/CI инструмент должен поддерживать используемые языки программирования

Каждый язык программирования, как правило, имеет свои собственные инструменты сборки и инструменты тестирования. Чтобы быть полезным для вас, инструмент CI/CD должен поддерживать все языки, являющиеся частью данного проекта. В противном случае вам может потребоваться написать один или несколько подключаемых модулей для инструмента. Образы Docker становятся все более и более важными для распределенного, модульного и микросервисного развертывания ПО. Очень полезно, если ваша CI/CD платформа знает, как обращаться с образами Docker, включая создание образа из исходного кода, двоичных файлов и предварительных условий, а также развертывание образа в определенной среде.

𝟯. Насколько хорошо вы знаете 𝗖𝗜/𝗖𝗗 платформу и ее инструменты?

Принципы CI и CD могут показаться очевидными, но детали — нет. Различные инструменты CI/CD имеют разные уровни поддержки и документации. Есть несколько книг о Дженкинсе, что неудивительно, поскольку это самая старая из всех. Для других продуктов вам, возможно, придется изучить документацию и форумы поддержки, а также варианты платной поддержки в рамках комплексной проверки при выборе инструмента.

𝟰. Можно использовать несколько 𝗖𝗜/𝗖𝗗 платформ для разных проектов

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

𝟱. Отдайте предпочтение serverless CI/𝗖𝗗

Как правило, развертывание облачных контейнеров дешевле, чем развертывание экземпляра облачного сервера, а безсерверное облачное развертывание дешевле, чем развертывание контейнеров. К сожалению, на момент написания этого поста немногие платформы CI/CD могут работать без сервера. Одной из немногих платформ CI/CD, которые могут работать без сервера, является Serverless CI/CD, часть Serverless Framework Pro, расширенной версии Serverless Framework с открытым исходным кодом. Бессерверная CI/CD оптимизирована для развертывания бессерверных приложений и в настоящее время работает только на AWS. Вам нужно будет определить, достаточно ли хорошо он поддерживает ваше приложение для использования. Открыть/Комментировать

2022-10-26 13:05:35 Какие плюсы и минусы использования REST API или GraphQL?

Что касается мутаторов, они примерно одинаковы.

В плане запросов REST похож на RPC: один метод возвращает (как правило) одну форму результата. Иногда, параметры запроса позволяют вызывающей стороне указывать «дополнительные» данные для возврата, но это не очень гибко.

GraphQL предлагает гибкость и, если кто-то ценит общее сокращение количества вызовов API, некоторую эффективность.

GraphQL диктует некоторую реализацию, которая является более гибкой и менее эффективной. Поколения иерархии данных якобы разделены, поэтому, например, невозможно оптимизировать соединения между таблицами. Загрузчик данных (dataloader) — это специфическая (и очень эффективная) оптимизация, но на самом деле это единственная доступная опция.

Каждый node в графе запросов может принимать свои собственные параметры (а не только верхнеуровневые node), поэтому критерии могут быть довольно специфичными. Поскольку можно повторно использовать узлы запросов, это поощряет внутренне согласованный API. Реализация критериев на каждом уровне будет выглядеть почти так же, как и для REST endpoint для тех же данных.

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

2022-10-25 20:17:46 GraphQL vs REST, что и когда лучше использовать? Можно ли использовать сразу оба варианта?

Однозначно, в вашем приложении вы можете сразу иметь и REST и GraphQL. Зачастую, команды делают выбор в пользу одного из вариантов, потому что это неоправданно трудозатратно поддерживать сразу 2 реализации. Популярные фреймворки как правило поддерживают REST или GraphQL, но не все сразу, поэтому мы начинаем с чего-нибудь одного.

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

Я пришел к выводу, что для проектов и API с огромным количеством данных, GraphQL становится более простым и удобным. С ним намного проще получить нужные данные с меньшим количеством API запросов. Также, для batch-операций, с GraphQL работается более просто.

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

Многие API платформы до сих пор используют REST как более понятный и распространенный вариант. Если вы относитесь к таковым или "сомневающимся" - можете начать с REST и затем уже перейти на GraphQL позже.

Так как API Gateway и другие API инструменты упрощают разработку API, я ожидаю появления большего количества смешанных API, если затраты на запуск API GraphQL и REST API снизятся. Но независимо от сложности, когда дело доходит до вариантов использования, может иметь смысл сделать и то, и другое. Открыть/Комментировать