Конечно, бумажка не обязательна. Да и универ не обязателен. Вообще, обязательного в нашем мире не так много, как кажется. Просто всё имеет свои последствия, приятные или не очень.
Я говорю о том, что это может помочь настроить своё мышление определённым образом.
Один из способов / инструментов достичь определённого понимания, при условии наличия хоть какой-то мотивации (но про мотивацию — это само собой разумеющееся).
Прелесть наличия подобной практики в университете для меня как раз в том, что человек сам собой таким редко занимается, это требует определённой толики мазохизма, а "в универ ходить вроде как надо" (если присутствует соответствующее воспитание), и — особенно про ВМК — это вроде как "место престижное", и вам сквозь некоторый дискомфорт приходится этим заниматься.
(Конечно, тут исключается человек абсолютно сознательный, коих процентно существенно меньше, кто уже в свои 17-18 понимает чётко, чем он хочет заниматься, как он хочет этим заниматься, какой университет/институт ему нужен, или что ему это вообще не нужно, и потом ни разу не жалеет о своём выборе. Такие ребята сами всеми силами пробьются к своей цели, потому никакие доп.стимулы им не нужны.)
Потом уже можно осознать определённую пользу от этого подхода. Да, кому-то, вроде вас, это не требуется, кому-то, вроде меня, это оказалось очень полезным.
Но если спросить и меня, и вас во время экзамена, хотите ли вы на бумаге писать, или нет — оба ответят "нет" :)
На мой взгляд, если по существу "претензий", то везде есть правда (и в мнении автора, и в совокупном мнении комментаторов).
Я очень благодарен тому, что, поступив на ВМК (МГУ) в 2010-ом, всё ещё попал на проверочные работы и экзамены по программированию, когда код надо писать на бумаге. Это дало мне ценнейший опыт "прорабатывания кода в голове", "думать как интерпретатор/компилятор" и т.д. Не знаю, практикуют ли они сейчас по-прежнему такой формат — но "пожалуйста, да".
А потом, когда я пошёл работать, я начал понимать, что информации становится очень много, и я не хочу свою "оперативную память" забивать процессами, которые мне сейчас не нужны.
Со временем, как мне кажется, я научился держать в голове то, что мне сейчас нужно, и всё лишнее оставлять на "я знаю, где посмотреть".
А вот умение тщательно въедаться в код не пропало, очень помогает при ревью, как своего кода, так и чужого.
И я рекомендовал бы практиковаться так тем, кто испытывает сложности в фундаментальном понимании того, что вообще происходит в программе. Так бывает, люди разные, в программирование пришли по-разному.
И немного больше про мой взгляд на собеседования...
Давно не ходил по собеседованиям, но мне кажется, если бы пошёл — стоял бы на том, что держать в уме все нюансы нецелесообразно (да, даже если в коде встретилась дичь, которая на самом деле работает совершенно не так, как думаешь: ты в любом случае привыкаешь к "хорошему коду", если "стремишься к лучшему", и любые необычные решения должны вызывать желание проверить, как оно работает внутри, если уж ты не помнишь).
И, проводя собеседования, никогда не упираюсь в то, помнит ли человек сигнатуру функции и т.д. Вообще, я стараюсь вычислить его умение мыслить и желание развиваться и писать хороший код, нередко мне вообще не нужно человека напрягать какими-то решениями каких-то типовых задач. Я считаю, что собеседование — это тоже немалое искусство, и нужен персональный подход (во всяком случае там, где компании могут себе это позволить).
И, скажем прямо, описанную в топике проблему я бы вычислил на стадии код-ревью, достаточно быстро. Ничего даже страшного, если бы такой сотрудник прошёл собеседование и начал у нас работать. Иногда лучше всего понятно, что за человек, уже "в боевых условиях". Во всяком случае, мне обиднее упускать потенциально ценного кандидата, чем отбраковывать по причине того, что ему некомфортно, скажем, на бумаге код писать.
У нас в ревью участвует минимум 3 человека. Всех приглашать? Кроме того, как можно сделать ревью кода, оторванного от проекта, подскажите? Стайл гайд и автоматические средства проверить могут.
Достаточно одного, человеку же нужно мнение о своём коде. Даже об участке кода можно многое сказать, не только про код-стайл — тут вам и время жизни переменной, и удачные наименования, и удачное разбиение на методы, например. С той же архитектурной точки зрения. (Вон как Макконнелл завещал.)
Сам участвую в собеседованиях, и сам был бы рад подобному вопросу, потому что, с моей стороны, важно видеть реакцию на возможную критику и конструктивные предложения. Как показала практика, не все кандидаты внезапно готовы к тому, что их код не будет принят "как есть".
В nakedip я бы использовал, скажем, grep -oP 'your_favorite_IP_pattern' — я не эксперт, но наличие в системе grep несколько более гарантированно, нежели наличие jq. Скажем, в стандартный base-пакет ArchLinux jq не входит.
Конечно, бумажка не обязательна. Да и универ не обязателен. Вообще, обязательного в нашем мире не так много, как кажется. Просто всё имеет свои последствия, приятные или не очень.
Я говорю о том, что это может помочь настроить своё мышление определённым образом.
Один из способов / инструментов достичь определённого понимания, при условии наличия хоть какой-то мотивации (но про мотивацию — это само собой разумеющееся).
Прелесть наличия подобной практики в университете для меня как раз в том, что человек сам собой таким редко занимается, это требует определённой толики мазохизма, а "в универ ходить вроде как надо" (если присутствует соответствующее воспитание), и — особенно про ВМК — это вроде как "место престижное", и вам сквозь некоторый дискомфорт приходится этим заниматься.
(Конечно, тут исключается человек абсолютно сознательный, коих процентно существенно меньше, кто уже в свои 17-18 понимает чётко, чем он хочет заниматься, как он хочет этим заниматься, какой университет/институт ему нужен, или что ему это вообще не нужно, и потом ни разу не жалеет о своём выборе. Такие ребята сами всеми силами пробьются к своей цели, потому никакие доп.стимулы им не нужны.)
Потом уже можно осознать определённую пользу от этого подхода. Да, кому-то, вроде вас, это не требуется, кому-то, вроде меня, это оказалось очень полезным.
Но если спросить и меня, и вас во время экзамена, хотите ли вы на бумаге писать, или нет — оба ответят "нет" :)
На мой взгляд, если по существу "претензий", то везде есть правда (и в мнении автора, и в совокупном мнении комментаторов).
Я очень благодарен тому, что, поступив на ВМК (МГУ) в 2010-ом, всё ещё попал на проверочные работы и экзамены по программированию, когда код надо писать на бумаге. Это дало мне ценнейший опыт "прорабатывания кода в голове", "думать как интерпретатор/компилятор" и т.д. Не знаю, практикуют ли они сейчас по-прежнему такой формат — но "пожалуйста, да".
А потом, когда я пошёл работать, я начал понимать, что информации становится очень много, и я не хочу свою "оперативную память" забивать процессами, которые мне сейчас не нужны.
Со временем, как мне кажется, я научился держать в голове то, что мне сейчас нужно, и всё лишнее оставлять на "я знаю, где посмотреть".
А вот умение тщательно въедаться в код не пропало, очень помогает при ревью, как своего кода, так и чужого.
И я рекомендовал бы практиковаться так тем, кто испытывает сложности в фундаментальном понимании того, что вообще происходит в программе. Так бывает, люди разные, в программирование пришли по-разному.
Давно не ходил по собеседованиям, но мне кажется, если бы пошёл — стоял бы на том, что держать в уме все нюансы нецелесообразно (да, даже если в коде встретилась дичь, которая на самом деле работает совершенно не так, как думаешь: ты в любом случае привыкаешь к "хорошему коду", если "стремишься к лучшему", и любые необычные решения должны вызывать желание проверить, как оно работает внутри, если уж ты не помнишь).
И, проводя собеседования, никогда не упираюсь в то, помнит ли человек сигнатуру функции и т.д. Вообще, я стараюсь вычислить его умение мыслить и желание развиваться и писать хороший код, нередко мне вообще не нужно человека напрягать какими-то решениями каких-то типовых задач. Я считаю, что собеседование — это тоже немалое искусство, и нужен персональный подход (во всяком случае там, где компании могут себе это позволить).
И, скажем прямо, описанную в топике проблему я бы вычислил на стадии код-ревью, достаточно быстро. Ничего даже страшного, если бы такой сотрудник прошёл собеседование и начал у нас работать. Иногда лучше всего понятно, что за человек, уже "в боевых условиях". Во всяком случае, мне обиднее упускать потенциально ценного кандидата, чем отбраковывать по причине того, что ему некомфортно, скажем, на бумаге код писать.
В
nakedipя бы использовал, скажем,grep -oP 'your_favorite_IP_pattern'— я не эксперт, но наличие в системеgrepнесколько более гарантированно, нежели наличиеjq. Скажем, в стандартныйbase-пакет ArchLinuxjqне входит.