Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать.
Стоит отметить, что «плохой» — слишком сильное и недостаточно точное слово, давайте использовать категории «слабый» и «сильный», подразумевая, что речь идет про способность человека качественно решать правильно поставленные задачи. Конечно, критерии качества тоже относительны, но все, кому приходилось работать с чужим кодом, наверняка понимают, что при одинаковом результате он может быть как удобным, понятным и эффективным, так и запутанным и неочевидным. Тех, кто пишет нечто ближе к первому (при условии правильности решения, разумеется), традиционно считают более сильными разработчиками, чем тех, кто грешит вторым.
Человеческая природа такова, что в процессе становления, как личного, так и профессионального, большая часть людей набивает одни и те же шишки, становится жертвой одних и тех же заблуждений и проявляет себя одинаковым образом в одинаковых ситуациях. Путь инженерного мышления — не исключение, и есть общие признаки, которые позволяют понять, что в работе с программистом будут проблемы, еще даже не читая его код.
В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается.
Сбивчивая речь и непоследовательность в изложении мыслей
Весьма неочевидная на первый взгляд закономерность состоит в том, что как человек говорит, так он пишет и код. Одним из весьма уважаемых специалистов, кто озвучил подобные соображения еще в 80х, был Эдсгер Дейкстра, автор одноименного алгоритма обхода графа, а в наши дни это подтверждают и научные подтверждения.
TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне: разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код. То есть язык программирования является такой же формализацией образов из мышления в конкретную систему символов и правил, как и любой другой человеческий язык.
Поэтому при знакомстве с разработчиком просто обратите внимание, как он говорит:
— Насколько объемный у него словарный запас;
— Как часто он поправляет себя;
— Как начинает и как заканчивает фразы;
— Насколько целостны и непротиворечивы его мысли;
— Насколько плавна его речь;
— Много ли он использует слов-паразитов и заполняющего паузы «мычания»;
— Насколько обширный контекст он способен удерживать в диалоге;
— Насколько лаконично и емко он способен донести информацию.
Такое наблюдение требует некоторой практики, но если вы будете обращать на это внимание, то тревожные звоночки вы заметите сразу. И, с большой вероятностью, все то же самое вы обнаружите и в его коде. Если человек многословен, то и код его будет избыточен. Если он прыгает с темы на тему, то и код будет лишен последовательности и изящества. Если же он может донести глубокую мысль понятным образом в несколько слов, то и в коде он будет прост и нагляден.
Это не на 100% универсальное и не безусловное правило, но корреляция достаточно высока, чтобы можно было ей пользоваться. Что характерно, это никак не зависит от языка, на котором идет общение.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях. Кроме того, стоит отдельно исключить из этого правила случаи, когда у человека есть органические или неврологические нарушения речи, такие как заикание или афазия.
Злоупотребление жаргонизмами и buzzwords
Некоторые разработчики в общении (или в резюме) часто используют профессиональные термины. Особенно внимательным стоит быть к людям, которые изменяют их морфологию, используя уменьшительно-ласкательные формы, вплоть до превращения их в эвфемизмы — «багуля», «тэзэшка», «аппликуха», «батончик».
Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний. То же самое относится к buzzwords — к «гламурной лексике», словам, которыми умышленно пытаются произвести ложное ощущение, а не передавать информацию. Например, «эксклюзивность» или «элитный» — слова, которые используются, чтобы произвести впечатление и апеллировать к эмоциям, а не передать информацию и апеллировать к разуму.
В этот же пункт входит слишком частое употребление новояза — особенно часто это встречается у людей, которые много работали в энтерпрайзах и часто общались с менеджерами, или в стартапах, где нужно регулярно выбивать инвестиции, создавая постоянную видимость прогресса. Такую манеру общения иногда называют «технотрёп» (“technobabble”), а в англоязычной культуре есть более общий (сугубо разговорный) термин “bullshitting”.
Вспомните свои университетские годы, когда некоторые студенты не готовятся к сессии, а во время экзамена пытаются налить преподавателю воды и создать видимость того, что они что-то понимают. С возрастом и опытом этот процесс становится менее очевидным, потому что слов по теме разработчик, даже «слабый», понахватается в больших количествах из общения с другими разработчиками и обучающих материалов. Некоторые разработчики доводят этот навык до уровня искусства, и нередко им удается обмануть собеседника, создав у него ложное впечатление владения предметом.
Если вы замечаете за разработчиком такую линию поведения, задавайте ему уточняющие вопросы в глубину и в ширину. Ирония тут в том, что даже если вы сами в этой теме не эксперт, поймать на на вранье такого «специалиста» будет достаточно просто. Поэтому разработчик, который может просто и без затей ответить на вопрос «я не знаю», уже немалого стоит, и такого точно не стоит списывать со счетов. А вот программист, который будет изображать осведомленность, жонглируя техническими жаргонизмами — однозначно «слабый».
Перфекционизм и идеализм
Среди разработчиков часто встречаются люди, которые имеют давно сформировавшееся мнение по многим вещам, и практически не меняют его. При этом часто никаких практических аргументов, которые бы подтверждали такое мнение, у них нет — как и релевантного опыта, то есть человек просто может уверенно повторять то, что где-то когда-то услышал. Например:
— Фреймворк или язык X лучше фреймворка или языка Y;
— Фреймворк или язык Z — вообще гадость;
— Задачи такого рода нужно всегда решать именно так;
— Надо делать так-то, потому что так сказал такой-то;
— Если в компании используют X, в этой компании не надо работать;
— Если в компании не используют X, в этой компании не надо работать;
— Бесплатные решения лучше платных;
— 100% кода должны быть покрыты тестами, иначе это плохой код;
— Тесты нужны только плохим разработчикам, хорошие могут работать и без них;
— Тернарные операторы это плохо;
— Мутабельные данные это неправильно;
— Однобуквенные названия переменных — это гадость.
Каждый подобный тезис может быть справедлив в ряде случаев — проблема в том, что человек возводит этот тезис в абсолют. Кроме того, сильная убежденность сопутствует некой эмоциональной привязанности к ней — это можно заметить по использованию субъективных эмоциональных оценок, таких как «хорошо/плохо» при обсуждении, даже сугубо теоретическом, решений и концепций программирования. Таким образом, рабочий вопрос может стать для человека личным, и этот человек будет весьма болезненно реагировать на критику и вносить очень нездоровую атмосферу в коллектив.
При этом такой разработчик может даже писать неплохой код, но едва ли с таким подходом он сможет подружить свои интересы с интересами команды и бизнеса. Люди такого склада характера не склонны искать компромиссы, и это неизбежно будет мешать эффективному решению задач. Помимо этого, такого разработчика крайне трудно вырастить до сеньора, поскольку одним из ключевых атрибутов высокого уровня является способность сравнивать, анализировать разные варианты и выбирать наиболее подходящие в конкретном случае по объективным причинам, а не по личным симпатиям.
Что же касается перфекционизма, тут все достаточно прозаично: как известно, лучшее — враг хорошего. Вряд ли можно назвать конструктивным для разработчика и для команды, если он тратит лишние часы на то, чтобы решить, какой цвет тени будет смотреться лучше — #444444 или #3e3e3e, или на переименование всех переменных и функций так, чтобы фрагмент кода был максимально приближен к грамматически корректному тексту.
Переусложнение или оверинженеринг
Классическая проблема новичков, которая может сохраниться с разработчиком на многие годы. Рано или поздно оверинженеринг станет проблемой — и не только для самого разработчика, но и для его коллег. Речь идет про систематическое привнесение избыточной сложности в решения как на микро-, так и на макроуровне. Достаточно сложно привести примеры этой проблемы, но можно выделить некоторые типовые случаи:
Желание учесть абсолютно все пограничные случаи работы приложения, независимо от их вероятности и степени рисков, которые они несут. При разработке сервиса бронирования (ресторана, отеля, медицинских услуг) такой разработчик может потратить лишние часы или дни на особую обработку случаев, когда база данных пустая, когда объект бронирования меняет свой ID, когда два запроса от разных пользователей конкурируют за общий слот, и так далее. Важно, что это может быть неплохая идея сама по себе, но отличие в том, что «сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать. Тогда как «слабый» программист, склонный к переусложнению, потратит на это время при любом раскладе, ни с кем не посоветовавшись.
Трата ресурсов и времени на разные аспекты задачи непропорционально их фактической значимости. Например, разработчик написал для своего сервиса невероятно продвинутую систему логирования из 30 файлов и с 5-ю различными слоями абстракции. В то время, как вся бизнес-логика этого сервиса умещается в сотню строк, и задачу можно было бы решить за считанные часы — тогда как заняло это несколько дней. Такая система может принести огромную пользу при некоторых обстоятельствах, но нужна ли она на данном этапе, и наступят ли вообще такие обстоятельства — «слабый» разработчик не задается такими вопросами.
Инновации ради инноваций. Разработчик, решая задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется), или ему просто хочется ее попробовать. Это не только неоправданная трата времени на изучение вопросов интеграции, освоение нового инструментария и повторной реализации решения. Это и создание в проекте избыточной сложности и точки отказа из-за появления новых зависимостей, новой семантики и вероятного отсутствия у других членов команды знаний по этому компоненту. Такие процессы бывают нужны и полезны для проекта, но проводятся они, в случае «сильных» разработчиков, для решения конкретных, известных и локализованных проблем. И делается это централизованно и планово, чтобы все участники процесса могли погрузиться в эту инновацию плавно и одновременно.
Сюда же можно отнести и преждевременную оптимизацию, которую Дональд Кнут назвал корнем всех зол в программировании. И самостоятельное привнесение в продукт фичей, которые никто не заказывал, и еще много чего, что довольно точно сформулировал автор блога «Code Simplicity» и одноименной книги:
В тот момент, когда ваше решение начинает все усложнять вместо того, чтобы все упрощать, — вы занимаетесь оверинженерингом.
Самому разработчику заниматься оверинженерингом — сплошное удовольствие: таким образом он изучает новые технологии, увеличивает глубину экспертизы и искренне вовлекается в процесс. При этом для команды и проекта это идет во вред — увеличиваются сроки доставки и стоимость реализации задач, а в репозитории становится больше кода и больше зависимостей, которыми нужно управлять, а вместе с этим копится и технический долг.
Требуется некоторый опыт, чтобы понять, что больше кода значит больше багов, и что краткость — действительно, сестра таланта. На этот счет есть расхожая и абсолютно верная фраза: «The best code is no code», — то есть самый лучший код — это его отсутствие. Если разработчик может решить задачу компактно и элегантно — может быть и вовсе без изменения кодовой базы, а большие и сложные задачи декомпозировать до компактных и элегантных — это верный индикатор того, что перед вами очень «сильный» разработчик.
Важно уточнить, что далеко не все непринципиальные для решения задачи дополнительные работы над кодом можно считать переусложнением. Рефакторинг и форматирование кода для соответствия принятым в команде стандартам, обогащение его комментариями, тестами, выделение дополнительных абстракций для снижения связности — это полезные действия, хоть и необязательные, которые целесообразно совершить при решении задачи, тут важен именно баланс.
Также важно качество самих решений: одно дело написать лишнего, но полноценно решить задачу, и совсем другое — просто написать лишнего. Кроме того, надо учитывать контекст: например, при разработке программного обеспечения для авиации, космических летательных аппаратов, медицинского оборудования существует жесткий регламент, который требует обработки всех возможных, даже самых невероятных условий. Плюс требуется максимальное покрытие тестами с самых ранних этапов, создание дублирующих механизмов для наиболее критичных участков, в то время как в типовом коммерческом проекте это все будет плохой практикой.
Самоуверенность и «велосипедизм»
Еще одна достаточно типовая проблема, сопутствующая многим разработчикам в начале их карьерного пути — в популярной литературе она называется термином «эффект Даннинга-Крюгера», и касается не только программистов.
Излишняя самоуверенность может быть логичным следствием ограниченности знаний и маркером «слабых» разработчиков. У программистов она проявляется как стремление для любой типичной задачи сделать свое решение — нередко еще и переусложнив его, вместо того, чтобы использовать существующие решения.
Часто это еще называют «изобретением велосипеда», и такой подход может иметь и куда более обширные и далеко идущие последствия. Например, такой разработчик бросается делать задачу, до конца не вникнув в требования — ему «и так все понятно». При этом он не задает никаких уточняющих вопросов, поэтому в итоге выдает результат, совершенно не соответствующий ожиданиям. При этом когда ему руководители указывают на ошибки, он может впасть во фрустрацию и еще сильнее снизить свою производительность.
Вообще, привычка задавать уточняющие вопросы — исключительно положительная, и ее наличие у разработчика добавляет ему очков в пользу «сильного». Нередко на собеседованиях программистам дают ситуационные или технические задачи с заведомо неполным условием, чтобы проверить именно эту способность кандидата.
Главное отличие самоуверенности от уверенности в себе разработчика в том, что уверенный в себе программист осознает границы своих знаний и не стесняется спрашивать более опытных коллег, советоваться и собирать мнения, валидировать гипотезы и проводить работу над собой.
Самоуверенному же разработчику, даже при наличии хороших задатков, предстоит пройти немалый путь, прежде чем он сможет избавиться от иллюзий о себе и своих способностях. И очень часто это является одним из главных препятствий на пути к тому, чтобы он смог реализовать свой потенциал.
Туннельное зрение
Мы используем термин «туннельное зрение» в переносном смысле — это когнитивное искажение, которое проявляется в человеке как безусловная приверженность выбранной позиции по какому-либо вопросу, которую он не подвергает попыткам критического осмысления.
В случае с разработчиками речь обычно идет о предпочтениях в выборе технологий, паттернов, каких-либо стилевых особенностей в написании кода и иных инженерных решений, которые обычно выбираются под конкретную задачу на основании некоторых аргументов, фактов и метрик. В некотором роде, это еще одна грань уже упомянутого идеализма, но важное отличие в том, что эта привычка основана именно на предшествующем опыте и мешает разработчику получать новый, более конструктивный опыт.
Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.
Предметом такой привязанности может быть как язык программирования, фреймворк или платформа, так и инструмент, не являющийся специфическим, например, редактор кода. Да, vim/emacs/eclipse/подставить нужное — классные инструменты, но точно не идеальные для всех возможных случаев.
Примеры такого поведения при написании кода:
Решение любых задач по работе со строками через регулярные выражения.
Реализация абсолютно всех модулей и сущностей в виде классов (в тех случаях, когда язык предлагает альтернативы).
Верстка абсолютно любых страниц и компонентов при помощи одного и того же приема разметки, например, flexbox.
Привычка использовать избыточные или неявные синтаксические конструкции. Например, оборачивать весь код код функции в try/catch, явным образом приводить типы в слаботипизированных языках или отдавать предпочтение однострочным выражениям, просто потому что они однострочные.
В более широком смысле это может быть иррациональная приверженность каким-либо пакетам и библиотекам или стремление затащить их в любую кодовую базу. Сюда же входит необдуманное покрытие тестами всего и вся или, например, слияние веток в git всенепременно через rebase.
Эти приемы не обязательно являются проблемой сами по себе. Проблемой оказывается именно то, что человек использует бездумно и даже не интересуется альтернативами. Как следствие, такой разработчик становится негибким, начинает постепенно отставать от идущей быстрыми темпами индустрии, привлекая слишком сложные или плохо читаемые решения в современные кодовые базы. Со временем он становится «слабым» и устаревшим разработчиком.
Такие программисты создают много лишних итераций своим командам в процессе code review и продуцируют баги, которые возникли из-за использования устаревших приемов и фрагментов кода в новых контекстах, и которых можно было бы избежать. Помимо этого, такие подходы у разработчика можно обнаружить и в ходе устного интервью — нужно просто предложить ему обдумать решения тех или иных задач. И вы, скорее всего, услышите одни и те же ключевые слова, повторяющиеся названия и имена, или похожую линию мысли во всех случаях.
Выводы
Все эти признаки, о которых я рассказываю в статье, не являются самодостаточными — поэтому не стоит их использовать, чтобы вешать ярлыки на людей. Скорее, мы говорим про вещи, которые позволяют задуматься про реальный профессионализм конкретного разработчика.
И не стоит забывать, что единственным реальным и объективным мерилом «хорошести» разработчика является демонстрация его прикладных способностей в решении задач программирования и разработки. Как говорил Линус Торвальдс: «Talk is cheap, show me the code», — именно поэтому крупные компании, заинтересованные в лучших из лучших, никогда не ограничиваются исключительно устными интервью, а предлагают порешать задачки, в онлайне или офлайне.
Кроме того, вполне возможно обнаружить данные паттерны у вполне состоявшихся, зрелых разработчиках, и даже в лидерах мнений и признанных экспертах индустрии. Это вовсе не означает, что они «слабые» — хотя, что греха таить, бывает и такое. Но тут надо обозначить два момента:
Во-первых, в «сильных» разработчиках можно усмотреть один-два из этих пунктов, но никогда — сразу все. В то время как у «слабых» они очень часто идут рука об руку. А во-вторых, как уже было сказано несколько раз, не стоит возводить все эти правила в абсолют.
Ну и важный итог — в соответствии с законами диалектики, любой процесс содержит в себе собственное отрицание. В данном случае — в ходе профессионального роста разработчик вполне может взять некоторые из этих недостатков на вооружение уже осознанно. Ведь, как известно, чтобы нарушать правила, надо их хотя бы знать.
Комментарии (306)
nulovkin
09.02.2022 15:00+127Стало быть, если программист не является хорошим спикером, то он обречён?
Sazonov
09.02.2022 16:01+59Не нужно быть спикером. Нужно уметь выражать свои мысли понятным языком и кодом.
У меня в команде был программист, которого сначала не хотели брать из-за "слабых софтскилов". Но на техническом собеседовании достаточно было копнуть чуть глубже чтобы понять что человек глубоко разбирается в программировании (уверенный сеньор). По факту были определённые трудности в коммуникациях с коллегами, которые легко разруливались лидом, но при этом задачи решались в срок и качественно.
Вот чтобы такое увидеть нужно быть одновременно и хорошим техническим специалистом, и понимать психологию.
Radisto
10.02.2022 09:44+37У меня есть знакомый с синдромом Аспергера. Работает программером-фрилансером, судя по оплате далеко не идиот, письменная речь грамотна, но собеседование он не проходит, и не просто не проходит а вообще с личным общением у него катастрофа. Мне кажется все эти корреляции способности кодить и софтскиллов типа говорить, выглядеть, одеваться и улыбаться - максимум для нейронормальных людей с абсолютно стандартной типовой психикой, да и то не факт. Шаг влево, шаг вправо - и все эти првила превращаются в тыкву. Сугубо моё ИМХО
kotandvla
10.02.2022 11:35+2Стандартные HR набирают стандартных людей :) Уметь рассмотреть в сложном человеке бриллиант и понимать, как его внедрить в свою работу - это совсем не тривиально. Как есть люди, для которых какой-нибудь обычный бэк - это потолок, но кому-то же надо этим заниматься.
ThePaleEmperor
10.02.2022 16:20+3Может, вместо того, чтобы нанимать на HR девочек после школы, нанять человека, который способен чиатть код?
Чтобы не придумывать "100 способов узнать о навыках программиста не открывая его код"kotandvla
10.02.2022 20:00Это как сказать "Зачем нанимать непонятных студентов на работу, ведь. можно взять одного рокстара".
Не всем дано делать сверх работу. А кому-то дано, но еще дорасти надо. Любой HR начинает с простого и обычного, а там - можно вырасти и в прекрасного эксперта. Но может не получиться, ведь "Давайте наймем челвоека, который умеет читать код, а остальным не будем давать возможности расти".
RTFM13
11.02.2022 20:32А разве задача ХР не просто договориться о собеседовании и прояснить административные вопросы?
С каких пор ХР определяют квалификацию программистов?
kotandvla
11.02.2022 20:52С тех пор как на HR повесили первичный отбор из большого потока людей, когда есть несколько фильтров - поглядеть резюме, пообщаться по человечески, позадавать вопросы из чек-листа.
Про квалификацию - вопрос скорее в том, чтобы увидив человека с плохими софт-скилами, иметь в виду/понимать/быть обученным тому, что данный человек как кодер может быть хорош. А его могут отшить, т.к. он не прошел базовый фильтры текущего процесса отбора.
gremsta
11.02.2022 21:16Вообще говоря, задача XP более высокоуровневая - оценить, подходит ли кандидат в существующий проект/команду или нет. Хар-скиллы, по-хорошему, должны быть за пределами его поля зрения.
Areso
12.02.2022 12:52Вообще говоря, задача XP более высокоуровневая - оценить, подходит ли кандидат в существующий проект/команду или нет.
Как эйчар может это сделать, если у эйчара нет ни малейшего представления ни о проекте, ни о команде? Даже in-house.
yorgo
10.02.2022 14:45+23софтскиллов типа говорить, выглядеть, одеваться и улыбаться
Мне всегда казалось, что софтскиллы это про:
не переходить на личности в код-ревью
адекватно реагировать на конструктивную критику
внятно и вежливо выразить свою точку зрения
заранее оповещать начальство о смещении сроков
задавать вопросы когда не понятно, а не биться головой о стену часами и днями
правильно расставлять приоритеты в задачах
не греть рыбные котлеты в микроволновке
Akon32
10.02.2022 17:58+3А как вам "софтскилл" писать гадости, но добавлять "))))" в конце, чтобы выйти сухим из воды? Хуже всего, что это работает.
Radisto
10.02.2022 18:19+3наверное так и есть)) во втором пункте у вас правда есть термины "адекватно" и "конструктивную". Как показывает жизнь, они чрезвычайно субъективны и их диапазон не у всех людей совпадает.
via-site
11.02.2022 11:20+1"не греть рыбные котлеты в микроволновке" - один раз согрешил)) и жалел об этом ещё очень долго!
Mirn
11.02.2022 15:47+1А я просто проветрил кухню и отмыл микроволновку пока никто не заметил и не учуял.
Вывод: софтскилы это ещё и умение понимать, принимать и вовремя исправлять свои провинности перед другими. Желательно быстро и незаметно для окружающих.
IvanIvanc
10.02.2022 13:41+2Так по первому пункту из этого "разбора" не пройдут большинство программистов, когда люди весь день в коде то болтология не про них
goldrobot
09.02.2022 16:37+67Я бы сказал несколько по другому
Если человек не является хорошим спикером, то он обречён.
Умение волочить языком это фактически самое полезное в жизни людей, к сожалению.
Умение казаться, а не быть, вот что позволит вам быть на волне успеха.
Andruh
09.02.2022 17:01+25Ну да, ценой небытия.
vkni
09.02.2022 18:06+1Сильный афоризм.
spmbt
09.02.2022 19:33+26Переформулируем:
Умение казаться, а не быть -
Вот, что позволит вам
Поймать волну успеха.
Ценой небытия.
Hardwar
09.02.2022 23:13+12Канонiчно в три строчки:
Умение казаться, а не быть -
успех.
Ценой небытия.
Metotron0
10.02.2022 00:32+15Умеешь коль не быть, а лишь казаться,
Успех познаешь в качестве награды.
Но стоимость его прими смиренно:
Небытие — цена того успеха.
SquareRootOfZero
10.02.2022 09:47+4Умеешь коль не быть, а лишь казаться,
Желаешь коль не жизни, а эрзаца —
Успешен будешь, как Эдита Пьеха.
Небытие — цена того успеха.
SquareRootOfZero
10.02.2022 08:24+42Умение казаться, а не быть —
Вот что позволит вам на всё забить,
Поймать волну ценой небытия
И деньги получать за нихуя.
Suor
09.02.2022 17:11+13Умение формулировать свои мысли - это не умение казаться
RTFM13
09.02.2022 18:16+22Я бы еще разделил устную речь и письменную.
По моим наблюдениям, "хорошо подвешенный язык" используется самостоятельно и к навыкам программирования не имеет ни малейшего отношения. В маркетологах или менеджерах такой скилл можно монетизировать более эффективно.
tommyangelo27
09.02.2022 19:13+7Я бы еще разделил устную речь и письменную.
Вот тут двумя руками «за».
На письме есть время остановиться и подумать, перечитать уже написанное, поправить. Отрефакторить, так сказать. А в разговоре, и тем более выступлении на конференции, например, такой возможности нет.
Bigata
09.02.2022 19:23+3Вот прямо в яблочко. Обычно много всяких балаболов лепят все подряд, а на практике оказывается, что в лучшем случае гугель или перевесить свои проблемы на другого
DummyBear
10.02.2022 13:26Я бы разделил умение удерживать внимание аудитории и умение объяснять. Под хорошо подвешенным языком чаще подразумевают первое, чем второе.
PendalFF
12.02.2022 00:30+1Хорошо подвешенный язык это просто "аудиокарта с хорошим процом"
Также как визуализация 3д в голове не у всех поддерживается.
С общим уровнем интеллекта коррелирует но как достаточный признак, а не необходимый.
Проще говоря - человек с повешенным языком вряд ли совсем уж дурак, но без оного может быть и умнее
saboteur_kiev
10.02.2022 02:23+2Умение волочить языком это фактически самое полезное в жизни людей, к сожалению.
Учитывая, что именно язык сделал человека человеком (а не дубина), сожаление непонятно.
FF_hunter
10.02.2022 10:41+2Скорее всего, автор исходного комментария подразумевает сожаление о том, что в технических IT профессиях софт-скиллы сейчас ставят на несколько ступеней выше, чем хард. В этом я с ним полностью согласен, нельзя доводить требование наличия какого-либо навыка до абсолюта.
Сам же зашел в статью, только чтобы увидеть
компании ... предлагают порешать задачки
Это было первое, о чем я подумал, прочитав заголовок статьи. Очевидно и логично. Про некоторые нюансы взаимодействия участников процесса разработки внутри команд тоже было интересно узнать.
nulovkin
10.02.2022 11:03Меня порадовала эта экстраполяция, но, на самом деле, я имел в виду, что у меня могут быть проблемы с изложением мыслей, и испугался, что это может мне помешать, вот и все.
goldrobot
10.02.2022 14:56+1Сожаление в том, что этот инструмент сейчас является API с легаси накапливаемым тясчелетиями. И, как в любом легаси, в нем множество недочетов и бэкдоров, о техническом долге же вообще лучше не заикать. Но и отрефакторить это легаси не представляется возможность, ибо апаратная составляющая уже давно зафиксированна на эту, старую, версию. Да и совместимость очень важна.
А ведь было бы очень полезно отрефакторить часть API, которая предоставляет функционал управления другим собеседником через интонации, позы, и прочее. На даном этапе развития, я считаю, стоит сильно подрезать эти публичные методы.
Suor
09.02.2022 17:10Если программист не может сформулировать свои мысли на естественном языке четко, понятно и лаконично, то скорее всего и код у него так себе. И то, и то можно усовершенствовать, так что необязательно обречён.
F0iL
09.02.2022 19:33+56Тут есть большая разница, что при программировании мы пишем код, многократно его рефакторим, реорганизуем, исправляем ошибки, и оценивают его уже по итоговому результату - то есть это ближе к письменной речи. Разговорная речь (спикерство) же представляет собой совершенное другое, она является real-time процессом без возможности остановиться, поревьюить сказанное, отмотать сказанное назад, переписать начало фразы или пару предыдущих фраз и продолжить.
Поэтому я вполне могу себе представить человека, который очень хорошо пишет код и тексты, но плохо толкает речи вживую.
pankraty
09.02.2022 23:00+5Не оспаривая написанного вами, всё же отмечу, что человек, способный стройно сформулировать мысль в режиме реального времени, без тщательного рефакторинга, - и в написании кода может оказаться более продуктивным, т.к. он будет получаться логичным с первого раза, без многократных переделок.
ShadowTheAge
10.02.2022 12:38+3... А может и не оказаться
Даже написание кода с первого раза происходит с изрядным обдумыванием, а не "что вижу то и пишу".
via-site
11.02.2022 11:26-2Часто встречал такую категорию людей как "академики". На словах они Лев Толстой, а на деле **й простой!
StupidMouse
10.02.2022 10:38Поэтому я вполне могу себе представить человека, который очень хорошо пишет код и тексты, но плохо толкает речи вживую.
принимая во внимание то, что адрессатом такой речи обычно выступает человек, а программы пишутся в первую очередь для машин, вообще легко. конечно многим хочется впоследствии легко читать эти тексты вместо машин, но это уже вопрос отдельного обсуждения, вероятно
PrinceKorwin
10.02.2022 12:30+4а программы пишутся в первую очередь для машин
Вот за это я и ругаю своих программистов. В первую очередь программы пишутся для программистов. Им потом этот программный код сопровождать.
А трудности перевода исходного кода в машинный меня мало волнуют - для этих целей умные люди придумали крутые инструменты.
utyftrut
11.02.2022 07:39Программы пишутся для тех, кто их будет эксплуатировать. А правильное проектирование любой вещи, должно предусматривать и возможную потребность в ремонтопригодности, а также просчитать реалистичный бюджет для поддержания работоспособности премета разработки. Кроме того предумотреть срок и условия эксплуатации предусматривающие замену проектируемого на что-нибудь другое и поставить об этом в известность тех, кто будет это эксплуатировать. Очевидно же.
Кроме этого, ремонтник, проектировщик и сборщик это разная специализация. Создание алгоритмов для решения задачи, перевод их на язык программирования и сопровождение программ - специальности разные. И способы подбора в команду этих людей тоже должны быть разными.
z1024
10.02.2022 17:20Те кто складно в realtime говорят - это наверное те Чак Норрисы, которые могут задачки типа medium и hard закодить на бумажке с 1й попытки)
monah_tuk
11.02.2022 02:57+6Ага. У меня экспромтная речь крайне плоха. Как и оперативный поиск аргументов. При этом мне легче изложить мысль письменно, упорядочив всё. Для спора и принятия решения здесь и сейчас это такое себе, но и код же пишется не сидя на сковородке.
И я тут подумал, нужно про почерк добавить. Ну а что? Плохой почерк - плохой программист.
SlimShaggy
11.02.2022 10:40Мне кажется мы скоро писать вообще разучимся, потому что ручку берем максимум пару раз в год чтобы каракулю в документе поставить. Какой почерк?
dolovar
11.02.2022 11:37+1Большую часть рабочего дня я молча общаюсь с клавиатурой и мышкой. Исключения — митинги, на которых я большую часть времени слушаю, и общение с семьей, где контекст подразумевает совсем не те темы и фразы с терминами, что на собеседованиях и докладах. Соответственно, навык публичных выступлений атрофируется за ненадобностью — в этом и состоит аналогия с почерком.
А в статье предлагается считать лучшим разработчиком того, кто вместо молчаливого изучения кода и перелопачивания документации выделяет время на практику краткой и понятной, емкой и точной разговорной речи. Причем не как с клавиатуры, когда можно спокойно обдумать, свериться, отредактировать, а в ходе живого диалога. Причем не как в курилках и на кофепойнтах, где можно короткими фразами эмоции выражать, впечатлениями делиться, а длинными гладкими конструкциями, как в кино. Следуя аналогии, хорошим технарем предлагают считать того, кто умеет писать красивым почерком, владеет навыком калиграфии. И, как в статье, можно даже озвучить «доказательство» — при письме ручкой по бумаге и при наборе кода с клавиатуры задействованы одни и те же области мозга, ученые доказали.
zynaps76
11.02.2022 14:46В статье не говорится про "говорить, как в кино". И более того: в статье явно указано, что это не 100% метрика и далеко не единственная. Скорее,- штрих к портрету... А вообще, да, умение говорить кратко, емко и по делу - благо, как для самого программиста, так и для его окружения. ;-)
Myxach
09.02.2022 15:08+75Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференция
У вас есть статистика? Просто...сколько программистов работают над известными проектами и столько появляются на конференциях? И Естественно, мы видим чаще хороших спикеров на конферециях, ибо их и выбирают, ну это не значит что только они хорошие программисты.
Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний.
Как у вас в детсом саду? Или где ещё пытаются впечатлить жаргонизмом
Phoen
09.02.2022 15:12+4Велика вероятность, что таким образом человек пытается впечатлить слушателя, замаскировать неуверенность в себе, или скрыть отсутствие опыта и реальных знаний.
Я тут подумал что это в целом описывает процесс среднего собеседования. Хоть в толковый словарь заноси.
syfim
09.02.2022 15:20-5Речь же не только про открытые конференции. Во многих компаниях практикуют регулярные внутренние митапы (иногда даже "добровольно-принудительные"), и корреляция между хорошим текстом/речью и скилами коллег отлично прослеживается)
Metotron0
09.02.2022 15:22+2только они хорошие программисты
В вашей цитате написано, что хорошие инженеры часто оказываются хорошими спикерами, а не то, что хорошие спикеры становятся хорошими инженерами. Хотя в статье речь как раз об этом, но тогда цитата была выбрана неправильно.
А то, что не все хорошие инженеры появляются на конференциях, не противоречит ни цитате, ни посылу статьи. Для опровержения цитаты, к примеру, нужно не считать, сколько хороших инженеров не поехали на конференции, а считать, сколько спикеров из их числа не стали хорошими.
На счёт детского сада не знаю, но какова причина использования людьми таких слов? "Эта багулина фиксится одной тулзочкой из моей репы, вот тут пропсики прокинуть и несколько рулесов в конфиг прописать"
Myxach
09.02.2022 15:24+2хорошие спикеры становятся хорошими инженерами
Это было бы ещё больше чушьи, речь как раз о том, что хорошие инженеры являются хорошими спикерами
Metotron0
09.02.2022 15:30+1Пожалуй, да, в статье только обратные примеры, что человек со сбивчивой речью вряд ли будет писать хороший код. Там не про то, как найти хорошего, а как отсеять плохих.
Но из этого всё равно не следует, что хорошие программисты — только те, кто выступают с докладами. Которые выступают, те скорее всего хорошие, но не только они.
Devilar
09.02.2022 15:46+5Я бы даже больше сказал, что хороший спикер это хороший спикер, а хороший программист это хороший программист, эти области пересекаются, но не всгеда спикер именно представитель этого пересечения.
Rukis
10.02.2022 16:35+1Вот тоже хотелось бы посмотреть на статистику. А то логика конечно интересная получается и не следует ли из неё, например, что люди с заиканием склонны к дублированию кода... Строить связь именно с устной речью (тем более со спикерством) - не убедительно, там же ещё столько социальной психологии замешано, которая к коду отношения не имеет.
alexeishch
11.02.2022 11:30У меня есть обратный пример. На прошлом месте приходил CTO, который участвовал в конференциях, но по факту оказался слабее любого лида в компании. Вот это был ад, которого я никому не пожелаю
Tomok
09.02.2022 15:17+27Первый пункт оценивает процесс написания кода или результирующий код?
Странно оценивать финальный код разработчика по его вербальным способностям, ведь в итоге код можно вылизать, чего нельзя сделать со своими фразами в разговоре.
mrise
09.02.2022 19:14+1С другой стороны, у каждой задачи есть срок, и порой он очень жёсткий. Так что умение выдавать что-то сносное под давлением времени - неплохой навык для разработчика.
Однако, я не могу отрицать, что полученная оценка является, в лучшем случае, склонна к ложно-отрицательным, а в худшем - и к ложно-положительным результатам.
goldrobot
09.02.2022 21:10+14Я ниразу не видел прямой зависимости между умением быстро и резко болтать, и быстро писать хороший код.
Я даже наоборот скажу, те кто не самый болтливый, в моем опыте, обычно побыстрее и получше код пишут.
omxela
09.02.2022 22:23+1кто не самый болтливый, в моем опыте, обычно побыстрее и получше код пишут.
Насколько я понял, речь идет чуть-чуть о другом. Вы можете быть молчуном, почему бы нет. Но если у вас возникнет необходимость что-то объяснить, то вы сделаете это ясно, понятно, и, конечно, лаконично.
t_kanstantsin
09.02.2022 23:29+5Или не сделаете. Не вижу никаких доказательств того, что умение писать код как-то коррелирует с умением объяснять (и уж тем более понятно и лаконично).
На примере спикеров из статьи невозможно сказать, как хорошо они что-то объясняют "сходу" - их доклад подготовлен заранее, вопросы проработаны. И я не раз видел, как после доклада спикер не мог толково ответить на вопросы.
AVX
11.02.2022 23:02+1Потому что те, кто умеют хорошо говорить (без пауз, без слов-паразитов, и с нужной интонацией/жестикуляцией), обычно делают это ценой добавления большого объёма "воды" в речь. То есть речь выглядит красиво, легко воспринимается, но там просто вместо "слов-паразитов" и "мычания", как иной раз говорят программисты, часто бывают фразы и выражения "общего" характера, которые служат только цели сохранить темп речи и обдумать в это время основную мысль.
При написании кода "вода" не нужна, её наоборот пытаются убрать и сделать код более лаконичным. Да и в речи - краткость - сестра таланта.
WraithOW
09.02.2022 15:21+71TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность
Это отличный аргумент, если у вас в компании принято первый драфт лить в продакшн. Во всех остальных случаях код, в отличие от речи, проходит несколько итераций правок, прежде чем принять окончательную форму и уехать в репозиторий. Редактура художественных текстов — вообще отдельная профессия.
Даже вот этот коммент я пару минут помусолил туда-сюда, прежде чем меня начали устраивать форма и содержание.Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях
И эти тематические конференции во всю нанимают профессиональных тренеров по выступлениям, которые помогают спикерам подготовиться, составить структуру, проработать темп подачи.
Умение выступать (да и вообще поставленная устная речь) — это отдельный, ортогональный инженерному делу навык. Пособеседуете бывших продажников — поймете, о чем я.Suor
09.02.2022 17:15-17Умение говорить отражает умение формулировать мысли. Если человек этого не умеет, то он может очень долго вылизывать, но код всё равно будет плох.
Я бы ещё добавил, что если в голове каша, то и в речи будет каша и в коде. Так что можно использовать как признак.
RTFM13
09.02.2022 18:37+14Я бы по-другому сказал. Речь это произведение умения думать на умение говорить.
И если умение думать отражается и на коде и на речи, то умение говорить - только на устной(!) речи. По этому при идентичном ораторском скиле мы имеем самые разные соотношения умений думать и говорить и, соответственно, самые разные уровни программирования.
С учетом немалого количества социопатов в программерской среде, я бы не стал ориентироваться на ораторские способности. Тем более это не интересно их непосредственным руководителям, т.к. навыки программиста под вопросом, за то очевидна потенциальная конкуренция.
bruian
11.02.2022 15:43Полностью поддержу адекватного человека. У Google вообще есть HR программа по найму людей с аутическим спектром, так многие из них вообще не склонны к общению. И такие люди в приоритете. Как правило они больше делают, чем говорят.
nsinreal
09.02.2022 16:00+7TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне: разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код. То есть язык программирования является такой же формализацией образов из мышления в конкретную систему символов и правил, как и любой другой человеческий язык.
У данной идеи есть некоторые разумные основания, но… Устная речь была нормальным прокси только в старое время. Потому что в старое время не было асинхронных чатов. Потому что сейчас можно буквально думать об notepad, компенсируя недостаток кратковременной памяти. Потому что сейчас можно написать тесты на код, а не пытаться удерживать все решение в голове. И т.д., и т.п. Время изменилось, прокси-оценка стала хуже работать.
Throwable
09.02.2022 16:10+88Сбивчивая речь и непоследовательность в изложении мыслей
Извините за токсичность, но брехня и полная чушь!
при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи
Даже при восприятии и формировании устной речи задействованы совершенно разные участки мозга, это вам подтвердит любой физиолог или даже человек, изучающий иностранный язык. Понимать речь и владеть ею -- это совершенно разыне навыки. И при многих поражениях речевого аппарата у человека как правило сохраняется возможность понимать речь и уж тем более мыслить.
разработчик сначала придумывает абстрактное решение в голове, как раз используя логические функции мозга, а затем происходит перевод этой абстракции в фактический код.
Бред! Абстрактное мышление вообще практически никак не связано с речью. Мы мыслим не речью и даже не символами, а некими абстрактными образами. Никаких "логических функций мозга" на этот счет не существует.
Речь -- это строго упорядоченная во времени система сообщений, тогда как мыслительный процесс, реализуемый нашей головной нейросетью, по большей части параллелен, неупорядочен, и многоуровнен. Когда программист "в потоке", он в голове держит сразу огромное количество абстракций, которые в процессе детализирует, постоянно перемещая фокус внимания от одной к другой. И код мы пишем не как вы изложили выше -- "от забора и до обеда", а во многих местах сразу, не особо заботясь о последовательности написания. Кроме того в момент особой концентрации на задаче перестает хватать "ресурсов" мозга на задействование речевого аппарата. Плюс зачастую речь просто не поспевает за мыслью, о скорости которой уже издревле сложились мемы. Поэтому за столом мы как правило видим программиста, судорожно шепчущего под нос непонятные слова, а не оратора, вещающего трактат о решении задачи.
Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста. И наоборот -- плавность и последовательность будет либо говорить о домашней заготовке, либо содержать наивные и поверхностные суждения, скорей всего ввиду ограниченности самого субъекта.
Сильные инженеры нередко оказываются хорошими спикерами — именно их вы чаще всего можете увидеть выступающими на тематических конференциях.
Однако, заведомо будет справедливо, что хороших инженеров, НЕ выступающих на конференциях, гораздо больше. Кроме того, излагать заранее подготовленный доклад -- совсем не то, что излагать свои мысли в реальной работе.
beerchaser
09.02.2022 16:57+23К Вашей аргументацтии я бы добавил, что хорошие выступающие спикеры готовят и репетируют свое выступление заранее, в то числе и возможные вопросы/ответы. Причем тема выступления известна заранее+уже есть опыт публичных выступлений. В случае с собеседованием все не так однозначно :)
Kreastr
09.02.2022 17:17Согласен. Да и вообще для того чтобы быть хорошим спикером лучше всего иметь очень хорошую долгосрочную память. Текст готовится заранее, полируется, заучивается, репетируется. Вот то как человек отвечает на дейстивтельно неожиданные вопросы можно было бы сравнить хоть как-то, а сами выступления - увы нет.
CampoT1P
09.02.2022 18:18+2Перед собеседованием тоже можно подготовить свое "выступление" заранее, включая вопросы и ответы. На N-ном собеседовании пересечение ваших заготовок с заготовками интервьюера будет достаточным, что бы вас посчитали хорошим
спикероминженером и выслали оффер.
Diamon33
09.02.2022 19:41+25“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.
edo1h
09.02.2022 23:51+1Так что именно затрудненная и непоследовательная речь будет скорей всего признаком хорошего программиста
не уверен, что это именно так работает, не удивлюсь, если вообще нет значимой корреляции между ораторскими способностями и программированием.
но вот если человек не может связно излагать свои мысли письменно — то это уже, думаю, нехороший звоночек.Throwable
10.02.2022 12:37+1Ну это было высказано в качестве контраргумента исходному тезису :) По манере речи и письма можно сказать об общем культурном уровне и образовании человека, который в общем случае может коррелировать с техническими навыками. Кроме того, речь -- это такой же скилл, который при желании и необходимости можно прокачать.
SquareRootOfZero
10.02.2022 09:43+2Бред! Абстрактное мышление вообще практически никак не связано с речью.
Гипотеза лингвистической относительности предполагает, что структура языка влияет на мировосприятие и воззрения его носителей, а также на их когнитивные процессы. Лингвистическая относительность широко известна как гипотеза Сепира — Уорфа. Выделяют две формулировки этой гипотезы[1]:
Строгая версия: язык определяет мышление, и, соответственно, лингвистические категории ограничивают и определяют когнитивные категории.
Мягкая версия: язык только влияет на мышление, и наряду с лингвистическими категориями мышление формируется также под влиянием традиций и некоторых видов неязыкового поведения.
Гипотеза небесспорная, особенно в своей «строгой» версии, но чтобы вот прям бред?..Throwable
10.02.2022 13:28Я бы сказал не небесспорная, а как раз очень даже спорная, по которой уже 100 лет не утихают дебаты.
Главным камнем преткновения в дискуссии о лингвистическом релятивизме является проблема корреляции между языком и мышлением. Самой строгой формой корреляции является лингвистический детерминизм, который предполагает, что язык полностью определяет все возможные когнитивные процессы индивида.
и
Основной спорный вопрос формулируется так: являются ли высшие психические функции по большей части универсальными и врождёнными или же они представляют собой преимущественно результат обучения и, следовательно, являются субъектом по отношению к культурным и социальным процессам, которые варьируются в зависимости от места и времени.
На мой взгляд интерес к теме черезмерно раскручен ввиду ее коммерческой перспективности: вся рекламная индустрия и рынок основан на когнитивной лингвистике. А там где рынок, там и бабло водится. Поэтому очередные "исследования" щедро спонсируются заинтересованными физ- и юр-лицами. А чтобы поток денег не прекращался, никто не заинтересован поставить финальную точку в этом вопросе.
Если уж брать язык как средство коммуникации и записи мыслей в общем смысле, то он не ограничивается исключительно лингвистикой и речью, которые по сути очень примитивны. Есть более компактные и емкие способы изложения и восприятия информации, которыми люди пользуются в технических областях: язык математически, графики и диаграммы, чертежи, рисунки наконец. И естественно соответствующие специалисты за свою карьеру прокачивают в первую очередь свои технические навыки, нежели разговорные. Ну а если вам нужен кандидат со связной речью -- идите искать на филфак.
2morrowMan
09.02.2022 16:25+22По своим наблюдениям добавлю еще один пункт с большой долей вероятности плохого программиста: человек перестал или стал меньше программировать и пошёл учить других в онлайн-школы программирования ;)
panzerfaust
09.02.2022 17:40+5Да просто "пошел учить" вполне достаточно. К сожалению, есть такой сорт старших разрабов, которые не хотят идти в менеджмен или архитектуру, но и обычный кодинг им уже осточертел. Вполне вероятны фокусы типа "а давайте наймем 5 джунов - а я их буду менторить (а кодить больше не буду)"
adictive_max
09.02.2022 19:07А если пошёл вести вечерние курсы для студентов 2 раза в неделю по 2 часа - это уже достаточно, чтобы хоронить, или надо всё-таки дождаться, когда на фулл-тайм уйдёт?
panzerfaust
09.02.2022 19:18+1человек перестал или стал меньше программировать и пошёл учить
Вроде булева алгебра тут несложная
goldrobot
09.02.2022 21:19+4Это вероятно вечерние курсы для студентов 2 раза в неделю по 2 часа сказываются.
PS: Извините, но было сложно удержаться.
spmbt
09.02.2022 19:50Пойти в менеджеры или аналитики - тоже вариант. Есть много аналитиков с хорошей вузовской подготовкой (знания, языки прог., алгоритмы, кругозор), которым практика программирования как-то "не заходит" и находят такой вариант приобщения к профессии, который так и остаётся основным.
tommyangelo27
09.02.2022 19:20+5Вспоминается цитата из Пратчетта:
Похоже на то, что ты не обладаешь абсолютно никакими полезными навыками или талантами, — заявил Хвиляга. — А ты никогда не задумывался над тем, чтобы заняться преподаванием?
Ndochp
10.02.2022 13:22+2У Прачета была еще более подходящая цитата, но быстро не нашел. Там было про построение длинной сложноподчиненной фразы, высказав которую аркканцлер гордился, что сумел её выдать не задействовав мозг.
vesper-bot
10.02.2022 15:48+4– Со всем уважением, лорд Витинари, – прервал его аркканцлер, – позволю себе заметить: раньше действительно считалось, что драконы вымерли, однако новые данные, осмелюсь заметить, заставляют несколько усомниться в этой теории.
Что же касается среды обитания, то данный случай является очередным примером изменения поведенческого образца, что было вызвано расширением городских территорий и распространением их на сельскую местность, в результате чего многие доселе дикие существа перешли, более того, во многих случаях прямо-таки рванулись к более цивилизованному образу жизни, и многие из них процветают благодаря новым, открывшимся перед ними возможностям.
Например, с недавних пор в университетские мусорные баки повадились лазать лисы…
Аркканцлер сиял. Он ухитрился выдать всю эту тираду, практически не задействовав мозг.
rodion-m
10.02.2022 10:43+6Удивляет сколько лайков набрал ваш комментарий. А потом на каждом шагу говорят мол "как же плохо сейчас учат программистов". Так кому их учить, если столь популярно такое мнение, как ваше? Вот есть хороший специалист, допустим, и для дела было бы полезнее, если бы он хотя бы понемногу начал преподавать (час-два в неделю), делиться своим опытом. Преподавать-то некому, вот и идут туда зачастую проходимцы - так лучше уж будут преподавать опытные спецы, но без педагогического опыта, чем вчерашние (или сегодняшние) студенты совсем без опыта работы программистом. Ибо "профессиональный программист-педагог" - это, конечно, большая роскошь. Сходу только Тимофей Федорович Хирьянов приходит на ум.
ЗЫ. Понятно, что такой коммент в блоге онлайн школы программирования действительно выглядит иронично :) поэтому надеюсь, вы просто пошутили)
Dlougach
09.02.2022 16:38+12Я не очень понимаю, как вы собираетесь в первом пункте понимать, что у кандидата, например, афазия, но хорошо замаскированная. И вообще логика в духе "корреляция достаточно высока, чтобы можно было ей пользоваться" опасна тем, что создают предрассудки — так, знаете ли, и пол, и цвет кожи вам могут дать какую-то достаточно высокую корреляцию.
Diamon33
09.02.2022 19:46+2Я думаю, ответ тут будет такой же, как и в большинстве американских компаний, у которых избыток кандидатов - "лучше не нанять хорошего, чем нанять плохого" ("потому что можем себе позволить"©). Если эта корреляция помогает следовать вышеуказанному правилу, то будут использовать ее. Ну а с полом и цветом кожи/расой и ориентацией уже квоты придумали для корректировки.
2ANikulin
09.02.2022 16:52+22Ох, ребята. Знавал я людей с подвешенным языком, котрые могли забалтать. Но пользы проекту они наносить не умели. Долго делали, много думали. Нет здесь четких критериев. Инициативность и вовлеченность, вот пожалуй главные.
Format-X22
09.02.2022 17:07+1Главное на этой почве не отсекать тех кто и говорить умеет - и делать дело. А то бывает.
2ANikulin
09.02.2022 17:10+2Да, пока с человеком не поработаешь - не поймешь. И никакие формальные правила прогнозирования здесь не работают
spmbt
09.02.2022 19:56Есть формальное положительное правило: если в беседе или в решении задачи чел легко переключается на более глубокий уровень анализа, привносит новую мысль (но тут и самому надо представлять круг возможных идей), разворачивается на другое решение - хороший специалист. Но тоже отсеивать нельзя, потому что говорить и одновременно думать над кодовым решением, озвучивая мысли - далеко не все могут, этому нужно учиться большинству.
garwall
09.02.2022 17:26+7Про Дейкстру.
Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
spmbt
09.02.2022 20:13+1Так он ведь и сам - с хорошо подвешенным языком, и программист далеко не последний. И методист. Конечно, он знал, что умение формулировать мысли добавляет много плюсов умению программировать.
omxela
09.02.2022 22:32+3Есть такая хорошая фишка, я сам её использую время от времени. Если въехал в проблему, а вот чего-то не хватает, чтобы сделать, - попытайся вслух внятно, ясно, объяснить это другому человеку, даже если он не специалист в данном вопросе. Где-то посередине процесса нужная мысль приходит. Но самое смешное, что у слушателя возникает (пусть на миг) иллюзия понимания. Всем хорошо.
VYudachev
09.02.2022 17:42+14Как плохой разработчик, скажу
Если в компании не используют X, в этой компании не надо работать;
Если в компании разработчик решает, какой цвет тени будет смотреться лучше, в этой компании не надо работать. Серьезно, эти вещи либо должен решать специально обученный дизайнер, либо все должно быть заранее решено и браться из дизайн-бука.
Если же он может донести глубокую мысль понятным образом в несколько слов, то и в коде он будет прост и нагляден.
Хорошая мысль, но несколько однобокая. Фейнман понятным образом изложил КЭД, но серьезно учат её все-таки больше по непонятному изложению Фейнмана или книгам Ландау-Лифшица. Сложность многих моделей ограничена снизу и серьезно упростить ее с получением на выходе эквивалентного результата может оказаться невозможно. Некоторые мысли при изложении в несколько слов существенно теряют в глубине. Другое дело, что от по-настоящему умного человека, который не ставит первоочередной целью произвести впечатление, ты практически никогда не услышишь слов, значения которых не знаешь.
«сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать.
Ну да, ну да. Заказчик скажет, что такая проблема не реальна. А когда вся система ляжет на проде из-за того, что два запроса от разных пользователей конкурируют за общий слот, заказчик скажет, что это его вина и никаких претензий к разработчику он не имеет. Именно так это и работает.
— Задачи такого рода нужно всегда решать именно так;
Разработчик, решая задачу, которая уже неоднократно решена в проекте, подключает для этого стороннюю библиотеку, потому что она решает эту задачу лучше (как ему кажется), или ему просто хочется ее попробовать.
Это может быть случаем «синдрома утенка», когда разработчик просто «прикипает» к подходу, который он применил для решения аналогичных задач в первый раз, романтизирует его и с тех пор продолжает пользоваться только им.
М-м-м, вкуснота, взаимопротиворечащие параграфы подвезли! А что, если сторонняя библиотека и правда решает эту задачу лучше? Вот только этого не удастся узнать, пока не попробуешь. Чтобы развиваться профессионально, нужно много узнать, а для этого надо постоянно интересоваться чем-то новым.
merlin-vrn
10.02.2022 14:04+2Фейман не то, чтобы "понятным образом изложил" КЭД. Это не изложение в том смысле, чтобы её можно было использовать по назначению или развивать. Это — красивая иллюстрация, чтобы домохозяйки поняли, о чём это. Конечно, так учить КЭД нельзя.
Однако, сама способность выдать такое изложение показывает нам, что Фейнман прекрасно ориентировался в теории. Именно этого эффекта ожидают и от кандидатов на собеседовании: если он может "изложить КЭД в нескольких словах", наверное, он глубоко ориентируется в теме.
VYudachev
10.02.2022 14:15Спасибо за интересное и хорошее замечание. Главное, чтобы собеседования проводил тот самый специалист, который сможет всё правильно различить. Правда, у меня у самого десять томов теоретической физики на данный момент больше предметом интерьера служат, надеюсь, когда-нибудь все же смогу осилить.
merlin-vrn
11.02.2022 09:06+1А там ничего сверхъестественного нет. Математики много, но довольно однообразной, за пределы исчисления многих переменных и комплексного, а также диффуров и линейной алгебры очень редко выходит. Ну и комбинаторика и теория вероятностей в статфизике ещё. Это осилить — просто тупо очень много работы.
johnfound
09.02.2022 18:12+3Не, вообще то я плохой программист и могу себе позволить:
– Свободные решения лучше несвободных!
– Линукс лучше Винды!
– Со временем все перепишут на ассемблере!
– Java и C# отстой!CampoT1P
09.02.2022 18:28+5– Свободные решения лучше несвободных!
– Линукс лучше Винды!
– Java и C# отстой!
Это еще можно понять
– Со временем все перепишут на ассемблере!
Но это слишком толсто)
johnfound
09.02.2022 18:36Как раз это тот тезис, которого можно доказать даже формально. А верхние три – так, вкусовщина.
CampoT1P
09.02.2022 18:48Докажите, я пока упорно не верю)
johnfound
09.02.2022 19:06+2Ну, если совсем коротко: Возможности вычислительной техники ограничены законами физики. А программы развиваются всегда в направление к усложнению. Поэтому код со временем должен быть все более и более оптимизированным. А каждая оптимизация рано или поздно доходит до ассемблера. Конечно не сразу и возможно очень даже медленно.
CampoT1P
09.02.2022 19:26+1Возможности вычислительной техники ограничены законами физики.
Ограничена возможность линейно наращивать производительность в рамках конкретной архитектуры, не более.
Поэтому код со временем должен быть все более и более оптимизированным.
Либо превращать приложение в тонкий клиент, и переносить все вычисления в датацентры, которые можно масштабировать до бесконечности...
johnfound
09.02.2022 23:18+2Масштабировать до бесконечности можно, но только если говорим о бесконечное число пользователей. А для одного пользователя, производительность всегда будет конечной и не факт что выше чем на локальном компьютере.
indestructable
09.02.2022 20:08Усложнение может быть "горизонтальным" - больше функций, вместо вычислительного усложнения текущего функционала
johnfound
09.02.2022 23:16Ну и что? Память тоже не бесконечная. А программы на ассемблере одновременно и меньше и быстрее.
ReadOnlySadUser
10.02.2022 17:22+4Что требуется в очень ограниченном количестве случаев. Тот факт, что чуть ли не каждая первая десктопная программа нынче - это electron, говорит нам, что тезис о том, что весь софт перепишут на ассемблер - не верен.
В этом мире миллион программ, пользователи которых готовы мириться с их ограниченной производительностью, потому они навсегда останутся написанными на чем-то медленном)
johnfound
10.02.2022 21:23+1Во первых, может это у вас только electron. На моем компьютере нет ни одного приложения работающее на electron. (могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится ????︎).
Во вторых, я комментировал насчёт горизонтального усложнения, для которого нужна память, а быстродействие не так важно.
0xd34df00d
11.02.2022 04:43+1На моем компьютере нет ни одного приложения работающее на electron. (могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится ????︎).
Мне, увы, нужен slack. Теперь научите обходиться без электрона (и, чтобы не читерить, без веб-морды слака).
ReadOnlySadUser
11.02.2022 09:19могу научить как сделать так, чтобы у вас тоже не были, но мне кажется что вам не понравится
Да не то, чтобы я не знал, как обойтись без приложений на электроне, вопрос в том - нафига? :) "Потому что"? :)
gremsta
11.02.2022 11:32-1Потому что не хочу видеть как кто-то или что-то просто засирает мою память в совершенно пассивном режиме. В активном там вообще гигабайтами аппетиты измеряются + тормозит вся эта срань как улитка под марьиванной:
utyftrut
11.02.2022 09:02"...готовывынуждены мириться с их ограниченной производительностью ..."ReadOnlySadUser
11.02.2022 09:11Да ну ладно уж. Взять тот же VSCode на электроне сделан. Прекрасное приложение, зачем оно на ассемблере? :) Мне его производительности хватает за глаза.
johnfound
11.02.2022 11:10Мне его производительности хватает за глаза.
Пока хватает. Да и то как вы написали «за глаза», выглядит что чуть-чуть хватает.
Но ведь здесь есть только два варианта
– VSCode продолжат развивать и он станет медленнее. А компьютеры увы быстрее не будут. И производительность VSCode вам уже хватать не будет, а будет раздражать. Поэтому придется оптимизировать старый код, чтобы можно было впихнуть новые функции не уменьшая быстродействие. В конечном итоге, придется отказываться от электрона. А если это невозможно, просто забросят проект и сделают все сначала на другой платформе.
– VSCode не будут развивать дальше. Но такие программы всегда прекращают использовать, какими бы они хорошими не были.
qw1
09.02.2022 21:04+4Ошибка утверждения в слове «перепишут». Подразумевается, что требования не меняются, и можно бесконечно переписывать старый код на более производительном языке.
В реальности, новые требования будут прилетать всё быстрее и быстрее. Переписывать что-то вообще не будет времени, и более правдоподобное предположение «Со временем всё будут писать с первой попытки на языке, который позволит побыстрее оформить требования в код».johnfound
09.02.2022 23:13Вообще-то да, конечно. В реальности именно так и получится.
Но с философской точки зрения, можно говорить о переписывание. Потому что неважно как именно называют, кто написал и на каком языке, абстрактный браузер, текстовой редактор или примерно ОС.
KGeist
10.02.2022 08:15+4Можно и по-другому аргументировать - оптимизирующие компиляторы, в т.ч. profile-guided компиляторы (особенно с динамической рекомпиляцией), идут в направлении оптимизации под конкретную нагрузку, а значит оптимизация руками будет всё менее и мене релевантна, т.к. сложно заранее предугадать, какая будет нагрузка (и какая там конфигурация сервера в данный момент, т.к. у каждого свои особенности). Да и сейчас, если дать написать ассемблер обычному разработчику, его код скорей всего будет менее оптимальный, чем код современного оптимизирующего компилятора.
Имхо, больше выгоды даст написание cache-friendly кода, правильный выбор алгоритмов (O(1) вместо O(n)), а это можно сделать и без ассемблера.
johnfound
10.02.2022 12:53Конечно можно. Но все это можно сделать и на ассемблере и будет еще лучше. Кроме того, хорошие оптимизирующие компиляторы можно сделать только для языков относительно низкого уровня типа C/C++. Для современных ООП языков типа C#, Java, Python, боюсь оптимизация получается довольно посредственной.
KGeist
10.02.2022 23:49хорошие оптимизирующие компиляторы можно сделать только для языков относительно низкого уровня типа C/C++. Для современных ООП языков типа C#, Java, Python, боюсь оптимизация получается довольно посредственной.
Собственно, вся суть С++ в том, что это С + ООП (на практике; есть, конечно, любители целиком шаблонами писать). И вот тут, как раз, рантаймы типа Java выигрывают в плане именно компиляторных оптимизаций под ООП, т.к. один из основных оверхедов это вызов виртуальных функций, и статический анализ здесь проигрывает динамическим рекомпиляциям: например, при вызове интерфейсных методов рантайм может на основе истории вызовов понять, что вот в этом конкретном месте (callsite) по факту под интерфейсом скрываются всего два конкретных класса (хотя интерфейс реализуют 9000 классов), и заменить дорогие вызовы через виртуальную таблицу (а это функция по указателю, что у многих процессоров сбивает branch prediction) на простое сравнение "если это класс А, то сделай jump сюда" (так называемый callsite cache), а может пойти дальше и полностью девиртуализировать вызов (если класс один), что сразу же позволяет активировать кучу оптимизаций типа инлайнинга. Такое ручками делать в постоянно развивающемся проекте - такое себе удовольствие. Но такие рантаймы обычно всё равно медленнее С++, просто потому, что в по дизайну в них чаще всего присутствует также сборщик мусора и отдаётся предпочтение by ref-объектам вместо value types, т.е. страдает memory locality. Не могу вспомнить, чтобы был язык с продвинутым JIT, но без GC. Было бы интересно на такой посмотреть.
KGeist
11.02.2022 00:16А, и ещё - в языках низкого уровня типа C/C++ существует проблема алиасинга, т.е. это когда мы не можем активизировать оптимизацию при работе с указателем в полную меру, потому что статически мы не всегда можем определить, есть ли ещё кто-то, кто ссылается на этот участок памяти (возможно, с другим типом). Если мы будем считать, что у указателя только один пользователь, мы можем применить далеко идущие оптимизации, но это зачастую ломает кучу кода (когда оказывается, что пользователей много - в других потоках, через type punning, это может быть несколько указателей на пересекающиеся участки массива), в итоге часто или ставят не самый высокий уровень оптимизации, или в самом компиляторе не делают оптимизацию, т.к. 99% софта надеятся на UB (не зная об этом). Вот тут как раз у более высокоабстрактных языков с чётко определённой memory model можно больше оптимизаций выжать.
0xd34df00d
11.02.2022 04:46+1Собственно, вся суть С++ в том, что это С + ООП (на практике; есть, конечно, любители целиком шаблонами писать).
Это чреватая большими проблемами интерпретация C++.
0xd34df00d
11.02.2022 04:48+1Хорошие оптимизирующие компиляторы можно сделать только для сильно типизированных языков с контролем эффектов. Чем больше у компилятора информации о семантике программы, тем лучше, и тем больше оптимизаций он может сделать, например, сливая циклы, выкидывая повторяющиеся вызовы даже к тем функциям, тела которых он не видит, и так далее.
Другое дело, что средние оптимизирующие компиляторы проще сделать для классических императивных языков вроде C или C++.
Vinchi
11.02.2022 04:36Когда дойдут до предела физического, код будет не на ассемблере. Например это будет нейроморфный чип на кубитах )
codecity
09.02.2022 19:04+4– Со временем все перепишут на ассемблере!
Берите
вышениже - на VHDL.johnfound
09.02.2022 19:08+1И это тоже. И уже. Но гибкости не хватает.
AnthonyMikh
10.02.2022 17:48Какой-то очень произвольный водораздел получается. Почему ассемблер достаточно гибок, а VHDL — уже нет?
johnfound
10.02.2022 21:39Потому что программа на ассемблере – самая обычная программа, которая загружается в РАМ и выполняется. Потом завершается и можно загрузить другую. Чтобы так программировать хардуер, понадобится совершенно другая архитектура компьютера.
khuzhinru
09.02.2022 18:26+7Понимаю, что речь идёт про общие закономерности и признаки, но меньше всего хотелось бы, чтобы меня как разработчика оценивали по качеству устной речи. Для меня, например, русский язык не родной и часто возникают проблемы с изложением своих мыслей, с плавностью речи и т.п. А что уж говорить о миллионах людей по всему миру с разным уровнем английского, которые работают или пытаются устроиться на работу.
RomanArzumanyan
09.02.2022 18:51+11То есть язык программирования является такой же формализацией образов из
мышления в конкретную систему символов и правил, как и любой другой
человеческий язык.Естественные и искуственные языки имеют разную грамматику и синтаксис. У искуственных языков нет переносного значения слов, двусмысленности высказываний, фразеологизмов. Отсутствует устная речь.
Выдвинутые в статье тезисы находятся на уровне диванной аналитики.
WASD1
09.02.2022 18:51+5По первому пункту у меня почти обратные впечатления.
В крайней точке - да корреляция есть: если речь сбивчивая, нелогичная, заторможенная (из разговора обычно ясно человек решение продумывает или банально ответ вспоминает), то и доходя до +/-технической части выясняется, что спец не очень.
Но если собеседовать джунов - то зачастую корреляция прямо обратная. Если ответы на вопросы "вылизанные" - то часто оказывается, что такой джун больше прочитал книг "как пройти интервью", чем книг "как стать хорошим программистом".omxela
09.02.2022 22:51Если ответы на вопросы "вылизанные"
Я иногда слушаю аспирантов на экзаменах. Это люди ужЕ обученные и подкованные. Тянут билет и после этого отправляются часа на 2-3 куда хотят. А потом мы беседуем. Так вот, если товарищ зубрил и даёт "вылизанный" ответ (пусть формально и правильный), то это видно с первых слов и дальше достаточно пары-тройки "отклоняющихся" вопросов, чтобы и товарищу стало ясно, что не прокатит. А вот тот, кто понимает, говорит ясно и без понтов. И его так просто не собьёшь (да и цели-то такой нет). Так что, это не обратная корреляция, имхо, а вбок.
BlackStar1991
09.02.2022 19:46Статья понравилась, но с автором по большому количеству изложеных мерил "хорошести" не согласин. Если б статья называлась как определить что перед вами Неопытный разработчик, то я бы согласился с названием. Все програмисты, (пока что люди), а у людей есть свои характеры, по тому как человек может изяснять свою речь, ещё ничего не означает. Лично я знавал крутого разраба, который с другими практически не общался, говорил короткими предложениями, но в решениях алгоритмов был докой.
Могу предложить свою формулу "хорошести" программиста.
Стоимость выполненных задачь програмиста (переведите в профит для бизнесса за месяц) / Стоисмость програмиста (в трудо часах).
Вот и получаем, что есть программисты которые лендинги клипают пачками, а есть которые Боинги запускают... Можно ли считать тех, которые приносят больше денег для бизнеса плохими программистами ? Да, если вы задаете мерила оценки. Всё остальное притянуто за уши... особенно те пункты где автор сначала пишет про велосипеды которые любят писать большинство программистов, а потом про технологии которые были выбраны этими же програмистами, потому что с ними удобнее работать.
Автор же предлагает на каждую задачу изучать свой редактор vim/emacs/eclipse/, что бы быть "хорошим" и выбирать под нужную задачу - нужный, но это противоречит его же принципу, где говориться, что не надо тратить много времени на уже решенные задачи. А ити и просить совета у более опытных, которые по факту за него потратили на эту задачу свое время.... цикл замкнулся. Ты не станеш хорошим, если не попробуешь решить сам - ты будешь плохим, если будешь решать, тратя ресурсы компании на эксперементы и саморазвитие.
dolovar
09.02.2022 20:32+6Сбивчивая речь и непоследовательность в изложении мыслей
Регулярно спотыкаюсь, обдумывая формулировку для наиболее ясного, но точного донесения мысли.
И с легкостью перехожу на другие мысли, поскольку обычно в голове крутится множество разных задач.Злоупотребление жаргонизмами и buzzwords… особенно часто это встречается у людей, которые много работали в энтерпрайзах и часто общались с менеджерами
Я много работал в энтерпрайзах и часто общался с менеджерами. Рили.Перфекционизм и идеализм… Например: Фреймворк или язык X лучше фреймворка или языка Y;
Да, я регулярно прихожу к мнению, что для задачи «альфа» лучше выбрать X, а не Y.Переусложнение или оверинженеринг… систематическое привнесение избыточной сложности в решения как на микро-, так и на макроуровне
Наспотыкавшись о необходимость перепахать кучу разного в застарелом легаси для реализации очередной фичи и практикуя системный подход с выяснением контекста и планов, я всегда привношу избыточную сложность в решения.Самоуверенность и «велосипедизм»
Я твердо самоуверен, что не может получиться великолепного специалиста из того, кто не писал и не пописывает велосипеды.Туннельное зрение… привычка основана именно на предшествующем опыте и мешает разработчику получать новый, более конструктивный опыт
Я ежедневно использую привычные инструменты и подходы, и, наверняка, иногда это мешает получать новый опыт, который, весьма вероятно, мог бы оказаться конструктивным в отдаленной перспективе.
У меня здесь остался только один вопрос — эйчары действительно руководствуются подобными, одобренными сообществом статьями для типирования кандидатов?
bullitufa
10.02.2022 08:51По эйчарам, думаю мало кто может дать полный ответ, это ж надо как минимум пройти добрую сотню интервью и "хорошо" проанализировать. И то, это не даст сколь нибудь значимый результат когда вы встретитесь с конкретным эйчаром.
vesper-bot
10.02.2022 15:51-1Ну, вот вы упускаете контекст — беседы ли, вопроса ли, утверждения ли. Это вам в минус. А в некоторых случаях, как мне кажется, намеренно его дропаете — это два минуса сразу.
dolovar
10.02.2022 16:23
Вам виднее, конечно, о оценивающий комментатор, выстраиваюший образ собеседника по прочитанному между строк. Оставайтесь на линии, ваша оценка очень важна для нас…практикуя системный подход с выяснением контекста и планов
вы упускаете контекст — беседы ли, вопроса ли, утверждения ли. Это вам в минус. А в некоторых случаях, как мне кажется, намеренно его дропаете — это два минуса сразу
Politura
09.02.2022 20:46+2TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи
А какие именно задействованы участки при изложении своих мыслей письменно? А то я знаю людей, которые говорят не очень, могут и сбиваються, и заикаются, но вот аргументировать свою позицию письменно могут прекрасно.
Ну и в целом, у этого вашего "исследования" все что есть в абстракте только одна строчка "Programming research has entered the Neuroage." походу сами исследователи даже письменно не могут изложить, что они там наисследовали, яб не стал на него ссылаться.
greenEkatherine
10.02.2022 14:37+1тоже хотела спросить автора, где хоть одно исследования для такого громкого заявления
andreyiq
09.02.2022 22:08если он тратит лишние часы на то, чтобы решить, какой цвет тени будет смотреться лучше — #444444 или #3e3e3e
Надо дизайнерам показать)
pokrovsky-marat
09.02.2022 22:27+5Те, что называют себя хорошими программистами, очень раздражают нас, действительно хороших программистов.
eeeMan
09.02.2022 22:47про речь не согласен, за неё и за написание кода отвечают разные участки мозга.
tsurugi-no_ken
09.02.2022 23:17+18Сильные инженеры нередко оказываются хорошими спикерами
Очередное оправдание для хрюш выбирающих по софтскиллс бабников
отвергая "задротов"?
Sayonji
10.02.2022 03:09+2Хрюши - уменьшительно-ласкательная форма термина, вплоть до прекращения в эвфемизм. Вы - плохой разработчик, вывод сделан.
AlexanderKudryavy
09.02.2022 23:17-9Согласен с каждым пунктом, сам многим из этого переболел в начале своего пути, теперь вспоминаю это с улыбкой, но когда приходится сталкиваться с новичками, которым искренне даёшь хорошие советы, с пускай уж и не большой высоты своих лет и опыта, но всё же, получив в ответ "да-да, я лучше сам разберусь" - хочется кинуть с прогиба :D Хорошо одно, с этими людьми я никак не связан по работе, они просто друзья. А вообще конечно печально осознавать то, что большинство людей не умеют учиться на чужих ошибках, а прямо стремятся потратить своё и чужое время на набивание шишек...
AlexanderKudryavy
10.02.2022 00:12-2Хотелось бы почитать аргументированный ответ на этот минус, по моему опыту все кому я советовал, пришли к этому же потратив очень много лишнего времени, которое можно было бы сэкономить и потратить его с пользой, не отрицаю то, что любой амбициозный разработчик должен пройти этот путь, цимес в другом, когда есть очевидные вещи, то сколько бы ты не изобретал велосипед придёшь к тому же, или кто-то хочет замутить свою периодическую таблицу химических элементов? Или может быть свою систему исчисления? Это просто бред, нужно уметь перенимать опыт.
tsurugi-no_ken
10.02.2022 00:17+4Я не минусил, но ваше не имеющее аргументов утверждение
Согласен с каждым пунктом
вызывало минус, тоже без аргументов.
AlexanderKudryavy
10.02.2022 00:30-3Ок, вот вам аргумент из моей области, все кто не использует DOTween и Odin Inspector в Unity - зря тратят свое время, собственно я целый год уговаривал товарища на это, а он отпирался со своим - " Да я сам разберусь", догадаетесь какой итог? Он начал их использовать :)
И да, это я поторопился, согласен почти с каждым пунктом, но это уже не важно.
edo1h
10.02.2022 00:33+4Хотелось бы почитать аргументированный ответ на этот минус, по моему опыту все кому я советовал, пришли к этому же потратив очень много лишнего времени, которое можно было бы сэкономить и потратить его с пользой
ирония:
вам кто-то влепил минус без аргументов, вам не понравилось.
но когда вы говорили другу «делай так», вам не приходило в голову, что свою позицию надо аргументировать.обучение программированию — это не только и не столько «смотри как надо делать», это скорее объяснение того, как ты пришёл к тому, что делать надо именно так.
AlexanderKudryavy
10.02.2022 00:43Это с чего вы так решили? Я не советую что либо не аргументировав свой совет, именно это я и делал, объяснял почему я к этому пришёл и почему он прийдёт к этому тоже, но в ответ получал - "Да-да, я сам разберусь", по итогу он разобрался и пришёл к этому сам, вопрос только в экономии времени.
Keeper1
10.02.2022 11:19+5Письменная речь на русском языке -- явно не ваша сильная сторона. Выводы сделайте сами.
bogolt
10.02.2022 16:29+1> печально осознавать то, что большинство людей не умеют учиться на чужих ошибках
Я вот считаю что учеба на чужих ошибках не работает. Ну или в лучше случае приводит к тому что люди боятся пробовать новое. Со стороны очень сложно порой понять где была ошибка, а где недостаток знаний/упорства/времени/денег и тд
Часто бывает так что «старшие коллеги» рассказывают что это не возможно, не будет работать и тд, но иногда они оказываются не правы, и решение внезапно достаточно хорошо работает. И я не только про программирование сейчас говорю.
ehots
10.02.2022 12:51+1Прям вижу экспертное код ревью от вас с замечаниями: неправильно, лучше DOTween, так не надо. А потом на кухне с коллегами жалуетесь что джуны вас не слушают и делают не так как говорите, а с чего бы им? Вам если скажут ходить с левой ноги, ведь так лучше, а вы ходите с правой, сразу начнете просто следовать этим экспертным советам?)
omxela
09.02.2022 23:39+1Спасибо автору, текст хороший, понятный, хотя и не без технотрёпа кое-где (типа, шутка). Основное достоинство статьи в том, что я с ней согласен. Скажу больше. На мой взгляд, всё сказанное относится к любой инженерной или научной работе. Ожидаемо большое оживление вызвал первый пункт о внятности изложения проблем. Ну, не я придумал: кто ясно мыслит, тот ясно излагает. Разумеется, в любом правиле есть нюансы и исключения. У меня был коллега (увы, его нет в живых), который очень просто и понятно решил одну радиофизическую задачу. Но когда он её излагал публично - это была катастрофа. Потому что он был педант и перфекционист (пункт №3), то есть, считал, что если он упустит в докладе какую-либо деталь, пусть самую махонькую, то всё пойдет насмарку. Мухи дохли на лету. Сердце сжимала предсмертная тоска. Вопросов после доклада не задавали. Давно это было. На нашу статью в ведущем американском журнале активно ссылаются до сих пор. Бывает.
Но мне-то кажется, что среди этих пунктов в статье есть более серьёзные, чем речь, перфекционизм и велосипеды. Я бы выделил "переусложнение" и "туннельное зрение". На мой взгляд, человек становится настоящим техническим профи, когда эти два чудовища если и не побеждены, то загнаны куда подальше. У меня ушло на это лет 20. Увы.
roswell
10.02.2022 15:07Пунктик о подобном складе ума напомнил эпизод у нашего-всего Антона Павловича Чехова из «Скучной истории»: ¨Петр Игнатьевич, даже когда хочет рассмешить меня, рассказывает длинно, обстоятельно, точно защищает диссертацию, с подробным перечислением литературных источников, которыми он пользовался, стараясь не ошибиться ни в числах, ни в номерах журналов, ни в именах, причем говорит не просто Пти, а непременно Жан Жак Пти.¨ Ну, а далее, через пару абзацев — всё в соответствии со сценарием, которого придерживались слушатели: ¨Веду я себя с Петром Игнатьевичем дурно, и только когда он уходит, и я вижу, как в окне за палисадником мелькает его серая шляпа, мне хочется окликнуть его и сказать: «Простите меня, голубчик!»¨
eimrine
09.02.2022 23:54Я бы сказал что этот список пунктов является райдером не только для разработчика — но и для друга. И хорошо когда пара-тройка таких есть постоянно в круге общения, хотя бы чтоб всегда можно было позвонить/написать такому.
Alexandroppolus
10.02.2022 01:33+5такой разработчик может потратить лишние часы или дни на особую обработку случаев, когда база данных пустая, когда объект бронирования меняет свой ID, когда два запроса от разных пользователей конкурируют за общий слот, и так далее.
вообще-то хреновый (или неопытный) разработчик профакапит всякие редкие, но острые случаи, и потом будет искать трудновоспроизводимые баги, и переписывать логику/архитектуру под неучтенные кейсы.
RTFM13
11.02.2022 21:13разработчик профакапит всякие редкие, но острые случаи, и потом будет искать трудновоспроизводимые баги, и переписывать логику/архитектуру под неучтенные кейсы
Идеальный сценарий для внешнего подрядчика с почасовой оплатой.
Yoooriii
10.02.2022 01:51-5Я хотел бы добавить кейс, когда сильный разработчик является плохим работником. Знает и умеет много, а работать не хочет. Формально таски в джире закрывает, но как-то бестолково.
AllexIn
10.02.2022 08:55+1"как-то бестолково" - это как?
F0iL
10.02.2022 10:29+9Формально таски в джире закрывает, но как-то бестолково.
Звучит как "человек нормально делает свою работу, но я просто уже не знаю, до чего еще докопаться" :)
tommyangelo27
10.02.2022 11:12+7В магазин завезли поддельные елочные игрушки. Выглядят так же, но радости никакой.
screamingbirdoftruth
10.02.2022 16:10+2Из моей практики — когда после закрытия заведенного багрепорта можно еще с десяток других открывать. То есть, формально ошибка больше не воспроизводится, но все равно с кодом потом проблемы, и чем больше изменений, тем больше проблем. Со стороны выглядит, будто делается, что называется, "напохуй", без продумывания последствий и невдумчиво.
invasy
11.02.2022 03:57-1Без ТЗ результат ХЗ.
Задачи ставить и декомпозировать надо толково. А это уже ответственность не только разработчика, верно? Похоже, у кого-то проблемы с софт-скилами?screamingbirdoftruth
11.02.2022 19:26+1Ловко придумано конечно, перекладывать ответственность на оформление репортов, но нет, это так не работает. Тостер может написать что функционал работает не в соответствии с поставленной задачей, дать шаги для воспроизведения, дать информацию по воспроизводимости и актуальности проблемы, но чего в багрепорте быть не может, так это "погаси или хотя бы не копи техдолг и потрать на пять минут больше пожалуйста, чтобы разобраться и сделать по красоте, а не городить огород не вникая в проблему", это мягко говоря непрофессионально. Или надо еще в ТЗ дописывать "делай на совесть"? Или что такого QA должен написать в репорте, чтобы исправление гарантированно не повлекло за собой гору косвенно связанных ошибок, обусловленных особенностями реализации, за которые тот же QA не в зуб ногой и принципиально знать не может?
Ndochp
12.02.2022 00:18-1А причем тут оформление репортов? тут манагер/аналитик ТЗписатель встретиться должны и сказать разработчику, что в приоритете.
- Быстрое закрытие таски, чтобы получить довольного пользователя
- рефакторинг/пересмотр архитектуры для снижения числа баготасков в жире.
А то ахнет разработчик неделю на переработку куска кода, а его на итогах спринта дрючить будут, что провозился с задачей на 2 часа 5 дней. Да и еще из за плохого покрытия проекта тестами пяток регрессов спровоцировал.
mayorovp
12.02.2022 12:36Если таксу закрыли так быстро, что аж пять новых появилось — пользователь, как правило, довольным не становится.
maslyaev
10.02.2022 11:09+2Формально таски в джире закрывает, но как-то бестолково
... но делает это без уважения
datacompboy
10.02.2022 02:16+25Дополню.
Посмотрите на пол собеседника. Если женский, то не берите, уйдёт в декрет или вообще будет фигнёй страдать.
Посмотрите на наличие бороды. Если её нет, нельзя брать на бэкенд.
Уточните знак зодиака. Овны упрямы, скорпионы злобные, берите близнецов, они работают за двоих.
И прочий бред "как принять решёние на основе нерелевантных, зато простых знаков".
JustDont
10.02.2022 03:10+6Рыб надо брать, рыб — тоже работают за двоих и при этом молча! Идеальный исполнитель!
tsurugi-no_ken
10.02.2022 06:36+3Посмотрите на наличие бороды. Если её нет, нельзя брать на бэкенд.
Брать на работу только таких разработчиков?
merlin-vrn
10.02.2022 14:13+1Нет. Формулировка не предполагает, что при наличи бороды надо сразу брать. Она только предполагает, что без бороды не брать.
BioHazzardt
10.02.2022 14:30+2ну такие разработчики полюбому пишут бомбический код
General_Failure
10.02.2022 14:40+1— Ахмед, у тебя краш произошёл!
— Так по ТЗ он и должен был произойти
— Ты не понял, не объект крашнулся, а твой код!
Nacreous1991
10.02.2022 02:33+7Стадии роста программиста:
1) Хочет все написать сам
2)Ищет подходящую библиотеку
3) Ищет подходящий фреймворк
4) Ищет кому бы отдать эту фигню на аутсорс, чтобы самому заниматься более интересными делами
Sayonji
10.02.2022 03:21+2Как понять, что перед вами плохой разработчик. Не стопроцентный способ, но сигнал: если он вывел правила подобные описанным в статье, то собственно вот, вы поняли. Либо у него так себе с анализом, и он нашел подтверждения этим правилам, когда вообще-то их нет, либо он оценивает других разработчиков по параметрам ортогональным разработке.
Разумеется я про суждение о силе программистами по его речи. Остальное в статье - капитанство.
AlexTOPMAN
10.02.2022 06:48Мне кажется, термины перфекционизм и идеализм не очень удачно были подобраны к контексту. Лучше было ввести термин "стереотипизм". Он также пододошёл бы и для раздела про туннельное зрение.
SquareRootOfZero
10.02.2022 08:46+3TLDR: при написании кода задействованы те же участки мозга, что и при восприятии и формировании устной речи, а участки, ответственные за логику и математические задачи, практически не меняют свою активность. Это можно объяснить на достаточно бытовом уровне
Хорошо, а если не на бытовом, а возвыситься до более-менее научного, какие-то ссылки на исследования у автора есть? Насколько я помню, для восприятия и формирования устной речи в мозге есть целые специализированный области (зона Вернике, зона Брока). При патологических изменениях этих областей нарушается устная речь. Для восприятия и формирования письменной речи никаких специализированных областей в мозгу нет (логично, письменность, по эволюционным меркам, появилась вот буквально только что, в отличие от речи). Также, нарушения речи (афазия) и неспособность к чтению и письму (дислексия) — два совершенно разных и несвязанных между собою заболевания.merlin-vrn
10.02.2022 14:18+2Зона Вернике вроде как за восприятие отвечает. Зона Брока, насколько я помню, работает как моторная речевая зона, т.е. для говорения вслух, но не формирования текста, и ещё она работает иногда не только для говорения. А так, вон https://scitechdaily.com/reading-computer-code-is-not-the-same-as-reading-language-to-the-brain/ пишут, что чтение кода не задействует те же самые зоны, которые возбуждаются при восприятии речи.
bullitufa
10.02.2022 08:48+2А что делать (и вопрос вовсе не праздный) если по многим пунктам статьи узнал себя?(
По некоторым пунктам есть конечно проблески, но в общем...
p.s. Искал такой вопрос в коментах, не увидел
DrAndyHunter
10.02.2022 11:41+1А что делать
По-моему совершенно правильный логичный вопрос, возникающий после прочтения статьи.
aFanOfSwift
10.02.2022 09:51Что характерно, это никак не зависит от языка, на котором идет общение.
Очень спорное утверждение. Может и не завист от языка, если это твой родной язык.
А если нет?!
Например, на русском, я могу говорить витиевато, строить длинные и сложные предложения. На английском нет. На английском я буду говорить крайне лаконично и кратко.
syrslava
10.02.2022 15:32Завидую; в отсутствие контроля я с тем же успехом запутываю предложения на английском, и, вообще говоря, это не есть хорошо
aFanOfSwift
10.02.2022 15:52+1На английском я буду говорить просто и лаконично, только потому, что мой уровень языка не позволит, говорит длинными, сложными предложениями, и использовать сложную лексику.
А у вас видимо уровень владения английским всё же выше.
SquareRootOfZero
11.02.2022 05:55Если «уровень языка не позволит» — это, скорее, «косноязычно», а не «лаконично». Уметь сказать всё чётко, понятно и правильно, но при этом просто и коротко (и никак иначе) — это какой-то странный уровень владения языком: нужно иметь обширный (близкий к носителю) словарный запас, знать идиомы, но при этом не уметь строить сложные предложения.
aFanOfSwift
11.02.2022 08:23По мне так, идиомы в любом языке ЧАСТО только усложняют и перегружают его, это ни как не про лаконичность. Что не очень то нужно в деловом общении. Они нужны для обогащения речи. Может для политика и/или для публичных выступлений. Но точно не на обсуждение таска.
Да и косноязычие, это скорее про неумение правильно составить предложение. И наверное если я буду пытаться говорить на иностранном языке, сложными преложениями, они будут косноязычные. Потому я так не говорю.
Например, можно по разному дать понять человеку о его не далёкости. Можно, коротко и ясно сказать, что он тупой и может парой слов объяснить почему в данном случае это правда. А можно красиво и с использованием сложной терминологии и идиом объяснить это человеку, но он, как мы знаем, мягко говоря, не далёк. Так он даже не поймёт этого объяснение, а значит велика вероятность того, что он не исправится, а так и останется идиотом.
Да и вообще иногда звучит странно, как кто-то пытается выеживаться используя вместо слов, "сложно" или "не просто", слово "не трививльно". Иногда хочется спросить у такого челика, а ты походу только вчера это слово узнал и теперь хочешь показать, что ты умный?! И вообще когда кто-то перегружает речь, и вместо трёх слов начинает прогонять огромную "телегу". Как-то настороженно начинаешь к человеку относиться, ведь складывается впечатление, будто он пытался тебя обмануть, лапши на уши на вешать. Это как с договором, если ты видишь, что у кого-то договор больше чем на трёх листах, обычный договор поставки, сразу начинаешь подозревать, что в договоре тебя пытаются наебать, часто это правда. Иногда дурачки просто ГК копируют и всталяют в договор, хотя и так наши отношения им регулируются, как продавца и покупателя. Хорошо, что я в этом говне больше не работаю.(держу в курсе)
Borjomy
10.02.2022 09:58+1Хороший программист тот, которому при новой вводной не надо переписывать весь код заново. Потому что он думает на несколько шагов вперёд. И избегает таким образом лишней работы.
И ещё очень важны сильные знания в смежных областях. Когда ты смотришь на мир не только в подзорную трубу, но ещё есть панорамное остекление.
Кто ясно мыслит, тот ясно излагает. Только не языком. Язык для программиста это его программа. Поэтому надо код смотреть.
Хороший программист пишет эффективный, элегантный и красивый код, который максимально соответствует физике процесса и способен работать за пределами установленных ограничений.
Keeper1
10.02.2022 11:25Хороший программист тот, которому при новой вводной не надо переписывать весь код заново. Потому что он думает на несколько шагов вперёд. И избегает таким образом лишней работы.
Сомневаюсь, что люди со способностями ясновидящих вообще станут работать программистами.
F0iL
10.02.2022 12:13+3А для этого не надо быть ясновидящим, достаточно просто задавать себе простые вопросы "А что если..." в процессе разработки. Конечно, предусмотреть всё заранее невозможно, но в этом и сила хорошей архитектуры и правильных практик проектирования - что они позволяют гибко расширять функциональность и сложность кода без необходимости на каждом шаге отдирать и переписывать всё прибитое гвоздями, либо существенно уменьшают требуемые объемы этого.
Radisto
10.02.2022 12:22А что если "сопровождать ваш код будет склонный к насилию психопат, который знает, где вы живёте"
Прощу прощения за бородатую шутку
F0iL
10.02.2022 13:51+3Тоже правильный подход, но он не заменяет описанное в предыдущм комментарии. Простой и понятный код может быть простым и понятным изначально, а спустя N лет превратиться во что-то, что будет вызывать желание убивать даже у психически здоровых людей - и случится это именно из-за отсутствия вопросов "А что если..." у его автора.
У меня до сих пор глаз дергается, когда я вспоминаю код одного embedded-проекта Устройством был контроллер замерной установки. На первый взгляд задача была простая: из буфера UART берем полученный пакет (ответ от IO-модуля на наш предыдущий запрос), парсим его в соответствии с используемым протоколом, проверяя его на корректность и выделяя оттуда блок данных, потом разбираем сам блок данных (он содержит сразу несколько значений разных данных/параметров), и в зависимости от этих данных делаем то или иное (меняем состояние state-машины, запускаем ту или иную функцию, возводим флаг аварии со сбросом в архив, и т.д.).
Разработчик, писавший этот код изначально, сделал все просто... это всё было не то что в одном модуле, и даже не то что в одном файле, а в одной на тот момент еще небольшой функции. Всё было просто, понятно, всё работало.А потом выяснилось, что вот эти вот модули что-то с рынка пропали, зато есть другие - почти точно такие же (в модели отличается одна последняя цифра), но у них немного другой формат некоторых параметров.... В функции добавилась горсточка if...else. Потом проектировщики в соответствии с требования заказчиков поменяли компоновку шкафа, что изменило назначение входов модулей, и, соответственно, логику разбора блоков данных... В функции добавилось еще больше блоков if-else, уже гораздо более жирных. Потом выяснилось, что у нас
импортозамещениеэкономия и нужно использовать модули другого производителя, у которых протокол обмена вроде бы тот же, но с некоторыми нюансами... Потом снова поменялась компоновка шкафов... Потом по требованиям заказчиков в прошивку добавили новый функционал, в результате чего потребовалось, чтобы реакция на те или иные события от модулей была разная в зависимости от текущего режима работы... Короче говоря, спустя 6 лет после начала разработки код этого файла представлял собой монструозное нечто с кучей вложенных if...else разветвлений, monkey-patching'ом полученных пакетов данных при необходимости и черт знает чем еще... Естественно, никакими тестами это покрыто не было (да даже если бы захотели, это было бы не так-то просто).И это не какой-то специфический и уникальный пример, такое вообще встречается повсеместно.
А теперь вопрос - как этого можно было избежать? Просто заранее надо было разделить всю эту логику на разные независимые друг от друга взаимозаменяемые части - было бы гораздо гибче, а бонусом еще и проще тестировать. Я понимаю, возможно разработчик, делавший первую версию этого кода думал что это изделие "на раз" и можно вообще ни секунды не думать о гибкости и расширяемости, но с другой стороны, если бы даже не обладая даром предсказания он бы просто слепо следовал тем же самым здесь не раз упомянутым S-, L- и D- принципам, и сделал всё сразу по уму, изначально потратив совсем чуть-чуть больше времени - то сэкономил бы кучу сил и ресурсов и себе, и всем остальным программистам, вынужденным поддерживать этот код после него.
svr_91
10.02.2022 15:31А удалось в результате переписать как хотели?
F0iL
10.02.2022 18:37Проблемой было выбить у начальства время на рефакторинг всего этого. В соседнем проекте (родственном, изначально они были одним продуктом, потом разделились и их пути сильно разошлись) это удалось сделать при переносе программы на другую аппаратную платформу - там под шумок получилось переписать по-нормальному, то есть на практике оказалось, что никаких технических препонов сделать все нормально сразу не было.
В том самом проекте, насколько я знаю, всё осталось по-старому, и до сих пор спустя много лет мне иногда пишут на е-майл новоприбывшие сотрудники той компании, спрашивая "Чувак, что делать, я боюсь трогать это", хотя я там давно уже не работаю и по сути дела к тому коду особо отношения не имел :)
ainoneko
10.02.2022 15:59сделал всё сразу по уму, изначально потратив совсем чуть-чуть больше времени
Может, он считал, что следует принципам YAGNI и KISS? ¯\_(ツ)_/¯F0iL
10.02.2022 18:39Хорошая попытка, но нет :)
YAGNI, как мне кажется, он больше про функционал. Логично, что нет смысла сразу запиливать полные парсеры для 3-х протоколов, когда используется только 1.
А вот KISS наоборот был грубо нарушен - сама его идея в том, что лучше иметь как можно более простые и маленькие методы и модули, а не пихать всё что можно в одно место.
nikolay-ermolenko
10.02.2022 17:18+1Заранее вряд ли можно было всё предусмотреть. Разработчику как поставили задачу, так он и сделал. И первоначальное решение в тех условиях было вполне подходящим. Проблема возникла во время переписывания и расширения возможностей ПО. И что-то мне подсказывает, что всё упиралось в сроки, которые ну никак нельзя было выдержать.
Borjomy
11.02.2022 15:59Заранее подумать о том, что свет клином на этом модуле не сошелся, надо. Особенно когда ты не первый год в инженерии. Это вообще должно быть второй мыслью после получения задания. Делать "константами" вещи, которые с очень высокой вероятностью могут измениться - не уважать своих коллег и заказчиков. Ситуация, когда прекращают выпуск тех-же микросхем - сплошь и рядом. И далеко не всегда находится полный функциональный аналог.
Надо всегда учитывать, что жизненный цикл большинства компонентов максимум пара лет. Даже модули, выпускаемые десятилетиями промышленными гигантами, могут существенно отличаться от начального дизайна (включая характеристики и ПО).tsurugi-no_ken
11.02.2022 16:36Делать "константами" вещи, которые с очень высокой вероятностью могут измениться - не уважать своих коллег и заказчиков.
Увы, так делать это очень модный карго-культ. :(
mayorovp
12.02.2022 12:47Заранее — может, и нельзя. Но вот после появляется первых или вторых "дополнений" уже стало очевидно в какую сторону оно будет расширяться. И надо было именно тогда и переписывать код, пока он не стал монстром.
oOKIBrTlUTohw4Sc
10.02.2022 14:11-1Ни разу не видел чтобы люди писали "с запасом на будущее" и в итоге угадали. Вот серьезно вообще ни разу, каждый раз писали кучу мертвого кода, и там где нужно расширяться они как-то этого не предусмотрели.
Кроме того я очень часто слышал "а вдруг завтра что-то поменяется, надо предусмотреть" как оправдание лютому говнокоду, где абстрактная фабрика создает фабрику абстрактных фабрик.
Мне как то даже сложно представить код, который прям не придется весь выкидывать при существенных изменениях. Наверное это просто обычный средний код, который выполняет свою задачу и избегает дублирования кода, но без фанатизма. Ну и без явного хардкода, конечно же.
Вместо того чтобы писать код который "никогда не нужно будет менять... в теории, ну вы знаете там, открыто для расширение, закрыто для изменения" лучше написать код в котором легко и быстро можно разобраться и если что даже с нуля переписать под новые требования. Потому что когда вдруг прикатывают новые требования и тебе нужно поправить переусложенный код - ты в итоге его просто подкостыливаешь, потому что разобраться в нем просто нереально, да и время редко есть на это.
dolovar
10.02.2022 14:56+2Ни разу не видел чтобы люди писали «с запасом на будущее» и в итоге угадали.
Но, предположу, Вы не раз видели обратные случаи, когда писали без запаса, из-за чего впоследствие приходилось переделывать уже работающее — с перелопачиванием скопившихся данных и болями при разнесении логики. Привычка предусматривать запас появилась не на пустом месте.
Да, иногда доходят до крайностей, когда вместо скрипта на две строки создают новый проект с контейнерами и автотестами. Но наличие одной неприятной крайности не делает противоположную крайность хорошей. Любая крайность плоха, баланс нужен.svr_91
10.02.2022 15:37Да, крайности всегда плохо, и найти середину непросто.
У меня бывало куча случаев, когда я пытался "все предусмотреть" и делал только хуже, и бывали случаи, когда коллега меня не слушал, и делал на "отшибись", а я потом смотрел на это и думал "как хорошо, что я тогда не настоял сделать "как надо".
Тут претензия к основному высказыванию, что "всегда нужно все предусматривать". И иногда действительно кажется именно так. Но реальность такова, что поведение "будь проще, не заморачивайся" приносит пользу может даже чаще, чем педантичность
0xd34df00d
11.02.2022 06:01+2Скрытый текст
язык с развитой системой типов.
svr_91
11.02.2022 08:50Ну тут вопрос не в том, хороший код или плохой, а в том, на что это влияет. Иногда я старался писать идеальный код, и это внезапно выходило мне боком. Иногда я писал (или видел, как пишут) ужасный код, и то, что раньше казалось ужасностью, превращалось в плюс. Может быть, мы слишком много уделяем внимания именно коду? Может, стоит концентрироваться на чем-то ином? Например, привнести что-то новое в этот мир. Те же ученые, например - далеко не самые лучшие программисты на свете, но не будем же мы игнорировать их открытия только по этой причине?
Tontu
10.02.2022 10:59+1Короче говоря, скилл владения бережливой разработкой всему голова. Сюда же входит и бережливое общение - умение за минимальное время донести максимальное количество информации в максимально удобоваримом виде. Буквально в каждом абзаце описываются кейсы, которые при бережливой разработке в общем случае не допустимы.
Надо было всё это ещё более явно прописать, хотя, по-моему, вывод и так уже достаточно ясно описывает итоговую мысль. С азов надо было что-ли начинать. Честное слово, не знаю откуда столько бурления.
gremsta
10.02.2022 11:41+2Честное слово, не знаю откуда столько бурления.
Подозреваю из-за того, что предполагается наличие навыка вангования, который плохо совместим с типичным ожиданием разработчика "без четкого ТЗ результат хз".
wkia
10.02.2022 11:11+3И не стоит забывать, что единственным реальным и объективным мерилом «хорошести» разработчика является демонстрация его прикладных способностей в решении задач программирования и разработки.
Ну и зачем тогда был весь этот лонгрид?
HellWalk
10.02.2022 11:31+1О, у меня 100% попадание:
Сбивчивая речь и непоследовательность в изложении мыслей
Да, сбивчивая речь, и говорю вообще не очень. Да и где этому навыку тренироваться - если живешь один и 99.9% времени проводишь с компом, за тем же программированием.
Злоупотребление жаргонизмами и buzzwords
Да, злоупотребляю, думаю бабушки у подъезда ничего бы не поняли из моих слов.
Перфекционизм и идеализм
Очень. Особенно что касается авто-тестов, и CI/CD
Переусложнение или оверинженеринг
Куда без этого. Интерфейсы, тесты, постоянно говорю что в проекте нужна документация, на которую обычно все забиваю. Не могу просто сделать чтобы работало и все.
Самоуверенность и «велосипедизм»
Когда смотрю сколько багов люди делают в своих проектах - конечно самоуверенность растет. И велосипеды делаю - как-то свой небольшой MVC-фреймворк написал. И в планах еще много велосипедов - только свободное время давай.
Туннельное зрение
Ну да, предпочитаю проверенные временем решения, качество работы которых я могу гарантировать работодателю. На текущей работе до меня внедрили gRPC в проект на php - просто ужасная технология для такого языка. Я бы не стал внедрять, не попробовав вначале технологию на своих домашних проектах.
Выводы
Не бывать мне хорошим программистом. Пойду поплачу...
DrAndyHunter
10.02.2022 11:37+1Сильные инженеры нередко оказываются хорошими спикерами — именно их вы
чаще всего можете увидеть выступающими на тематических конференциях.Да это далеко не всегда так. Сколько ездил по конференциям, чаще оказывается совсем наоборот. Пример из жизни: на работе руководство решило представить свою компанию и свой продукт на одной из известных конференций. Доклад подготовили группой наших программистов, но выступил с докладом человек не сказать чтобы прям сильный, да и в разработке продукта он не участвовал. Просто человек сам по себе такой был, как говорится, душа компании.
В целом статья по-моему является очень поверхностным обзором некоторых когнитивных искажений (из Википедии). Приведены признаки "слабого программиста", но почему-то нет обсуждения, что с этим делать, и как "слабому" стать сильнее?
Goupil
10.02.2022 11:49+3Потому все люди нужны, все люди важны (кроме идиотов с инициативой). Лучший результат это союз людей, у которых достоинства компенсируют недостатки других. Это называется хорошая команда, и слаженная команда это не сумма составляющих ее элементов, а произведение, а иногда и степенная фукнция.
Но нет, всем надо рок-звезд, которые в одиночку разгребут авгиевы конюшни, принесут огромные доходы инвесторам и хозяевам и свалят в закат.
DrAndyHunter
10.02.2022 13:15Звучит как
"Как мотивировать себя что-то делать?
— Да никак, оставайтесь в жопе!"
Goupil
10.02.2022 22:08+2Если для вас жопа - четкое осознание своих сильных и слабых сторон, то уж извините.
igrishaev
10.02.2022 11:45Испанский стыд...
dolovar
10.02.2022 12:40Вы про оценки статье, которые на данный момент +53?
igrishaev
10.02.2022 12:48Я про статью. Очень не похоже на Хекслет, какую-то дичь написали.
dolovar
10.02.2022 13:58+2Таких статей много, за каждую переживать — нервов не хватит.
Лично меня смущает здесь только оценка сообществом. Есть что-то странное в том, что произвольный набор спорных постулатов перешагнул в оценках через полтинник (уже +60). Спорность подтверждается многочисленными комментариями, но что-то еще я явно не учитываю, что-то положительное находят люди в этой статье, и меня смущает то, что я не понимаю что именно.
Jammarra
10.02.2022 17:29+2Эх рискую кармой за такие высказывания всегда. Но тут разгадка лежит в разрезе ботов и чатов из разряда "У нашей компании вышла новая статья поставьте плюсов" А не в отношении сообщества.
dolovar
11.02.2022 12:23+73 вчера вечером, +83 сейчас — это какие-то особо умные «боты», которые льют оценки не пачкой, а равномерно на протяжении нескольких дней. То есть вряд ли это боты, просто статья реально кому-то нравится.
Статья набрала много противоречивых комментариев, поэтому попала в рекламный блок справа «читают сейчас», из-за чего набрала больше просмотров и оценок, далее попала в топ20 за неделю, поэтому читатели продолжают приходить и ставить оценки.
Вопрос только в том, почему приходящие люди не видят, мягко говоря, сомнительности постулатов в тексте статьи. Я по-прежнему прихожу к выводу, что чего-то не замечаю. Может, в статье такие есть хоть что-то полезное?
utyftrut
11.02.2022 17:42Людям обычно не нравится считаться плохими. Хотя быть плохими они часто не стесняются. Вот и весь секрет.
maslyaev
10.02.2022 11:47-1которые изменяют их морфологию, используя уменьшительно-ласкательные формы
Ага, давайте говорить "оформил запрос на оценку качества и (или) эффективности корректировки программного решения коллегами и (или) отвественным сотрудником в системе контроля версий Github" вместо "запросил пирревьюшку на багфиксик в гитхабчике".
merlin-vrn
10.02.2022 14:21+2Давайте говорить "запросил обзор на фикс в гитхабе", и давайте не ёрничать.
dolovar
10.02.2022 15:04+4Уменьшительно-ласкательные в речи появились не просто так, а по вполне логичной причине — передать незначительность. Например, «тут нужно бажочек пофиксить» подразумевает «тут нужно баг пофиксить, но он не большой, критичных систем не задевает, так что на первый взгляд много работы не понадобится, поэтому имеет смысл сделать сразу, чтобы потом не вспоминать десять раз в ходе перепланирований». На что можно получить ответ «да нет, тут не бажок, а застарелый бажище».
Да, кто-то в попытке протолкнуть или навязать свою оценку начинает злоупотреблять, уменьшать всё подряд, по поводу и без. Но огульно записывать все уменьшительные формы в разряд абсолютного зла — это такая же ошибка черно-белого мышления, как и противоположное мнение.
djarik
10.02.2022 11:50+7Заметил обратную тенденцию по поводу ораторского мастерства у программистов.
Часто хороший код пишут люди с дефектом речи, дислексией, заики и вообще не любители говорить. А у базарных баб и код как у базарных баб. Хотя, скорее всего, ораторское мастерство и мастерство программирования никак между собой не коррелируют.bullitufa
10.02.2022 13:21-1Знаю одного программиста, в письме в каждом слове ошибка. Но программист отличный!
maldalik
10.02.2022 11:55+4Я правильно понимаю, собеседование, у человека имеющего трудности с общением волнение, он путается сбивается, значит он плохой программист?
RemiZOffAlex
10.02.2022 12:27+8Статья звучит как попытка снизить оплату труда за "сбичивую речь" или паузу при обдумывании "уточняющего вопроса"
shaman4d
10.02.2022 13:27+1Ну кто-то будет искать такого как вы описали, а кто-то найдет того кто просто будет выполнять задачи.
smoluks4096
10.02.2022 13:32А я ведь помню ещё времена, когда программисту нужно было уметь только кодить, эх
iddi
10.02.2022 13:40автор одноименного алгоритма обхода графа, а в наши дни это подтверждают и научные подтверждения.
да, хорошо когда программист умеет аккуратно излагать свои мысли, и код он тогда тоже аккуратно пишет
MaryRabinovich
10.02.2022 14:04+1Ой, Хекслет:)
А я только что к вам попробовалась на хедхантере. И ваш, видимо, HR Полина Кокина мне уже отказала:) Давайте обсудим? Я бы была бы рада какому-то отклику чуть подробнее, чем"к сожалению, пока мы не можем предложить вам продолжить коммуникацию на эту позицию."
Это цитата мышкой, это ответ такой мне пришёл, да. Не можем предложить продолжить коммуникацию на позицию.
Короче, вот что там было в моём мотивационном письме:
Добрый день,
буду рада собеседованию,
поскольку вакансия довольно противоречивая (вроде бы, речь о PHP, вышла я к вам вообще по запросу про Laravel, но ничего подобного в самом тексте нету, а есть, напротив, про http & dns. Ну, я не очень-то сисадмин, так что в деталях о протоколах tcp udp и компания не расскажу - хотя понимаю в целом, как там пакеты ходят туда-сюда, реальные мои навыки заканчиваются на уровнях типа ajax, axios и компания)Почему я могла бы вам подойти, как мне кажется:
я преподаватель с хорошим стажем (хотя в основном я преподаю математику, а не программирование),
сравнительно много пишу на laravel (на чистом php бывает тоже, но... просто для тренировки, на литкоде - вот, например, задачка оттуда: ...тут ссылочка в мой гитхаб, сейчас убираю, ибо камент не про это - М.Р.).Мне было бы интересно поработать с чужим кодом,
особенно при наличии наставников и вашего материала для преподавания.
Не буду врать, мой основной интерес - ещё получше в этом во всём разобраться. Как преподаватель со стажем я верю в максиму "столько раз им объяснил, уже сам всё понял..."Добавлю, что буду рада и ГПХ, и договору с ИП. Другое дело, что как ИП я бы не хотела заморачиваться актами и договорами сама - если ваша бухгалтерия может это вот всё оформлять, отлично. Если же нет... для меня это будет минусом, хотя и преодолимым
polina_kkn
10.02.2022 16:14Мария, добрый день еще раз :)
Действительно, отказала вам на hh. В вакансии указано, что мы ожидаем от кандидатов, что у них есть опыт коммерческой разработки. Наставник на Хекслете - это действующий программист.
Из резюме и сопроводительного письма увидела, что основной ваш опыт работы - это репетиторство по математике. Соответственно, причина отказа - нерелевантный опыт.
Прошу прощения за такую краткую обратную связь. В день приходит очень много откликов, написать всем детально обратную связь не всегда позволяют временные ресурсы, но я буду работать над этим. Успехов вам!MaryRabinovich
10.02.2022 18:34Добрый день, Полина,
вот начало моего сопроводительного письма:
"Почему я могла бы вам подойти, как мне кажется:я преподаватель с хорошим стажем (хотя в основном я преподаю математику, а не программирование),сравнительно много пишу на laravel (на чистом php бывает тоже, но... просто для тренировки, на литкоде - вот, например, задачка оттуда: https://github.com/MaryRabinovich/leetcode_numSubmatrixSumTarget ). "
Перефразирую:
в коммерческих проектах я сейчас пишу на ларавель, это такой фреймворк php, достаточно сложный
для себя, чтобы не деградировать, иногда тренируюсь на php как таковом, в частности, беру задачки с литкода. Дальше ссылка в мой гитхаб. Где выложено аккуратненькое решение, с миленьким алгоритмом (не буду врать, что сама придумала алгоритм, нет - нарыла в сети, он меня совершенно потряс, поэтому, собственно, на гитхаб и выложила результат). Добавлю, что в этом репозитории есть папка тестов на phpunit.
Ни разу не набиваюсь в сотрудники, просто должна была тут ответить на вашу трактовку про отсутствие у меня опыта в продакшене. Это же хабр, мало ли, вдруг кто-нибудь тут прочтёт, что у меня нет опыта, и... даже страшно подумать.
Alexandroppolus
10.02.2022 20:42вот, например, задачка оттуда: https://github.com/MaryRabinovich/leetcode_numSubmatrixSumTargetКод не смотрел, но у Вас получилось решение быстрее очевидного O(N^2 * M^2) для матрицы MxN?
MaryRabinovich
10.02.2022 21:28Угу, с одним уточнением - это не то, чтобы "у меня" получилось. Конечно, тут фишечка в алгоритме, "а воплотить на пыхе сможет каждый дурак".
Сначала я сделала для линейного случая, простым алгоритмом, и вроде бы тесты прошли (литкодовские). Взялась за двумерный случай... и ну никак. Тесты стабильно ругались на продолжительность (незавершимость).
Несколько дней сама с ней бодалась, потом пошла в сеть и где-то у некоего индуса нашла алгоритм - для линейного случая. Уже толковый. Потом адаптировала его для двумерного.
У индуса для одномерного идея в следующем:
1) строим хеш-таблицу сумм подмассивов от 0 до k, k от 0 до n.
Ключами становятся эти частичные суммы, значениями - массивы соответствующих k.
Пример: исходный массив [10,1,0,2], хештаблица: 10=>[0], 11=>[1,2], 13=>[3].
Поясню пример: с суммой 10 от левого края только один подмассив, от 0-го до 0-го элемента (ну то есть он сам, нулевой элемент). С суммой 11 два подмассива: от нулевого до первого элемента, и от нулевого до второго. Остался один подмассив, от нулевого до третьего, и там сумма 13.
2) если нам надо сумму s, допустим - сумму 1 в моём примере,
а) проверяем, есть ли у нас ключ s; если да, учитываем длину массива в хештаблице на ключе s - в моём примере вообще нет ключа 1,
б) дальше перебираем ключи, проверяем для каждого ключа x есть ли у нас ключ x+s, если есть, идём внутрь соответствующих массивов и выбираем пары "k(x), k(x+s)" такие, что второе к больше (правее) первого.
В моём примере:
берём ключ 10, обнаруживаем наличие ключа 10+1=11, смотрим, сколько у нас пар "элемент массива с ключом 10, элемент массива с ключом 11, причём второй больше первого". Таких у нас две пары: (0,1) и (0,2),
берём ключ 11, видим, что ключа 11+1=12 у нас нету,
берём ключ 13, видим, что ключа 13+1=14 у нас нету.
Всё, оказалось, у нас два подмассива с нужной суммой 1.
Двумерный случай я как-то свела к линейным итеративным, в деталях уже не помню. Типа сначала ищем одномерные подматрицы - гуляем внутри одномерных строк. Потом переписываем нашу матрицу: вместо первой строки сумма первой и второй, вместо второй строки сумма второй и третьей, и т.д. Повторяем поиск по одномерным. Снова переписываем матрицу (вот кстати да, для этого надо было хранить исходную матрицу тоже, чтобы после "вместо первой строки сумма первой и второй" иметь возможность сделать "вместо первой строки сумма первой, второй и третьей").
Alexandroppolus
11.02.2022 00:31Одномерный вариант дано решал со словарем (сумма => количество), он простой, линейный.
А тут действительно сводится к нему - для строк i = 1...M, j = i...M, можно поддерживать массив высот: heights[k] = sum(arr[i][k] ... arr[j][k]), а уже для этого массива height запускать одномерный варинат. Итого O(M^2 * N) по времени, O(N) вспомогательной памяти. Вроде прикольная задача.
MaryRabinovich
11.02.2022 10:11-1Со словарём "сумма => количество" не получится. Надо хранить массивы правых концов, а не просто количества. Иначе вы не сможете различить итоговые подмассивы с суммой s и с суммой -s. То есть, такой вариант допустим, только если s = 0.
И вроде бы на литкоде была задачка и про нулевые подсуммы, она вашим способом решается, да.
mayorovp
12.02.2022 13:01Э-э-э, а что вам мешает отличить подмассив с суммой 1 от подмассива с суммой -1?
werevolff
10.02.2022 14:21Особенно внимательным стоит быть к людям, которые изменяют их морфологию, используя уменьшительно-ласкательные формы, вплоть до превращения их в эвфемизмы — «багуля», «тэзэшка», «аппликуха», «батончик».
Велосипедизм.
Ясно, понятно.
Каждый подобный тезис может быть справедлив в ряде случаев — проблема в том, что человек возводит этот тезис в абсолют. Кроме того, сильная убежденность сопутствует некой эмоциональной привязанности к ней — это можно заметить по использованию субъективных эмоциональных оценок, таких как «хорошо/плохо» при обсуждении, даже сугубо теоретическом, решений и концепций программирования.
Особенно вспоминается недавняя статья Хекслета о неприменимости SOLID в реальных условиях потому, что лошадь_в ванной_с_огурцами.jpeg
kspshnik
10.02.2022 16:40+3Привычка использовать избыточные или неявные синтаксические конструкции. Например, оборачивать весь код код функции в try/catch, явным образом приводить типы в слаботипизированных языках
Я правильно понимаю, что признаком хорошего программиста является умение качественно выстрелить себе в ногу???
Sorates
10.02.2022 17:20+4Не смог читать дальше второго пункта
Имхо, бред полный. Что только ненавыдумывают абы усложнить программистам жизнь на собеседовании. Конечно, зачем на собесе просить код писать, а давайте будем слушать как он разговаривает, ведь количество употреблений слова "апишка" и "тэзэшка" это гораздо более сильный признак того, как программист пишет код, чем, собственно, попросить его написать код на собесе или задизайнить что-нибудь.
Напоминает собесы в Амазон, где на каждом из 4-5 собесов половину времени занимает сторитэллинг
ninzyaValerok
10.02.2022 17:23+5Коротко про этот текст - поверхностно, преувеличенно и иногда откровенно не правдиво.
Про речь не знаю, может есть какая то зависимость, но явно слабая, особенно про словарный запас - как это может быть связано с умеем писать код или читать документацию? Для общения с командой конечно, но это другой аспект - софт и хард скилы и вот это вот все.
Про buzzwords было особенно забавно, когда через параграф читаешь про оверинжинеринг и тд)) Ну и тут тоже ничего такого нет, ну использует человек жаргон и что? Может на прошлом месте это было нормой и человек просто привык, может такой период в жизни.
Перфекционизм вообще не как не связан с примерами! Примеры это набор стериотипов или доведенных до категоричности тезисов. Где во фразе "Фреймворк или язык X лучше фреймворка или языка Y" перфекционализм я не понимаю.
Anton1978
10.02.2022 17:49+3Потрясающее "исследование", получается, что лучшие программисты это поэты, политики и мотивационные ораторы. Вот у кого речь развита, так развита.
Bellizar
10.02.2022 17:54+2К форме черепа не присматриваитесья? Родословной?
По моему евгеника сейчас не в моде
CRMguru
10.02.2022 18:02+5На самом деле, есть люди, которые потрясающе излагают мысли в письменном виде и совершенно не умеют формулировать их устно - есть несколько крутых знакомых специалистов, которые пишут прям очень понятно и вдумчиво, а сходу выразить мысль им сложно. Поэтому насчет сбивчивости - сомнительно, тем более, что касается программистов - людей, которые значительно отличаются от продажников и у которых совершенно другие задачи, отличные от презентации
souls_arch
10.02.2022 19:45+3Основная мысль статьи притянуть за уши логику и поставить знаки строгого равенства (вместо возможно) там где им не место.
Как в бородатом анекдоте:
"- Гоги, у тебе аквариум есть?
- Нэт.
- Значит, ты - пид..рас!"
princessmilana
10.02.2022 20:14Хорошие критерии для поиска разработчиков, если у вас вилка х2 от рынка.
XaBoK
11.02.2022 03:45+2Первые два пункта - явно самые резонансные. Стоит отметить, что жонглирование терминами (технотрёп) легко проверяется техническим вопросом по теме. А просто англицизмы и жаргон - норма в данной области.
А вот насчёт речи - тут уж полная ерунда. Начиная от того, что в наше время собеседование может быть и не на родном языке, заканчивая тем, что по сути работа программиста - умение общаться с машиной ограниченным набором слов. Основная задача - понимать сложные фразы человеческого языка и переводить в примитивы языка программирования. А совсем не наоборот.
N0zzy
11.02.2022 04:35+3Имхо, статья несёт дискриминационный характер в стиле айти-элитаризма. Если человек, не дай бог, заикается или какие другие имеет проблемы с речью, то ему носить клеймо плохо специалиста
Ну и важный итог — в соответствии с законами диалектики, любой процесс содержит в себе собственное отрицание. В данном случае — в ходе профессионального роста разработчик вполне может взять некоторые из этих недостатков на вооружение уже осознанно. Ведь, как известно, чтобы нарушать правила, надо их хотя бы знать.
Ложка дегтя в "бочке меда". Таки, да. Хорошие разработчики тоже говорят жаргонами, допускают баги, пишут грязный код и прочее, и прочее.
rtemchenko
11.02.2022 09:08Статья описывает недостатки, которые могут мешать разработчикам. Но многие из них вполне решаемы если не доходят до абсурда и человек адекватный.
А вот сложно решаемых проблем стоит добавить:
Человек не аккуратный. Наиболе заметно по резюме и форматирвоанию кода. Казалось бы мелочи, но имеет корелляцию с намного более важными вещами. Неаккуратный разработчик мало заботится о качестве решения. Основной принцип "И так сойдет". И это крайне сложно извенить.
Человек не идет на компромиссы и упрямствует до посинения. Иногда это полезно, но намного чаще это контр-продуктивно. Обычно такого разработчика можно убедить только авторитетом. Т.е. просто приказать делать не так как он хочет. Но работать в таком режиме долго не получится.
gremsta
11.02.2022 11:24+2Наиболе заметно по резюме и форматирвоанию кода
Спорно. Потому как очень похоже на способ сделать вывод о (не)пригодности бойца к боевым действиям по тому, как у него надраена бляха ремня и нагуталинены сапоги. А, и конечно же по тому, как он не по линейке кровать заправил.
Pyakacot
11.02.2022 18:10Есть примеры хороших специалистов, которые давали рваное резюме, написанное на скорую руку, с бардаком в форматировании кода, но на которых молится вся команда? Нет? Ну тогда притензия из разряда "вы меня не взяли потому что я черный (а не потому что образования нет)"
lxsmkv
11.02.2022 12:19Ну вы и загнули. Это прямо рассовая теория какая-то. Не одобряю такого. Максимализмом страдают все в юном возрасте, и он выражается во всем и в работе тоже. С жизненным опытом это проходит. И не нужно переусложнять. А те кто делят всех на сильных и слабых страдают элитаризмом.
Короче, нужно не делением и выявлением заниматься, а поддержкой и развитием. 2022 на дворе, как-никак.
П.С.: Кстати, заметил, чем больше ненумерованых списков тексте, тем вероятнее это коммерчески направленая статья. Сразу контент-маркетингом за версту несет.
nmrulin
11.02.2022 13:17+1Не знаю , не знаю. Я вот в устной речи достаточно косноязычен. Но тексты, скажем, уже лучше пишу. Так что оценивать по какому-то одному параметру это такое себе.
Хотя , возможно доля истины в этом есть, я лично в любой речи люблю, чтобы сразу переходили к сути. И в коде не люблю, кода какой-то важный функционал запрятан за 100500 переходами и обёртками. Даже чисто процедурный стиль лучше такого.
E32_735i
11.02.2022 16:48Всё гораздо проще, говоришь программисту "stackoverflow", если зрачки сузились, а писька встала, то перед вами плохой программист.
Не благодарите.
F0iL
11.02.2022 17:00+2Можно добавить в этот список маркеров еще cppreference для плюсовиков, MSDN для win-плюсовиков и шарпистов, MDN для фронтендеров, и т.д.
Потому что настоящий труЪ-программист обязан писать код вообще не подглядывая куда-либо за подсказками (sarcasm).
Tetsuzin72
11.02.2022 18:17+1Преждевременная оптимизация говорите?
Тимлид: не надо заниматься преждевременной оптимизацией!
Тимлид: не надо переусложнять!
Он же, через полгода: все оказалось намного сложнее, нам нужны новые фичи!
Тимлид: как это? Все нужно переделывать?
Тимлид: Мы не можем себе это позволить, релиз на носу!
Хе.
yakun123
11.02.2022 18:18+1Есть сотня способов провести собес, потом у вас 3 месяца испытательного срока. 3 месяца, чтобы дать человеку задачи и понять хороший он или нет, и возможность уволить его если он не справляется. К чему эти извращения?
Отсеивают разработчиков по словарному запасу, а потом начинают ныть:
Не можем найти разработчика
Че разработчики так много денег хотят
Macmep_007
11.02.2022 18:21+1Отличная статья, правда никуда не годная. Начну, пожалуй, с придирки. Если сразу же в самом начале мы меняем термины с "плохой" на "слабый", почему бы сразу в заголовке не написать "слабый"?
Сбивчивая речь и непоследовательность в изложении мыслей - это абсолютно ничего не значит. Программист в большинстве случаев - интроверт, и работает в "своем режиме". Он может очень невнятно излагать мысли, просто потому, что ему нужно больше времени, чтобы собраться с мыслями, победить свои страхи перед возможной баталией аргументов в холиваре. Возможно, коммуникативные навыки довольно низкие, но когда этот парень в деле, его мозговые центры могут работать на полную катушку, и он уделает любого, кто может мастерски работать языком.
Злоупотребление терминами - это практически ничего не значит в профессиональном смысле. Да, каждый термин имеет свой русский перевод (баг, фича, инстанс, закоммитить и т.д. и т.п.), но чаще всего так быстрее донести смысл, чем вспоминать его русское значение. Попробуйте сделать это прямо сейчас!
Перфекционизм - ну я сейчас одну ересь скажу: каждый программист в своем роде - перфекционист. Если ты не перфекционист, то ты решаешь поставленную задачу в лоб самым топорным способом. Возможно это эффективно, но кодревью покажет, какого цвета у тебя пояс по программированию. Кроме того, неперфекционисты не учитывают большую часть возможных ошибок, и каждая задача будет возвращаться на доработку не раз.
Идеализм - да вообще нет такого. Ни один нормальный человек не будет добавлять в коллекцию уникальных значений новый элемент через List с проверкой, когда есть Set. Максимум, что может быть в такой ситуации - это джун, выдающий себя за миддла. Знаний - ноль, зато уверенности - хоть отбавляй. Ну это уже про самоуверенность. Велосипедизм - туда же. Просто узнайте у собеседника про его опыт. Год-два - за такой период нельзя вырасти в полноценного миддла. Спросите, читали ли Кента Бека, Роберта Мартина, Мартина Фаулера, Гради Буча... спросите про шаблоны, джун ответит только про синглтон, что по сути даже является антипаттерном.
Переусложение - это редкость. Думаю, ни один здравомыслящий человек не будет сидеть 2-3 дня и украшать свой код до неприличия, пока начальник не поинтересуется, а чего ты копаешься так долго. Есть сроки, дедлайны, спринты. Тебе отводится кусок времени на задачу, и ты её делаешь. Ты не можешь молча сидеть дальше и доделывать/переделывать. Тебе надо как минимум сказать тимлиду, что вот такая-то вещь написана слабо, или плохо интегрируется. Надо сделать рефакторинг, чтобы было удобнее или снизить риск ошибок. Согласовав, что надо сделать и сколько это примерно займет, тебе дают добро и дополнительное время. Никто не будет говорить "нет, нам надо только вот так, и никак иначе". Все понимают, что ошибки надо исключать. Несогласование мелких случаев, не требующих длительных по времени затрат, скорее придаст программисту статус большей самостоятельности. В это же время согласование с бизнесом более долгих работ закрепит за вами ярлык ответственного сотрудника, выявляющего скрытые нюансы, на которые бизнес не обратил внимания. Другое дело, если ты работаешь по старой школе, когда тебе назначают куча задач, ты выбираешь любую, делаешь сколько хочешь (или можешь), и все ждут только тебя. Разработчик - наш кормилец и царь-батюшка. Как заслужить такой авторитет - загадка!
"Туннельное зрение" - о чем это вообще? Цитата (под привычкой подразумевается идеализм): "эта привычка основана именно на предшествующем опыте и мешает разработчику получать новый, более конструктивный опыт". Чтооааа? полученный опыт мешает приобрести старый? Да, человеку свойственно сохранять удачный опыт и отбрасывать неудачный. Так он растет. Идеализировать один какой-то конкретный опыт в чем-то - никто так не делает. Выбор IDE зависит от языка. Java - IDEA, C++/C# Visual Studio, Delphi - Embarcadero RAD IDE, PHP - Eclipse, NetBeans и прочие бесплатные. И да, за софт платит компания, для физ. лица дорогое удовольствие - платить за полюбившийся софт.
Выводы: Ну надо искать другие признаки. Эти никуда не годятся. Наверное самый главный из них - мотивация. Мотивированных людей сразу видно. Если у него нет опыта, но он мотивирован, глаза горят, хватайте его и растите в своей компании. Этот человек добьется немалых успехов и принесет солидный доход. А если он проводит рабочее время в youtube, ВК, ОК, ФБ, инсте, чатится в телеграмм, а под конец рабочего дня пытается за час-два уложиться в готовое решение... Гнать в шею паршивца!
Сам я успел с разными людьми поработать, есть любитель топорного способа (например у нас в Dynamics AX есть енум NoYes = (No, Yes), который он всегда сравнивал с 0 и 1. Иногда даже просто в if-выражениях явно сравнивал булевый результат с 0 или 1. Это прям бесило!). Есть и мотивированный парень инвалид, он уходил в отпуск, чтобы из дома порефакторить код в спокойной обстановке. Помимо программирования, он ничего другого не делает. Он - гик и интроверт. Но это никак не минус. Сейчас ему примерно 45, и он - реально ходячая энциклопедия. Но вот с общением у него не все так гладко, мысли путаются (это же явный звоночек, не так ли?). Когда спрашиваешь его о чем-то конкретном, он пытается объяснить абсолютно все нюансы, хоть как-то касающиеся вопроса. Он может час тебе объяснять ответ на вопрос, на который надо было ответить либо да, либо нет. Однако он идеально и практически без ошибок работает и укладывается даже в нереальные сроки.
vitaliyalserov
11.02.2022 18:23Легко понять - постоянно ноет что все плохо, кговавый режым и пора валить
lilouse
11.02.2022 18:24Эта статья настолько ужасна, что прекрасна. Сохранил себе, чтобы перед собеседованием перечитать, напомнить себе, с какими людьми придется иметь дело.
Nerli
11.02.2022 18:28Внимание! Здесь я буду откровенно придираться к тексту.
Кроме того, стоит отдельно исключить из этого правила случаи, когда у человека есть органические или неврологические нарушения речи, такие как заикание или афазия.
И этому посвящено всего 2 строчки, о которых практически все читатели забудут уже через пару минут.
При разработке сервиса бронирования (ресторана, отеля, медицинских услуг) такой разработчик может потратить лишние часы или дни на особую обработку случаев, когда база данных пустая, когда объект бронирования меняет свой ID, когда два запроса от разных пользователей конкурируют за общий слот, и так далее. Важно, что это может быть неплохая идея сама по себе, но отличие в том, что «сильный» разработчик поинтересуется у менеджера или заказчика, насколько это важно делать прямо сейчас, и реальна ли вообще проблема, прежде чем ее решать. Тогда как «слабый» программист, склонный к переусложнению, потратит на это время при любом раскладе, ни с кем не посоветовавшись.
Если о таких возможных проблемах не задумываться на начальных этапах, не дизайнить весь последующий процесс с учётом решения даже такого, то после релиза и многочисленных правок - получится старая поломанная ветка и кусок дурнопахнущей субстанции перемотанные синей изолентой. Если же ваша команда занимается разработкой проектов такого уровня, в чём нет чего-то постыдного, под каждые задачи - свои решения, бюджеты и потребности, то вы в любом случае будете предоставлять ТЗ
ушкуразработчикам уже с учётом того, что делать не нужно, а они не будут тратить ваше время.
iyurip
11.02.2022 18:28Хороший програмист разбивает сложную задачу на несколько простых и ищет наиболее простое и удобное для себя решение.
hockfan
12.02.2022 12:28"Зачем в автомобиле ставить подушки безопасности и тратить время на их разработку. Делать удобные кресла. Зачем-то оставлять место для багажника"... Надо быстро сделать.
"Зачем тратить время на проклейку пароизоляции при строительстве каркасного дома?" Главное быстрее достроить стоит вроде дом да и ладно.
и так можно продолжать бесконечно. Не нужно ничего переусложнять. Как персонаж из известного мультфильма "и так сойдёт"...
Живём мы в эпоху такую "Эпока коекакеров". При чём когда на нашем пути приходится заказывать работу у таких людей результат никому обычно не нравится.
Потом берёшь такую поделку на скорую руку где вообще нет проверок на ошибки и думаешь... ёпрст как это должно работать на твой взгляд вообще? А не важно, проект сдан, деньги получены. Как это будет работать не проблема коекакеров.
Последний раз столкнулся с таким шедевром на портале клиники где во время записи пациента в принципе нет никаких обработок ошибок. Вплоть до того что тупа нет записи к искомому врачу. Результат - заваленный звонками каллцентр с вопросом какого х выбираю врача и при нажатии кнопки записи просто вылетает "неизвестная ошибка". Зато программист самый лучший - в принципе не обрабатывает никаких "ошибок".
Не знаю, что написать... Просто бомбануло в одном месте наверное от накопленных эмоций!
UncleAndy
Очень неплохой обзор. Сам ко всему этому пришел интуитивно, но было интересно почитать все это в четко сформулированном виде.
Hydro
ИМХО, это полная хрень, а не обзор. Давайте честно признаемся. Рецепты не меняются:
1) Берем тему с кликбейтным заголовком
2) Выпячиваем и преувеличиваем все спорные моменты
3) Профит + завернули трафик на youtube канал
ooprizrakoo
А каким в вашем представлении должен быть "хороший" обзор? В чём бы у него были ключевые отличия от текущего?
Hydro
Я разве назвал это "плохим обзором"? Вроде бы я высказал своё мнение в других словах. Ну и вы серьезно? пытаетесь сделать меня субъектом в дискуссии, где задача предмета спровоцировать людей? Всё понятно, люди писали, старались, потратили время. Это конечно они молодцы, но их цели я не разделяю.
ooprizrakoo
>Я разве назвал это "плохим обзором"?
Вы задаете этот вопрос, будто я приписывал вам слова про "плохой обзор". Но я этого не делал, поэтому отвечать на него не буду.
Подмена тезиса — логическая ошибка и один из демагогических приёмов, основанных на опровержении фиктивной точки зрения с целью обоснования другого утверждения.
>пытаетесь сделать меня субъектом в дискуссии, где задача предмета спровоцировать людей?
Это ваше мнение и ваши личные подозрения, однако не имеющие ничего общего ни с моими намерениями, ни с сутью мною вам заданного вопроса.
Ложная альтернатива, ложная дилемма — достаточно распространённый приём, основанный на приведении в качестве альтернативы двух вариантов из гораздо большего множества.
>Всё понятно, люди писали, старались, потратили время. Это конечно они молодцы, но их цели я не разделяю.
Вместо того, чтобы доказывать истинность своих положений и опровергать аргументацию оппонента, демагог может обращаться к приёму ad hominem — критиковать не аргументы, а личность оппонента, пытаясь убедить зрителей, что оппонент — плохой, недостойный, не разбирающийся в вопросе, пристрастный или лицемерный человек.
Бинго.
В одном своем коротком хабракомментарии вы собрали 3 из 9 самых распространенных демагогических приёмов: https://ru.wikipedia.org/wiki/Демагогия#
Дальнейшая дискуссия, видимо, смысла не имеет?
Hydro
Ув. коллега, дискуссия изначально не имела смысла, т.к. Ваш вопрос был откровенно провокационный. Давайте формализуем подразумеваемое в нашем диалоге:
Мнение, что статья хрень, цель - запустить баттхерт у читателей и продать youtube канал
А как надо было написать, чтобы была не хрень и продать youtube канал? Критикуешь - предлагай
Высказывание мнения не обязывает к обратной связи. Ну и Вы серьезно хотите бесплатных советов для улучшения фастфудной статьи?
Вы демагог
WTF???
ooprizrakoo
я бы формализовал вот так:
- кг/ам
- а как автору надо было раскрыть тему?
- чо ты привязался, мне не понравилось, и всё.
- ясно-понятно.
pharrell
Вопрос не был провокационным. Он задан с использованием самых нейтральных формулировок.
Алексей не задавал его с позиции "Критикуешь - предлагай". Он лишь поинтересовался развитием вашего же мнения, которое вы высказали.
К обратной связи вас также никто не обязывал.
zebra67
Интересно, конечно, вы написали. Только ложной дилеммы здесь нет, потому что вообще дилеммы здесь нет.
Человек задаёт вопрос, а вы пишете, что это его мнение. Вопрос это мнение?
Последний пункт вообще смешно (Только не надо писать, что смешно это субъективное эмоционально наполненное выражение и что то, что я сейчас написал в скобках, это тоже некая психологическая манипуляция). Человек написал короткое субъективное мнение не для объективного его доказательства, а вы никакой аргументации не проводили.
Вообще складывается ощущение, что это написала плохо обученная нейронная сеть, в которую вогнали паттерны демагогии или ещё чего-то.
ooprizrakoo
>Интересно, конечно, вы написали. Только ложной дилеммы здесь нет, потому что вообще дилеммы здесь нет.
Есть несколько вариантов того, как можно трактовать мои слова, обращенные к автору того комментария. Например, воспринять обычный вопрос именно как обычный вопрос.
Но автор вместо ответа по делу захотел выбрать позицию, что я его хочу "подставить" и на этом начал строить все последующие обвинения и занял агрессивно-оборонительную позицию.
kai3341
И следом
Не совру, если скажу "да"
yatsenko-ihor
полная хрень звучит как "плохой обзор"
упс, уже написали
janekprostojanek
Да, вы назвали это плохим обзором. Ваши слова: "имхо, это полная хрень, а не обзор".
CrocodileRed
Хоть кто-то сказал правду :-)
KislyFan
Ну так уровень статьи граничит с инфоциганством. Много гипертрофированных взаимоисключающих параграфов, большинство из которых можно свести к старому-доброму "только ситхи все возводят в абсолют".. на этом фоне Дарт Вейдер в заголовке статьи весьма доставляет )