Search
Write a publication
Pull to refresh
34
0.3
Send message

Бум курсов никак не влияет на эту зарплату.

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

Зарплата тут определяется единственным фактором - желанием удержать тех, кто таки начнёт подавать надежды через пару месяцев. Противостоянием тому самому "давлению рынка", которое мы и хотим измерить.

Предлагаемая ЗП в компаниях РФ часто больше зависит от "послужного списка", чем от каких-то там грейдов, опыта и квалификаций.

Если в резюме есть легкопроверяемая строчка "работал в Сбердексе за 300к", то такого на 300к возьмут не глядя - в случае чего, у менеджера уже есть, чем прикрыть задницу. А если такой строчки нет, то даже в ООО "Рога и копыта" за 100к будут нос вертеть, будь у кандидата хоть 10 лет опыта и желание "вотпрямщас на реальном проекте его продемострировать".

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

Поэтому единственным непредвзятым барометром зарплат в IT можно считать уровень зарплат на вакансиях типа entry-level job "приходи к нам после курсов, всё покажем-расскажем" и уже по нему смотреть повышение-понижение зарплат. А там сейчас, судя по рассказам, тот ещё треш творится.

По большей части согласен, разве что вот с этим абзацем не могу согласиться:

Веди репозиторий так, будто ты работаешь в команде. Помечай коммиты префиксами, старайся чаще коммитить, разделяй ветки на задачи. Всегда готовься быстро вносить / откатывать изменения. Это сэкономит тебе несколько десятков часов в будущем.

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

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

Чтобы быстро вносить/откатывать изменения, процесс внесения/отката изменений должен содержать минимальное количество телодвижений.

Например, поменял цифру в конфиге, ctrl+s, залил файл. Потестил.

Всё сломалось? Ctrl-z, ctrl-s, залил файл. Может, комментарий написал рядом, мол "тут не меняй, а то всё ломается". Занимает секунды.

Делать то же самое по всем регламентам через репозиторий - на порядки дольше.

Ну, то есть, вероятно, сначала они попробовали указать расу прямым текстом в резюме - сенсационной картины не получилось (иначе бы об этом написали).

Потом они попробовали указать оттенок цвета кожи - тоже сенсации не получилось.

Потом попробовали указывать только пол - тоже сенсации не получилось.

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

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

Потом попробовали GPT4 и там ничего не получилось, но упомянуть всё равно можно.

То есть, отработав 8 часов программистом в офисе, он торопится домой, чтобы заняться тем, что ему нравится - программированием (любимым пет-проектом, захватывающей книгой, интересной задачей).

Ну, или тем, что не успел доделать за 8 часов, но лучше доделать сегодня, ибо завтра уже забудешь, на чём остановился.

Или вторым (третьим, четвертым) проектом по совместительству, который "очень просили посмотреть".

Или решением бесконечных проблем домочадцев с их компами / телефонами / умными холодильниками.

Так на интересности-хотелки уже и часов в сутках не останется.

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

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

3 человека, понимаете? Не десяток, не сотня. 

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

Поэтому тут и смысл на собесе говорить, выполнял задачи или нет, а приписывать себе в заслуги всю работу команды и ещё и результат от неё - просто очевидное враньё.

Ну, я выполнял все поставленные задачи...".

«Создал дашборд со всеми метриками компании – «Зачем?» – чтобы руководители отслеживали эффективность каждого отдела»

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

Во-первых, у нормальных работников за N лет работы скапливается куча выполненных работ, одно только перечисление которых займёт больше 30 минут. И ограничиваться тут упоминанием одного дэшборда - враньё, только идущее себе во вред.

Во-вторых, не всегда на собесе есть время объяснять гуманитарию, что такое, например, рефакторинг легаси кода, для чего он выполняется и какую пользу он приносит.

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

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

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

Я вижу пользователей проприетарного и открытого по разным.

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

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

Я вижу это скорее как ожидания от разных классов программ.

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

Тут либо серьёзное профессиональное ПО, на которое можно положиться, либо "а что ты хотел, скажи спасибо, что хоть какое-то".

Ответ на ваше негодование кроется в одном предложении, которое я вижу постоянно - WITH ABSOLUTELY NO WARRANTY.

Дык, оно во всех лицензиях и так написано. И если покопаться в EULA проприетарного софта, то и там тоже много подобных формулировок. На такое уже слепота выработалась, все всегда говорят, что они никому ничего не должны, это ничего не говорит об ожиданиях.

Проблема чисто в позиционировании. Пример с потолка, сравните:

Библиотека для обработки изображений в формате CR2

и

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

Когда пользователь скачивает первое, он ожидает, что получит рабочую стандартную библиотеку, а не второе. Но если указать на это автору, он скорее будет говорить про NO WARRANTY и возмущаться, что никто не читает лицензии, но не пойдёт и не исправит описание своего проекта с первого на второе.

Когда на графике был столбец 35к, было 90. Как убрали столбец - стало 150.

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

Когда пришёл, сел, прочитал описание fizzbuzz и пошёл оставшиеся 30 минут пытаться его реализовать с нуля. И ведь если оно в задаче называется не fizzbuzz, а как-то по-другому, то тут уже даже гугл мало чем поможет гуманитарию.

Представьте, каким жутким читом на этом фоне выглядит ChatGPT, который просто берёт и выдаёт ответ по сумбурному текстовому описанию задачи, даже не переспрашивая. В этом смысле и правда "программисты" (соседи по парте) становятся не нужны.

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

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

Потому что в любой IT-продукт можно вложить реально неограниченное количество денег. Можно даже в сайт-одностраничник хоть 1 млн вложить, хоть 10 млн (и с заметным отличием первого от второго). Но если всегда сразу называть цену "по верхней планке", то заказчик просто молча развернётся и уйдёт.

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

Не совсем так. Для меня "пригодилось" означает значительно на что-то повлияло. Есть яркий пример из опыта: Если в JS написать

let asd = [];
asd[10] = 'a';
asd; // = (11) [empty × 10, 'a']

то мы получим массив длиной в 11 элементов (первые 10 - пустые).

В PHP не так:

<?
$asd = [];
$asd[10] = 'a';
print_r($asd); // = Array([10] => a)
print_r(count($asd)); // = 1

Массив с 1 элементом.

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

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

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

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

Но вот попадись ему такой вопрос на собеседовании (или задачка литкодовая) - его бы непременно признали "не программистом".

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

Алгоритмы и структуры — это базовые вещи, фундамент (так же, как и математика)

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

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

Когда за 30, ты не работаешь в экстренных службах (где могут дергать и после работы), не ухаживаешь за больными родными, то НЕ уметь построить свой график == инфантилизм.

Не обязательно больными родными, в 30+ уже не ровен час самому стать тем самым "больным родным", за которым сам же и ухаживаешь. А тут уже с понятием "график сна" придётся попрощаться в некоторых случаях.

ИМХО всё просто — вижу KPI - делаю KPI. Любой ценой.

Вероятно, проблема в том, что в компании недостаточно понятно объяснили, что это был именно KPI.

Это как подойти к работнику на заводе и спросить:

- А круто было бы, если бы ты английский в этом году выучил?

- Да, таащ начальник, было б круто.

- Будешь к этому стремиться?

- Ну, наверно.

- Отлично. А вот придумай ещё 10 таких "круто" и напиши мне.

- Ок.

А потом в конце года...

О какой вообще ответственности тут может идти речь?

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

Цензура в ChatGPT это скорее не про уход от ответственности, а про позиционирование.

Инвесторы не хотели бы быть связаны с ботом, который "говорит то, что нельзя".

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

Они в своём роде первопроходцы (первые из глобально популярных), потому им приходится нести это бремя и перестраховываться, порой до абсурдности.

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

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

Тогда бы разрешали гуглить.

Почему все собеседования построены именно на решении задач на время, как будто набирают в спецназ?

Потому что это более зрелищная клоунада, к тому же куда более понятная гуманитариям, чем реальная работа программиста.

Information

Rating
4,497-th
Registered
Activity