Комментарии 201
Тут, мне кажется, интереснее другое - зачем вообще писать десктоп и мобилки на C++?
Потому что не в любом софте есть возможность платить за ГЦ и использовать память как не в себя( т.к. она нужна для другого )
Ну, у вас наверняка есть что посоветовать в качестве работающей альтернативы C++ для разработки современных компьютерных игр?
А чем вам C++ не устроил? Ищите лучше хороший компилятор, а не языки. Для C++ по крайней мере есть большой выбор редакторов кода, для всяких ржавчин и змей нет даже и этого.
А хороший компилятор — это какой?
Вот пусть и ответит человек выше на этот вопрос. Кому-то функционал подавай, кому-то эргономику.
Из Java-подобных компиляторов мне больше понравился Eclipse, но там даже 0,7 коньяка едва ли хватит, чтобы разобраться.
Из С/С++/С# поработал с плагинами для Visual Studio, но предпочитаю больше CodeGear 2009 и ему подобные компиляторы с 5-оконным интерфейсом. Засовывать всё в одно окно, как делают это современники - крайне ущербная тактика.
У меня есть много претензий к C++. Но дело не в этом.
Человек выше написал комментарий в стиле "Да не нужон этот ваш С++". Вот я и спрашиваю - а чем его заменить во вполне конкретной области.
Unity с C#. Хорошо работает, кстати.
Rust
Почему-то я не раз за разом от вас читаю о ужасных падениях в С++ от любого чиха, но в моём продукте этого нет. Может мы что-то делаем не так?( например, используем квалифицированных разработчиков, а не джунов с курсов "с++ за 21 день" )
Значит, у вас софт не падает, а тихо портит память, что ещё хуже
Такие вещи нельзя адекватно прикрутить к языку пост-фактум, язык надо изначально создавать с ними в уме.
Интересно, и как это вы себе представляете конкретно для C/C++? Может изначально нужно в стандарте для разработчиков компиляторов ещё прописывать, чтобы интегрировали статические анализаторы, а то программисты совсем не внимательные стали? Вот очень интересно узнать, ответьте, пожалуйста.
"Интересно, и как это вы себе представляете конкретно для C/C++?"
Вы серьёзно меня спрашиваете, как я представляю себе вещи, которые по моему же утверждению не существуют? Никак не представляю.
К чему тогда все ваши притензии? Может тогда это только вы плохо знаете основы программирования и просто невнимательны?
Если вам так нравится Rust, то пишите только на нём. Он же компилируемый, а следовательно на нём можно всё что угодно писать. На черта вы всем вокруг пытаетесь навязывать свои предрассудки как религиозную догму?!
Да мне абсолютно всё равно, кто он здесь. Даже если он копипастил чужие мануалы по написанию драйверов, то это далеко ещё значит, что он сам написал хотя бы один реально рабочий драйвер.
Хатаб больше сделал для общества, чем ваш @0xd34df00d, который даже псевдоним человеческий не мог сочинить и прикрывается адрессацией.
"К чему тогда все ваши притензии? Может тогда это только вы плохо знаете основы программирования"
Вполне возможно. В конце концов, я уже давно пишу очень мало кода, который бы запускался.
"и просто невнимательны?"
А вот это не «возможно», а абсолютно точно так. Я про себя знаю, что я невнимателен, забывчив, могу писать код не выспавшись, могу встречаться с чужим кодом, где я понял не все детали, и так далее.
Занимательно. Невозможно успеха в работе, если не умеешь расслабляться, с одной стороны. И при этом вы словно ничего не пытались изменить - с другой.
Тут уже скорее выбор инструментов под себя, нежели поиски каких-то "идеальных языков программирования", языки лишь способ изложения, программу создаёт уже компилятор.
Я не спорю, что именно вам полезны инструменты статического анализа, всё таки лучше всего они справляются именно с опечатками.
С другой стороны лучше уже привить себе привычку писать код разборчиво, чтобы его изначально было удобно читать. Тоже и касается и редактора кода - если бы мне пришлось работать только на Visual Studio, то как минимум в первую очередь я сделал плагин, который возвращает классическое выделение и напрочь убрал цветное выделение, кроме классического зелёного для препроцессора и директив компилятора и синего для значений констант. Наблюдать постоянную ЛГБТ-подсветку, которую ещё трудно отключить, во всём исходнике довольно утомительное удовольствие.
Тоже и касается и редактора кода - если бы мне пришлось работать только на Visual Studio, то как минимум в первую очередь я сделал плагин, который возвращает классическое выделение и напрочь убрал цветное выделение, кроме классического зелёного для препроцессора и директив компилятора и синего для значений констант. Наблюдать постоянную ЛГБТ-подсветку, которую ещё трудно отключить, во всём исходнике довольно утомительное удовольствие.
Наверное, это субъективно, но если будет слишком мало цветов, текст будет одного цвета или, наоборот, цветов будет слишком много, то будет тяжело ориентироваться по тексту. Предположу, что для каждого "мало" и "много" свои (вообще видел пользователя в интернете, который писал, что отключил полностью подсветку синтаксиса в своём редакторе и пользуется минимумом плагинов).
Тексты комментариев и статей во всём Интернете всегда одного цвета. Но это не мешает ориентироваться по заголовкам.
Когда же весь текст у тебя как Новогодняя Ёлка, украшенная довольно безвкусно, то это неизбежно утомляет при его чтение, а выделяет мало или зачастую там, где это не имеет смысла.
Такие вещи понимаешь из опыта, может кому-то это более интересно, поэтому я больше за кастомизацию плагинами, а не тупо "поставим пользователей перед фактом, у них всё равно нет другого выбора". Выбор есть всегда, нужно просто уметь его найти.
Но я всё ещё мечтаю встретить внимательных сверхлюдей, которые не делают ошибок в проектах больше, чем на два часа. Спросил бы у них про их секрет.
Всё очень просто. Доверие.
Когда вы пытаетесь искать везде только изъяны, то неизбежно становитесь заложником своих же предрассудков и постепенно, но неминуемо превращаетесь в параноика.
Программирование подобно течению. Для того чтобы подчинить его своей воли, нужно ему поддаться. И для начала перестать скрести по сусекам и выбрать что-то конкретно определенное.
Ваша самая большая ошибка, в том что вы исчите изъян в инструменте, когда вся ваша речь один большой синтез и не может иметь строго одного определения.
Воззразите: А что с этим делать?
Достаточно ответить только на один вопрос: "А что ожидают от программы, кроме того, чтобы она делала то что от неё требуется и не выводила из себя её пользователя?"
Что и называется, "работает без нареканий".
Здесь и отличие хорошего программиста от плохого. Хороший программист уже по привычке следует негласным правилам хорошего тона, плохой такой привычки ещё не имеет. Хорошо, когда хотя бы стремятся подражать, плохо - когда человек находит любое удобное объяснения своему равнодушию.
Но я всё ещё мечтаю встретить внимательных сверхлюдей, которые не делают ошибок в проектах больше, чем на два часа. Спросил бы у них про их секрет.
На практике такие секреты, скорее обычные профессиональные привычки, которых у вас ещё нет.
Тут всё зависит от того, что подразумевается под ошибком в данном случае.
Умение видеть картину объемно вырабатывается ещё на первых курсах технических вузов. С другой стороны и гуманитариев обижать не стоит, профессионально это называется зуммирование, когда вы смотрите на ситуации не из момента "здесь и сейчас", а в более общем плане, чётко представляя что вы сделали до этого по сравнению с тем, что было до вас.
Если хотите инструментарии, то очень советую обратить внимание на более профессиональные программы трейсировки. На Хабре есть статья "24-ядерный CPU, а я не могу сдвинуть курсор", где наглядно представлена практика работы с такими программами. Я так же с этим работал, когда разбирал выбесшие меня "Системные прерывания" на планшете с Windows 10 - несколько минут в Google, предложили подобную программу от MSI, с помощью её понял, что ОС не могла запустить драйвер встроенной графики и конфликтовала с ним. Дальнейший путь меня привёл к тому, что оказалась проблема в сильно костыльном несовместимом UEFI (он был жестко завязан на Windows 8) - теперь ожидает, когда у меня появится снова программатор, чтобы уже окончательно разобраться с этой проблемой.
Было бы очень интересно услышать об этих привычках. Что конкретно стоит взять на вооружение?
Например, логической привязки имён функций и переменных с внутренней логикой модуля, в котором они используются. Очень хорошо это отражено через имена стандартных функций и STL.
Не буду лгать. Очень трудно читать ваш код, он не сложен по структуре, а именно лишен всякой логики в связке с модулем.
Как изменения в нейминге могли бы помочь найти висячую ссылку?
Изменения в нейминге сделают код значительно более удобочитабельным, что позволит проще понять его свежим взглядом. И следовательно проще будет найти алгоритмическую ошибку, приводящую к появлению высячих ссылок, утечек памяти и прочих подобных ситуаций.
Такие вещи самособойразумеющиеся и представляют элементарное здравомыслие при написание любой программы.
как можно было бы его существенно поменять, но это следующий вопрос.
У вас проявляются все симптомы сильного профессионального выгорания. Тут скорее поможет хороший психолог, чем мои консультации - только вы и люди, с которым вы непосредственно близко общаетесь, знают ваши настоящие мотивации, никто в Сети не сможет вам дать эффективный рецепт для работы над собой и повышения самооценки, не более чем намекнуть, надоумивают обычно либо близкие люди, либо друзья, либо коллеги, либо как раз психологи, которые придметно консультируют.
Да ё-моё, спрашиваешь у явно опытного в продакшен-разработке человека советов по тому, как бы улучшить код, а тебя в ответ к психологу посылают :(
А как ещё помочь человеку, который потерял веру в себя?
Посоветовать действовать решительней и не воспринимать неоконченную документацию как истину в последней инстанции? Или ещё изложить басню о том, что делать какие-то свои доработки, пусть и только в оформление - это вполне нормальная практика, и в ней нет ничего непристойного?
Не понимаю, почему бы конкретно не сказать на простом и достаточно мелком примере на 50 строк кода.
Я ещё в 2014-м отказался от этой практике на форумах, когда такой приём использовался только чтобы без слов сказать "сделайте всё за меня".
Обычно такие элементарных исходят из того, чтобы можно было только по одним именам функций и их параметров легко определить что они делают, в рамках объекта или модуля в целом.
Если вам этого не достаточно, то разберитесь с форматами данных, которые получаете, и которые выдаёте в конкретных функциях, и уже значительно легче будет понять что с ними делать.
Я открыто и со словами говорю «покажите, сенсей, какие практики и как в этом коротком, годящемся в учебные примере надо применить, чтобы улучшить код».
Мне неинтересно решать задачки за других, ясно. Лучше киньте тогда что-то более полезное, например затык в полезном специфическом софте. Вот там помогу решить.
"А как ещё помочь человеку, который потерял веру в себя?"
Какую веру в себя? Я всего лишь не верю в собственную абсолютную внимательность (как и в абсолютную внимательность любого другого программиста). Если вы верите, что вы можете 100% времени быть 100% внимательным, то, ну, тут уж я не знаю, что сказать.
Да вы по всему топику о себе много рассказали. Языки вам какие-то не такие. Тестирование для него какое-то не такое. Отлаживать за 10 лет не научился, а скорее всего там и года не было.
Ещё и накидываетесь на других, мол, какие-то не такие. Руку сначала набейте в отладке, тогда и поймёте что вам даёт C, а следом C++.
Ну вот это был затык в полезном специфическом софте.
Нет, это был вылезанный из пальца кусок из специфической библиотеке со спорной полезностью, притащенный вдобавок за уши.
сказать по существу
"80% работы программисты - это отладка, но даёт она только 20% результата. Однако без отладки невозможно 80% функциональных возможностей любой программы. Если вы хотите добится успеха, вы должны сначала добиться успеха в отладке."
В работе я пологаюсь на принципе логики Хоора - это привычка доведенная до автоматизма, как слепой ввод в любой современной клавиатуры. Вот и всё, что вы хотели узнать.
Для программ на C и C++ сепарационная логика выглядит более разумным выбором, так как они на Хоара ложатся не очень хорошо. Как и почему вы обходитесь Хоаром?
Потому что логика Хоара - это не избирательность, а соответствие форматов входных и выходных данных. Такой подход изначально создавался для упрощения тестирования при разработке, в ряде случаев разница затраченного времени достигала в 10 раз.
Архитектуры вычислительных машин изначально строились из этой логики: "у нас определенное число бит", "мы производим с ними заранее определенные операции", "на выходе получаем тоже определенное число бит".
Нужно понимать, что С изначально создавался с тем, чтобы обеспечить гибкость ассемблера, чем подкупил программистов, и там нет определения "корректное поведение".
Само понятие "правильное" или "определенное поведение" (defined behavior) не более чем задуманное не вызывающее нареканий программистом поведение программы, описываемое понятным для вычислительной машины двоичным кодом.
Ваш ночной кошмар "неопределенное поведение" (undefined behavior) описывается более порядочным "нежелательные побочные эффекты", о чем иногда говорят в справочниках, но не заостряют внимание. И правильно делают, так как если сильно оберегать программу от любых "внешних мешательств", то можно и огрести неприятный feedback от опытного пользователя, которого не устроило, что разработчик посчитал его за дурака.
Частный пример - современные драйвера. Пользователи глубоко заблуждаются, когда говорят, что драйверы от современного железа не совместимо с операционной системой ниже Windows 10. На самом деле даже в файлах установочных конфигураций прослеживается, что ограничение сильно искусствено. При чем не на уровня кода sys-файла, а чисто нескольких строчек в inf-файле. Скоро буду как раз разбирать такой кейс, может напишу об этом статью на Хабре.
Понятное дело, что выстрелить проще ( за это мы его и любим ). Просто приличной замены для его области применения пока что нет.
Rust, потенциально, может ею стать когда будет достаточный набор библиотек и решатся нынешние проблемы с выпиливанием проверок границ в llvm. Хотя, при попытках отказаться от копирований и переалокаций памяти проблемы с UB в rust начинаются ничуть не хуже плюсовых. А то и забористей, учитывая меньшее количества накопленного опыта с ним. По сути по одному rustonomicon и приходится навигировать
… решатся нынешние проблемы с выпиливанием проверок границ в llvm
А вот про это можно поподробнее?
Сейчас по какой-то непонятной причине все проверки границ внутри контейнеров rust остаются внутри бинарника, даже если компилятор точно должен видеть какие значения может принимать индекс.
Т.е. если не использовать слайсы, то можно огрести от того, что проверки с вызовом panic! будут торчать по всему коду и довольно заметно мешаться в кеше
https://godbolt.org/z/PoWxcrMcG
И обойти это можно только рассыпав повсюду грабли
`unsafe { ..get_unchecked() }`
вот, приблизительно тот же код на C++, где clang снова не выпилил проверки границ https://godbolt.org/z/8vqaGPb8e
Извините, но вы какой-то максимально неубедительный пример привели. Во-первых, тут можно поменять условие проверки, чтобы не проверять длину, а именно что получать слайс нужной длины:
pub fn foo3(data: &[i32], count: usize) -> i32 {
// if count >= data.len() {
// return 0;
// }
let data = match data.get(..count) {
None => return 0,
Some(data) => data,
};
let mut res: i32 = 0;
for i in 0..count {
res = res + data[i];
}
return res;
}Во-вторых, можно не использовать индексы вовсе и написать код для суммирования идиоматично, как бы это и выглядело в реальном проекте:
pub fn foo3(data: &[i32], count: usize) -> i32 {
if count >= data.len() {
return 0;
}
// let mut res: i32 = 0;
// for i in 0..count {
// res = res + data[i];
// }
// return res;
data.iter().sum()
}Что первое, что второе изменение полностью убирают проверки границ.
И, кстати, даже в C++ вы можете использовать range-based for loop (доступный с C++11):
int foo2(std::vector<int>& data, size_t count) {
if(count >= data.size() || count < 0) {
return 0;
}
int res = 0;
for (auto x: data) {
res += x;
}
return res;
}, который тоже проверки границ убирает.
В последних двух ваших примерах (раст и С++) проверки компилятор не "убирает" - их просто там изначально нету.
Добавлено: А в первом примере кстати логика поменялась. Там у автора был что если `count == data.len()` то всё равно вернуть ноль. Не знаю специально или случайно.
В примере на C++ с range-based поменялась логика - теперь суммируются все элементы.
И я специально указал "если не использовать слайсы", потому что в том коде, где я на это наткнулся, слайсы использовать возможности нет
ГЦ не тождественен "использованию память как не в себя", ровно как и использование C++ не гарантирует отсутствие тормозов.
А куда еще применить знания плюсов в 2022г? Жирный эмбеддед разве что.
ну пишите компиляторы не на с++ :) никто же не запрещает.
Ну как же "не было"? Хаскель же появился еще в начале 90-х, уж V8-то (2008 год) могли бы на нем написать! Да и UE тоже. И о чем они только думали, все эти разработчики...
Ну ничего, зато сейчас можно, наверное (ведь можно, да?) Да что там - конечно, можно! Я от кого-то слышал (не помню от кого), что там и инлайн-ассемблер есть теперь, так что точно можно. Правда, ассемблер штука такая: одно движение - и готово убэ, от которого земля налетит на небесную ось.
Отсылка к инлайн-ассемблеру толстовата, попробуйте тоньше.
В следующий раз обязательно попробую :)
Просто есть такая интересная тема, что если вам интересны условные плюсы (или JS), то вы, скорее всего, ещё не ковыряли хаскель. А если вам интересен хаскель, то вам уже неинтересен JS.
Мне просто неинтересно заниматься RIIx, так что работаю с тем, что есть с использованием того, что для этого требуется, вот и все.
Отсылка к инлайн-ассемблеру толстовата, попробуйте тоньше.
Я целую статью написал ради отсылки
начальная реализация раста была почему-то написана на том же окамле
С "небольшими" вкраплениями LLVM (собственно, они до сих пор никуда не делись), который написан... На чем же он написан?... Никак не вспомню :)
начальная реализация раста была почему-то написана на том же окамле, а не на плюсах
OCaml считается наиболее удобным языком для построения компиляторов.
Ну, а на чем например писать антивирус, или софт для устройства gps-навигации, которое должно работать днями от двух батареек AA?
На Rust
Который использует бэкенд LLVM, который написан на C++. Огонь.
что malloc и linux kernel не существует? =)
Во-первых, лично вы при этом не пишете на C++, существенно сокращая поверхность кода, которому нельзя доверять.
Rust хороший язык, но в вашей фразе есть какая-то доля самообмана. Что значит нельзя доверять? Linux, Windows, Mac, PostgreSQL / MariaDB / sqlite / mongodb, nginx, haproxy, LLVM, Unreal Engine / Unity, TensorFlow и миллион другого супер важного софта написаны на C/C++. Это же не мифические гномы в вакууме пишут, вполне себе обычные разработчики, и как-то же они это пишут так, что я без головной боли все это использую.
Что значит нельзя доверять?
Напоминает один очень меткий комментарий:
"Я не люблю C++, потому что он не позволяет мне писать говнокод".
Что сказать, в остроумие автору не занимать.
Сколько видел подобной критики, но ни одного конструктивного предложения в ответ.
Ваши примеры выглядят как "систематическая ошибка выжившего". На C/C++ написано 98% всего критичного в мире разработки софта, логично, что в нем находят ошибки. Так-то можно сказать, что в этом году критический уязвимостей на языках Pascal и Пролог не найдено, значит, с ними все ок.
Go вон тоже был весь из себя такой безопасный, но как докер начали использовать везде, так и уязвимости поперли.
Да, в некоторых языках сложнее делать ошибки, в некоторых проще. В rust действительно делать ошибки сложнее, чем в плюсах. Но в мире плюсов для этого есть тесты, санитайзеры, ворнинги как ошибки, статичекие анализаторы, код-ревью и т.д. Если процессы в компании выстроены нормально, то и языковых ошибок почти нет.
в 2009-ом ещё и модерн С++ толком не было, другие языки что вы перечислили тоже вряд ли были. Ошибка в коде на Си, и вы зря инронизируете, она вызвана недостатком абстракций. Так устроена ОС, которой лет ещё больше, что аргументы приходят в формате argc/argv. Соответсвенно где-то это реализация должна быть. И такую же ошибку можно было бы допустить где угодно, если неправильно понять что первый аргумент может быть нулл (или в чём там ошибка). Например её можно совершить при реализации библиотечной функции getArgs в хаскель (кстати проверте на всякий случай что там - выглядит немного подозрительно - но я хаскель не знаю). Но, были бы абстракции, парсинг аргументов происходил бы только один раз в стандартной либе, вместо того чтобы делать его в каждой программе на си. Это позволило бы выявить уязвимость раньше, и исправить её сразу у всех. Но у polkit всё сложнее, потому что эта утилита должна со всеми этими аргументами, переменными окружения, fork/exec работать достаточно много, т.е. получается это и есть аналог стандартной библиотеки для управления политиками безопасности. Кроме того, выбор си может быть обусловлен тем, что надо предоставлять си-интерфейс чтобы polkit можно было использовать из других языков.
Гетопт не сильно лучше, да и вообще не то наверное.
Сишный интерфейс можно предоставить, но тогда у вас в коде будет значительную часть занимать конверсия из/в си, и гарантии языка будут завязаны на эту конверсию. Так что для небольшого кода профита мало.
Зы. Что там хаскель код глянули? Я там проверку на argc != 0 не вижу.
Добавлю насчёт гетопт. Вообщем смылс того кода в pkexec, чтобы перезаписать argv[0]. И вряд-ли либы стандартные в языках дают такую возможность. Уже объект к нам придет из языка, а нужен сырой указатель.
Ок, проверка в `peekArray` есть, это хорошо. Я быстрым гуглением только `getArgs` посмотрел и там было вот это `p - 1` и сразу advancePtr подозрительное.
Насчёт FFI, то что его объявить легко это один вопрос, но другой вопрос что у вас указатели продолжают гулять по коду до момента преобразования в `[String]`. Т.е. уже после этого есть какой-то профит от высокоуровновсти языка, до этого это всё ещё код для связи с Си.
считать кривой
Stringвы сможете, а вот записать в него — уже нет иммутабельность же.
Это замечательно, но по ТЗ как раз надо записать, о чём я и говорил.
Нет такого ТЗ.
Ок, можно было скопировать в новый массив и передать его в execv.
В C и C++ ещё со стародавних времён argc не может быть равным 0. Обычно 1, так как первым параметром всегда передаётся путь к исполняемому файлу.
Если в кратце то это выглядит так:
void main (int argc, char* argv[])
{
if argc>1 {
cout << "Вы передали следующие параметры:/n/r";
for (int i=1; argc; i++)
{
//Выводим в виде нумерованного списка
cout << i << ".";
сout << argv[i-1];
cout << "/n/r";
}
}
else cout << "Я здесь: " << argv;
// argv == argv[0];
cout << "Число аргументов: " << argc;
scanf();
return 0;
} Итого 18 строк вместе с телом функции и комментариями.
В C и C++ ещё со стародавних времён argc не может быть равным 0.
а теперь сходите по ссылке на уязвимость polkit, ну и можете ещё в стандарт Си/Си++ заглянуть если хочется, или POSIX.
Сначала потешное:
for (int i=1; argc; i++)— зачем сравниватьiсargc? Лучше написать бесконечный цикл! Который, кстати, довольно быстро вылезет за границыargv, что метаиронично в контексте этого треда.
Ирония, когда давно не брался за компилятор. Заигрался с SolidWorks в сборки, и вот пожалуйста. Ирония, в том, что отладчик сразу бы и указал на эту нестыковку - на Хабре же писал.
И к слову, хоть и правильно "\n\r", но последовательность более верная у меня. Переход на новую строку и возврат каретки, то есть курсора ввода в начало строки.
Вообще, вы очень зря уповаете на некоторую безусловную последовательность - многое от привычек зависит, однако манипуляции с курсором в консоли позволяли делать воистину феерические трюки, покруче всех ваших вебов вместе взятых.
Во втором
coutвнутри цикла (которыйargv[i-1]выводит) первая букца цэ не латинская.
Нет, там в английской расскладке всё написано. Видимо какой-то баг словил.
scanfобязана принимать форматную строку.
Нет, не обязана. Она просто ничего не запишет, но курсор ввода с окном удержит, а мне это и нужно в консольном приложение.
Сразу видно, что вы ни дня на реальном C++ не писали. Только хаять можете и не больше. Всё с вами решено, прощайте.
Да, в некоторых языках сложнее делать ошибки, в некоторых проще. В rust действительно делать ошибки сложнее, чем в плюсах.
Весь прикол в том, что если в C/C++ ты сделал ошибку, то её так же легко и исправить. Да и далеко не часто делаешь серьёзные ошибки - чаще весь хайп вокруг уязвимостей построен на потенциальных уязвимостях, а не лабораторий ESET, Антивируса Касперского, Dr. Web и прочих институтах, которые целиком занимаются исследования компьютерных вирусов и хакерских атак.
Граждан тут слишком утрирует ситуацию, мол слишком много об уязвимостях говорят (нет, это ты слишком мало читаешь что-то ещё), и теперь я не могу доверять ни одному языку программирования. Отсюда и все дикости с переписыванием стандартной библиотеки и прочий бред.
Серьёзные люди такими дикостями не занимаются. Так же как и давно переросли в себе комплекс перфекциониста, и не ставят себе вопросом жизни и смерти задачу написать идеальную программу с первого раза.
тут уместно вспомнить, что C++ использует стандартную библиотеку, которую на [стандартном] C++ написать невозможно, точно так же как C использует стандартную библиотеку, которую на [стандартном] С написать невозможно (по крайней мере, в обоих случаях — без UB). И что это значит?
Вы себя послушайте. Вся стандартная библиотека написана базовым синтаксисом языка, и представляет во многом обобщение раннего опыта разработчиков в рамках ещё C89, после дополненных в C99, и расширенных в С++ в 1998 году, и STL, на основе его же синтаксических конструкций, использующих самые продвинутые техники использования языка в 2002 году.
То что в них иногда обнаруживали выходы за границы массивов, переполнения регистров или краш из-за несовпадения последовательности (в данном случае процессор пытается обратиться к несуществующему адрессу) уже говорит о том, что сами современные программисты не соблюдают правила слишком часто, чем программисты поколением до них. Кому тут больше недоверия уже совсем другой вопрос.
Например, даже в C написать сколь угодно оптимизированный memcpy без совершения UB
Если мне нужно оптимизировать потоки и извлекать меньшие конфликты от ожиданий данных, то ещё с 2010-го года, со стандартами С11, С++11 есть атомарные операции.
Не говоря уже о том, что есть классические семафоры, мониторы и мьютексы, для особо критических случаев, помимо синхронизаций. Там порядочно добавили, на любой вкус.
А в других языках стандарта попросту нет, и malloc они используют в конечном итогое тоже из си. Получается безвыходная ситуация - ни одной корректной программы под линукс написать нельзя.
И винду и маком туда же, потому что они тоже C/C++. Чудом выживаем, можно сказать.
На языках там где больше управления на себя берёт рантайм писать легче - с этим никто не спорит. Только надо отделять мух от котлет, т.е. проблемы языка, и проблемы предметной области. Ну и ещё проблемы бизнеса, потому что времени возиться с "вашими" доказательствами у него нету.
Тот же електрон, тоже интересный пример. Потому что Javascript довольно отвратительный язык, но так исторически сложилось что в него влили много ресурсов и на сам веб движок и на кое какие либы и на подготовку кадров. В итоге получается отрасль с него слезть не может.
Вообщем там где выбирают електрон, там плюсы выбирать не надо. А там где выбирают С++, там выбрать Си+прувер не получается. Как-то так.
Идея хорошая, но не без проблем. Так, в rust уже год как не могут сделать сборку под последний NDK :(
На рынке не так много людей, кто хорошо знаком с Rust. А это один из главных критериев, который стоит учитывать, когда выбираешь язык разработки.
А зачем писать антивирус исключительно на С/С++? Понятно, что фильтр-драйвера придется писать на С, а всю бизнес-логику, какую-то машинку/анализ и особенно UI, можно писать на C#/JAVA и пр, преимущество в сокращении времени разработки.
софт для устройства gps-навигации, которое должно работать днями от двух батареек AA?
Для этой задачи да нужен низкоуровневый язык, но если убрать требование к энергоэффективности, то JAVA/C# опять же помогают просто удешевить разработку.
Парень, даже не вступай в дискусс с этими бывшими торгрвцами бананами. "Стань программистом за пол года"... Вот они пачками и становятся. Это щелевое сознание, сформированное рынком, API Windows/Linux не про них. Оконная процедура? Не, не слышали, а чё ета? Там рулит PHP. А то что браузеры, серверы, интерпретаоры PHP и JS, операционные системы, драйвера, прошивки их/не их рутеров и опорного кольца, и прочее, и прочее, чем они каждый день с утра до вечера пользуются, написано на С/С++/assempler грамотными людьми - это для бывших торговцев бананами несущественная мелочь. Они, кстати, вряд ли догадываются, что сегодня и бэк-енд в высоконагруженных вещах часто пишется именно сями. Гыыыы))) Ета ж пепсикольная братия, они акрамя <html></html> ничего не знают, а полвина даже не понимают, что это обозначает, зато программисты, однако...
Фидбэка не дождался
а вот это, мягко говоря, хамство
Мои личные фавориты, по степени приятности собеседований (в алфавитном порядке):Про Kaspersky нет в статье. Собеседование было раньше 2021?
- Joom
- Kaspersky
- Network Optix
Мне менеджерам всех компаний хочется воззразить лишь одним словом: "Вы либо крестик снимите, либо трусы наденьте". Что это за цирк Шаппито?! Они что там все совсем джуна нанимают?!
Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся, и ограничился только общими вопросами по условиям работы, остальное - покажет только испытательный срок.
Тоже касается и опыта. Тут нужно просто задавать вопросы, а не слепо надеятся, что в резюме всё опишут в подробностях. Был у человека опыт в коллективе, не был - не столь важно, однако если подразумевается что кандидат будет работать в уже существуюшем (!) коллективе, то достаточно спросить об предыдущем коллективе в общих чертах, отношение в целом к коллективу и даже если у человека это первыф коллектив за много лет, то тут нет никаких поводов для отказа. Скорее это подсказка о том, кто с вами (менеджером) будет чаще общаться, а кто предпочитает работать без лишнего внимания.
Если же коллектив молодой или еще формируется, то когда оцениваете возраст кандидата, оценивать стоит его на должность выше или как самого опытного сотрудника среди них и организовывать работу соответствующим образом.
Не все пилят что-то для себя или опенсорса
Возможно, но это в любом случае намного лучше, чем терпеть этот цирк Шаппито. По крайней мере, если у человека есть уважение к себе и своей профессии, то найти 2 часа и написать одну программу он точно сможет.
у большинства нет на это ни дополнительных сил, ни времени. Семья и отдых дороже.
Если человек ищет работу, то у него точно найдётся и время, и вдохновение.
Мой личный рекорд — 8 этапов-собеседований в течение 1.5 месяцев в яндекс (после такой хрени, я к ним больше ни ногой), прошел из интереса, но пока это все проходило, у меня 4 менее интересных офферов сгорело, одно из которых мне очень понравилось по команде
Мне очень интересно кто тут больше дурак: вы или они? 1,5 месяца на собеседование - это же ещё деградировать до такого уровня надо. Не топ-менеджера же они выбирали, ни директора филиала.
Вот только за 2 часа вы в лучшем случае напишите крохотную утилитку
А я где-то говорил об обязательно больших программах? Или где-то, как тут некоторые прикручивали, про open source? Нет, ни единого слова.
Цитата:
Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся, и ограничился только общими вопросами по условиям работы, остальное - покажет только испытательный срок.
Вы поступаете очень невежливо в отношение собеседника, когда пытаетесь приплетать к нему того, что он никаким образом не имел ввиду. Подумайте над этим ещё раз перед тем, как писать свои отговорки.
Написанная за два часа маленькая программка в данном случае разработчика "раскроет" лишь частично - вам все равно нужно будет выяснить, писал ли он ее сам, а не подсунул ли чужую, насколько глубоко его знание используемого стека, а не сделал ли он херак-херак копипастой со стековерфлоу, владеет ли он технологиями, которые нужны для проекта, но не были затронуты в его "маленькой программке", способен ли он к дизайну архитектуры, что в маленькой простенькой программке не продемонстрировать почти никак.
Маленькая программа как раз показывает всё что именно нужно, если вы её не просто читаете, а ещё слушаете прекрасную басню о том, как кандидат её создавал.
Маленькая часть неформальной работы, которую приходится делать каждый день. А мне оно и нужно - всё что вы подразумеваете под профессиональными качествами, не более чем привычки, которые видно даже невооруженным глазом. Талант, как говорится, не пропьёшь.
Вопросы честности, манер, стиля работы и всего остального, что выделенно курсивом как раз прекрасно покажет кандидат за время испытательного срока.
О, и не волнуйтесь, я не увольняю человека только за то, что он приукрасил своё резюме. Мне не важно как человек сделал программу, написал с нуля или адаптировал свои или чужие предыдущие наработки, куда важнее, чтобы работа производилась в приемлимые сроки и проходила ряд требований во время тестирования, то есть программа работала без нареканий.
И для справки: Испытательный срок длится всего 21 день. Эмпиречески уже давно определенный период времени, за который человек сможет как минимум влится в коллектив, а заодно понять всё что ему необходимо. Увы, идеальных компаний здесь не бывает.
Для упращения работы бухгалтерии его обычно назначают кратным 1 месяцу, 3 месяца - это максимальный срок установленный ТК РФ. Вопрос "Кто кого тут обхитрил?" уже риторический, бывает люди назначают бесплатные стажировки, с чем я в корне не согласен. Если человек только набирается своего первого опыта работы в коллективе, то его труд всегда должен оплачиваться.
Тем более учитывайте, что умение писать небольшие, но полезные программы, куда больше говорит о программисте, чем писать только большие проекты, где далеко не ясно насколько он был в авангарде, а насколько перекладывал свою работу на других.
Например, я использую короткие кейсы для того, чтобы разобраться в новых для себя инструментах. Сейчас, по иронии судьбы, мне нужно перебрать 170 ГБ информации из 60 с лишним тысяч медиа-файлов, из которых полезных фотографий только 24 ГБ. Вручную уйдёт на это годы, а нужную программу написать на понравившемся компиляторе займёт не более чем 2 часа, даже с нормальным оконным UI.
Да, для программистов этот навык очень важен и необходим, но в наше время он не является достаточным - в зависимости от специфики проекта и его прикладной области существует еще очень много вещей, которые должен знать и уметь разработчик, и которые вы не проверите "небольшой программкой" вообще никак.
Только вы одного не учитываете. Я беру кейсы на основе реальной практики, а не каких-то псевдофилософских предположений, как вы.
По одной вашей манере речи можно судить какой вы специалист. Вам бы уже давно только на этом основание указали на дверь. Может вы забыли, но мы говорим не о начинающих, а об уже сформировавшихся специалистах.
Например, вам нужен синьор,
Я и без вас знаю, когда нужен сеньор, а когда прекрасно справится мидл. Ни у меня, ни у моих коллег нет традиции усложнять себе работу, спасибо.
Или вам нужен человек, хорошо разбирающийся в написании интерпретаторов скриптовых языков с JIT-компиляторами
Вряд ли в таком вообще возникнет необходимость. В инженерии, где я работаю, и в более зрелых коммерческих областях предпочитают опираться на более зрелые и документированные стандарты, нежели выдумывать велосипеды на каждый чих.
найти 2 часа и написать одну программу он точно сможет.
Я пишу код в день от 4 до 12 часов (в зависимости от кол-ва совещаний и трат на менторинг), иногда подряд, а рабочий день обычно начинается в 9 утра и заканчивается в 19-20 часов вечера. Вы меня извините, но мне хочется проводить свое свободное время с семьей и изучением различной литературы в других интересных мне областях, и в целом за решением других проблем, которых тоже не мало, и на которых тоже никогда не хватает времени. Если у вас так много свободного времени, что вы можете себе это позволить, то ваше право, но я себе это УЖЕ позволить не могу. Я люблю свою работу и программирую уже более 11 лет, за это время я разработал (один или в команде) предостаточно, как поделок разной степени качества, так и коммерческих сервисов, и показывать их на собеседовании не намерен (одни просто слишком стары и просты/говнокод старых времен, или NDA), потому что ни одну из них не запускал уже много лет. Если мне приспичит делать что-то для опенсорса, то это будут или мои эксперименты по работе, которые мне ПОЗВОЛЯТ выкладывать, или если у меня на это появится время/желание (возможно потенциально коммерческое), но никак не необходимость. Чтобы оценить мои навыки, можно меня о них спросить, и вы не поверите, но большинство компаний это устраивает. Я достаточно регулярно меняю работу (1-2 года), и проблем с выбором компаний у меня нет, у меня все мессенджеры и ящики ЗАВАЛЕНЫ предложениями о работе, хотя везде написано, что я не ищу работу, и стоит мне открыть этот кран, как уже Я могу выбирать, куда хочу. Так в прошлом году, я за 2 недели прошел около 25 собеседований за пару недель отпуска и получил более десятка офферов в достаточно хорошие компании. В общем рекомендую вам попробовать походить по собеседованиям, чтобы убедиться в том, что там где на «техническом фильтре» стоят не hr'ы, а нормальные тех. специалисты, проблем с определением уровня кандидата не возникает.
И более того, лично я часто делаю выводы о компании по тому, как мне представляются, коммуницируют, какие задают вопросы и как отвечают на мои вопросы, а если мне с порога предлагают потратить мои выходные на создание условно какой-нибудь игры на javascript в вакууме, причем без оплаты моего времени, когда я уже далеко не джун, то я воспринимаю это как факт неуважения моего рабочего времени. И чем больше люди будут отказывать в подобном бреде, тем лучше будут фильтры, так я думаю
P.S Для особо буйных уточню. Я не утверждаю, что тестовые задания бесполезны, они хороши, если они:
а) достаточно короткие и хорошо раскрывают какие нибудь базовые аспекты понимания тех или иных инструментов, чтобы по этим решениям можно было опросить потенциального сотрудника, это может ускорять опрос (если задавать нормальные вопросы о глубине реализации, то можно выявить потенциальных лжецов, которые не сами делали задание)
б) если их используют для проверки к примеру ребят, которые идут в стажеры и джуны, потому как их ОЧЕНЬ много приходит (к примеру на одном из моих собеседований в Яндекс, мне рассказали, что на первых двух этапах заканчивают собеседовать под 80% кандидатов, а их приходят сотни), и более 90% отсеиваются (по моему личному опыту), если с каждым сажать для собеседования нормального специалиста, это будет большая трата времени (а за это часто, о ужас, нужно еще и доплачивать, т.к это часто делается вне основного рабочего времени), и то я в данном случае тоже за небольшие домашние задания на пару часов максимум, если человек понимает, что делает, он может управиться и быстрее…
В общем рекомендую вам попробовать походить по собеседованиям, чтобы убедиться в том, что там где на «техническом фильтре» стоят не hr'ы, а нормальные тех. специалисты, проблем с определением уровня кандидата не возникает.
А я изначально думал, что хотя бы за уважительный тон смогу поблагодарить. Знаете в чем ирония? С вами сейчас и беседовал технический специалист, прошедший только за прошлый год 15 собеседований за 2 месяца при смене места работы.
Но увы, вы слишком часто делаете выводы из глупых предположений. А спросить явно вам либо ума, либо совести не хватило. Жалкое зрелище все ваши отговорки, которыми вы оправдываетесь на том, о чем не додумался всего лишь спросить.
Вы слишком грубы, когда предписываете собеседнику что он никаким образом не имел ввиду. Я ни слова не говорил ни про open source, ни про большие программы. Хватило бы короткого полезного вам кейса, может исходник рабочей программы созданной вами, который скорее всего я потребовал только прокомментировать и рассказать о том через что вы прошли, чтобы его создать. Даже более скажу, вы бы сами охотно так и поступили.
Также никто не мешает спокойно использовать наработки из ранее написанных проектов. За NDA никто вам слова не скажет - попробуйте ещё доказать факт его нарушения. А стучать сам на себя - сами знаете как это выглядит.
Настоящие технические специалисты с хорошим образованием никогда не строят выводы только из предположений, как минимум об этом делают замечание, но, повторю, никогда не аргументируют свои слова таким грубым способом. Как минимум, это проявление неуважения к собеседнику.
И для справки: На более высоких должностях интересуют далеко не базовые вещи, а то что всегда остаётся в глубине. Нельзя построить нормальных отношений с сотрудником, который неуважительно относится к своей профессии, и тем более, если он не уважает даже себя.
Вы читать вообще умеете? Я предлагал адаптировать код, использовать наработки из прошлых проектов, а не публиковать. И никто публиковать это в свободный доступ тут не собирался.
Цель собеседования определить уровень синьерности. Если проходит - определить уровень лидовства. Если нет - смотрим сможет ли на мидла (джуна). Какие задачи будет решать никто не знает. За 2-3-4-5 недель всё может поменяться. Нужно чтобы человек мог впечатывать тысячи строк кода в месяц и дебажить неочевидные multithreading service oriented architecture. Нужны рок-звезды или хотябы звездочки. Человек может не писать код дома, а Кормена решать или Кнута. И вообще человек может быть с мат-кафедры, а не информатики или программной инженерии. Главное мозги, а не зубрежка.
"Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся"
Это вообще как? Давайте подумаем.
<...>
Вот и получаем простую ситуацию: я уже полтора десятка лет профессионально программирую, у меня большой послужной список проектов, во всех компаниях, где я работал, моей работой были довольны и коллеги, и руководство, и заказчики - а показать код я не могу. И таких как я тысячи. Что будем делать?
Сделайте любительский проект, чисто для души, который не стыдно показать другим - это более чем достаточно. Одно только его наличие в резюме уже сильно вас выделит. Оправдывать себя мифами о неком "большинстве" больше походит на откровенное инфоцыгантство, чем слова компетентного человека.
Сделайте любительский проект, чисто для души
Классная логика. В вашем мире после основной работы строители все как один возводят любительские небоскребы, хирурги делают любительские операции, дальнобойщики ездят в любительские рейсы. Так, чисто для души. А кто отказывается - сразу вон из профессии.
А как вам другой вариант - знакомитесь с человеком, он говорит "я художник, очень люблю рисовать, 10 лет уже работаю художником", вы просите его показать свои рисунки, а он "не могу, все что рисую - рисую для работы, а они показывать запретили", согласитесь несколько странно звучит?
Опять же, это не значит, что кто-то должен что-то делать в свое свободное время. Это, лично для меня, говорит о том, что работа для такого человека - это просто работа.
Соответственно, в какой-то критической ситуации (например, на проекте 100 багов на проде) - человек будет абсолютно спокоен - "мне задачи на исправление этих ошибок никто не ставил - какие вопросы?"
Опять же, человек по своему прав, но вот мне, человеку который не равнодушен к своей работе (и я хочу, чтобы проекты, над которыми работаю были качественными), работать с такими очень неприятно.
Нет ни малейшей связи между пет-проектами и способностью вытаскивать ситуацию из задницы.
Ну и логика тоже классная. Я не сомневаюсь, что вы способны написать в коде тысячи хитрейших валидаций, чтобы ни одни корявые данные не пролезли в БД. Но когда дело доходит до людей, то все валидации низводятся до одноклеточных: "Если есть пет-проект, то мужик работящий. А если нет, то человечек с гнильцой - кинет нас на аврале".
Это же уровень шуток про бабушек у подъезда: "Если в миниюбке - проститука, а если с наколками - нарокман"
Если есть пет-проект, то мужик работящий. А если нет, то человечек с гнильцой - кинет нас на аврале
Вы глумитесь. Наличие пет-проектов показывает, что человеку не лень в свое свободное время позаниматься программированием. Из чего следует, что программирование ему скорее всего нравится. А из этого следует, что его качество кода будет получше, чем в среднем. Опять же, код на github позволяет проверить, так это или нет.
А если человек говорит, что:
Свободное время, выходные дни и отпуска я провожу со своей семьёй и близкими мне людьми - с любимой женой, с родственниками, с друзьями.
То это как бы намекает, что написание кода для него - просто работа. А это уже другое отношение. И если ему за это не платят - то у него есть занятия и поинтереснее.
Опять же, с точки зрения обычного человека это абсолютно нормально. Но есть люди, которым с кодом приятнее проводить время, чем с друзьями, девушками и т.д., и вот таким людям выявить себе подобных можно только через пет-проекты с открытым кодом.
P.S.
Меня вообще поражает, как в среде программистов много людей, которые хвалятся тем, как им плевать на программирование, и что в свободное время у них есть дела и поинтереснее. Я вот ни разу не слышал про гонщиков, которые бы говорили "хорошо в отпуск съездил, ни разу за руль не садился". Вроде бы как обычно стремятся к тому, чтобы и работа и хобби были одним и тем же делом.
Я вот ни разу не слышал про гонщиков, которые бы говорили "хорошо в отпуск съездил, ни разу за руль не садился"
Вообще мимо. В гоночное межсезонье большинство гонщиков отвисает на яхтах и лазурных берегах. Все "гоночные" активности только в рамках промо и прочих контрактых обязательств. Механики и инженеры тоже проводят время с семьями, т.к. потом с марта по декабрь им мотаться по всему миру.
И уж точно никто (кроме Алонсо) не бежит гоняться "для души" или проводить питстопы "для души" сразу после основной гонки уикэнда. Потому что все понимают, что есть время работать и есть время восстанавливаться. На юношеском максимализме можно выиграть спринт, но не марафон.
Вообще мимо.
Конечно, конечно, и знаменитому Шумахеру начали платить с 5 лет, когда он уже начал участвовать в гонках:
Карьера гонщика началась для Михаэля Шумахера с вождения карта, построенного его отцом Рольфом, бывшего управляющим местной трассой картинга. Шумахер сел за руль в возрасте четырёх лет, в пятилетнем возрасте участвовал в гонках на картах.
А без оплаты он конечно же за руль бы даже и не сел. Вот еще, участвовать в гонках только потому, что просто нравится.
Таки да :) Ну, т.е. представляем себе ситуацию, когда шумахер приходит на собеседование, а его сначала полтора часа мучают вопросами по типу "а с какой стороны педаль газа?" и "как оптимальнее всего переключать скорости в автомобиле, если у вас вместо рычага переключения скоростей - спагетти". А потом говорят "ну, вы вроде нам подходите, но чтобы убедиться в том, что вы умеете водить - пожалуйста, запишите на камеру, как вы катаетесь по треку 8 часов подряд" :)
Из чего следует, что программирование ему скорее всего нравится. А из этого следует, что его качество кода будет получше, чем в среднем
Знаете, я вот смотрю на тот код, который понаписан у меня на проекте и думаю: "а ведь его писали те, кто по вечерам пишет пет-проекты". А он такое же гавно, как и везде. Хорошие куски написаны когда было много времени, плохие - когда было мало) Безотносительно людей. Ведь, внезапно, есть код-ревью и код-стайл)
А вообще - мне непонятно откуда следует качество кода в пет-проектах. Качество кода может расти только при регулярном кодревью. В пет-проектах ты просто закрепляешь привычки (плохие и хорошие) , не более.
Я вот ни разу не слышал про гонщиков, которые бы говорили "хорошо в отпуск съездил, ни разу за руль не садился".
Я вот ни разу не слышал про работников АЭС, которые дома строят себе маленький ядерный реактор. Что это доказывает? Правильно. Что все аналогии ложны.
Когда ты вынужден сталкиваться с кодом, который ты писал 5-10 лет назад (или даже полгода назад) — это тоже учит
Чему? :) Тому что за 5 лет технологии шагнули вперёд? Тому, что оказывается можно было написать иначе? Ну тык всегда можно написать иначе.
За эти 5 лет ты всему научился на работе, смотря на чужой код и давая другим посмотреть твой. А пиля в тихой комнатке свой пет-проект единственный плюс, который можно извлечь - это потрогать какую-то технологию, знание которой вполне вероятно может понадобиться в другом месте. Это действительно плюс, но в целом, не так чтобы великий. Практически в 100% случаев плохой код возникает не от того, что кто-то не знал внутренности библиотеки Х.
Скажем так, от пет-проекта у меня только одно ожидание - я его заброшу через неделю :) Мои прогнозы очень точны в этом.
Если я уж и пишу дома какую-то программу/скрипт, то из расчёта, что она нахрен никому не сдалась и пользоваться ей буду в лучшем случае я, в худшем - никто.
Поэтому и код там соответствующий :)
Соответственно, в какой-то критической ситуации (например, на проекте 100 багов на проде) - человек будет абсолютно спокоен - "мне задачи на исправление этих ошибок никто не ставил - какие вопросы?"
Опять же, человек по своему прав, но вот мне, человеку который не равнодушен к своей работе (и я хочу, чтобы проекты, над которыми работаю были качественными), работать с такими очень неприятно
Спасибо за приятные слова. Зрите прямо в корень! Если бы мог поставить плюс и комментарию, и в карму то уже бы это сделал.
Мне далеко до маститого специалиста, но свой гит в резюме указываю. Хоть своим кодом не доволен, да и вряд ли его кто-то будет смотреть с пристрастием.
Другое дело, что если в процессе собеседования выясняется, что будущий начальник ожидает каких-то сверхурочных активностей (а иначе не тру-программист), то руководство там будет барин-стайл. Это когда просчеты менеджмента ложаться на плечи разработчиков, а поощряют вместо денег всяким барахлом.
Надо из такого места валить поскорее, можно рыбкой в окно)
В общем, я за програмистский кураж, но только если он добровольный.
Мы многогранны — поэтому естественно, что наша жизнь разделена между массой разных занятий. Например, самые крутые теор.физики, с которыми я общался, и в походы ходили, и на музыкальных инструментах играли, и по два неродных языка знают (не то, что мы тут).
Когда-то и я относился к миру таким образом, а людей воспринимал лишь как функцию, которую они выполняют в моей жизни. Меня это всё привело к лютой апатии и бессмысленности бытия.
В какой-то момент я осознал, что мысль о том, что занятие любимым делом - это самое важное в жизни - полная херня, самый большой обман во вселенной. Когда я перестал зацикливаться и стал интересоваться вещами, которые объявил для себя неинтересными - жизнь стала намного лучше. Когда женился - совсем хорошей)
Так что я рад за тебя, если тебя устраивает жизнь в которой ты только и делаешь, что занимаешься делом. Просто это вариант не для всех, я бы даже сказал он вообще мало кому подходит)
Меня это всё привело к лютой апатии и бессмысленности бытия.
А у меня наоборот. Как только я дистанцировался от людей, перестал беспокоиться о том, "что подумают княгини Марьи Алексевны" и начал заниматься только тем, что мне нравится, я стал гораздо счастливее. Все люди разные, кто-то пишет код 8 лет только на работе и счастлив, а кто-то пишет его 35+ лет, даже нигде не работая (потому что интересно), и тоже счастлив. Каждому свое.
Когда я перестал зацикливаться и стал интересоваться вещами, которые объявил для себя неинтересными - жизнь стала намного лучше. Когда женился - совсем хорошей)
Не забывайте про надпись на кольце царя Соломона :)
И это тоже верно, я понимаю, о чем вы говорите. Но тут есть деталь - даже в этой песне собаку все-таки сосед отравит, то есть другой человек, а к самой собаке вопросов, как правило, нет, собаки - довольно искренние по отношению к человеку существа. Если же на месте собаки будет человек, то он сам, вполне добровольно и с песней, отравит кого угодно, а в первую очередь - вас :) Так что против собаки я не против (C), я вполне способен защитить ее от соседа. А вот защищать человека фактически от самого себя я не в состоянии, да и не нужно мне это.
Не забывайте про надпись на кольце царя Соломона :)
Если речь о библейском персонаже, я бы к нему вообще прислушиваться не стал. Тот еще был человек)
Как только я дистанцировался от людей, перестал беспокоиться о том, "что подумают княгини Марьи Алексевны" и начал заниматься только тем, что мне нравится, я стал гораздо счастливее.
Так, а я разве говорил что-то про княгинь? Никто не мешает положить болт на каких-то там княгинь и общаться с людьми, которые интересны.
Я скорее о том, что когда в твоей жизни появляются люди, на которых тебе не наплевать, то так уж случается, что рано или поздно возникает конфликт интересов. Моя позиция в том, что нет ничего страшного в том, чтобы иногда отказаться от своих хотелок в пользу другого человека, на которого тебе не плевать. Нет ничего страшного в том, чтобы измениться. Я считаю сильно преувеличенной драму вокруг потери собственного я.
Проблема тут в том, что дистанцировавшись от всех, нет шансов, что у тебя появятся в жизни люди, на которых тебе искренне не плевать. Вот это состояние, когда мне плевать на всех - вызывает у меня депрессию и апатию, меня оно грустит намного больше невозможности заниматься тем, чем хотелось бы.
Если речь о библейском персонаже, я бы к нему вообще прислушиваться не стал.
По моему личному опыту мысль о том, что "все проходит, и это тоже пройдёт" оч правильная.
Моя позиция в том, что нет ничего страшного в том, чтобы иногда отказаться от своих хотелок в пользу другого человека, на которого тебе не плевать.
Ну дай-то бог, чтобы это действительно происходило лишь иногда, и не прогрессировало со временем в ситуацию, когда уступки, во-первых, односторонние, а, во-вторых, постоянные. Такое происходит, опять-таки по моим личным наблюдениям, слишком уж часто.
По моему личному опыту мысль о том, что "все проходит, и это тоже пройдёт" оч правильная.
Закон сохранения энергии против этого правила) Мне лично больше по душе думать: "всё проходит, но ничего не исчезает". Так, как оно всё сегодня через 10 лет точно не будет, и через 10 лет мои отношения с женой и друзьями будут не те. Фактически и я буду другой, и все остальные. Можно сказать сегодняшние мы будем давно мертвы. Это вообще не повод отказываться от сегодняшнего дня.
Такое происходит, опять-таки по моим личным наблюдениям, слишком уж часто.
Я уже попадал в такие отношения. И успешно из них выбрался. Причём дважды - сначала я многим жертвовал, затем ради меня многим жертвовали - оба случая оказались плохими, но баланс между ними существует. В это обычно оч тяжело поверить, а уж тем более тяжело найти такого спутника по жизни, но опять же, эта сложность - для меня не оказалсь поводом отказываться от поисков совсем. Могу понять, тех, кто решил забить, сам пробовал, но как оказалось, лучше периодически ошибаться, чем жить по сути только для того, чтобы работать.
чем жить по сути только для того, чтобы работать
Поправка: жить для того, чтобы заниматься тем, что тебе нравится, а не идти на бесконечные уступки другим людям. Я развлекаюсь тем, что пилю код и правлю баги в опенсорце, но вполне мог бы путешествовать (я честно пробовал, но, приезжая куда-либо, я точно так же сидел в номере, пилил код, по вечерам ездил на пляж или гулял, но все то же самое я могу делать (и делаю), никуда не уезжая, так что я забил), ходить на яхте, рыбачить, скалолазить, да что угодно. Главное - это заниматься тем, что ТЕБЕ нравится, а не жертвовать этим ради непонятно чего. Многим нравятся и отношения вот эти вот все, ну ОК, без проблем. Но когда есть ощущение, что ты чем-то именно жертвуешь ради непонятно чего - то мое ИМХО (подкрепленное жизненным опытом), что от этого надо драпать со всех ног.
Главное - это заниматься тем, что ТЕБЕ нравится, а не жертвовать этим ради непонятно чего.
Есть только одно жирнющее НО - количество вещей, которыми мне нравится заниматься существенно превышает время, которое я способен бодрствовать, вот и приходится жертвовать.
Согласен, что жертвовать чем-либо ради непонятно чего - это тупо. И я согласен, что от этого стоит бежать. Просто я лично вполне точно осознаю чем жертвую и ради чего))
Вопрос выбора цвета обоев, фильма на посмотреть под пиццу или что-то такое — это, конечно, ерунда
Вопрос выбора того, чем заниматься в долгосрочной перспективе — это уже куда серьёзнее.
Это причины, почему люди сходятся и расходятся, в общем и целом - обыденность. Драму из этого устраивать как-то не получается у меня.
Люди приходят и уходят, а твои дела с тобой навсегда.
В моей жизни, внезапно, дела менее постоянны людей. И это с учётом того, что за последние 5 лет я сменил 3 города и суммарно 5 переездов между квартирами.
Опять же, когда печально - дела не помогают, в отличии от людей. Так что, по итогу, ни дела, ни люди с тобой не остаются навсегда.
Это немного грустное состояние, но оно даёт силу и свободу.
Мне так не повезло. Лично меня это привело к жизни, когда я после рабочей недели приходил с работы, заказывал 4 пиццы и не вставал (кроме как в туалет сходить) с дивана все выходные. Вот прям вообще. Я даже не всегда смотрел телевизор. Просто иногда лежал в потолок смотрел. И так 4 месяца к ряду. В будние дни тоже не лучше, вставал в 8 утра, возвращался с работы в 22:00. Не потому что хотелось работать (да я и не работал особо после 19:00), а потому что не хотелось идти домой. Отпуск не помогал, путешествия тоже.
Если бы. Практика показывает, что далеко не из-за давления они это делают. Социальные сети сейчас давят на человека куда больше, чем любой самый что ни на есть эффективный менеджер.
Нормальный руководитель будет собирать команду по уникальным компетенциям и не будет нанимать 100 разработчика, который умеет вращать красночерное дерево, т. к. достаточно одного, максимум двух.
Я приводил практику, руководствуясь элементарным здравомыслием, и тем что прекрасно представляю, в чем состоит работа менеджера среднего звена. Сам же работаю на подобном должностном уровне.
Вариант, что люди после работы не работают вообще не рассматривается? Я вот 8 лет пишу коммерческий код и что-то не припомню, чтобы писал программы для себя. По крайней мере на С++. На bash/python ещё чет могу поавтоматизировать дома, но не более. Про опенсорс я вообще молчу. Играть в это благородство у меня нет ни сил, ни желания. У меня есть жена, есть друзья и есть другие интересы, помимо программирования.
Как по мне всё у человека прошло плюс/минус норм, хотя я бы на задание с TCP-сервером даже не стал бы время тратить, по крайней мере забесплатно. Писать код я умею, мне это никому доказывать не нужно, если кто-то не верит - могу прислать рекомендации с предыдущих мест работы. Обычно максимум на что я согласен - в real time немножко попрограммировать, не больше часа.
Как же мне, наверное, повезло, что я и на работе занимаюсь опенсорсом (Kotlin), так и в качестве пет-проджекта тоже занимаюсь опенсорсом, причем делаю существенные фиксы (ANTLR). Всегда будет что показать.
но оффер не делают, так как им показалось, что личностно (sic!) мне будет тяжело работать в их команде. Ок, правда на собеседовании задавались чисто технические вопросы, на которые я давал чисто технические ответы, личность вообще не обсуждалась.
Я проводил много-много технических собеседований и задавал только технические вопросы. Но при этом личность обычно видна достаточно хорошо. И были кандидаты, про которых я писал "у нас скорее всего не приживётся", хотя технические скиллы хорошие. Потому что манера речи, взаимодействие с незнакомым человеком, некоторые поведенческие особенности (например, неспособность признать ошибку или неспособность аргументированно и спокойно отстаивать свою точку зрения) порой видны вполне явно.
Если я вижу, что не могу с человеком наладить базовый контакт - я не хочу с ним работать, т.к. по работе общаться придётся немало. И это не говорит о том, что человек "плохой", просто он не вписывается в нашу (уже собранную) команду. Такое бывает редко, но бывает. Был яркий пример - у человека был мат через каждые несколько слов. Я не снежинка и вырос во дворе напротив воинской части, но... это был перебор. Да, мы и сами в работе иногда для красного словца упортребляем разные выражения, но не постоянно, через слова, когда вместо названия объектов и конструкций используются их матерные переиначивания. Иногда я даже не был до конца уверен, что именно хочет сказать мой собеседник и приходилось просить его более чётко формулировать мысль.
Другой вариант был когда человек напрочь отказывался признавать ошибку. Сначала аргументированно обсудили, как будет работать код - наши мнения не сошлись. Покопались, поняли что мы по-разному помним, как работает функция XX. Я знаю, что могу и сам ошибиться, поэтому предложил посмотреть что написано в стандарте (это было собеседование по С++ и функция из STL). Почитали, написано так, как я говорил и... челвоек сказал, что это старая версия стандарта. Ок, я предложил запустить в онлайн-компиляторе, компиль всё выдал в соотвествии стандарту, но... собеседник заявил, что в компиляторе баг. Я и сам находил баги в компиляторах (даже в актуальном clang было дело как-то), поэтому такой вариант не исключил - возьмём другой компиль. В итоге все проверенные компили (кажись clang, gcc и icc) работали ожидаемо одинаково. В общем, после некоторых препирательств я понял, что не вижу смысла тратить так много времени на бесполезный спор и двинулся дальше. И вот казалось бы, ну залупается чел, ну чего я придираюсь? Язык-то знает хорошо, алгоритмы понимает. А ответ прост - я не хочу потом каждую неделю тратить время на то, чтобы доказывать ему, что у него баг, а потом ещё и самому эти баги исправлять когда он откажется т.к. "у меня всё праивльно написано".
Что примечательно - с каждым из кандидатов общались строго по техническим вопросам, никаких личных или "о жизни". Оба были хорошими техническими спецами (не идеальными, но все люди чего-то могут не знать) которых точно бы наняли если бы не личностные черты.
Что примечательно - с каждым из кандидатов общались строго по техническим вопросам, никаких личных или "о жизни". Оба были хорошими техническими спецами (не идеальными, но все люди чего-то могут не знать) которых точно бы наняли если бы не личностные черты.
И это ещё хорошие специалисты? Боюсь представить, как выглядили плохие?!
Сочуствую, коллега. Многих повидал на своём опыте, даже близко не походили на изложенное. У нас таких равнодушних неадекватов ни то что на порог не впустили, впринципе ещё постаратся найти надо.
Ну тот, который матерился, работал несколько лет в гугле на позиции то ли Senior, то ли Staff SWE. Такими кандидатами не раскидываются, решили дать шанс (хотя HR ещё на скрининге отметила его "непривычный стиль изложения мыслей"). И технический спец он реально хороший, прям круто на вопросы отвечал и язык знал. А, забыл, он ещё посередине собеса начал просить закурить =) Это огонь был =)
Справедливости ради, такому человеку и предложить выпить не жалко. По опыту знаю, что в менеджменте нормальные доверительные отношения можно сложить только с людьми, которые как минимум неравнодушны к себе, и как следствие к своей работе.
Один из признаков профессионального роста - это умеренная самооценка.
Судя по нику вы раньше работали на Мотороллу?
Ронда или Тельма? Или в Питере?
Мои собеседования '2021 (C++ developer)