При том же я ни разу не видел, чтобы сроки требовали сразу же при постановке задачи.

Значит, вы ни разу не работали напрямую с заказчиком - мелким/средним бизнесом и частниками. Потому что срок идёт в прямой зависимости от стоимости проекта. А стоимость им нужна ещё до заключения договора. Той же кафешке за 5 т.р. автоматическая умная предлагалка соуса на сайте не помешает, а за 100 т.р. - не, дорого.

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

Одно из отличий профессионала от дилетанта - умение планировать свою работу, в том числе и по времени.

Как раз таки одно из отличий профессионала от дилетанта в том, что он осознаёт все потенциальные подводные камни и их влияние на сроки. И то, что срок - это не цифра, а вероятностная шкала.

Это у дилетанта - "будем считать, что одна кнопка это один час работы. 80 кнопок = 80 часов = 10 дней".

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

• Сначала я попробую простой(наивный) подход и это займёт день.

• Если он не сработает - тогда второй, более сложный, и это будет неделя.

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

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

Нет, конечно, можно себе вообразить программиста, у которого достаточно мозгов, чтобы помнить и в уме мгновенно компилировать сотни мегабайт кода и наперёд знать, что именно и как будет работать, а что - нет, но такой человек бы сейчас торговал акциями на Уолл Стрит, а не сайтики кафешкам бы делал.

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

Потому что это, блин, IT-разработка.

Настроить уже готовый функционал - минутное дело. И часто он уже есть в каком-то виде.

А если его нет или попробовал, но он не подходит? Тогда нужно посмотреть, что есть из готовых библиотек или подобного функционала. Это уже часы/дни.

А если нормальных готовых библиотек нет или попробовал и не подходят? Тогда нужно свой код писать, а это уже дни/недели/месяцы.

И как это всё обозначить одной цифрой ещё до начала работ? Да никак. Да и после начала, на любом этапе вплоть до завершения, никогда нет 100% гарантии что ты "уже почти сделал" и твой подход не тупиковый и всё не придётся переделывать с нуля. Поэтому на такие вопросы и не любят отвечать, ни разработчики менеджерам, ни одни менеджеры другим.

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

Нейросеть на присланных картинках тренировали *пожимает плечами*

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

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

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

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

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

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

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

Журналисты также провели похожие опыты с более продвинутой 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+ уже не ровен час самому стать тем самым "больным родным", за которым сам же и ухаживаешь. А тут уже с понятием "график сна" придётся попрощаться в некоторых случаях.