Комментарии 403
Очень неплохой обзор. Сам ко всему этому пришел интуитивно, но было интересно почитать все это в четко сформулированном виде.
ИМХО, это полная хрень, а не обзор. Давайте честно признаемся. Рецепты не меняются:
1) Берем тему с кликбейтным заголовком
2) Выпячиваем и преувеличиваем все спорные моменты
3) Профит + завернули трафик на youtube канал
А каким в вашем представлении должен быть "хороший" обзор? В чём бы у него были ключевые отличия от текущего?
Я разве назвал это "плохим обзором"? Вроде бы я высказал своё мнение в других словах. Ну и вы серьезно? пытаетесь сделать меня субъектом в дискуссии, где задача предмета спровоцировать людей? Всё понятно, люди писали, старались, потратили время. Это конечно они молодцы, но их цели я не разделяю.
>Я разве назвал это "плохим обзором"?
Вы задаете этот вопрос, будто я приписывал вам слова про "плохой обзор". Но я этого не делал, поэтому отвечать на него не буду.
Подмена тезиса — логическая ошибка и один из демагогических приёмов, основанных на опровержении фиктивной точки зрения с целью обоснования другого утверждения.
>пытаетесь сделать меня субъектом в дискуссии, где задача предмета спровоцировать людей?
Это ваше мнение и ваши личные подозрения, однако не имеющие ничего общего ни с моими намерениями, ни с сутью мною вам заданного вопроса.
Ложная альтернатива, ложная дилемма — достаточно распространённый приём, основанный на приведении в качестве альтернативы двух вариантов из гораздо большего множества.
>Всё понятно, люди писали, старались, потратили время. Это конечно они молодцы, но их цели я не разделяю.
Вместо того, чтобы доказывать истинность своих положений и опровергать аргументацию оппонента, демагог может обращаться к приёму ad hominem — критиковать не аргументы, а личность оппонента, пытаясь убедить зрителей, что оппонент — плохой, недостойный, не разбирающийся в вопросе, пристрастный или лицемерный человек.
Бинго.
В одном своем коротком хабракомментарии вы собрали 3 из 9 самых распространенных демагогических приёмов: https://ru.wikipedia.org/wiki/Демагогия#
Дальнейшая дискуссия, видимо, смысла не имеет?
Ув. коллега, дискуссия изначально не имела смысла, т.к. Ваш вопрос был откровенно провокационный. Давайте формализуем подразумеваемое в нашем диалоге:
Мнение, что статья хрень, цель - запустить баттхерт у читателей и продать youtube канал
А как надо было написать, чтобы была не хрень и продать youtube канал? Критикуешь - предлагай
Высказывание мнения не обязывает к обратной связи. Ну и Вы серьезно хотите бесплатных советов для улучшения фастфудной статьи?
Вы демагог
WTF???
я бы формализовал вот так:
- кг/ам
- а как автору надо было раскрыть тему?
- чо ты привязался, мне не понравилось, и всё.
- ясно-понятно.
Вопрос не был провокационным. Он задан с использованием самых нейтральных формулировок.
Алексей не задавал его с позиции "Критикуешь - предлагай". Он лишь поинтересовался развитием вашего же мнения, которое вы высказали.
К обратной связи вас также никто не обязывал.
Интересно, конечно, вы написали. Только ложной дилеммы здесь нет, потому что вообще дилеммы здесь нет.
Человек задаёт вопрос, а вы пишете, что это его мнение. Вопрос это мнение?
Последний пункт вообще смешно (Только не надо писать, что смешно это субъективное эмоционально наполненное выражение и что то, что я сейчас написал в скобках, это тоже некая психологическая манипуляция). Человек написал короткое субъективное мнение не для объективного его доказательства, а вы никакой аргументации не проводили.
Вообще складывается ощущение, что это написала плохо обученная нейронная сеть, в которую вогнали паттерны демагогии или ещё чего-то.
>Интересно, конечно, вы написали. Только ложной дилеммы здесь нет, потому что вообще дилеммы здесь нет.
Есть несколько вариантов того, как можно трактовать мои слова, обращенные к автору того комментария. Например, воспринять обычный вопрос именно как обычный вопрос.
Но автор вместо ответа по делу захотел выбрать позицию, что я его хочу "подставить" и на этом начал строить все последующие обвинения и занял агрессивно-оборонительную позицию.
ИМХО, это полная хрень, а не обзор. Давайте честно признаемся.
И следом
Я разве назвал это "плохим обзором"?
Не совру, если скажу "да"
Плохой обзор можно критиковать конструктивно, предлагая улучшения для слабых мест.
А в случае полной хрени бесполезно спрашивать «что именно вы предлагаете улучшить, чтобы получилось хорошо» — здесь нужно выкинуть всё от формулировок проблемы до сборника рецептов.
полная хрень звучит как "плохой обзор"
упс, уже написали
Да, вы назвали это плохим обзором. Ваши слова: "имхо, это полная хрень, а не обзор".
Зря вы так. Правило#1: "Никогда не давать заднюю преждевременно". И себя дураком выставили, и перед собеседником в колени сразу кланятся.
это полная хрень, а не обзор
Я разве назвал это "плохим обзором"?
Бро))) Ну так нельзя...
Хоть кто-то сказал правду :-)
Ну так уровень статьи граничит с инфоциганством. Много гипертрофированных взаимоисключающих параграфов, большинство из которых можно свести к старому-доброму "только ситхи все возводят в абсолют".. на этом фоне Дарт Вейдер в заголовке статьи весьма доставляет )
Наверное, вы имели ввиду "это полная хрень, а не обзор, для меня".. Не могу назвать эту статью "полная хрень".. Это отличная статья, которая расскрывает и хорошо описывает разные случаи, когда человек может на самом деле может быть не подходящим кандидатом, но создать хорошее впечатление. Я как человек, который собеседовал людей в свою маленькую комманду - нуждаюсь в подобной статье, для личного роста.
Хайпанули тут Вы, мне кажется, а не автор.
"полная хрень, а не обзор" - когда уже научимся давать доказательства вместе с ярлыками? Автор все изложил логично и прозрачно.
"Давайте честно признаемся " - давайте честно признаемся, что вот эти три слова манипулируют читателем, подразумевая, что автор нечестен. Опять-таки без доказательтсв. Для двача сойдет, ага.
" Берем тему с кликбейтным заголовком " - месье когда-либо писал блоги или статьи? Ну или хотя бы читал какие-то работы про качественную журналистику? Да блин, любой хороший заголовок - кликбейтный. Извините что автор не использовал что-нить вроде заголовка газ. Правда брежневских времен.
"Выпячиваем и преувеличиваем все спорные моменты" - ой ли? А почему ж тогда книжка "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" содержит примерно те же fallacies? Там, в частности, пишут, что мол, граждане, не ставьте свое резюме вперед задач клиента и не развлекайтесь с новыми штуками тогда, когда они понадобились вам для резюме, но нахрен не сдались работодателю.
"Профит + завернули трафик на youtube канал" - какой ужас, наверное все остальные компании, ведущие тут блоги, никогда так не делали. Вот незадача.
когда уже научимся давать доказательства вместе с ярлыками? Автор все изложил логично и прозрачноДайте доказательство вместе с ярлыками «логично» и «прозрачно».
давайте честно признаемся, что вот эти три слова манипулируют читателем, подразумевая, что автор нечестен. Опять-таки без доказательтсв. Для двача сойдет, ага.Давайте честно признаемся, что слова «для двача сойдет» манипулируют читателем. Опять-таки без доказательств.
месье когда-либо писал блоги или статьи? Ну или хотя бы читал какие-то работы про качественную журналистику?Опять манипуляция.
любой хороший заголовок — кликбейтныйБездоказательно и даже противоречит наблюдаемым фактам.
Далее аналогично.
Вывод — людям не хватает зеркал.
Ого, "сперва добейся" подвезли, неплохо неплохо
Вылезла новость на мобиле в рекомендованых, решил зайти почитать,(мож быть что-то интересное и дельное пишут касаемо моей профессии? увы, нет) хабр как был помойкой так и остался, кроме бредятины и мусора ничего тут нет.
Стало быть, если программист не является хорошим спикером, то он обречён?
То он найдет работу в другой компании. Может даже так для всех будет лучше.
Не нужно быть спикером. Нужно уметь выражать свои мысли понятным языком и кодом.
У меня в команде был программист, которого сначала не хотели брать из-за "слабых софтскилов". Но на техническом собеседовании достаточно было копнуть чуть глубже чтобы понять что человек глубоко разбирается в программировании (уверенный сеньор). По факту были определённые трудности в коммуникациях с коллегами, которые легко разруливались лидом, но при этом задачи решались в срок и качественно.
Вот чтобы такое увидеть нужно быть одновременно и хорошим техническим специалистом, и понимать психологию.
У меня есть знакомый с синдромом Аспергера. Работает программером-фрилансером, судя по оплате далеко не идиот, письменная речь грамотна, но собеседование он не проходит, и не просто не проходит а вообще с личным общением у него катастрофа. Мне кажется все эти корреляции способности кодить и софтскиллов типа говорить, выглядеть, одеваться и улыбаться - максимум для нейронормальных людей с абсолютно стандартной типовой психикой, да и то не факт. Шаг влево, шаг вправо - и все эти првила превращаются в тыкву. Сугубо моё ИМХО
Стандартные HR набирают стандартных людей :) Уметь рассмотреть в сложном человеке бриллиант и понимать, как его внедрить в свою работу - это совсем не тривиально. Как есть люди, для которых какой-нибудь обычный бэк - это потолок, но кому-то же надо этим заниматься.
Может, вместо того, чтобы нанимать на HR девочек после школы, нанять человека, который способен чиатть код?
Чтобы не придумывать "100 способов узнать о навыках программиста не открывая его код"
Есть проблема - найти человека "который способен чиатть код" и который будет работать за рейт хрюшки после школы - сложно, если вообще возможно.
Это как сказать "Зачем нанимать непонятных студентов на работу, ведь. можно взять одного рокстара".
Не всем дано делать сверх работу. А кому-то дано, но еще дорасти надо. Любой HR начинает с простого и обычного, а там - можно вырасти и в прекрасного эксперта. Но может не получиться, ведь "Давайте наймем челвоека, который умеет читать код, а остальным не будем давать возможности расти".
А разве задача ХР не просто договориться о собеседовании и прояснить административные вопросы?
С каких пор ХР определяют квалификацию программистов?
С тех пор как на HR повесили первичный отбор из большого потока людей, когда есть несколько фильтров - поглядеть резюме, пообщаться по человечески, позадавать вопросы из чек-листа.
Про квалификацию - вопрос скорее в том, чтобы увидив человека с плохими софт-скилами, иметь в виду/понимать/быть обученным тому, что данный человек как кодер может быть хорош. А его могут отшить, т.к. он не прошел базовый фильтры текущего процесса отбора.
Вообще говоря, задача XP более высокоуровневая - оценить, подходит ли кандидат в существующий проект/команду или нет. Хар-скиллы, по-хорошему, должны быть за пределами его поля зрения.
Вообще говоря, задача XP более высокоуровневая - оценить, подходит ли кандидат в существующий проект/команду или нет.
Как эйчар может это сделать, если у эйчара нет ни малейшего представления ни о проекте, ни о команде? Даже in-house.
если у эйчара нет ни малейшего представления ни о проекте, ни о команде?
Если у эйчара нет ничего из этого списка, то это хрюшка-передаст, которая максимум с бумажками работать может, а никак не эйчар, чья задача - работать с людьми. И я понимаю, что такие - большая редкость, но тем не менее, за 20 лет в индустрии я видел парочку таких.
софтскиллов типа говорить, выглядеть, одеваться и улыбаться
Мне всегда казалось, что софтскиллы это про:
не переходить на личности в код-ревью
адекватно реагировать на конструктивную критику
внятно и вежливо выразить свою точку зрения
заранее оповещать начальство о смещении сроков
задавать вопросы когда не понятно, а не биться головой о стену часами и днями
правильно расставлять приоритеты в задачах
не греть рыбные котлеты в микроволновке
А как вам "софтскилл" писать гадости, но добавлять "))))" в конце, чтобы выйти сухим из воды? Хуже всего, что это работает.
наверное так и есть)) во втором пункте у вас правда есть термины "адекватно" и "конструктивную". Как показывает жизнь, они чрезвычайно субъективны и их диапазон не у всех людей совпадает.
"не греть рыбные котлеты в микроволновке" - один раз согрешил)) и жалел об этом ещё очень долго!
Так по первому пункту из этого "разбора" не пройдут большинство программистов, когда люди весь день в коде то болтология не про них
Я бы сказал несколько по другому
Если человек не является хорошим спикером, то он обречён.
Умение волочить языком это фактически самое полезное в жизни людей, к сожалению.
Умение казаться, а не быть, вот что позволит вам быть на волне успеха.
Ну да, ценой небытия.
Сильный афоризм.
Переформулируем:
Умение казаться, а не быть -
Вот, что позволит вам
Поймать волну успеха.
Ценой небытия.
Вы приняты. Но "ну да" стоит отрефакторить
Умение формулировать свои мысли - это не умение казаться
Я бы еще разделил устную речь и письменную.
По моим наблюдениям, "хорошо подвешенный язык" используется самостоятельно и к навыкам программирования не имеет ни малейшего отношения. В маркетологах или менеджерах такой скилл можно монетизировать более эффективно.
Я бы еще разделил устную речь и письменную.Вот тут двумя руками «за».
На письме есть время остановиться и подумать, перечитать уже написанное, поправить. Отрефакторить, так сказать. А в разговоре, и тем более выступлении на конференции, например, такой возможности нет.
Вот прямо в яблочко. Обычно много всяких балаболов лепят все подряд, а на практике оказывается, что в лучшем случае гугель или перевесить свои проблемы на другого
Я бы разделил умение удерживать внимание аудитории и умение объяснять. Под хорошо подвешенным языком чаще подразумевают первое, чем второе.
Умение волочить языком это фактически самое полезное в жизни людей, к сожалению.
Учитывая, что именно язык сделал человека человеком (а не дубина), сожаление непонятно.
Скорее всего, автор исходного комментария подразумевает сожаление о том, что в технических IT профессиях софт-скиллы сейчас ставят на несколько ступеней выше, чем хард. В этом я с ним полностью согласен, нельзя доводить требование наличия какого-либо навыка до абсолюта.
Сам же зашел в статью, только чтобы увидеть
компании ... предлагают порешать задачки
Это было первое, о чем я подумал, прочитав заголовок статьи. Очевидно и логично. Про некоторые нюансы взаимодействия участников процесса разработки внутри команд тоже было интересно узнать.
Сожаление в том, что этот инструмент сейчас является API с легаси накапливаемым тясчелетиями. И, как в любом легаси, в нем множество недочетов и бэкдоров, о техническом долге же вообще лучше не заикать. Но и отрефакторить это легаси не представляется возможность, ибо апаратная составляющая уже давно зафиксированна на эту, старую, версию. Да и совместимость очень важна.
А ведь было бы очень полезно отрефакторить часть API, которая предоставляет функционал управления другим собеседником через интонации, позы, и прочее. На даном этапе развития, я считаю, стоит сильно подрезать эти публичные методы.
Если программист не может сформулировать свои мысли на естественном языке четко, понятно и лаконично, то скорее всего и код у него так себе. И то, и то можно усовершенствовать, так что необязательно обречён.
Тут есть большая разница, что при программировании мы пишем код, многократно его рефакторим, реорганизуем, исправляем ошибки, и оценивают его уже по итоговому результату - то есть это ближе к письменной речи. Разговорная речь (спикерство) же представляет собой совершенное другое, она является real-time процессом без возможности остановиться, поревьюить сказанное, отмотать сказанное назад, переписать начало фразы или пару предыдущих фраз и продолжить.
Поэтому я вполне могу себе представить человека, который очень хорошо пишет код и тексты, но плохо толкает речи вживую.
Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
Поэтому я вполне могу себе представить человека, который очень хорошо пишет код и тексты, но плохо толкает речи вживую.
принимая во внимание то, что адрессатом такой речи обычно выступает человек, а программы пишутся в первую очередь для машин, вообще легко. конечно многим хочется впоследствии легко читать эти тексты вместо машин, но это уже вопрос отдельного обсуждения, вероятно
а программы пишутся в первую очередь для машин
Вот за это я и ругаю своих программистов. В первую очередь программы пишутся для программистов. Им потом этот программный код сопровождать.
А трудности перевода исходного кода в машинный меня мало волнуют - для этих целей умные люди придумали крутые инструменты.
Программы пишутся для тех, кто их будет эксплуатировать. А правильное проектирование любой вещи, должно предусматривать и возможную потребность в ремонтопригодности, а также просчитать реалистичный бюджет для поддержания работоспособности премета разработки. Кроме того предумотреть срок и условия эксплуатации предусматривающие замену проектируемого на что-нибудь другое и поставить об этом в известность тех, кто будет это эксплуатировать. Очевидно же.
Кроме этого, ремонтник, проектировщик и сборщик это разная специализация. Создание алгоритмов для решения задачи, перевод их на язык программирования и сопровождение программ - специальности разные. И способы подбора в команду этих людей тоже должны быть разными.
Те кто складно в realtime говорят - это наверное те Чак Норрисы, которые могут задачки типа medium и hard закодить на бумажке с 1й попытки)
Поэтому я вполне могу себе представить человека, который очень хорошо пишет код и тексты, но плохо толкает речи вживую.
А еще можно представить тысячи людей, которые хорошо толкают речь вживую, но плохо пишут... да простейшие тексты. Про код не говорю.
Даже в писательском ремесле и около ориентироваться на устную речь порочно и невыразимо глупо. А в IT это и вовсе странно.
И, кстати, написание текста на естественном языке тоже может быть "поточным". Причем чаще всего таковым и является. Даже если это поэзия. Тексты, где над каждым словом думают часами, получаются плохо.
Автору поста нужны спикеры или хорошие разработчики?
Ага. У меня экспромтная речь крайне плоха. Как и оперативный поиск аргументов. При этом мне легче изложить мысль письменно, упорядочив всё. Для спора и принятия решения здесь и сейчас это такое себе, но и код же пишется не сидя на сковородке.
И я тут подумал, нужно про почерк добавить. Ну а что? Плохой почерк - плохой программист.
Мне кажется мы скоро писать вообще разучимся, потому что ручку берем максимум пару раз в год чтобы каракулю в документе поставить. Какой почерк?
А в статье предлагается считать лучшим разработчиком того, кто вместо молчаливого изучения кода и перелопачивания документации выделяет время на практику краткой и понятной, емкой и точной разговорной речи. Причем не как с клавиатуры, когда можно спокойно обдумать, свериться, отредактировать, а в ходе живого диалога. Причем не как в курилках и на кофепойнтах, где можно короткими фразами эмоции выражать, впечатлениями делиться, а длинными гладкими конструкциями, как в кино. Следуя аналогии, хорошим технарем предлагают считать того, кто умеет писать красивым почерком, владеет навыком калиграфии. И, как в статье, можно даже озвучить «доказательство» — при письме ручкой по бумаге и при наборе кода с клавиатуры задействованы одни и те же области мозга, ученые доказали.
В статье не говорится про "говорить, как в кино". И более того: в статье явно указано, что это не 100% метрика и далеко не единственная. Скорее,- штрих к портрету... А вообще, да, умение говорить кратко, емко и по делу - благо, как для самого программиста, так и для его окружения. ;-)
умение говорить кратко, емко и по делу — благо, как для самого программиста, так и для его окруженияУмение говорить кратко, емко и по делу — благо в любой профессии, будь то стендап-комик, слесарь-сантехник или политик. Отсутствие развитого навыка общения никоим образом не является показателем плохости именно разработчика. И если отсутствие навыка хорошей разговорной речи является недостатком для комика и политика, то для слесаря и разработчика этот критерий вообще никак не работает — у них другие задачи.
В статье не говорится про «говорить, как в кино».Разберем подробнее сказанное в статье?
просто обратите внимание, как он говорит:
— Насколько объемный у него словарный запас — программист набирает огромный запас знаний в языках и фреймворках, поэтому он вполне может не знать разницу между «тривиальный» и «незначительный». Более того, огромный словарный запас помогает выражаться кратко, но мешает выражаться ясно, поскольку отнюдь не все слушатели владеют таким же запасом знаний нюансов, и могут даже раздражаться при встрече с незнакомыми словами — зачем это разработчику? Если разработчик имеет словарный запас значительно выше среднего, то это говорит лишь о том, что он посвятил много времени изучению слов, а не разработке — вполне допустимо, может хобби у него такое. Если же разработчик имеет словарный запас ниже среднего, то это говорит лишь о том, что у него другие хобби, и ничего не говорит о качестве его продуктов.
— Как часто он поправляет себя — если программист задался целью научиться кратко и точно, то он будет постоянно поправлять сказанное собой, пытаясь добиться лучшего результата. То есть с точностью до наоборот — если человек не гнушается поправлять себя, то это признак хорошего разработчика. Если же на собеседовании разработчик говорит выверенными безупречными фразами, как в кино, то это говорит лишь о том, что фразы берутся из шаблонов, которые наработались опытом многочисленных собеседований, то есть указывают на человека, который посвятил много времени навыку прохождения собеседований.
— Как начинает и как заканчивает фразы — не понятно, что автор статьи имел в виду. Возможно, автору следует научиться поправлять себя. Здесь я могу нафантазировать десяток разных вариантов, поэтому воздержусь от комментария. Автору статьи не хватает целостности высказываемых мыслей.
— Насколько целостны и непротиворечивы его мысли — при большой разнице в знаниях для слабого слушателя речь специалиста всегда будет выглядеть рваной и местами противоречивой. Потому что очевидные для специалиста связи и условия будут пропущены для краткости, выводы получатся неожиданными, странными и спорными. Только в кино мы видим персонажей, фразы которых сценарист постарался сделать максимально целостными, непротиворечивыми, понятными для массового зрителя.
— Насколько плавна его речь — как в кино? Если вы видите человека, который говорит плавно, то это значит то, что он посвятил львиную долю времени развитию навыка говорения. Возможно, в ущерб прочим навыкам, включая навыки разработчика.
— Много ли он использует слов-паразитов и заполняющего паузы «мычания» — слова-паразиты и заполняющие паузы звуки играют в речи определенную роль, приносят пользу. Например, в живом диалоге важно дать понять собеседнику, что ты не закончил мысль, сейчас сформируешь и продолжишь — это те самые мычания, эканья и многочисленные слова-связки. И чем опытнее специалист, чем сложнее мысль, которую он хочет выразить, и чем больше у него одновременно задач удерживается в голове, тем больше у него потребность в паузах на подбор слов и формулировок. Если человек говорит без пауз, то это говорит лишь о том, что он в данный момент времени ни о чем особо не размышляет. Как в кино, где сценарист за персонажа уже все обдумал и теперь должен экономить экранное время.
— Насколько обширный контекст он способен удерживать в диалоге — не понятно, что автор статьи имел в виду. Возможно, автору следует научиться удерживать в голове контекст, который задал в начале статьи: на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке.
— Насколько лаконично и емко он способен донести информацию — практика общения с менеджерами подсказывает, что лаконичность и ёмкость высказываемых мыслей должна соответствовать уровню собеседника. В общении с некоторыми уважаемыми заказчиками приходится разжевывать простыми словами, привлекать многочисленные аналогии из мира заказчика и не лениться повторять одну и ту же мысль разными словами. А уж на собеседованиях так и вовсе рекомендуют не упорствовать в краткости, а раскрывать каждую мысль. Только в кино сценарист может позволить себе регулярно использовать краткие сочные фразы, поскольку зритель на протяжении часа погружен в контекст истории.
в статье явно указано, что это не 100% метрика и далеко не единственная.Если присмотреться к рекомендациям внимательней, то становится ясно, что это плохая метрика. Она не то что не 100%, она вообще никак не помогает разглядеть хорошего разработчика, а местами еще и работает наоборот, украшая плохого разработчика.
Скорее,- штрих к портретуСкорее, гадание на кофейной гуще. Типирование разработчика по гладкости и темпу речи ничуть не лучше, чем типирование разработчика по выбору одеколона или цвету кожи.
Если разработчик имеет словарный запас значительно выше среднего, то это говорит лишь о том, что он посвятил много времени изучению слов, а не разработке
Либо просто читал(а) много хороших текстов. Собственно, это именно мой случай.
Кроме того, если тысячу раз встретить какое-то слово в художественных текстах, можно так и не узнать нюансы значения, подхватить первое похожее на правду толкование и закрепить его в привычках. Для расширения словарного запаса нужно в словари регулярно поглядывать, а не просто употреблять чужие тексты.
очевидные для специалиста связи и условия будут пропущены для краткости, выводы получатся неожиданными, странными и спорными. Только в кино мы видим персонажей, фразы которых сценарист постарался сделать максимально целостными, непротиворечивыми, понятными для массового зрителя
Именно так!
И это противоречит требованию " — Насколько лаконично и емко он способен донести информацию ".
Скорее, гадание на кофейной гуще.
Нет никакого гадания. Это неосновная метрика, о чем явно указанно. Так сказать, "косячок". Пока косячков один или два - ничего страшного и вообще пофиг, но когда их много - это уже косяк. Так понятнее? ;-)
Ближайшая аналогия - антиспам, скоринг. Там таких метрик сотни. Выкинуть их все, потому, что по одной единственной нельзя судить о результате? Угу, крутой подход. ;-)
Это неосновная метрикаКогда набирают неосновные метрики, тоже ориентируются на пользу. Если метрика приносит не пользу, а вред, то её не включают в список используемых. Вне зависимости от того, основная она или нет.
Что касается перечисленных в статье «метрик», то их можно свести к теме крайностей. И в таком случае они начнут работать, но при этом перестанут быть неосновными. И перестанут быть метриками, станут маркерами.
В контексте собеседований:
Сбивчивая речь и непоследовательность в изложении мыслей — крайности «слишком гладко ораторствует» и «мычит что-то невнятное».
Злоупотребление жаргонизмами и buzzwords — крайности «прячет отсутствие смысла за красивыми терминами» и «не понимает распространенных специальных терминов».
Перфекционизм и идеализм — крайности «делает тяп-ляп» и и «тратит много времени на вылизывание мелочей» плюс «склонен к выгоранию из-за недостижимости идеалов», к которым зачем-то в одну кучу доложили «недостатки черно-белого мышления» от которых следует отделить крайности «склонен к избыточному консерватизму» и «чрезмерно увлекается экспериментами».
Переусложнение или оверинженеринг — крайности «слишком много усилий тратит на попытки предусмотреть всё» и «уделяет недостаточно много внимания закладыванию гибкости для постедующего развития и поддержки».
Самоуверенность и «велосипедизм» — крайности «не склонен к развитию», «не признает ошибок», «склонен к самобичеванию» и «склонен к выгоранию из-за неуверенности в своих силах», к которым зачем-то в одну кучу доложили крайности «не умеет пользоваться чужими наработками» и «стремится всегда прикручивать чужие решения».
Туннельное зрение в смысле «безусловная приверженность выбранной позиции по какому-либо вопросу» — повторение пункта «идеализм».
Автор статьи выпятил половину крайностей, потеряв противоположные, из-за чего вместо шкалы, позволяющей ориентироваться, мы получаем висящие в вакууме сомнительные постулаты, описывающее некое абстрактное зло — к этому основная претензия.
Маркеры выбраны каким-то случайным образом, системное мышление не проявляется, встречаются повторы и сомнительные места, которые можно трактовать с точностью до наоборот — именно потому, что вместо упоминания двух крайностей описывается недостаток только одной стороны.
Недостатки именно технического специалиста смешаны с недостатками просто человеческими, из-за чего статья вовсе теряет смысл. Отсутствие системного мышления, неспособность удерживать контекст и цель, отсутствие желания и ресурсов для развития — вот признаки плохого технического специалиста, которых нет в статье.
Очень много текста. Cбивчивая речь - это маркер сбивчивой мысли. Сбивчивая мысль рождает сбивчивый код. А оно вам надо?... Тут только один вопрос: переволновался человек или всегда так мыслит/говорит/кодит?
неспособность удерживать контекст и цель
Бинго! ;-)
Сбивчивая мысль не означает сбивчивого кода.
Можно сходу найти много разных причин для сбивчивой речи — кофе, туалет, волнуется, думает о более важном, заикается с детства, нахамил кто-то пять минут назад…
И можно сходу придумать разные причины для гладкой речи — пофигист, не имеет идей и даже целей, посвятил много времени сценическому искусству…
Никак нельзя делать на основании подобных маркеров выводы о способности данного человека большую часть времени обретать и применять специальные знания.
Я не представляю собеседование, на котором вас поят лошадиной дозой кофе, хамят и не пускают в туалет одновременно. К чему тут это? На собесе будет одно - большое волнение. Оно заметно, человека успокаивают или метрика отбрасывается.
ps А то так любую метрику можно выкинуть изначально. Решил задачу на собесе? Да просто вчера на литкоде ее зазубрил. Есть код на гитхабе? Да просто нанял кого-то его за деньги наполнить. Нельзя так.
Еще раз: как работает тот же антиспам? Беруться сотни малозначительных (не очень) совершенно разных метрик, группируются и по совокупности их весов делается окончательный вывод. Чем меньше метрик, тем больше вес оставшихся и тем чаще письмо в папке "спам" или спам во "входящих".
Я не представляю собеседование, на котором вас поят лошадиной дозой кофе, хамят и не пускают в туалет одновременно.Если человек пришёл на собес, это не значит что у него нет другой жизни. Нахамить ему могли в транспорте или на улице 5-10 минут назад или даже с утра, но так, что заряда настроения на весь день хватает. Мог просто не выспаться и закинуться конской дозой кофе.
А то так любую метрику можно выкинуть изначально. Решил задачу на собесе? Да просто вчера на литкоде ее зазубрил.В учебных заведениях с известными темами и хотя бы примерными билетами можно и зазубрить. Задачки на собесах — да их бесконечное множество, некоторые я так понимаю вообще на ходу придумывают.
Есть код на гитхабе? Да просто нанял кого-то его за деньги наполнить. Нельзя так.Если есть сомнения, можно ткнуть в рандомную репу, рандомный кусок кода и спросить, что это. Правда, в этом случае код может быть заимствованным (форк, копипаста, кто-то другой пульнул, а чел просто чекнул и принял), но об этом тоже можно рассказать.
как работает тот же антиспам? Беруться сотни малозначительных (не очень) совершенно разных метрик, группируются и по совокупности их весов делается окончательный выводВ данном случае для антиспама предлагается метрики вроде «тема письма начинается на букву А» и «в теле письма нет имени отправителя» — какими бы мелкими они ни были, как бы ни дополнялись другими метриками, они остаются бесполезными и даже вредными, которые не следует брать, группировать и учитывать в совокупности.
они остаются бесполезными и даже вредными
Не вижу ничего хорошего в том, что человек не в состоянии сформировать мыcль. Если кто-то вывел из себя - собес переносится. Не важно, температура поднялась или ногу подвернул. И другое дело, что ты всегда говоришь так, как будь-то у тебя температура, вывихнута нога, внутри лошадиная доза кофе и очень хочется в туалет.
Сбивчивый: "Лишенный последовательности, логической стройности; путаный, беспорядочный.". Малый академический словарь.
И вот, у нас чувак на секции про "поговорить", архитектурной, к примеру, несет два часа какую-то малосвязанную пургу. И про свой код (на секции про код) тоже толком ничего объяснить не может. И вы утверждаете, что такого чела надо обязательно брать в команду?..
Да тут, походу, письмо начинается прямо с фразы "Я сын негерийского принца в изгнании". ;-)
Не вижу ничего хорошего в том, что человек не в состоянии сформировать мыcль.Не вижу ничего плохого в том, что человек не может сходу гладко и красиво сформулировать некоторые мысли. И вполне могу предположить, что обратный маркер также может указывать на что-то плохое — гладкое, последовательное и даже логичное изложение регулярно используется для маскировки недостатков.
у нас чувак на секции про «поговорить» несет два часа какую-то малосвязанную пургу. И про свой код тоже, толком ничего объяснить не можетСлучаи «постоянно несет пургу» и «не может объяснить свой код» сильно выходят за рамки написанного в статье «на собеседовании говорил сбивчиво и перепрыгивал с мысли на мысль».
вы утверждаете, что такого чела надо обязательно брать на работу?Где я такое утверждал?
гладко и красиво сформулировать
Причем тут придуманная гладкость и красота? Термин этого не предполагает. Или мы на обсуждение чего-то другого уже перепрыгнули?
Я не знаю как увязать красоту речи и код. Вы, надеюсь тоже. Давайте, все же вернемся к другой речи: сбивчивой.
сильно выходят за рамки
Не выходят, а прямо этому и соотвтствует термин. Нагромождение беспорядочных, нестойких утверждений, когда одно не вытекает из другого,- словесная пурга.. Ну или признак "непризнанного гения", что еще хуже. "Что я тут всяким дебилам элементарные вещи объяснять буду".
И то и другое, капец, так-то.
Термин этого не предполагает.Не термин, а ваше прочтение термина. С моей точки зрения «гладкий путь» вполне антонимичен пути, на котором исчезает последовательность, логическая стройность, начинается путаница, наблюдается беспорядочность, в общем сплошные спотыкания и сбивчивость. И речь — это именно путь для выражения своих мыслей.
Или мы на обсуждение чего-то другого уже перепрыгнули?Мы со своих точек зрения, пытаясь извлечь свою пользу, разную для разных собеседников, постоянно наблюдаем у оппонентов пропуски связей и перепрыгивания на другие темы.
Например, если посмотреть на типичные комментарии на Хабре, проследить треды споров и вооружиться первой же «метрикой» из данной статьи, то можно сделать вывод, что на Хабре скопилось слишком много плохих технических специалистов — это еще одна иллюстрация того, что предложенные маркеры плохи, не годятся для применения на практике.
На практике нужен не маркер «речь стройная и гладкая», который явно нуждается в шкале для измерения, а крайности «всегда несет пургу», «прячет за умными словами отсутствие смысла» и тому подобные.
С моей точки зрения
Если допускается двоякость в прочтении термина, то надо допустить и то что (внезапно) именно вы неправильно его читаете. Логично? Допустимо? Я же никакой двоякости в термине не вижу: красиво != последовательно и структурировано. Ораторские качества, литературный слог и прочую красоту речи сюда тащить за уши ошибочно.
Ок, понятнее станет, если я на полном серьезе скажу, что по красоте речи нельзя судить о навыках программирования? Только, причем тут это утверждение? С этим никто и не пытается спорить. И ни к одному моему комментарию это не применимо. Речь о другом. Или это непонятно?
постоянно наблюдаем у оппонентов пропуски связей и перепрыгивания на другие темы
Да ладно вам. Зачастую, это не говорит о неструктурной мысли. Просто проиграв или зайдя в тупик с одними аргументами, достают новые. Хотя иногда попадаются, да, такие, что диву даешься: а как они работу-то работают с такой кашей в голове. ;-))
Зачастую, это не говорит о неструктурной мысли. Просто проиграв или зайдя в тупик с одними аргументами, достают новые. Хотя иногда попадаются, да, такие, что диву даешься: а как они работу-то работают с такой кашей в голове.Рассуждения (в том числе и вслух), попытки бывают только в мозгу курильщика? Мозг здорового человека сразу выдаёт нужный путь решения? Скажите, вы про групповое обсуждение, мозговой штурм слышали когда-нибудь?
Если допускается двоякость в прочтении термина, то надо допустить и то что (внезапно) именно вы неправильно его читаете. Логично?Нет. Во-первых, термин «правильно» мы явно понимаем по-разному. Во-вторых, в данной постановке вопроса логика не имеет никаких зацепок для указания на одного из читающих.
Допустимо?Допустимо также то, что мы спим в криокапсулах, будучи похищенными сборщиками урожая. Допущения, которые не несут пользы, бесполезны.
Я же никакой двоякости в термине не вижу: красиво != последовательно и структурировано.Не равно, но красота вполне может включать в себя отсутствие сбивчивости, упорядоченность, последовательность, наличие структуры и многое другое. Красота хорошо пересекается с терминами «симпатично» и «нравится» — мне нравится то, как он говорит, что подразумевает понимание, согласие и отсутствие царапающих слух моментов.
проиграв или зайдя в тупик с одними аргументами, достают новыеОппонент вполне может и не играть — с его точки зрения. Впечатление его проигрыша может существовать только в вашей голове. И вполне нормально перебирать аргументы, откидывая опровергнутые, находя новые. Если, конечно, они были опровергнуты не методами вроде «отмахнуться негативной оценкой» или «увод темы в сторону».
Хотя иногда попадаются, да, такие, что диву даешься: а как они работу-то работают с такой кашей в голове.Если допускается непонимание, впечатление «каши», то надо допустить и то, что (внезапно) непонимание существует в вашей собственной голове и не связано с головой говорящего.
Какой почерк?
Ну... у меня неплохой :) Я люблю писать, особенно, когда думаю над чем-то. Перьевые ручки люблю. Фетиш, всё такое. Но это не повод это критерием делать. Выше @dolovarверно мою аналогию понял.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференция
У вас есть статистика? Просто...сколько программистов работают над известными проектами и столько появляются на конференциях? И Естественно, мы видим чаще хороших спикеров на конферециях, ибо их и выбирают, ну это не значит что только они хорошие программисты.
Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний.
Как у вас в детсом саду? Или где ещё пытаются впечатлить жаргонизмом
Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний.
Я тут подумал что это в целом описывает процесс среднего собеседования. Хоть в толковый словарь заноси.
Речь же не только про открытые конференции. Во многих компаниях практикуют регулярные внутренние митапы (иногда даже "добровольно-принудительные"), и корреляция между хорошим текстом/речью и скилами коллег отлично прослеживается)
только они хорошие программисты
В вашей цитате написано, что хорошие инженеры часто оказываются хорошими спикерами, а не то, что хорошие спикеры становятся хорошими инженерами. Хотя в статье речь как раз об этом, но тогда цитата была выбрана неправильно.
А то, что не все хорошие инженеры появляются на конференциях, не противоречит ни цитате, ни посылу статьи. Для опровержения цитаты, к примеру, нужно не считать, сколько хороших инженеров не поехали на конференции, а считать, сколько спикеров из их числа не стали хорошими.
На счёт детского сада не знаю, но какова причина использования людьми таких слов? "Эта багулина фиксится одной тулзочкой из моей репы, вот тут пропсики прокинуть и несколько рулесов в конфиг прописать"
хорошие спикеры становятся хорошими инженерами
Это было бы ещё больше чушьи, речь как раз о том, что хорошие инженеры являются хорошими спикерами
Пожалуй, да, в статье только обратные примеры, что человек со сбивчивой речью вряд ли будет писать хороший код. Там не про то, как найти хорошего, а как отсеять плохих.
Но из этого всё равно не следует, что хорошие программисты — только те, кто выступают с докладами. Которые выступают, те скорее всего хорошие, но не только они.
Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Вот тоже хотелось бы посмотреть на статистику. А то логика конечно интересная получается и не следует ли из неё, например, что люди с заиканием склонны к дублированию кода... Строить связь именно с устной речью (тем более со спикерством) - не убедительно, там же ещё столько социальной психологии замешано, которая к коду отношения не имеет.
У меня есть обратный пример. На прошлом месте приходил CTO, который участвовал в конференциях, но по факту оказался слабее любого лида в компании. Вот это был ад, которого я никому не пожелаю
Первый пункт оценивает процесс написания кода или результирующий код?
Странно оценивать финальный код разработчика по его вербальным способностям, ведь в итоге код можно вылизать, чего нельзя сделать со своими фразами в разговоре.
С другой стороны, у каждой задачи есть срок, и порой он очень жёсткий. Так что умение выдавать что-то сносное под давлением времени - неплохой навык для разработчика.
Однако, я не могу отрицать, что полученная оценка является, в лучшем случае, склонна к ложно-отрицательным, а в худшем - и к ложно-положительным результатам.
Я ниразу не видел прямой зависимости между умением быстро и резко болтать, и быстро писать хороший код.
Я даже наоборот скажу, те кто не самый болтливый, в моем опыте, обычно побыстрее и получше код пишут.
кто не самый болтливый, в моем опыте, обычно побыстрее и получше код пишут.
Насколько я понял, речь идет чуть-чуть о другом. Вы можете быть молчуном, почему бы нет. Но если у вас возникнет необходимость что-то объяснить, то вы сделаете это ясно, понятно, и, конечно, лаконично.
Или не сделаете. Не вижу никаких доказательств того, что умение писать код как-то коррелирует с умением объяснять (и уж тем более понятно и лаконично).
На примере спикеров из статьи невозможно сказать, как хорошо они что-то объясняют "сходу" - их доклад подготовлен заранее, вопросы проработаны. И я не раз видел, как после доклада спикер не мог толково ответить на вопросы.
Вполне возможно, что Вашу просьбу просто проигнорируют сочьтя неквалифицированной. Часто в командах для этой цели отвечать на вопросы новичков назначают менторов в обязанности которых как раз и входит введение в курс дела. Менторы как раз и происходят в силу того, что знание и способности к программированию часто некоррелируются со способностями внятно объяснять. Во многих компаниях где мне приходилось работать есть даже специальные должности евангелистов.
Потому что те, кто умеют хорошо говорить (без пауз, без слов-паразитов, и с нужной интонацией/жестикуляцией), обычно делают это ценой добавления большого объёма "воды" в речь. То есть речь выглядит красиво, легко воспринимается, но там просто вместо "слов-паразитов" и "мычания", как иной раз говорят программисты, часто бывают фразы и выражения "общего" характера, которые служат только цели сохранить темп речи и обдумать в это время основную мысль.
При написании кода "вода" не нужна, её наоборот пытаются убрать и сделать код более лаконичным. Да и в речи - краткость - сестра таланта.
TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность
Это отличный аргумент, если у вас в компании принято первый драфт лить в продакшн. Во всех остальных случаях код, в отличие от речи, проходит несколько итераций правок, прежде чем принять окончательную форму и уехать в репозиторий. Редактура художественных текстов — вообще отдельная профессия.
Даже вот этот коммент я пару минут помусолил туда-сюда, прежде чем меня начали устраивать форма и содержание.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях
И эти тематические конференции во всю нанимают профессиональных тренеров по выступлениям, которые помогают спикерам подготовиться, составить структуру, проработать темп подачи.
Умение выступать (да и вообще поставленная устная речь) — это отдельный, ортогональный инженерному делу навык. Пособеседуете бывших продажников — поймете, о чем я.
Умение говорить отражает умение формулировать мысли. Если человек этого не умеет, то он может очень долго вылизывать, но код всё равно будет плох.
Я бы ещё добавил, что если в голове каша, то и в речи будет каша и в коде. Так что можно использовать как признак.
Я бы по-другому сказал. Речь это произведение умения думать на умение говорить.
И если умение думать отражается и на коде и на речи, то умение говорить - только на устной(!) речи. По этому при идентичном ораторском скиле мы имеем самые разные соотношения умений думать и говорить и, соответственно, самые разные уровни программирования.
С учетом немалого количества социопатов в программерской среде, я бы не стал ориентироваться на ораторские способности. Тем более это не интересно их непосредственным руководителям, т.к. навыки программиста под вопросом, за то очевидна потенциальная конкуренция.
Про боязнь публично выступать слышали что-нибудь?
Да как это может работать, если речь и логика одним участком мозга обрабатывается, ты либо думаешь и молчишь, либо придумал и говоришь. Но во время собеседования ты не можешь позволить себе долго молчать и обдумать всю речь, как спикер, спрашивают то разное всегда, только рассказ про предыдущее место работы заранее можно продумать.
Меня вообще никто не понимает если я думаю и одновременно говорю, речь автоматом в бубнешь превращается, постоянно потом повторять приходится.
Полностью поддержу адекватного человека. У Google вообще есть HR программа по найму людей с аутическим спектром, так многие из них вообще не склонны к общению. И такие люди в приоритете. Как правило они больше делают, чем говорят.
TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне: разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код. То есть язык программирования является такой же формализацией образов из мышления в конкретную систему символов и правил, как и любой другой человеческий язык.
У данной идеи есть некоторые разумные основания, но… Устная речь была нормальным прокси только в старое время. Потому что в старое время не было асинхронных чатов. Потому что сейчас можно буквально думать об notepad, компенсируя недостаток кратковременной памяти. Потому что сейчас можно написать тесты на код, а не пытаться удерживать все решение в голове. И т.д., и т.п. Время изменилось, прокси-оценка стала хуже работать.
Сбивчивая речь и непоследовательность в изложении мыслей
Извините за токсичность, но брехня и полная чушь!
при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи
Даже при восприятии и формировании устной речи задействованы совершенно разные участки мозга, это вам подтвердит любой физиолог или даже человек, изучающий иностранный язык. Понимать речь и владеть ею -- это совершенно разыне навыки. И при многих поражениях речевого аппарата у человека как правило сохраняется возможность понимать речь и уж тем более мыслить.
разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код.
Бред! Абстрактное мышление вообще практически никак не связано с речью. Мы мыслим не речью и даже не символами, а некими абстрактными образами. Никаких "логических функций мозга" на этот счет не существует.
Речь -- это строго упорядоченная во времени система сообщений, тогда как мыслительный процесс, реализуемый нашей головной нейросетью, по большей части параллелен, неупорядочен, и многоуровнен. Когда программист "в потоке", он в голове держит сразу огромное количество абстракций, которые в процессе детализирует, постоянно перемещая фокус внимания от одной к другой. И код мы пишем не как вы изложили выше -- "от забора и до обеда", а во многих местах сразу, не особо заботясь о последовательности написания. Кроме того в момент особой концентрации на задаче перестает хватать "ресурсов" мозга на задействование речевого аппарата. Плюс зачастую речь просто не поспевает за мыслью, о скорости которой уже издревле сложились мемы. Поэтому за столом мы как правило видим программиста, судорожно шепчущего под нос непонятные слова, а не оратора, вещающего трактат о решении задачи.
Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста. И наоборот -- плавность и последовательность будет либо говорить о домашней заготовке, либо содержать наивные и поверхностные суждения, скорей всего ввиду ограниченности самого субъекта.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях.
Однако, заведомо будет справедливо, что хороших инженеров, НЕ выступающих на конференциях, гораздо больше. Кроме того, излагать заранее подготовленный доклад -- совсем не то, что излагать свои мысли в реальной работе.
К Вашей аргументацтии я бы добавил, что хорошие выступающие спикеры готовят и репетируют свое выступление заранее, в то числе и возможные вопросы/ответы. Причем тема выступления известна заранее+уже есть опыт публичных выступлений. В случае с собеседованием все не так однозначно :)
Согласен. Да и вообще для того чтобы быть хорошим спикером лучше всего иметь очень хорошую долгосрочную память. Текст готовится заранее, полируется, заучивается, репетируется. Вот то как человек отвечает на дейстивтельно неожиданные вопросы можно было бы сравнить хоть как-то, а сами выступления - увы нет.
Перед собеседованием тоже можно подготовить свое "выступление" заранее, включая вопросы и ответы. На N-ном собеседовании пересечение ваших заготовок с заготовками интервьюера будет достаточным, что бы вас посчитали хорошим спикером инженером и выслали оффер.
“How long does it take you to prepare one of your speeches?” asked a friend of President Wilson not long ago.
“That depends on the length of the speech,” answered the President. “If it is a ten-minute speech it takes me all of two weeks to prepare it; if it is a half-hour speech it takes me a week; if I can talk as long as I want to it requires no preparation at all. I am ready now.
Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста
не уверен, что это именно так работает, не удивлюсь, если вообще нет значимой корреляции между ораторскими способностями и программированием.
но вот если человек не может связно излагать свои мысли письменно — то это уже, думаю, нехороший звоночек.
Ну это было высказано в качестве контраргумента исходному тезису :) По манере речи и письма можно сказать об общем культурном уровне и образовании человека, который в общем случае может коррелировать с техническими навыками. Кроме того, речь -- это такой же скилл, который при желании и необходимости можно прокачать.
Бред! Абстрактное мышление вообще практически никак не связано с речью.
Гипотеза лингвистической относительности предполагает, что структура языка влияет на мировосприятие и воззрения его носителей, а также на их когнитивные процессы. Лингвистическая относительность широко известна как гипотеза Сепира — Уорфа. Выделяют две формулировки этой гипотезы[1]:
Строгая версия: язык определяет мышление, и, соответственно, лингвистические категории ограничивают и определяют когнитивные категории.
Мягкая версия: язык только влияет на мышление, и наряду с лингвистическими категориями мышление формируется также под влиянием традиций и некоторых видов неязыкового поведения.
Гипотеза небесспорная, особенно в своей «строгой» версии, но чтобы вот прям бред?..
Я бы сказал не небесспорная, а как раз очень даже спорная, по которой уже 100 лет не утихают дебаты.
Главным камнем преткновения в дискуссии о лингвистическом релятивизме является проблема корреляции между языком и мышлением. Самой строгой формой корреляции является лингвистический детерминизм, который предполагает, что язык полностью определяет все возможные когнитивные процессы индивида.
и
Основной спорный вопрос формулируется так: являются ли высшие психические функции по большей части универсальными и врождёнными или же они представляют собой преимущественно результат обучения и, следовательно, являются субъектом по отношению к культурным и социальным процессам, которые варьируются в зависимости от места и времени.
На мой взгляд интерес к теме черезмерно раскручен ввиду ее коммерческой перспективности: вся рекламная индустрия и рынок основан на когнитивной лингвистике. А там где рынок, там и бабло водится. Поэтому очередные "исследования" щедро спонсируются заинтересованными физ- и юр-лицами. А чтобы поток денег не прекращался, никто не заинтересован поставить финальную точку в этом вопросе.
Если уж брать язык как средство коммуникации и записи мыслей в общем смысле, то он не ограничивается исключительно лингвистикой и речью, которые по сути очень примитивны. Есть более компактные и емкие способы изложения и восприятия информации, которыми люди пользуются в технических областях: язык математически, графики и диаграммы, чертежи, рисунки наконец. И естественно соответствующие специалисты за свою карьеру прокачивают в первую очередь свои технические навыки, нежели разговорные. Ну а если вам нужен кандидат со связной речью -- идите искать на филфак.
По своим наблюдениям добавлю еще один пункт с большой долей вероятности плохого программиста: человек перестал или стал меньше программировать и пошёл учить других в онлайн-школы программирования ;)
Да просто "пошел учить" вполне достаточно. К сожалению, есть такой сорт старших разрабов, которые не хотят идти в менеджмен или архитектуру, но и обычный кодинг им уже осточертел. Вполне вероятны фокусы типа "а давайте наймем 5 джунов - а я их буду менторить (а кодить больше не буду)"
А если пошёл вести вечерние курсы для студентов 2 раза в неделю по 2 часа - это уже достаточно, чтобы хоронить, или надо всё-таки дождаться, когда на фулл-тайм уйдёт?
человек перестал или стал меньше программировать и пошёл учить
Вроде булева алгебра тут несложная
Пойти в менеджеры или аналитики - тоже вариант. Есть много аналитиков с хорошей вузовской подготовкой (знания, языки прог., алгоритмы, кругозор), которым практика программирования как-то "не заходит" и находят такой вариант приобщения к профессии, который так и остаётся основным.
Похоже на то, что ты не обладаешь абсолютно никакими полезными навыками или талантами, — заявил Хвиляга. — А ты никогда не задумывался над тем, чтобы заняться преподаванием?
У Прачета была еще более подходящая цитата, но быстро не нашел. Там было про построение длинной сложноподчиненной фразы, высказав которую аркканцлер гордился, что сумел её выдать не задействовав мозг.
– Со всем уважением, лорд Витинари, – прервал его аркканцлер, – позволю себе заметить: раньше действительно считалось, что драконы вымерли, однако новые данные, осмелюсь заметить, заставляют несколько усомниться в этой теории.
Что же касается среды обитания, то данный случай является очередным примером изменения поведенческого образца, что было вызвано расширением городских территорий и распространением их на сельскую местность, в результате чего многие доселе дикие существа перешли, более того, во многих случаях прямо-таки рванулись к более цивилизованному образу жизни, и многие из них процветают благодаря новым, открывшимся перед ними возможностям.
Например, с недавних пор в университетские мусорные баки повадились лазать лисы…
Аркканцлер сиял. Он ухитрился выдать всю эту тираду, практически не задействовав мозг.
Удивляет сколько лайков набрал ваш комментарий. А потом на каждом шагу говорят мол "как же плохо сейчас учат программистов". Так кому их учить, если столь популярно такое мнение, как ваше? Вот есть хороший специалист, допустим, и для дела было бы полезнее, если бы он хотя бы понемногу начал преподавать (час-два в неделю), делиться своим опытом. Преподавать-то некому, вот и идут туда зачастую проходимцы - так лучше уж будут преподавать опытные спецы, но без педагогического опыта, чем вчерашние (или сегодняшние) студенты совсем без опыта работы программистом. Ибо "профессиональный программист-педагог" - это, конечно, большая роскошь. Сходу только Тимофей Федорович Хирьянов приходит на ум.
ЗЫ. Понятно, что такой коммент в блоге онлайн школы программирования действительно выглядит иронично :) поэтому надеюсь, вы просто пошутили)
Кто умеет, тот делает; кто не умеет, тот учит.
Я не очень понимаю, как вы собираетесь в первом пункте понимать, что у кандидата, например, афазия, но хорошо замаскированная. И вообще логика в духе "корреляция достаточно высока, чтобы можно было ей пользоваться" опасна тем, что создают предрассудки — так, знаете ли, и пол, и цвет кожи вам могут дать какую-то достаточно высокую корреляцию.
Я думаю, ответ тут будет такой же, как и в большинстве американских компаний, у которых избыток кандидатов - "лучше не нанять хорошего, чем нанять плохого" ("потому что можем себе позволить"©). Если эта корреляция помогает следовать вышеуказанному правилу, то будут использовать ее. Ну а с полом и цветом кожи/расой и ориентацией уже квоты придумали для корректировки.
Ох, ребята. Знавал я людей с подвешенным языком, котрые могли забалтать. Но пользы проекту они наносить не умели. Долго делали, много думали. Нет здесь четких критериев. Инициативность и вовлеченность, вот пожалуй главные.
Главное на этой почве не отсекать тех кто и говорить умеет - и делать дело. А то бывает.
Да, пока с человеком не поработаешь - не поймешь. И никакие формальные правила прогнозирования здесь не работают
Есть формальное положительное правило: если в беседе или в решении задачи чел легко переключается на более глубокий уровень анализа, привносит новую мысль (но тут и самому надо представлять круг возможных идей), разворачивается на другое решение - хороший специалист. Но тоже отсеивать нельзя, потому что говорить и одновременно думать над кодовым решением, озвучивая мысли - далеко не все могут, этому нужно учиться большинству.
Про Дейкстру.
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
Так он ведь и сам - с хорошо подвешенным языком, и программист далеко не последний. И методист. Конечно, он знал, что умение формулировать мысли добавляет много плюсов умению программировать.
Есть такая хорошая фишка, я сам её использую время от времени. Если въехал в проблему, а вот чего-то не хватает, чтобы сделать, - попытайся вслух внятно, ясно, объяснить это другому человеку, даже если он не специалист в данном вопросе. Где-то посередине процесса нужная мысль приходит. Но самое смешное, что у слушателя возникает (пусть на миг) иллюзия понимания. Всем хорошо.
Как плохой разработчик, скажу
Если в компании не используют X, в этой компании не надо работать;
Если в компании разработчик решает, какой цвет тени будет смотреться лучше, в этой компании не надо работать. Серьезно, эти вещи либо должен решать специально обученный дизайнер, либо все должно быть заранее решено и браться из дизайн-бука.
Если же он может донести глубокую мысль понятным образом в несколько слов, то и в коде он будет прост и нагляден.
Хорошая мысль, но несколько однобокая. Фейнман понятным образом изложил КЭД, но серьезно учат её все-таки больше по непонятному изложению Фейнмана или книгам Ландау-Лифшица. Сложность многих моделей ограничена снизу и серьезно упростить ее с получением на выходе эквивалентного результата может оказаться невозможно. Некоторые мысли при изложении в несколько слов существенно теряют в глубине. Другое дело, что от по-настоящему умного человека, который не ставит первоочередной целью произвести впечатление, ты практически никогда не услышишь слов, значения которых не знаешь.
«сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать.
Ну да, ну да. Заказчик скажет, что такая проблема не реальна. А когда вся система ляжет на проде из-за того, что два запроса от разных пользователей конкурируют за общий слот, заказчик скажет, что это его вина и никаких претензий к разработчику он не имеет. Именно так это и работает.
— Задачи такого рода нужно всегда решать именно так;
Разработчик, решая задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется), или ему просто хочется ее попробовать.
Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.
М-м-м, вкуснота, взаимопротиворечащие параграфы подвезли! А что, если сторонняя библиотека и правда решает эту задачу лучше? Вот только этого не удастся узнать, пока не попробуешь. Чтобы развиваться профессионально, нужно много узнать, а для этого надо постоянно интересоваться чем-то новым.
Фейман не то, чтобы "понятным образом изложил" КЭД. Это не изложение в том смысле, чтобы её можно было использовать по назначению или развивать. Это — красивая иллюстрация, чтобы домохозяйки поняли, о чём это. Конечно, так учить КЭД нельзя.
Однако, сама способность выдать такое изложение показывает нам, что Фейнман прекрасно ориентировался в теории. Именно этого эффекта ожидают и от кандидатов на собеседовании: если он может "изложить КЭД в нескольких словах", наверное, он глубоко ориентируется в теме.
Не, вообще то я плохой программист и могу себе позволить:
– Свободные решения лучше несвободных!
– Линукс лучше Винды!
– Со временем все перепишут на ассемблере!
– Java и C# отстой!
– Свободные решения лучше несвободных!
– Линукс лучше Винды!
– Java и C# отстой!
Это еще можно понять
– Со временем все перепишут на ассемблере!
Но это слишком толсто)
Как раз это тот тезис, которого можно доказать даже формально. А верхние три – так, вкусовщина.
Докажите, я пока упорно не верю)
Ну, если совсем коротко: Возможности вычислительной техники ограничены законами физики. А программы развиваются всегда в направление к усложнению. Поэтому код со временем должен быть все более и более оптимизированным. А каждая оптимизация рано или поздно доходит до ассемблера. Конечно не сразу и возможно очень даже медленно.
Возможности вычислительной техники ограничены законами физики.
Ограничена возможность линейно наращивать производительность в рамках конкретной архитектуры, не более.
Поэтому код со временем должен быть все более и более оптимизированным.
Либо превращать приложение в тонкий клиент, и переносить все вычисления в датацентры, которые можно масштабировать до бесконечности...
Усложнение может быть "горизонтальным" - больше функций, вместо вычислительного усложнения текущего функционала
Ну и что? Память тоже не бесконечная. А программы на ассемблере одновременно и меньше и быстрее.
Что требуется в очень ограниченном количестве случаев. Тот факт, что чуть ли не каждая первая десктопная программа нынче - это electron, говорит нам, что тезис о том, что весь софт перепишут на ассемблер - не верен.
В этом мире миллион программ, пользователи которых готовы мириться с их ограниченной производительностью, потому они навсегда останутся написанными на чем-то медленном)
Во первых, может это у вас только electron. На моем компьютере нет ни одного приложения работающее на electron. (могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится 🤣︎).
Во вторых, я комментировал насчёт горизонтального усложнения, для которого нужна память, а быстродействие не так важно.
На моем компьютере нет ни одного приложения работающее на electron. (могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится 🤣︎).
Мне, увы, нужен slack. Теперь научите обходиться без электрона (и, чтобы не читерить, без веб-морды слака).
могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится
Да не то, чтобы я не знал, как обойтись без приложений на электроне, вопрос в том - нафига? :) "Потому что"? :)
"...готовы вынуждены мириться с их ограниченной производительностью ..."
Да ну ладно уж. Взять тот же VSCode на электроне сделан. Прекрасное приложение, зачем оно на ассемблере? :) Мне его производительности хватает за глаза.
Мне его производительности хватает за глаза.
Пока хватает. Да и то как вы написали «за глаза», выглядит что чуть-чуть хватает.
Но ведь здесь есть только два варианта
– VSCode продолжат развивать и он станет медленнее. А компьютеры увы быстрее не будут. И производительность VSCode вам уже хватать не будет, а будет раздражать. Поэтому придется оптимизировать старый код, чтобы можно было впихнуть новые функции не уменьшая быстродействие. В конечном итоге, придется отказываться от электрона. А если это невозможно, просто забросят проект и сделают все сначала на другой платформе.
– VSCode не будут развивать дальше. Но такие программы всегда прекращают использовать, какими бы они хорошими не были.
Есть принцип Ландауэра, описывающий минимально выделяемую энергию при потере одного бита информации (применимо к классическим машинам, вычисляющим неинъективные преобразования, которыми является большинство программ, неприменимо к квантовым системам с унитарными операторами). Соответственно, производительность классических машин ограничена рассеиванием энергии на фундаментальном уровне.
Есть ещё пара других ограничений, описывающих максимальную плотность информации в заданном объёме и максимальную скорость вычислений у заданной массы.
Правда, в любом случае, нам до этого всего очень далеко.
Дам только один пример:
Сейчас активно используются и прекрасно работают компьютеры сделанные в 2012-ом году. (Примерно Sandy/Ivy Bridge) Да, немножко подтормаживают, но вполне даже ничего.
Да я сам и пишу вот с компьютера на Intel N3540 — выпуск 2014-ого года.
А теперь посмотрим как было раньше – в 2002-ом году выпускался процессор Pentium III. А если кому-то пришлось в голову использовать процессор десятилетней давности, то пришлось бы ему использовать Pentium I (50MHz!) — что уже было совершенно невозможно в плане производительности.
А я вот, на Pentium III (1000..1400MHz) даже и сейчас запустил бы кое-что и работало бы более менее хорошо.
То есть, выходит, что уже 20 лет, производительность компьютеров увеличивается как О(n), ну пусть будет О(n^2), но далеко не О(2^n) как было раньше.
Такие «прорывы» в девяностых и начале нулевых случались каждые полтора года. А сейчас вы это воспринимаете как прорыв. Об этом я и говорю.
Да робяты, плевать на ноуты. Дайте мне системник который в один поток молотит в 3-5 раз быстрее топ интела. Чтобы у меня задачка вместо 40 минут буста за 10 решалась.
Только загвоздка в том, что далеко не все задачи можно распараллелить. Вот вам: Закон Амдала
Так что, удваивание процессоров не дает удвоенная производительность. Увы.
Ну и кому-то плевать на ноуты, а кому-то они вполне себе заменяют десктопы.
Это какому-то пользователю. А вот производителю вроде не должно быть плевать, если есть спрос. Значит наверное возможностей не хватает. И не "все меньше обращают внимания" мне кажется, а просто уперлись в потолок и хоть многопотоком пытаются производительности набрать.
Если что — я не про многопользовательский сервер, а про личную числодробилку.
В реальности, новые требования будут прилетать всё быстрее и быстрее. Переписывать что-то вообще не будет времени, и более правдоподобное предположение «Со временем всё будут писать с первой попытки на языке, который позволит побыстрее оформить требования в код».
Можно и по-другому аргументировать - оптимизирующие компиляторы, в т.ч. profile-guided компиляторы (особенно с динамической рекомпиляцией), идут в направлении оптимизации под конкретную нагрузку, а значит оптимизация руками будет всё менее и мене релевантна, т.к. сложно заранее предугадать, какая будет нагрузка (и какая там конфигурация сервера в данный момент, т.к. у каждого свои особенности). Да и сейчас, если дать написать ассемблер обычному разработчику, его код скорей всего будет менее оптимальный, чем код современного оптимизирующего компилятора.
Имхо, больше выгоды даст написание cache-friendly кода, правильный выбор алгоритмов (O(1) вместо O(n)), а это можно сделать и без ассемблера.
Конечно можно. Но все это можно сделать и на ассемблере и будет еще лучше. Кроме того, хорошие оптимизирующие компиляторы можно сделать только для языков относительно низкого уровня типа C/C++. Для современных ООП языков типа C#, Java, Python, боюсь оптимизация получается довольно посредственной.
хорошие оптимизирующие компиляторы можно сделать только для языков относительно низкого уровня типа C/C++. Для современных ООП языков типа C#, Java, Python, боюсь оптимизация получается довольно посредственной.
Собственно, вся суть С++ в том, что это С + ООП (на практике; есть, конечно, любители целиком шаблонами писать). И вот тут, как раз, рантаймы типа Java выигрывают в плане именно компиляторных оптимизаций под ООП, т.к. один из основных оверхедов это вызов виртуальных функций, и статический анализ здесь проигрывает динамическим рекомпиляциям: например, при вызове интерфейсных методов рантайм может на основе истории вызовов понять, что вот в этом конкретном месте (callsite) по факту под интерфейсом скрываются всего два конкретных класса (хотя интерфейс реализуют 9000 классов), и заменить дорогие вызовы через виртуальную таблицу (а это функция по указателю, что у многих процессоров сбивает branch prediction) на простое сравнение "если это класс А, то сделай jump сюда" (так называемый callsite cache), а может пойти дальше и полностью девиртуализировать вызов (если класс один), что сразу же позволяет активировать кучу оптимизаций типа инлайнинга. Такое ручками делать в постоянно развивающемся проекте - такое себе удовольствие. Но такие рантаймы обычно всё равно медленнее С++, просто потому, что в по дизайну в них чаще всего присутствует также сборщик мусора и отдаётся предпочтение by ref-объектам вместо value types, т.е. страдает memory locality. Не могу вспомнить, чтобы был язык с продвинутым JIT, но без GC. Было бы интересно на такой посмотреть.
А, и ещё - в языках низкого уровня типа C/C++ существует проблема алиасинга, т.е. это когда мы не можем активизировать оптимизацию при работе с указателем в полную меру, потому что статически мы не всегда можем определить, есть ли ещё кто-то, кто ссылается на этот участок памяти (возможно, с другим типом). Если мы будем считать, что у указателя только один пользователь, мы можем применить далеко идущие оптимизации, но это зачастую ломает кучу кода (когда оказывается, что пользователей много - в других потоках, через type punning, это может быть несколько указателей на пересекающиеся участки массива), в итоге часто или ставят не самый высокий уровень оптимизации, или в самом компиляторе не делают оптимизацию, т.к. 99% софта надеятся на UB (не зная об этом). Вот тут как раз у более высокоабстрактных языков с чётко определённой memory model можно больше оптимизаций выжать.
Собственно, вся суть С++ в том, что это С + ООП (на практике; есть, конечно, любители целиком шаблонами писать).
Это чреватая большими проблемами интерпретация C++.
Хорошие оптимизирующие компиляторы можно сделать только для сильно типизированных языков с контролем эффектов. Чем больше у компилятора информации о семантике программы, тем лучше, и тем больше оптимизаций он может сделать, например, сливая циклы, выкидывая повторяющиеся вызовы даже к тем функциям, тела которых он не видит, и так далее.
Другое дело, что средние оптимизирующие компиляторы проще сделать для классических императивных языков вроде C или C++.
Хорошие оптимизирующие компиляторы можно сделать только для сильно типизированных языков с контролем эффектов.
Никогда бы не подумал, что у Object Pascal может быть такой потенциал. Вы его фактически описали:
Чем больше у компилятора информации о семантике программы, тем лучше, и тем больше оптимизаций он может сделать, например, сливая циклы, выкидывая повторяющиеся вызовы даже к тем функциям, тела которых он не видит, и так далее.
Справедливости ради и компиляторы для C и C++ не были этого лишены, но как показывают наблюдания всё сводится к тому, что программа больше чем на половину состоит только из инструкций mov.
Что не так уж и плохо, если посмотреть на это с истории создания процессора Cell:
Когда дойдут до предела физического, код будет не на ассемблере. Например это будет нейроморфный чип на кубитах )
– Со временем все перепишут на ассемблере!
Берите выше ниже - на VHDL.
Понимаю, что речь идёт про общие закономерности и признаки, но меньше всего хотелось бы, чтобы меня как разработчика оценивали по качеству устной речи. Для меня, например, русский язык не родной и часто возникают проблемы с изложением своих мыслей, с плавностью речи и т.п. А что уж говорить о миллионах людей по всему миру с разным уровнем английского, которые работают или пытаются устроиться на работу.
То есть язык программирования является такой же формализацией образов из
мышления в конкретную систему символов и правил, как и любой другой
человеческий язык.
Естественные и искуственные языки имеют разную грамматику и синтаксис. У искуственных языков нет переносного значения слов, двусмысленности высказываний, фразеологизмов. Отсутствует устная речь.
Выдвинутые в статье тезисы находятся на уровне диванной аналитики.
По первому пункту у меня почти обратные впечатления.
В крайней точке - да корреляция есть: если речь сбивчивая, нелогичная, заторможенная (из разговора обычно ясно человек решение продумывает или банально ответ вспоминает), то и доходя до +/-технической части выясняется, что спец не очень.
Но если собеседовать джунов - то зачастую корреляция прямо обратная. Если ответы на вопросы "вылизанные" - то часто оказывается, что такой джун больше прочитал книг "как пройти интервью", чем книг "как стать хорошим программистом".
Если ответы на вопросы "вылизанные"
Я иногда слушаю аспирантов на экзаменах. Это люди ужЕ обученные и подкованные. Тянут билет и после этого отправляются часа на 2-3 куда хотят. А потом мы беседуем. Так вот, если товарищ зубрил и даёт "вылизанный" ответ (пусть формально и правильный), то это видно с первых слов и дальше достаточно пары-тройки "отклоняющихся" вопросов, чтобы и товарищу стало ясно, что не прокатит. А вот тот, кто понимает, говорит ясно и без понтов. И его так просто не собьёшь (да и цели-то такой нет). Так что, это не обратная корреляция, имхо, а вбок.
Статья понравилась, но с автором по большому количеству изложеных мерил "хорошести" не согласин. Если б статья называлась как определить что перед вами Неопытный разработчик, то я бы согласился с названием. Все програмисты, (пока что люди), а у людей есть свои характеры, по тому как человек может изяснять свою речь, ещё ничего не означает. Лично я знавал крутого разраба, который с другими практически не общался, говорил короткими предложениями, но в решениях алгоритмов был докой.
Могу предложить свою формулу "хорошести" программиста.
Стоимость выполненных задачь програмиста (переведите в профит для бизнесса за месяц) / Стоисмость програмиста (в трудо часах).
Вот и получаем, что есть программисты которые лендинги клипают пачками, а есть которые Боинги запускают... Можно ли считать тех, которые приносят больше денег для бизнеса плохими программистами ? Да, если вы задаете мерила оценки. Всё остальное притянуто за уши... особенно те пункты где автор сначала пишет про велосипеды которые любят писать большинство программистов, а потом про технологии которые были выбраны этими же програмистами, потому что с ними удобнее работать.
Автор же предлагает на каждую задачу изучать свой редактор vim/emacs/eclipse/, что бы быть "хорошим" и выбирать под нужную задачу - нужный, но это противоречит его же принципу, где говориться, что не надо тратить много времени на уже решенные задачи. А ити и просить совета у более опытных, которые по факту за него потратили на эту задачу свое время.... цикл замкнулся. Ты не станеш хорошим, если не попробуешь решить сам - ты будешь плохим, если будешь решать, тратя ресурсы компании на эксперементы и саморазвитие.
Сбивчивая речь и непоследовательность в изложении мыслейРегулярно спотыкаюсь, обдумывая формулировку для наиболее ясного, но точного донесения мысли.
И с легкостью перехожу на другие мысли, поскольку обычно в голове крутится множество разных задач.
Злоупотребление жаргонизмами и buzzwords… особенно часто это встречается у людей, которые много работали в энтерпрайзах и часто общались с менеджерамиЯ много работал в энтерпрайзах и часто общался с менеджерами. Рили.
Перфекционизм и идеализм… Например: Фреймворк или язык X лучше фреймворка или языка Y;Да, я регулярно прихожу к мнению, что для задачи «альфа» лучше выбрать X, а не Y.
Переусложнение или оверинженеринг… систематическое привнесение избыточной сложности в решения как на микро-, так и на макроуровнеНаспотыкавшись о необходимость перепахать кучу разного в застарелом легаси для реализации очередной фичи и практикуя системный подход с выяснением контекста и планов, я всегда привношу избыточную сложность в решения.
Самоуверенность и «велосипедизм»Я твердо самоуверен, что не может получиться великолепного специалиста из того, кто не писал и не пописывает велосипеды.
Туннельное зрение… привычка основана именно на предшествующем опыте и мешает разработчику получать новый, более конструктивный опытЯ ежедневно использую привычные инструменты и подходы, и, наверняка, иногда это мешает получать новый опыт, который, весьма вероятно, мог бы оказаться конструктивным в отдаленной перспективе.
У меня здесь остался только один вопрос — эйчары действительно руководствуются подобными, одобренными сообществом статьями для типирования кандидатов?
По эйчарам, думаю мало кто может дать полный ответ, это ж надо как минимум пройти добрую сотню интервью и "хорошо" проанализировать. И то, это не даст сколь нибудь значимый результат когда вы встретитесь с конкретным эйчаром.
Ну, вот вы упускаете контекст — беседы ли, вопроса ли, утверждения ли. Это вам в минус. А в некоторых случаях, как мне кажется, намеренно его дропаете — это два минуса сразу.
Вам виднее, конечно, о оценивающий комментатор, выстраиваюший образ собеседника по прочитанному между строк. Оставайтесь на линии, ваша оценка очень важна для нас…практикуя системный подход с выяснением контекста и плановвы упускаете контекст — беседы ли, вопроса ли, утверждения ли. Это вам в минус. А в некоторых случаях, как мне кажется, намеренно его дропаете — это два минуса сразу
TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи
А какие именно задействованы участки при изложении своих мыслей письменно? А то я знаю людей, которые говорят не очень, могут и сбиваються, и заикаются, но вот аргументировать свою позицию письменно могут прекрасно.
Ну и в целом, у этого вашего "исследования" все что есть в абстракте только одна строчка "Programming research has entered the Neuroage." походу сами исследователи даже письменно не могут изложить, что они там наисследовали, яб не стал на него ссылаться.
если он тратит лишние часы на то, чтобы решить, какой цвет тени будет смотреться лучше — #444444 или #3e3e3e
Надо дизайнерам показать)
про речь не согласен, за неё и за написание кода отвечают разные участки мозга.
Сильные инженеры нередко оказываются хорошими спикерами
Очередное оправдание для хрюш выбирающих по софтскиллс бабников
отвергая "задротов"?
Согласен с каждым пунктом, сам многим из этого переболел в начале своего пути, теперь вспоминаю это с улыбкой, но когда приходится сталкиваться с новичками, которым искренне даёшь хорошие советы, с пускай уж и не большой высоты своих лет и опыта, но всё же, получив в ответ "да-да, я лучше сам разберусь" - хочется кинуть с прогиба :D Хорошо одно, с этими людьми я никак не связан по работе, они просто друзья. А вообще конечно печально осознавать то, что большинство людей не умеют учиться на чужих ошибках, а прямо стремятся потратить своё и чужое время на набивание шишек...
Хотелось бы почитать аргументированный ответ на этот минус, по моему опыту все кому я советовал, пришли к этому же потратив очень много лишнего времени, которое можно было бы сэкономить и потратить его с пользой, не отрицаю то, что любой амбициозный разработчик должен пройти этот путь, цимес в другом, когда есть очевидные вещи, то сколько бы ты не изобретал велосипед придёшь к тому же, или кто-то хочет замутить свою периодическую таблицу химических элементов? Или может быть свою систему исчисления? Это просто бред, нужно уметь перенимать опыт.
Я не минусил, но ваше не имеющее аргументов утверждение
Согласен с каждым пунктом
вызывало минус, тоже без аргументов.
Ок, вот вам аргумент из моей области, все кто не использует DOTween и Odin Inspector в Unity - зря тратят свое время, собственно я целый год уговаривал товарища на это, а он отпирался со своим - " Да я сам разберусь", догадаетесь какой итог? Он начал их использовать :)
И да, это я поторопился, согласен почти с каждым пунктом, но это уже не важно.
Хотелось бы почитать аргументированный ответ на этот минус, по моему опыту все кому я советовал, пришли к этому же потратив очень много лишнего времени, которое можно было бы сэкономить и потратить его с пользой
ирония:
вам кто-то влепил минус без аргументов, вам не понравилось.
но когда вы говорили другу «делай так», вам не приходило в голову, что свою позицию надо аргументировать.
обучение программированию — это не только и не столько «смотри как надо делать», это скорее объяснение того, как ты пришёл к тому, что делать надо именно так.
Письменная речь на русском языке -- явно не ваша сильная сторона. Выводы сделайте сами.
Я вот считаю что учеба на чужих ошибках не работает. Ну или в лучше случае приводит к тому что люди боятся пробовать новое. Со стороны очень сложно порой понять где была ошибка, а где недостаток знаний/упорства/времени/денег и тд
Часто бывает так что «старшие коллеги» рассказывают что это не возможно, не будет работать и тд, но иногда они оказываются не правы, и решение внезапно достаточно хорошо работает. И я не только про программирование сейчас говорю.
Прям вижу экспертное код ревью от вас с замечаниями: неправильно, лучше DOTween, так не надо. А потом на кухне с коллегами жалуетесь что джуны вас не слушают и делают не так как говорите, а с чего бы им? Вам если скажут ходить с левой ноги, ведь так лучше, а вы ходите с правой, сразу начнете просто следовать этим экспертным советам?)
Спасибо автору, текст хороший, понятный, хотя и не без технотрёпа кое-где (типа, шутка). Основное достоинство статьи в том, что я с ней согласен. Скажу больше. На мой взгляд, всё сказанное относится к любой инженерной или научной работе. Ожидаемо большое оживление вызвал первый пункт о внятности изложения проблем. Ну, не я придумал: кто ясно мыслит, тот ясно излагает. Разумеется, в любом правиле есть нюансы и исключения. У меня был коллега (увы, его нет в живых), который очень просто и понятно решил одну радиофизическую задачу. Но когда он её излагал публично - это была катастрофа. Потому что он был педант и перфекционист (пункт №3), то есть, считал, что если он упустит в докладе какую-либо деталь, пусть самую махонькую, то всё пойдет насмарку. Мухи дохли на лету. Сердце сжимала предсмертная тоска. Вопросов после доклада не задавали. Давно это было. На нашу статью в ведущем американском журнале активно ссылаются до сих пор. Бывает.
Но мне-то кажется, что среди этих пунктов в статье есть более серьёзные, чем речь, перфекционизм и велосипеды. Я бы выделил "переусложнение" и "туннельное зрение". На мой взгляд, человек становится настоящим техническим профи, когда эти два чудовища если и не побеждены, то загнаны куда подальше. У меня ушло на это лет 20. Увы.
Пунктик о подобном складе ума напомнил эпизод у нашего-всего Антона Павловича Чехова из «Скучной истории»: ¨Петр Игнатьевич, даже когда хочет рассмешить меня, рассказывает длинно, обстоятельно, точно защищает диссертацию, с подробным перечислением литературных источников, которыми он пользовался, стараясь не ошибиться ни в числах, ни в номерах журналов, ни в именах, причем говорит не просто Пти, а непременно Жан Жак Пти.¨ Ну, а далее, через пару абзацев — всё в соответствии со сценарием, которого придерживались слушатели: ¨Веду я себя с Петром Игнатьевичем дурно, и только когда он уходит, и я вижу, как в окне за палисадником мелькает его серая шляпа, мне хочется окликнуть его и сказать: «Простите меня, голубчик!»¨
такой разработчик может потратить лишние часы или дни на особую обработку случаев, когда база данных пустая, когда объект бронирования меняет свой ID, когда два запроса от разных пользователей конкурируют за общий слот, и так далее.
вообще-то хреновый (или неопытный) разработчик профакапит всякие редкие, но острые случаи, и потом будет искать трудновоспроизводимые баги, и переписывать логику/архитектуру под неучтенные кейсы.
Я хотел бы добавить кейс, когда сильный разработчик является плохим работником. Знает и умеет много, а работать не хочет. Формально таски в джире закрывает, но как-то бестолково.
"как-то бестолково" - это как?
Формально таски в джире закрывает, но как-то бестолково.
Звучит как "человек нормально делает свою работу, но я просто уже не знаю, до чего еще докопаться" :)
"Без души", "механистично", ну знаете там, ВАВЛЕЧЕНАСТЬ и все такое
Из моей практики — когда после закрытия заведенного багрепорта можно еще с десяток других открывать. То есть, формально ошибка больше не воспроизводится, но все равно с кодом потом проблемы, и чем больше изменений, тем больше проблем. Со стороны выглядит, будто делается, что называется, "напохуй", без продумывания последствий и невдумчиво.
Задачи ставить и декомпозировать надо толково. А это уже ответственность не только разработчика, верно? Похоже, у кого-то проблемы с софт-скилами?
Ловко придумано конечно, перекладывать ответственность на оформление репортов, но нет, это так не работает. Тостер может написать что функционал работает не в соответствии с поставленной задачей, дать шаги для воспроизведения, дать информацию по воспроизводимости и актуальности проблемы, но чего в багрепорте быть не может, так это "погаси или хотя бы не копи техдолг и потрать на пять минут больше пожалуйста, чтобы разобраться и сделать по красоте, а не городить огород не вникая в проблему", это мягко говоря непрофессионально. Или надо еще в ТЗ дописывать "делай на совесть"? Или что такого QA должен написать в репорте, чтобы исправление гарантированно не повлекло за собой гору косвенно связанных ошибок, обусловленных особенностями реализации, за которые тот же QA не в зуб ногой и принципиально знать не может?
А причем тут оформление репортов? тут манагер/аналитик ТЗписатель встретиться должны и сказать разработчику, что в приоритете.
- Быстрое закрытие таски, чтобы получить довольного пользователя
- рефакторинг/пересмотр архитектуры для снижения числа баготасков в жире.
А то ахнет разработчик неделю на переработку куска кода, а его на итогах спринта дрючить будут, что провозился с задачей на 2 часа 5 дней. Да и еще из за плохого покрытия проекта тестами пяток регрессов спровоцировал.
Если таксу закрыли так быстро, что аж пять новых появилось — пользователь, как правило, довольным не становится.
Речь не совсем об этом шла, я просто привел пример, когда опытный разработчик делает работу некачественно потому что просто не хочет тратить время на оптимальное решение. Качество было в приоритете по условию. Собственно, весь тезис -- "иногда опытному разработчику скучно заниматься рабочей задачей и он решает ее плохо"
Формально таски в джире закрывает, но как-то бестолково
... но делает это без уважения
Дополню.
Посмотрите на пол собеседника. Если женский, то не берите, уйдёт в декрет или вообще будет фигнёй страдать.
Посмотрите на наличие бороды. Если её нет, нельзя брать на бэкенд.
Уточните знак зодиака. Овны упрямы, скорпионы злобные, берите близнецов, они работают за двоих.
И прочий бред "как принять решёние на основе нерелевантных, зато простых знаков".
Стадии роста программиста:
1) Хочет все написать сам
2)Ищет подходящую библиотеку
3) Ищет подходящий фреймворк
4) Ищет кому бы отдать эту фигню на аутсорс, чтобы самому заниматься более интересными делами
Как понять, что перед вами плохой разработчик. Не стопроцентный способ, но сигнал: если он вывел правила подобные описанным в статье, то собственно вот, вы поняли. Либо у него так себе с анализом, и он нашел подтверждения этим правилам, когда вообще-то их нет, либо он оценивает других разработчиков по параметрам ортогональным разработке.
Разумеется я про суждение о силе программистами по его речи. Остальное в статье - капитанство.
Мне кажется, термины перфекционизм и идеализм не очень удачно были подобраны к контексту. Лучше было ввести термин "стереотипизм". Он также пододошёл бы и для раздела про туннельное зрение.
TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне
Хорошо, а если не на бытовом, а возвыситься до более-менее научного, какие-то ссылки на исследования у автора есть? Насколько я помню, для восприятия и формирования устной речи в мозге есть целые специализированный области (зона Вернике, зона Брока). При патологических изменениях этих областей нарушается устная речь. Для восприятия и формирования письменной речи никаких специализированных областей в мозгу нет (логично, письменность, по эволюционным меркам, появилась вот буквально только что, в отличие от речи). Также, нарушения речи (афазия) и неспособность к чтению и письму (дислексия) — два совершенно разных и несвязанных между собою заболевания.
Зона Вернике вроде как за восприятие отвечает. Зона Брока, насколько я помню, работает как моторная речевая зона, т.е. для говорения вслух, но не формирования текста, и ещё она работает иногда не только для говорения. А так, вон https://scitechdaily.com/reading-computer-code-is-not-the-same-as-reading-language-to-the-brain/ пишут, что чтение кода не задействует те же самые зоны, которые возбуждаются при восприятии речи.
А что делать (и вопрос вовсе не праздный) если по многим пунктам статьи узнал себя?(
По некоторым пунктам есть конечно проблески, но в общем...
p.s. Искал такой вопрос в коментах, не увидел
Что характерно, это никак не зависит от языка, на котором идет общение.
Очень спорное утверждение. Может и не завист от языка, если это твой родной язык.
А если нет?!
Например, на русском, я могу говорить витиевато, строить длинные и сложные предложения. На английском нет. На английском я буду говорить крайне лаконично и кратко.
Как понять, что перед вами плохой разработчик