Интересная статистика на HH есть, оказывается. Графики говорят сами за себя - конкуренция увеличилась (с 6.1 до 8.5), а количество вакансий просело в лучшем случае на 20%. Сложно сказать за бэкенд, но довольствуемся "Информационными технологиями" :)
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
🤯3👍2
Fullstack-разработчик - худший выбор, который можно сделать для своей карьеры в IT. Плюсов у этого решения нет, зато минусов - целый вагон.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?ХАХА, НЕТ .
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
1💯7🔥5😁2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2🤔1
Вы знали, что существует флоу, в котором просто нет тестировщиков? Совсем. Меня такой подход сильно удивил. И речь именно о крупных проектах, которые не жмутся за каждого человека в штате.
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?💻
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👀4🤔3👍2
Не понимаю как люди пользуются DeepSeek'ом. Мощностей у них кот наплакал. 50% запросов (в лучшем случае) уходят в "Server is busy" 🤬
Please open Telegram to view this post
VIEW IN TELEGRAM
🥴8👍3🤷2👎1
Цензура в ChatGPT закончилась. Сначала подумал, что это очередные сказочки из мусорных пабликов, пока своими глазами не увидел ЭТО 🤨
Надеюсь, что это не баг, а новая фича. Работать с таким подходом намного приятнее.
P.S Пожалуй прямиком в сборник цитат "Он прост как хуй на блюдце, но при этом мощный, как ебучий локомотив. "
P.P.S Судя по новостям 12 февраля изменился подход к цензуре. Так что официально - не баг. Фича. Все посты ссылаются на обновленный Model Spec. К примеру тут: https://techcrunch.com/2025/02/12/openai-pledges-that-its-models-wont-censor-viewpoints/
Надеюсь, что это не баг, а новая фича. Работать с таким подходом намного приятнее.
P.S Пожалуй прямиком в сборник цитат "Он прост как хуй на блюдце, но при этом мощный, как ебучий локомотив. "
P.P.S Судя по новостям 12 февраля изменился подход к цензуре. Так что официально - не баг. Фича. Все посты ссылаются на обновленный Model Spec. К примеру тут: https://techcrunch.com/2025/02/12/openai-pledges-that-its-models-wont-censor-viewpoints/
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣5🤯3👍1🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Апрувим?
Anonymous Poll
74%
Апрув. Главное доверять друг другу 😎
26%
Нет. Надо изучить каждую строчку 🧐
Давайте иногда вспоминать вопросы с собесов. Забывается быстро, а вспоминать всё сразу тяжело. Буду помечать хэштегом #собесы, так будет легче найти. Постараюсь поделиться именно личным опытом и чем-то полезным вокруг таких вопросов. Со временем соберём полноценную "шпаргалку".
И так, первый вопрос мне попался на Хабре, совсем недавно. Актуально и для фронтов и для бэков. Такими вопросами обычно проверяют общую "подкованность" кандидата. Лучше на них не сыпаться. И, конечно же, я позабыл ответ, пришлось погуглить.
Вопрос: Почему структурная типизация более гибкая чем номинальная?
Ответ:
Структурная типизация определяет совместимость по наличию нужных свойств, а не по именам, что позволяет использовать объекты с аналогичной структурой без явного наследования.
И так, первый вопрос мне попался на Хабре, совсем недавно. Актуально и для фронтов и для бэков. Такими вопросами обычно проверяют общую "подкованность" кандидата. Лучше на них не сыпаться. И, конечно же, я позабыл ответ, пришлось погуглить.
Вопрос: Почему структурная типизация более гибкая чем номинальная?
Ответ:
🔥5👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Приехал на Python Birthday meetup. Посмотрим что сегодня расскажут 👍
👍7🔥1
Недавно прошел Python Birthday Meetup 34 в офисе Сбера на Кутузовской. Это ежегодный митап в честь дня рождения питона (20 февраля 1991 года была опубликована версия 0.9.0). Мне понравилось. Но есть нюансы.
Главная сцена впечатляет – пока что лучший зал для конференций, который я видел. Но не хватило воды! Давайте купим Сберу куллер с водой, что ли. В общем, то ли они рассчитывали, что никто не придет, то ли планировал всё ChatGPT.
Всего было 3 доклада. Первый был самый душевный – про лень и нейросети. Получился общий разбор всех AI-решений на все случаи жизни: написание кода, генерация полноценных MVP с фронтом, суммаризация созвонов, генерация презентаций и т. д. Почти всё применимо, но без ручной «доработки» всё ещё никак. Из инструментов упоминались:
Для разработки: Github Copilot, Cursor, GigaCode
Автоматизация принятия PR/MR: qodo
Создание MVP вместе с UI: V0
Для создания презентаций: Presentation AI, Gamma
Второй доклад был про асинхронщину с кучей задачек, которые естественно почти никто правильно не решил. Приложу некоторые из них в отдельном посте. Было сложно, душно и интересно. Собеседование в Точку я бы не прошёл. Ну и про асинхронный DI (dependency injection).
В третьем докладе рассказали про кейс применения Pydantic и сравнение его с остальными «аналогами» (msgspec, cerberus, marshmallow). Главный вывод такой: Pydantic самый гибкий, мощный и достаточно быстрый. Он медленнее конкурентов на порядок, но точно не будет бутылочным горлышком. Кстати, под капотом, начиная со второй версии, он написан на Rust.
Ещё успел пообщаться на стойке с ребятами из Сбера. К моему удивлению, в большинстве команд теперь доступна полная удалёнка; раньше был только гибрид (надо бы проверить на HH). Ну и, конечно же, спросил про бюрократию и объяснительные за всё подряд. Говорят, такого в большинстве команд нет. Хотя я слышал другое. Верим?
#meetups
Главная сцена впечатляет – пока что лучший зал для конференций, который я видел. Но не хватило воды! Давайте купим Сберу куллер с водой, что ли. В общем, то ли они рассчитывали, что никто не придет, то ли планировал всё ChatGPT.
Всего было 3 доклада. Первый был самый душевный – про лень и нейросети. Получился общий разбор всех AI-решений на все случаи жизни: написание кода, генерация полноценных MVP с фронтом, суммаризация созвонов, генерация презентаций и т. д. Почти всё применимо, но без ручной «доработки» всё ещё никак. Из инструментов упоминались:
Для разработки: Github Copilot, Cursor, GigaCode
Автоматизация принятия PR/MR: qodo
Создание MVP вместе с UI: V0
Для создания презентаций: Presentation AI, Gamma
Второй доклад был про асинхронщину с кучей задачек, которые естественно почти никто правильно не решил. Приложу некоторые из них в отдельном посте. Было сложно, душно и интересно. Собеседование в Точку я бы не прошёл. Ну и про асинхронный DI (dependency injection).
В третьем докладе рассказали про кейс применения Pydantic и сравнение его с остальными «аналогами» (msgspec, cerberus, marshmallow). Главный вывод такой: Pydantic самый гибкий, мощный и достаточно быстрый. Он медленнее конкурентов на порядок, но точно не будет бутылочным горлышком. Кстати, под капотом, начиная со второй версии, он написан на Rust.
Ещё успел пообщаться на стойке с ребятами из Сбера. К моему удивлению, в большинстве команд теперь доступна полная удалёнка; раньше был только гибрид (надо бы проверить на HH). Ну и, конечно же, спросил про бюрократию и объяснительные за всё подряд. Говорят, такого в большинстве команд нет. Хотя я слышал другое. Верим?
#meetups
1👍6
👍4