Как понять, что перед вами плохой разработчик

Очень неплохой обзор. Сам ко всему этому пришел интуитивно, но было интересно почитать все это в четко сформулированном виде.

Стало быть, если программист не является хорошим спикером, то он обречён?

Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференция

У вас есть статистика? Просто...сколько программистов работают над известными проектами и столько появляются на конференциях? И Естественно, мы видим чаще хороших спикеров на конферециях, ибо их и выбирают, ну это не значит что только они хорошие программисты.

Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний.

Как у вас в детсом саду? Или где ещё пытаются впечатлить жаргонизмом

Первый пункт оценивает процесс написания кода или результирующий код?

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

TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне: разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код. То есть язык программирования является такой же формализацией образов из мышления в конкретную систему символов и правил, как и любой другой человеческий язык. 

У данной идеи есть некоторые разумные основания, но… Устная речь была нормальным прокси только в старое время. Потому что в старое время не было асинхронных чатов. Потому что сейчас можно буквально думать об notepad, компенсируя недостаток кратковременной памяти. Потому что сейчас можно написать тесты на код, а не пытаться удерживать все решение в голове. И т.д., и т.п. Время изменилось, прокси-оценка стала хуже работать.

Сбивчивая речь и непоследовательность в изложении мыслей

Извините за токсичность, но брехня и полная чушь!

при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи

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

разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код.

Бред! Абстрактное мышление вообще практически никак не связано с речью. Мы мыслим не речью и даже не символами, а некими абстрактными образами. Никаких "логических функций мозга" на этот счет не существует.

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

Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста. И наоборот -- плавность и последовательность будет либо говорить о домашней заготовке, либо содержать наивные и поверхностные суждения, скорей всего ввиду ограниченности самого субъекта.

Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях.

Однако, заведомо будет справедливо, что хороших инженеров, НЕ выступающих на конференциях, гораздо больше. Кроме того, излагать заранее подготовленный доклад -- совсем не то, что излагать свои мысли в реальной работе.

По своим наблюдениям добавлю еще один пункт с большой долей вероятности плохого программиста: человек перестал или стал меньше программировать и пошёл учить других в онлайн-школы программирования ;)

Я не очень понимаю, как вы собираетесь в первом пункте понимать, что у кандидата, например, афазия, но хорошо замаскированная. И вообще логика в духе "корреляция достаточно высока, чтобы можно было ей пользоваться" опасна тем, что создают предрассудки — так, знаете ли, и пол, и цвет кожи вам могут дать какую-то достаточно высокую корреляцию.

Ох, ребята. Знавал я людей с подвешенным языком, котрые могли забалтать. Но пользы проекту они наносить не умели. Долго делали, много думали. Нет здесь четких критериев. Инициативность и вовлеченность, вот пожалуй главные.

Про Дейкстру.

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

Как плохой разработчик, скажу

Если в компании не используют X, в этой компании не надо работать;

Если в компании разработчик решает, какой цвет тени будет смотреться лучше, в этой компании не надо работать. Серьезно, эти вещи либо должен решать специально обученный дизайнер, либо все должно быть заранее решено и браться из дизайн-бука.

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

Хорошая мысль, но несколько однобокая. Фейнман понятным образом изложил КЭД, но серьезно учат её все-таки больше по непонятному изложению Фейнмана или книгам Ландау-Лифшица. Сложность многих моделей ограничена снизу и серьезно упростить ее с получением на выходе эквивалентного результата может оказаться невозможно. Некоторые мысли при изложении в несколько слов существенно теряют в глубине. Другое дело, что от по-настоящему умного человека, который не ставит первоочередной целью произвести впечатление, ты практически никогда не услышишь слов, значения которых не знаешь.

«сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать.

Ну да, ну да. Заказчик скажет, что такая проблема не реальна. А когда вся система ляжет на проде из-за того, что два запроса от разных пользователей конкурируют за общий слот, заказчик скажет, что это его вина и никаких претензий к разработчику он не имеет. Именно так это и работает.

— Задачи такого рода нужно всегда решать именно так;

Разработчик, решая задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется), или ему просто хочется ее попробовать.

Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.

М-м-м, вкуснота, взаимопротиворечащие параграфы подвезли! А что, если сторонняя библиотека и правда решает эту задачу лучше? Вот только этого не удастся узнать, пока не попробуешь. Чтобы развиваться профессионально, нужно много узнать, а для этого надо постоянно интересоваться чем-то новым.