Поэтому умение аккуратно обозначить себя как потенциальную добычу для корпоративных браконьеров я считаю одним из наиважнейших soft skills специалиста в любой ценной области.
Да на любом конкурентном рынке умение продать важнее всего остального. Пусть даже продать себя потенциальным работодателям. Сегодня этот скилл действительно должен быть основным, если хочется карьеру программиста, конкуренция огромная. Как бонус, это избавит и от пузырьковых сортировок, ну и сама тема пиара и маркетинга должна быть интересна программистам.
А вот по поводу рыночного обоснования, если это не аутстаф и аутсорс, то компаниям все-таки выгодно удерживать работников как можно дольше. И они вполне могут платить гораздо выше рыночных денег тем, кто будет за это бороться. Опять же, все в руках работника, soft skills и все остальное.
Cassandra сравнима разве что с Riak и DynamoDB. А HBase по CAP это CP система, такие системы проигрывают AP системам по доступности, latency, и, соответственно, производительности, просто потому, что обязаны ждать консенсуса по каждой операции.
Спрос на разработчиков пока ещё огромный, а квалифицированных людей всегда нехватает. Если ваш уровень хотя бы чуть выше среднего, то без работы вы не останетесь…
Спрос не превышает предложения и вполне можно остаться без работы с любым уровнем.
Вообще работать 20 лет программистом это скорее исключение из правил, многим уже через 5-10 лет становится понятно, что надо уходить во что-то другое.
Какие глупости. Я помню когда я учился все до единого сдали экзамен по программированию на первом курсе с этими самыми пузырьками, включая людей у которых даже компьютеров не было. Думаю догадаетесь, что не многие из них могут работать на какой-либо специализации программиста. Это все-таки совершенно другие навыки.
Когда-нибудь поймете или нет, не знаю, знаю что некоторые жалеют со временем, что такими глупостями занимались. Но обсуждать тут это похоже бесполезно, да и все равно у абсолютного большинства этот процесс не излечим, особенно у аутсорса и крупных компаний. Там всегда практически кто попало будет набирать людей абы как, без малейшего понятия. Что и хорошо, так они талантливым командам конкуренции составлять никогда и не будут.
Я вам пытаюсь объяснить, что такие интервью вообще никак не коррелируют с уровнем разработчиков. Более того, вы понятия не имеете, какого уровня были разработчики, которых вы отсеяли, но смело предполагаете, что «нормальных» не отсеяли и еще и жалуетесь, что раньше «нормальных» было больше. Это называется survival bias, кстати, все наниматели им страдают. На самом деле проблема только в вас, в вашем понимании ситуации и в ваших процессах. Вы по сути отбираете только тех, кто вам нравится, но не тех, кто хорошие разработчики. И в этом нет ничего позорного, почти все страдают таким. Но хотя бы не стоит себя обманывать.
А что он будет делать, если у него в реальной работе вдруг случится дедлайн, или у крупного клиента выскочит крупный и срочный баг?
Сядет спокойно и будет делать, это же совсем другая ситуация. Или чужие люди тоже будут ходить наблюдать за ним и оценивать дальнейшую его судьбу каждый раз? Тогда такую работу никто не выдержит.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
нет ничего страшного, если вы нечаянно отсеете специалиста
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.
Нет, он не лукавит. Он может его написать дома. Сесть спокойно, вспомнить, написать код, написать тесты, выловить эдж кейсы и прочие прелести императивного кода. Но не с ходу, в незнакомой обстановке, под присмотром чужих людей, со стрессом, с кучей предубеждений в свою сторону по поводу внешнего вида, манеры общения и т.д.
Реальная разработка не имеет ничего общего с решением глупых задачек на листочках и уж наверняка никто из синьоров не практикуется в такой ерунде, потому чтобы пройти такие интервью им надо готовиться, как к экзаменам в институте. Но мало кто будет. Очень наивно думать, что вы хороших людей отбираете, в лучшем случае случайных среднестатистических, а то и вообще хуже среднего, но хорошо умеющих проходить интервью.
Но я так понимаю, что вам все равно, это какой-нибудь аутсорс или крупная компания, где и так все подряд сойдут.
Берите любой большой проект на Haskell или Rust и смотрите, дефектов там не меньше, чем у других. Формальная верификация такого кода тоже может заметно уменьшить их количество.
Просто причина совсем не в математике, причина в сложности, которой «земляне» могут оперировать. И если атаковать одну и ту же проблему двумя принципиально разными методами или на двух совершенно разных уровнях для подстраховки, то при вероятности ошибки 0,01 в каждой строчке обоих методов мы все равно снижаем вероятность одновременного присутствия ошибок в обоих до 0.01*0,01, т.е. до 0.0001. В этом вся суть.
Почитайте вводные статьи по TLA+/TLC/TLAPS, как раз из вашей области. Вот пример на TLA+, для проверки подобного отсутствия зависимостей, правда для снэпшотов.
Это формальность, данные хранятся в сортированных таблицах и их можно искать и по ним итерировать. Потому достаточно добавить timastamp или счеткик к концу ключа и получатся множественные значения.
Так эта «общая устойчивость» — тоже алгоритмы и их тоже можно верифицировать. Точнее даже в распределенных системах только их в первую очередь и имеет смысл верифицировать, сам Лесли Лампорт главный адвокат такого подхода с его TLA+.
Нам не интересна проверка корректности ради проверки корректности. Нам интересно избавление от проблем, вызванных дефектами и формальная верификация в этом далеко не самый надежный способ, не стоит заблуждаться. А лишь один из инструментов повышения надежности, причем довольно узкоспециализированный.
Формальная верификация — это совсем не 100% гарантия, что программа работает корректно. Это способ перепроверить программу лишний раз, анализируя ее в другой плоскости другим методом, тем самым выявляя дефекты и уменьшая вероятность не раскрытых дефектов. Но не стоит забывать, что пока этим занимаются «земляне», они в доказательствах тоже могут допустить ошибки, некорректные допущения и т.д. История самой математики знает далеко не единицы таких ошибок. Поэтому верификация позволяет уменьшить частоту дефектов в коде на один-два порядка, но не избавиться от них полностью.
Важно понять, что смысл не в том, чтобы избавиться от всех дефектов, а в том, чтобы найти какой-то подход, который позволит избавиться от многих дефектов минимальными усилиями с учетом современных реалий. Формальная верификация тут не пройдет.
Хотите сказать, что компилятор с теми -march=native -mtune=native для генту перепишет ваши интринсики? Нет, конечно, он может только другие инструкции сгенерить, но лэйаут тот же останется, а для конкректной архитектуры лэйаут не менее важен. Собственно в обработке изображений и видео можно наблюдать подход с получением CPUID в рантайме и выбором подходящей под процессор оптимизированной функции. Да и на ассемблере все, интринсики в этом не встречал, потому что хз что там компилятор в очередной новой версии начнет оптимизировать, а ассемблер таким и останется, ассемблер надежнее.
Если бы. Отойти подальше от конкретной архитектуры и уже нужен другой код. Те же x86 инструкции у разных интеловских атомов очень отличаются от не атомов и тот же код, что оптимально работал на хасвеле совсем не оптимален на атомах.
Да на любом конкурентном рынке умение продать важнее всего остального. Пусть даже продать себя потенциальным работодателям. Сегодня этот скилл действительно должен быть основным, если хочется карьеру программиста, конкуренция огромная. Как бонус, это избавит и от пузырьковых сортировок, ну и сама тема пиара и маркетинга должна быть интересна программистам.
А вот по поводу рыночного обоснования, если это не аутстаф и аутсорс, то компаниям все-таки выгодно удерживать работников как можно дольше. И они вполне могут платить гораздо выше рыночных денег тем, кто будет за это бороться. Опять же, все в руках работника, soft skills и все остальное.
Спрос не превышает предложения и вполне можно остаться без работы с любым уровнем.
Вообще работать 20 лет программистом это скорее исключение из правил, многим уже через 5-10 лет становится понятно, что надо уходить во что-то другое.
Когда-нибудь поймете или нет, не знаю, знаю что некоторые жалеют со временем, что такими глупостями занимались. Но обсуждать тут это похоже бесполезно, да и все равно у абсолютного большинства этот процесс не излечим, особенно у аутсорса и крупных компаний. Там всегда практически кто попало будет набирать людей абы как, без малейшего понятия. Что и хорошо, так они талантливым командам конкуренции составлять никогда и не будут.
Нет, извините, такие вопросы не касаются профессиональной компетенции. Это все не пересекается с реальной разработкой.
Сядет спокойно и будет делать, это же совсем другая ситуация. Или чужие люди тоже будут ходить наблюдать за ним и оценивать дальнейшую его судьбу каждый раз? Тогда такую работу никто не выдержит.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.
Реальная разработка не имеет ничего общего с решением глупых задачек на листочках и уж наверняка никто из синьоров не практикуется в такой ерунде, потому чтобы пройти такие интервью им надо готовиться, как к экзаменам в институте. Но мало кто будет. Очень наивно думать, что вы хороших людей отбираете, в лучшем случае случайных среднестатистических, а то и вообще хуже среднего, но хорошо умеющих проходить интервью.
Но я так понимаю, что вам все равно, это какой-нибудь аутсорс или крупная компания, где и так все подряд сойдут.
Просто причина совсем не в математике, причина в сложности, которой «земляне» могут оперировать. И если атаковать одну и ту же проблему двумя принципиально разными методами или на двух совершенно разных уровнях для подстраховки, то при вероятности ошибки 0,01 в каждой строчке обоих методов мы все равно снижаем вероятность одновременного присутствия ошибок в обоих до 0.01*0,01, т.е. до 0.0001. В этом вся суть.
Важно понять, что смысл не в том, чтобы избавиться от всех дефектов, а в том, чтобы найти какой-то подход, который позволит избавиться от многих дефектов минимальными усилиями с учетом современных реалий. Формальная верификация тут не пройдет.