Как стать автором
Обновить
9
Карма
0.2
Рейтинг

Пользователь

  • Подписчики 3
  • Подписки

Минусы от высокой зарплаты у IT-специалистов в России

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

Почему же они это спрашивают: а потому, что прошлого джуна, который выдал себя за миддла, они спросили о других мелочах, а он накосячил в этих. До него они спрашивали об ещё одних мелочах, но тот джун накосячил в том, о чём спрашивали прошлого джуна. А первого инженера на проект компания взяла, спросив у него: "Витёк, ты с Python/JS/Ruby работал"? И Витёк сказал: "Да, работал"!

Просто нанимать на работу технарей, используя вопросы из курса "Senior из слесаря за пол года" - это такая себе идея. В принципе, и на этих курсах можно не париться: отправляете по собеседованиям своих преподавателей, а в конце составляете учебную программу. Пусть студент вызубрит то, что сейчас спрашивают на собесах, и результат ему будет гарантирован. Бесценно будет знать, что гордые своим образованием инженеры, будут набирать зелень, а потом плеваться: "как же так?! Он же рассказал мне всё, о чём я спрашивал, а код писать не умеет"?!

Минусы от высокой зарплаты у IT-специалистов в России

А себя, пожалуйста, уберите оттуда.

Минусы от высокой зарплаты у IT-специалистов в России

Какой бред я у него прочитал?! Какой бред?!

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

Все эти обещалки проблем на IT рынке игнорируют простой факт: даже немного раскрученный, недавно запущенный стартап способен кормить джуна зарплатой в 1200 - 2000 USD без вливания средств инвесторов.

Мы пашем непаханное поле. Мы делаем прогресс. Как раньше рабочие делали прогресс, строя города из металла и камня. Как инженеры делали прогресс, автоматизируя производство, так и мы сегодня делаем прогресс, автоматизируя человеческий быт. Люди готовы платить деньги за то, чтобы им привозили домой продукты, чтобы читать электронные книги, заказывать билеты онлайн. Бизнес готов платить за живой мониторинг процессов, за самую детальную статистику. Наша зарплата не берётся из воздуха, и, вплоть до окончания информационной революции, которую мы совершаем, нам будут платить. И, есть ощущение, что эту революцию будут завершать наши дети, а то и внуки. Но никак не мы.

Как стать программистом за 60 секунд или «Яндекс.Практикум» — НЕ ковчег судьбы

«Ревьювер», он покажет тебе всё, где ты неправильно списал из тренажера и заставит написать так как написано в тренажере, даже если ты проявишь немыслимые мысли и напишешь так как будут писать через 10 лет в Google, то всё равно тебе это придется переписывать точно так, как в тренажере, ибо как говориться: «Парламент не место для дискуссий!». 

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

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

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

Почему программисты через 10 лет будут не нужны?

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

Пишем на Питоне сразу хорошо

Ты хабр со смехопанорамой перепутал.

Пишем на Питоне сразу хорошо

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

If a:

print('foo is true')

return a

return на уровне условного оператора. Бухаю на балконе, пишу со смартфона.

Пишем на Питоне сразу хорошо

В целом, там тренарный оператор. Вполне явный.

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

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

Пишем на Питоне сразу хорошо

Серьёзно? Он в первом примере предлагает негативную проверку ставить над позитивной. И не видит, что там вообще всё до одной строчки сокращается : return not my_value.

Но это всё фигня потому, что с первых строк он пишет, что что-то не может запомнить, что-то субъективно вооспринимает. Когда он узнает о том, сколько рекомендаций PEP существует, и что они проверяются ещё и автоматически, прогонит свой код через линтеры, получит ошибки, то тогда он крайне сильно удивится. Не знаю, перевод это статьи, или нет, но идея писать код так, как хочется, а не как рекомендуется - это чушь и опасная практика. Я после первого же примера пролистал немного его советы. Есть и неплохие: их надо выбирать - в этом проблема. Например, использование dict для замены switch/case (коих нет в пайтоне) - это разумная практика, но есть значимые исключения. Прежде-всего, стоит помнить, что elif является официальной заменой switch/case, и, вводя свой формат обработки этого оператора, человек заставляет других программистов писать не так, как рекомендуется, а как он сам хочет. Поэтому, надо знать, когда применять elif, а когда - словари.

Но автор не ссылается на best practice, PEP, popular styleguides. Он просто гонит отсебятину.

MastermindCMS – что это такое? Система управления контентом? Фреймворк?

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

Что касается рудиментов, то их там не так уж много. Шаблонизатор там уже давно меняется через настройки. Jinja2 вполне себе заменяет дефолтный шаблонизатор. Использование ORM там тоже не жёсткое. Просто, ORM - это фича джанги, и я лично не вижу особого смысла использовать джангу без него.

Вы совершенно не описываете главных минусов джанги: это много лишнего кода, низкая скорость работы, в сравнении с более легковесными фрэймворками, слишком жёсткий стиль организации кода с большим набором всевозможных файлов (когда можно было бы обойтись парой файлов). Слишком много концепций, и для написания нормального кода на Django следует знать прямо очень много деталей и постоянно следить за обновлениями пакетов. Плюс, концепция Django - это универсальность. Фрэймворк, и основные дополнения к нему, типа DRF, пытается покрыть максимум кейсов. Из-за этого, для добавления простого эндпоинта ты вынужден писать много кода во множество файлов, попутно решая, какие миксины и наследования использовать, чтобы оно работало как надо и без повторов кода. То есть, даже с появившейся недавно поддержкой async во многих местах, джанга - так себе решение для большинства микросервисов.

MastermindCMS – что это такое? Система управления контентом? Фреймворк?

Вообще-то, на многих CMS бэкенд писать надо. Другой вопрос: а почему вы считаете, что написали именно CMS, а не фрэймворк?

Языковой сервер Pylance вышел в релиз

Смотря для чего: если ты работаешь с многофайловым проектом, и у тебя используется множество концепций, а также, подсобных инструментов для работы (тестирование регулярок, сложная real-time проверка стиля кода, автодополнение, определение типов данных и т.д.), то JetBrains, действительно, является наиболее мощным инструментом. В некоторых компаниях на собеседовании даже спрашивают о том, используешь ли ты его? Потому, что команда не будет ждать, пока ты настраиваешь свой vim под определённые задачи.

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

НО! Решение платное. Решение не быстрое. Решение комплексное. Если у тебя будут задачи, связанные, например, с небольшими проектами, то открывать на каждый файл эту IDE - затратно. И, опять же, если она себя не окупает, или ты принципиально не хочешь платить, то она не для тебя. Бесплатная версия не даёт всех инбокс плюшек. Решение периодически ломают, но разрабы жёстко и успешно с этим борются.

Основные кейсы, связанные с использованием IDE JB - это исполнение скриптов из коробки. Для пайтона, например, это test и debug. Здесь JB даёт возможность запуска всего мышкой, а также, предоставляет свой инспектор для дебага. Но есть люди, которым этот функционал не нужен, либо они не счииают нормальным платить за него. Или они не хотят пользоваться таким упрощением.

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

Почему большинство юнит тестов — пустая трата времени? (перевод статьи)

Ну, сам автор, я думаю, код пишет лучше, чем статьи. Кликбейтный заголовок и растекается мыслью по древу. Я могу быть сто процентов согласным с его идеей, но она нифига не понятна массам. Я могу читать «Юнит-тесты не нужны», и понимать «тесты не нужны, и вы не должны за них платить». При этом, лишь опыт позволяет мне понять, что истерия по поводу создания целой подсистемы юнит-тестов — лишь фанатизм. Думаю, перевод статьи стоит оставить тем, кто имеет хороший опыт программирования, и может понять о чём говорит автор. Для Хабра было бы лучше набросать вольное изложение с примерами кода. Благо, сейчас на рынке очень много команд, которые прямо тащатся от избыточного юнит-тестирования.

Почему большинство юнит тестов — пустая трата времени? (перевод статьи)

Вы хотите сказать, что не вы выбирали статью для перевода и размещения на Хабре?

Почему большинство юнит тестов — пустая трата времени? (перевод статьи)

Слабо оформленная портянка текста без образцов кода — это типа не замечание?

Почему большинство юнит тестов — пустая трата времени? (перевод статьи)

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

Как Unix-way убивает десктопный Linux

Вопрос уже в том, зачем линуксу нужна молодёжь? Бабушки так-то в молодости могли и Дженту собирать, и на Слаке в качестве десктопной системы сидеть.

Как Unix-way убивает десктопный Linux

В целом, я готов согласиться и с вами, и с автором, но хочется сделать ряд критических замечаний.

1. Популярность десктопного Linux растёт в разные периоды времени. Например, вспомним нулевые. Это было время расцвета почившей Мандривы и победившей Убунты. Это время призового спринта Unity, которая, по сути, превратила Gnome в живой труп. Последствия десктопного развития Linux в нулевых мы видим и сейчас. Допустим, GIMP доказал, что фотошоп, по большей части, слишком сложный и не нужен во многих кейсах. VLC плеер занял свою долю на рынке. Open/Libre Office привели к тому, что стандарт открытого документа был принят, в том числе, в Microsoft Office. Сама Windows обзавелась в десятой версии встроенным менеджером буфера обмена, screenshot maker'ом и менеджером аудиопотоков приложений (когда ты можешь переключать вывод и ввод звука для отдельных приложений на отдельные устройства). Всё это последствия работы энтузиастов, которые пилили юзер-френдли решения для Linux. Энтузиазм гаснет, да, но сейчас нет никаких предпосылок к тому, что не будет такого периода, когда энтузиазм снова вспыхнет, и молодые люди вновь вовлекутся в гик-культуру. Да, сегодня истинных гиков мало. Ты умеешь настроить приложение на Андроид, и уже считаешь себя технарём. Но я уверен, что со временем появятся те, кто поймёт, что можно и нужно копать глубже, чтобы добиться большего результата.

2. В те же нулевые Linux активно использовался в качестве виртуальной песочницы. Вспомним тот же DrWeb Live CD. На винде часто ставили Virtualbox/WMWare с убунтой. Мой знакомый тогда работал компьютерным мастером (своё ООО). Он несколько раз ставил убунту в виртуалку нерусским клиентам. Они любили посмотреть порнушку, но не пользовались одним единственным аггрегатором, а искали её через поисковики, что приводило к заражению компа вирусами. Вот он им ставил всё и объяснял: «Хочешь смотреть свою порнуху — открываешь этот значок, загружаешь песочницу, через неё смотришь, иначе будешь мне постоянно платить». Сейчас есть такое решение, как Vagrant — по сути, обёртка над виртуалкой. То есть, есть тенденция развития юзер-френдли над виртуализацией. Опыт контейнеров типа Docker, а также, WSL ведёт к тому, что целой виртуалки с убунтой не нужно для запуска нескольких приложений в окружении Убунты из-под винды. Прогнозы делать здесь сложно, но можно предположить, что безопасная песочница с десктопными линукс-приложениями может вскоре стать более популярным и доступным решением. Во всяком случае, за развитием виртуализации интересно наблюдать. И если раньше мы пытались запустить windows приложения внутри wine, то сейчас всё может пойти в другом направлении, и мы будем запускать приложения в виртуальном окружении Linux на винде.

3. Десктопный линукс, побеждающий винду, в принципе не нужен. Просто оставьте мне, и подобным мне, эту визуальную среду для энтузиастов с популярностью 2%, и не надо пытаться превратить её в коммерчески успешную оболочку. Я и сам сейчас работаю на Windows с использованием WSL. Мне хватает текстового интерфейса для работы с Linux. Если в плане графических оболочек под Линукс случится очередной взрыв энтузиазма, я с радостью поставлю второй диск с каким-нибудь новым дистрибутивом, чтобы поиграться и снова вернуться в винду. Но этот опыт будет для меня отдушиной и радостью.

4. Вы забываете, что огромная доля пользователей Windows — это корпоративный сектор. Я знаю, какие там, зачастую, используются приложения для управления документооборотом, базами данных и т.д. В большинстве случаев, wsl может решить проблему с дерьмовым софтом корпоративного сектора, поскольку разработка серверного ПО для линукс-сервера развита лучше. У нас лучше окружение и инструментарий. У нас больше практики, и наша разработка стоит дешевле. Вопрос стоит только в том, что сервер требует клиента, а клиент — это десктопное приложение. То есть, по-хорошему, с развитием WSL разработка кроссплатформенного GUI может и выстрелить. Опять же, прогнозы делать рано, но я уверен, что компании, которые решатся переписать большую часть корпоративного shit-software в России под WSL, сорвут неплохой куш.

Узелковое мышление. Об информационной уникальности кипу

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

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

Информация

В рейтинге
1,887-й
Дата рождения
Зарегистрирован
Активность