22 апреля 2009, 00:43 · zed-s-dead
Как распознать хорошего программиста?

Как нанимателю распознать насколько хорошим и талантливым окажется программист?

Это не такое простое дело, как кажется. Описание опыта работы в резюме далеко не всегда может раскрывать полностью правду о программисте – с одной стороны опыт может быть обманчивым и существовать скорее только на бумаге, а не в реальности. С другой стороны далеко не всегда прекрасный программист в "официальном" резюме может указать толком и подробно, в чём, как и почему он действительно так хорош. Хотя и есть ряд тонкостей, благодаря которым можно почерпнуть даже из резюме полезную информацию, раскрывающую "качественность" программиста.

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

Пол Грэм в своей популярной статье "18 ошибок, которые убивают стартапы " отмечает следующее:

"Причиной смерти большинства e-commerce стартапов в девяностых стали плохие программисты. Большинство тех компании создавались бизнесмена, которые думали, что для успеха IT проекта нужно придумать хорошую идею, а потом просто нанять программистов, чтобы они её реализовали. Однако в реальности всё оказывается гораздо сложнее. Сложнее просто потому, что такие наниматели не могли определить хороший программист перед ними или нет. Кроме того, они толком и не видели хороших программистов, поскольку профессиональный и качественный кодер редко когда жаждал в качестве работы выбрать "реализацию видения проекта заказчиком", не разбирающимся в IT и программировании.

В результате, такие бизнесмены нанимают тех программистов, которые им кажутся хорошими (написано у него в резюме Microsoft Certified Developer, значит, хороший кодер, по-любому). А потом удивляются, почему их проект пыхтит как бомбардировщик второй мировой, а конкуренты проносятся мимо на реактивных самолётах. Такое может и проходит в случае большой компании, но для стартапа смерти подобно.

Так как нанять хорошего программиста, если вы сами не программист? Ответа на это нет, и вряд ли будет. Можно для начала нанять одного хорошего, чтобы потом с его помощью отсеивать остальных, но этого одного хорошего тоже надо как-то найти сначала…"

Я совершенно не согласен с автором данного отрывка. Я считаю, что есть набор чётких индикаторов, по которым можно распознать хорошего программиста или же наоборот посредственного. Вот я и постарался изложить эти индикаторы качественности и некачественности в данной статье.

1. Увлечённость.

Во время работы мне довелось встретить доселе небывалый тип программистов: программист-карьерист. Представители данного типа кодеров пошли в программирования только потому, что считается, что именно в IT можно сделать хорошую карьеру. Они и пальцем не притронутся к кодированию в своё свободное время, они не понимают, зачем у одного человека дома может быть несколько компьютеров и зачем они объединены в сеть. Это только работа и заниматься всем этим стоит только на работе. Они не учат ничего нового по своей воле, программирование для них – это рутинная работа с девяти до шести. Они не обсуждают за пределами офиса какие-то технические вопросы, да и на работе обсуждают их без всякого энтузиазма.

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

2. Самообразование и интерес к обучению новому.

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

Если вы думаете нанять программиста, который говорит: "пошлите меня на курсы обучения этой новой технологии тогда я в этом смогу разобраться" – не нанимайте его. Хорошему программисту не нужны курсы обучения новой технологии. Он сам прожужжит вам все уши, о какой-то очередной новой технологи, о которой вы даже не слышали, и что вы обязательно должны использовать её в своём проекте, даже если никто из других сотрудников её не знает, и даже если он сам её толком не знает и не пробовал.

3. Интеллект

Некоторые люди из бизнеса и менеджмента считают, что недостаток тактичности в общении – это прямо свидетельство о необразованности и невысокой интеллектуальной развитости человека. Однако умственные способности человека имеют много проявлений и эмоционально-вербальное только одно из них. Хорошие программисты не тупые. В принципе. В реальности – они одни из умнейших людей из всех, кого я знаю. Причём у многих из них при этом ещё и прекрасные навыки общения с людьми. Клише о том, что настоящий программист в разговоре в компании не может толком и предложения вставить, это всего лишь клише. По моему опыту общения с лондонской Ruby юзергруппой, за небольшим исключением в ней собрались исключительно умные, общительные и разговорчивые люди. Глядя на них, вы не подумаете никогда "ну что за стадо гиков" по крайней мере до тех пор, пока вы не подойдёте поближе и услышите, что они с жаром обсуждают RESTful приложение со сложным пользовательским интерфейсом клиентской части.

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

Даже не думайте нанимать "немого" программиста, который вроде как должен быть хорошим. Он им не будет. Если человек не может в обычной расслабленной обстановке подержать беседу, толку и на работе от него будет немного. С другой стороны, далеко не все те, кто умён и сообразителен имеет потенциал стать действительно хорошим программистом.

4. Скрытый опыт

Данный пункт можно было бы включить в пункт "увлёченность", но он является таким важным индикатором качества программиста, что лучше его было лишний раз подчеркнуть и раскрыть.

Я начал программировать, когда мне было девять лет, на компьютере Commodore 64. Затем я перешёл на PC, где возился с Pascal. В четырнадцать лет я, потратив уйму времени, написал на C и Assembler небольшой движок для графических эффектов с обращением напрямую к видеокарте. Это было то, что я называю "стадией кокона". Когда я делал первые шаги на этой стадии, я был посредственным программистом, мне не хватало уверенности взяться за что-нибудь действительно сложное. По её окончанию, я как-раз-таки приобрёл эту уверенность и знал, что могу кодировать вполне себе хорошо практически всё что угодно.

Отражено это всё каким-либо образом в моём резюме? Нет, конечно.

Я искренне верю, что у любого хорошего программиста резюме представляет собой лишь только верхушку айсберга, а большая часть всего скрыто. Что-то кажется не совсем уместным, что-то не соответствует профилю вакансии, однако является при этом замечательным достижением и подтверждением профессионализма и увлечённости человека как программиста. Хороший вопрос который стоит задать на собеседовании – "Не могли бы вы рассказать что-нибудь о своём личном проекте, даже и наоборот, особенно, если он не связан с вашим рабочим профилем – что-нибудь, на что вы тратили своё свободное время и это не нашло отображения в резюме?". Если человек не может на этого ничего ответить (при том, что резюме у него на двадцать страниц), то он, скорее всего не самый хороший программист. Даже программист с наиболее исчерпывающим резюме, должен иметь пару-тройку проектов, которые остались за кадром.

5. Разнообразие технологий.

Здесь всё очень просто. Так как хороший программист всегда любит обучить и узнать и попробовать новую технологию, а также образно выражаясь "поиграться" с ней даже если он не имеет отношения к его профессиональной деятельности, любой хороший программист старше 22 лет должен разбираться в доброй дюжине различных технологий. Они могут быть и в каком-то смысле бесполезными, но для хорошего программиста изучение новой технологии – один из самых интересных способов провождения свободного времени. Чем они, собственно, со свойственной им увлечённостью и регулярно занимаются. Конечно, они не должны быть гуру во всём, но любой хороший специалист будет разбираться в целом перечне различных технологий.

Но здесь необходимо учитывать одну тонкость. Любой Java программист средней руки перечислит вам в своем списке известным ему технологий, что-нибудь типа Java, J2EE, Ant, XML, SQL, Hibernate, Spring, Struts, EJB, Shell scripting и т.д. На самом деле это всё по сути ветви и части одной технологии. Непрограммисту это, наверное, понять сложно, но если спросить у программиста как все его перечисленные навыки коррелируют между собой, то всё станет ясным. Переспециализированность кодера на одной и той же технологии – это индикатор не самого лучшего программиста.

Наконец, хороший знак, если технологии известные программисту представляют собой самые новые и продвинутые языки или там фреймворки. На момент написания статьи (Ноябрь 2007) это Merb, Flex, RSpec, HAML, UJS и многие другие. Они кстати, тоже связаны между собой и через несколько лет их перечисление будет таким же перечислением "одной и той же" технологии, как и в примере с Java.

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

6. Формальность квалификации

Это как раз тот момент, когда "официальная" квалификация программиста не является индикатором его качественности. Хороший программист может иметь специализированное образование, а может и не иметь. Различные сертификаты типа MCSE или SCJP могут означать высокий уровень кодера, а могут и нет. Они призваны быть доступными и желательными для всех программистов, но не более того. Всё что они означают - это наличие у человека определённого набора знаний. Это, по сути, гарантия для нанимателей из больших компаний, что "вот этот вот парень знает Java, и у него есть официальное доказательство этому" без проведения всяких там интервью и собеседований.

Если вы нанимаете программиста для стартапа или создаёте штурмовую команду для решения важнейших задач на уровне предприятия, вы должны игнорировать формальную "официальную" квалификацию программиста. Она ничего вам толком не расскажет о том, насколько хорош тот или иной специалист. Точно также нужно игнорировать и возрастной показатель – программист может быть хорош и прогрессивен и в 18 лет и в 40 лет. (Кроме разве что случая, когда вы подбираете команду одного возраста, для того чтобы создать лучшую кооперацию в коллективе, впрочем, возрастная дискриминация официально итак запрещена в большинстве стран).

В завершение темы, по моим наблюдениям большинство посредственных программистов начинают кодировать только в университете, изучая соответствующие предметы. Большинство хороших программистов начинают программировать задолго до ВУЗа, и обучение в университете является лишь развитием их хобби, зародившимся ещё до него. Если ваш программист не занимался каким-либо кодированием до университета, а на практическом уровне начал участвовать в разработке только по его завершению на своей первой работе, то своре всего он вряд ли будет хорошим программистом.

Примечание:

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

Итак, подведём итоги и тезисно по пунктам перечислим положительные и отрицательные индикаторы высокого уровня программиста.

Положительные индикаторы:

  • Увлечённость технологиями
  • Программирование – не только работа, но и хобби
  • Способность прожужжать все уши о какой-то технической проблеме и методах её решения, если потребуется
  • Наличие достаточно серьёзных (а часто и не одного) своих персональных проектов
  • Изучает технологии по своему собственному желанию
  • Подтверждённое упорство о том, какую технологию лучше использовать в данном случае
  • Ощущает некомфортность, когда приходится работать с технологией, которую он не считает правильной
  • Очевидно умён и сообразителен, способен поддержать разговор на различные темы
  • Начал программировать задолго до поступления в университет
  • Располагает скрытыми знаниями и личными проектами неуказанными в резюме
  • Знание широкого набора технологий
Отрицательные индикаторы
  • Программирование для него – повседневная рутина, работа с 9 до 6
  • Нет стремления обсуждать технические проблемы, даже при их наличии
  • Изучает новые технологии только по принуждению
  • Готовность работать с любой технологией, с которой скажут, ему нет разницы и дела до этого.
  • Не выглядит особо быстросоображающим
  • Начал программировать только в университете
  • Весь опыт программирования укладывается в резюме
  • Сфокусирован исключительно на одной или двух технологиях и не знает ничего кроме них.
источник, оригинал

Новые комментарии

Обсуждение

Missing-male
+2

Я плохой программист.) Большинство критериев можно использовать и для определения качества работника в других отраслях, но все они спорные и под большим знаком вопроса, ИМХО.

Picture_1442?1356409841

привет: это потому, что программисты - тоже люди... а критерии как раз применяют к людям ;)

Picture_1442?1356409841
+21

пока читал, вспомнился факт один: знаю немало людей, которые до поступления в вуз уже на тот момент знали немало в программинге, да и в математических олимпиадах участвовали. А вот потом те, кто пришел на первый курс, догнали их, обогнали и так далее... просто факт - не более того.

Думаю, что проблема кроется в том, что программирование, которое у многих до универа - то больше алгоритмическое. Суть в том, что оно не всегда в таких дебрях полезно или применимо в бизнес-девелопменте. Не секрет, что в большинстве аутсорс-проектов более важно как раз понимание бизнес-модели заказчика и модели обработки данных на логическом уровне, чем знание 350-ти алгоритмов (хотя, и такое бывает, но намного реже). И когда технари-любители (в самом хорошем смысле) алгоритмов приходят в мир бизнес-разработок, то многие теряют интерес. Да и объемы знаний, и их структура, и цели - разные. Но что для них отличается намного более серьезно - так это то, что надо 90% времени копаться в чужом коде и исправлять чужие ошибки, а не создавать свое. Снова вспоминаем о невыгодности для компании - такой "креатив" в действиях подчиненных обычно попросту не нужен, ибо рядовым программерам "ну никак не может быть позволена" своего рода отсебятина. Это не я придумал - таковы реалии. Более того, это очень часто встречается на практике.... Поэтому для большинства справедливо: свои проекты - красота кода или что там еще душе угодно; здоровый рационализм на работе и "нет" - овертаймам...

В соседних топиках уже давно сквозит мысль - тоже не секретная - что часто излишне красиво созданная архитектура банально _экономически нецелесообразна_ (отчасти согласен). Отсюда вытекают совершенно другие требования к программистам в наших реалиях аутсорса. И далеко не всегда эти требования находятся в плоскости неограниченных возможностей в технической экспертизе. Что и логично, исходя из проектов и целей компаний. НО как раз вот это и не дает спокойно жить настоящим программерам-технарям. В итоге жизнь берет свое.... кушать хочется всегда.

пост интересный.

я бы к положительным сторонам отнес еще умение признавать собственные ошибки и умение не только прожужжать все уши, а и слушать других (хотя бы тех, с кем в команде))))

Missing
+1

Очень согласен с se, особенно в последнем абзаце )

Missing
+5

*посыпает голову пеплом

Ну не знал я про мир программирования и математики в школе. Ну не показали. Ох сколько людей считает, что если человек "не играл на фортепиано в 5 лет, то значит это просто не его, нету у его к этому таланта", а то, что он в своей жизни фортепиано увидел по телевизору первый раз в 14 лет и только в 16 смог начать учиться, пропускают из виду, отговариваясь фразами типа "просто не хотел играть". Неужели если я только в университете обнаружил для себя программирование, то я буду плохим программистом? (прекрасно понимаю, что это подпадает под "примечание" , но надо же было как-то трагично оформить мысль =) )

1bd4bcb24184e88fae49d290ef73a9c9?1499980811
+5

а у меня даже компьютера не было до 11го класса. что, совсем не судьба девелопить теперь? :)

Picture_415?1356409808
+2

Знаете, у меня ПК не было до 2001 года. С 94го года (мне никто ничего не показывал и не рассказывал о программировании). И то, первые программы я вообще на бумаге писал и отлаживал. На васике, да. Впрочем, дабы не быть обвинённым в разжигании фаллометрии, скажу короче: кто хочет - ищет возможность, кто не хочет - ищет причину.

Missing

В том-то и дело, что сейчас я всеми силами ищу и нахожу возможности, потому как мне это действительно интересно.

И вот тогда интересно как Вы меня охарактеризуете. С одной стороны я (вот бездарь эдакий ) не занимался программированием до универа и должен на данный момент классифицироваться как челоек, которому программирование не интересно и на деле лишь ищу оправдание себе. С друго стороны сейчас я увлечен и кроме универа параллельно изучаю еще две области программирования, которым там не обучают, все свободное время самообразовываюсь. И что в сумме получается? Я человек которому интересно программирование или болбес, который даже не удосужился до универа учиться?

Picture_415?1356409808

>В том-то и дело, что сейчас я всеми силами ищу и нахожу возможности, потому как мне это действительно интересно.

Продолжайте в том же духе. Я считаю этот путь правильным. И успехов вам всяческих :)

Picture_434?1356409810
STInG
– Mobile Developer в Playtika

Это реально круто! Респект!

ЗЫ. О появилось редактирование комментариев. Тока какие то глюки с символами %uXXXX.

Missing-male
+1

На счет 5 пункта не соглашусь. Я считаю, что важна специализация. Сугубо личное мнение, но любой программист владеющий одной технологией будет в вигрыше по отношению к многостаночнику. (при сравнении по заданной технологии например ASP.NET). Если человек изучает что-то дополнительно, то он недопоплучает знаний по основной специализации. (Это не относится к тому что если под изучением понимать чтение статей в журнале типа вышел iphone разрабатывать под него так то и так то)

Missing-male
+2

Вы правы. На практике если в резюме написано .NET, Java и немного PHP - то это значит, что, скорее всего, нормальных знаний нет ни в одной из технологий.

F54c8f5a4c4c4d8f95ea106f39d015f0?1365455415

Не стоит быть таким категоричным. Я например на работе программирую на Java, дома тоже изучаю новые интересные вещи которые там появляются, но это мне не мешает использовать в университете C# и C , а так же в свободное время писать свой проект на .NET, просто потому что интересно как там у конкурентов дела =)

Т.е. Java мой профиль которому я уделяю большую часть времени, но в свободное смотрю и другие платформы/языки/библиотеки. Просто потому что интересно и часто можно почерпнуть что-нибудь для себя, например на rsdn была очень интересная статья про написания java кода в функциональном стиле.

Missing-male
+2

У нас с вами разные представления о нормальных знаниях. Я утверждаю, что мне на проекте нужны люди, которые не просто умеют писать компилируемый код на C#, а пишут эффективный код. Помимо наличия знаний, не зависящих от платформы, это подразумевает под собой понимание принципов работы CLR, нормальные знания BCL, Web Forms, NHibernate и пр. Нельзя хорошо написать приложение в сжатые сроки, основываясь на абстрактных знаниях о том, что такое ООП. Более того, даже для проектирования архитектуры приложения этих абстрактных знаний недостаточно.

Меня удивляют люди, которые оправдывают отсутствие знаний умением быстро обучаться. Если человек ищет в гугле, как сделать html encode строки, то он будет работать раза в 3 медленнее, чем тот, кто это знает. Если же человек не понимает принципов работы ViewState, то ему могут понадобиться недели, чтобы разобраться со всеми тонкостями. Более того, конкретная технология подразумевает и набор инструментария (IDE различные утилиты), на изучение работы с которым тоже требуется масса времени.

Picture_1442?1356409841
+3

согласен с Abrakadabr. Ничто не мешает быть в курсе дел конкурентов. Это отлично. Одно дело, когда в наших (да, что тут - и не только в наших) условиях можно знать многое поверхностно - и этого хватит для большинства проектов; другое - когда речь идет о качественных знаниях.

Могу сказать (даже из своего опыта): очень скоро вы физически, с большой вероятностью, не будете успевать даже все основные средства изучать, что уж говорить о качественных знаниях во всех подряд технологиях. Даже если ваша работа - изучение технологий. )))

для примера можно предположить, что если вы умеете использовать hibernate под Java, то вы легко сможете перенести свои глубокие знания на nhibernate. И тут начнут выясняться раличия в реализациях, особенности и так далее. Количество специализированных тулов и их различия для мира java и .net уже давно зашкаливает и только увеличивается. Abrakadabr говорит о знаниях уровня эксперта в своей области и их эффективном использовании.

Missing-male
+4

Вопрос "как распознать хорошего программиста" некорректен. Более правильным является вопрос "как найти хорошего программиста", или, в более общей постановке "как найти хорошего специалиста". Вопрос актуален для любой отрасли и любой страны.

Если человек, который проводит собеседование, соответствует своей позиции, то для него не составит труда распознать хорошего программиста. Рыбак рыбака видит издалека. Таким образом, возникает ещё одна проблема - где найти подходящего человека для проведения собеседований. Такого человека найти ещё сложнее, потому что желательно, чтобы его уровень квалификации (не только технической, но и вербальной) был выше, чем у собеседуемого. Более того, часто у таких специалистов банально просто нет времени проводить собеседования из-за девелопмента, консультаций, семинаров и пр.

Некоторые компании полагают, что если из 100 человек, приходящих на собеседование, они отбирают одного, то это неким образом будет гарантировать высокую квалификацию специалиста. На самом деле это говорит лишь о том, что из 100 человек, находящихся на рынке труда и пришедших к вам на собеседование, вы отобрали одного. И вероятность попадания в эту сотню хороших специалистов может быть гораздо ниже 1%, потому что вероятнее всего

1) у таких людей уже есть работа, и очень много работы в силу высокой востребованности

2) такие люди часто вообще не ходят на собеседования, а с места на место переходят по референсам знакомых

3) если и ходят, то их стремятся удержать уже в первой компании

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

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

Missing

Поставил 1. Со всем согласен, но хочу внеси маленькую поправочку по поводу "...не составит труда распознать...". Например, у интервьюируемого биоритмы в минусе, а машина интервьювера в ремонте и он добирался на работу в троллейбусе. Понятно, что это не лучший момент для интервью, но такое бывает. Шансы распознать в таком случае не велики.

Missing-male
+4

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

Таким образом, основные качества "хорошего" программиста (и работника в IT) можно перечислить как:

1) Не просто знает технологию, а умеет применять её для решения конкретных практических задач (в особенности - тех, которые стоят перед нанимателем);

2) Умеет работать в команде, эффективно и корректно общаться;

3) Понимает, что главное на проекте - сделать так, как надо заказчику, а не как пишут в блогах великие светила или же как ему велит сердце. Дисциплина исключительно важна, когда человек работает в коллективе.

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

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

Picture_1442?1356409841
+6

|| Понимает, что главное на проекте - сделать так, как надо заказчику, а не как пишут в блогах великие светила

|| или же как ему велит сердце. Дисциплина исключительно важна, когда человек работает в коллективе.

|| Все эти качества можно обнаружить, если задавать на собеседовании правильные вопросы. В конце

|| концов, не столь важно, как долго он работал в отрасли и какие сертификаты у него есть.

|| Важна пригодность человека к работе на данном проекте.

здесь есть небольшой подводный камень, который и порождает все "проблемы". Есть институт образования, где будущему программеру рассказывают, _как правильно_ надо делать то-то и то-то... В моей практике были просто знакомые программисты (а некоторые из них - и просто знакомые ПМ, успешные как ПМ, при этом сами - из "технарей"). И, как ни странно, они тоже внесли свою лепту на этапе моего становления. Тоже рассказывая, _как надо_ правильно все делать. Все-таки есть еще компании, где это тоже важно ;) или это люди просто разумные на моем пути попались

Так вот... проходит время, и когда человек наконец добирается до реального бизнес-проекта, то ему уже ведь не скажут явно: ты, это заканчивай тут свои паттерны умные по три часа имплементить, сделай лучше за 2 (условно) как угодно, абы работало и мы быстрее отправили это Кастомеру .... =))) И получается, что техн. человек, который привык думать в контексте "правильных архитектур", не может понять, как почему все-таки так. Ответ: потому что бизнес, а не НИИ. ДЛя меня тоже это было ой как странно в свое время. Но бороться с этим явлением нет смысла особого - деньги в этом мире решают все. Решат и в этом случае: рано или поздно вам прозрачно намекнут. Думаю, в процентах 80-90 наших компаний имеенно такой подход и подразумевается.

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

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

да, кстати... компании, видимо, не понимают (не хотят понимать, или им просто пофигу, потому что важнее нагрести миллион+ зеленых долларов здесь и сейчас), что таким образом они существенно подрывают зачатки хорошего будущего развития индустрии в стране. Воспитывается много народу, который знает или слышал о сотне технологий, а реально не сможет выбраться за пределы среднего аутсорс-проекта. Но бизнесу как-то все равно - его цели какие-то личные. Что логично и в то же самое время - никакой консолидации ИТ-сообщества. отсбда и финансовая емкость нашей отрасли... аж $100M с небольшим плюсом. Вот как этого не понимают компании - это странно. Но я думаю, что там неглупые люди - и все понимают, просто есть какая-то причина.

Missing-male
+1

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

Picture_1442?1356409841
+1

в общем-то, да. может, не совсем правильно понимаю, но все же, давайте уж начистоту, "вина" здесь - и менеджмента в том числе. "Правильная архитектура", о которой мы здесь начали говорить - это в какой-то степени _творчество_ инженера, вошедшее в привычку (бывает). Соотв., требует какое-то время на обдумывание. Это вам не гвоздь забить (утрирую, плотников обидеть не хотел) - по щучьему велению ничего не происходит. Скорость имплементации - это то, что надо, чтоб "все были счастливы". Основных мысли здесь две:

1. не все знают, как писать "правильно" - тут все понятно. Обсуждать здесь особо нечего.

2. те, кто знают, не всегда это сознательно делают. И вот почему. Потому что часто задаются вопросы наподобие: "ну что там - сделал уже? - нет пока. - тогда давай побыстрее, надо успеть к..., а то нам ...". Мы же команда... :) Т.е. вопрос, с одной стороны, закономерен. С другой - это и есть причина (одна из причин). И получается, что додумать не успели, а уже надо заканчивать имплементацию. И вот он - результат: быстрый и готовый код. Сдан в срок и (пока) работает. Его сопроводение потом (возможно) отнимет не один день и кучу нервов тому же девелоперу, когда вылезет хитрый баг. Еще и скажут, что он балбес: языком молоть - не мешки ворочать (народная мудрость). И так далее. Лично мне понятны действия обеих сторон. Всего лишь хотел показать природу возникновения такого явления.

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

Missing
scruoge
– Team-lead в Viber

+5

К радости "правильных" разработчиков, могу сказать, что достаточно один раз (тут конечно от заказчика зависит) сказать, и доказать на практике, что правильная архитектура - это не просто лишние затраты, а наоборот - экономия. Программа или модуль написанный на коленке за 2 (условно) часа - будет переходить несчетное число раз от QA к разработчикам, и обратно, и в конце-концов обрастет "костылями" так, что только удивляться будете, как оно все-таки работает и не падает.

Тогда как "правильно" спроектированный модуль - заработает сразу, и врядли будет бегать от QA к разработчикам более 2-3 раз.

Все это к тому - что "правильно" разработанная вещь - на поверку, как правило, оказывается гораздо дешевле.

Picture_1326?1356409837
+4

1)...

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

2)...

Мы нанимаем команду тусовщиков-филологов ??? Я утрирую конечно :) Конечно важно чтобы человек втерся в команду и адекватно смог пояснять свою позицию и мнение. Но требовать создать команду веселых и общительных программистов - это наверное в телешоу(все равно у каждого свои мухи и с этим надо мириться.)

3)...

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

Не хочет работать на дядю - пускай работает на себя. Деньги НЕ ЕДИНСТВЕННЫЙ фактор. Я наверное не одинок если предположу что мало кто согласиться пойти на работу на 30% прибавки с условием поминутного контроля времени и утренних гимнов божественности компании.

Picture_968?1356409826
Dreamer
– Software Engineering Team Leader в EPAM

Статья не о том как распознать хорошего работника, а именно о хорошем программисте...

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

Собс-нно в этом и причина краха большинства стартапов упомянутых в блоге. В стартапе, когда зачастую есть только идея, быть просто исполнителем и хорошим работником - мало. Требуется иметь талант, быть гуру, увлеченным в свое дело, чтобы уметь действовать в нестандартных ситуациях. Нужно быть готовым решать непредвиденные проблемы и предлагать свои оригинальные идеи.

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

Picture_968?1356409826
Dreamer
– Software Engineering Team Leader в EPAM

>3) Понимает, что главное на проекте - сделать так, как надо заказчику, а не как пишут в блогах великие светила или же как ему велит сердце. Дисциплина исключительно важна, когда человек работает в коллективе.

А этот пункт вообще враг настоящего программера. Типа давайте будем тупыми исполнителями-кодерами. Только конкурировать с китайцами/индусами по их правилам глупо - все равно их больше.

Picture_1442?1356409841
-1

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

Missing-male
+2

Полагаю, что нужно сравнивать не бизнес и науку, а людей. Так как куда ни глянь всегда концы ведут к конкретным людям. Бизнесу и компании в целом все равно какая прибыльность, какая архитектура и т.п. А вот допустим директору компании ой как надо получить как можно быстрее и больше сейчас, т.к. неизвестно, что будет дальше. Нет у наших людей еще понимания того, что лучше сделать качественно чем быстро и работать всю жизнь с "одним" (грубо говоря) клиентом, чем искать постоянно новых в силу того, что их почему-то не устраивает качество. И важно помнить что 80% прибыли приносят 20% клиентов.

Picture_1442?1356409841

в общем-то, вы правы. Разве что: каждому свое. Но вашу точку зрения - разделяю.

Missing
+5

|| Отрицательные индикаторы

///Программирование для него – повседневная рутина, работа с 9 до 6

конечно, сколько можно... даже самое вкусное и любимое блюдо при ежедневном употреблении вызывает отторжение. А тем более, если тебе говорят:"ну давай, Spring за папу, Hibernate за маму... ну, давай JavaScript за бабушку.." Бууууээээээээээээээээ..

И забесплатно в добавок по вечерам дома.

///Нет стремления обсуждать технические проблемы, даже при их наличии

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

///Изучает новые технологии только по принуждению

не по принуждению - только следующую страницу камасутры. Я не хочу на надгробной доске иметь надпись:"Умер за рабочим столом ночью, изучая новую технологию." Выучил её сам, она не прижилась и умерла. Пришлось учить другую. А не лучше ли это время провести со свей женой и ребёнком? На шашлычки съездить? На море?

///Готовность работать с любой технологией, с которой скажут, ему нет разницы и дела до этого.

Вам за работу платят деньги, а не за ваши нюни - хочу/не хочу. Детсад. Не нравится - выход найдете.

///Не выглядит особо быстросоображающим

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

///Начал программировать только в университете

бред... ищете зомби? все давно уже поняли - жизнь одна и провести ее надо точно не сидя за монитором, если есть возможности не делать этого.

///Весь опыт программирования укладывается в резюме

краткость это уже талант

///Сфокусирован исключительно на одной или двух технологиях и не знает ничего кроме них.

зато такой человек может стать консультантом и получать куда больше, чем всезнайки.

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

Missing-male
+2

Отлично сказано, кстати, люди которые уделяют все свое своболное время прогаммированию, по моим наблюдениям, зачастую одиноки и в чем-то ущербны, ИМХО. Когда кодишь лет 10-15, то просто смешно слышать от автора темы "Я считаю, что хорошие программисты всегда увлечены программированием. Хороший программист будет программировать даже бесплатно – просто для себя." Ну-ну...хотя есть и такие, но как я уже говорил, 99% из них одинокие люди... ИМХО

Missing-male
damavik
– mobile technical lead в Kibo

-2

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

...

Согласен про внешние признаки :D Ещё можно добавить: "пузо".

Missing-male
Kartas39
– Lead Consultant в EPAM

delete this comment please

Picture_1616?1356409847
+1

Критерии актуальны, но в основном для единоличников.

По хорошему нужно (и это во многом противоречит статье):

1) Быстро осваивать новое, даже если не нравится. Не может все нравится.

2) Работа в команде

3) Здоровая субординация

4) Делать работу вовремя или быстрее, в том что он успевает её сделать с 9 до 6 нет проблем :-)

Missing-male
www
– работаю в Digiteum

+1

Ага, я предлагаю просто написать:

1) Должен быть хорошим программистом.

Missing-male
+1

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

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

Picture_572?1356409814
agentcooper
– PM в Softeq Flash Solutions

+3

Коллеги, не парьтесь ! Способов распознать хорошего программиста за одно-два интервью в природе не существует - как и хорошего человека. Максимум возможного - распознать плохого :)) - на этом и следует сконцентрироваться !

Picture_130?1356409798
-1

Совершенно безосновательно для того, чтобы иметь наглость не соглашаться с Полом Грэмом. Много букв ни про что.

Missing
+2

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

Я не сяду просто так изучать новые технологии или программировать для удовольствия, хоть начинал программить в 9-м классе на zx spectrum. Сейчас другие цели - с помощью имеющихся знаний получить максимальное количество денег и реализовать свои амбиции.

E7ed2879678dce548ed44e24815cee11?1401052277

Хорошо, что HR в наших фирмах не руководствуются такими статейками. Статья из разряда "Найми программиста за 90 секунд". Тестовое задание и испытательный срок - и будет видно: хороший программист или плохой.

P.S. Я всегда думал, что "кодер" и "программист" - это разные понятия.

Picture_1442?1356409841

кстати, а чем же руководствуются вообще HR в наших компаниях-то? прямо заинтересовало...

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

Missing-male

Выше я упоминал о том, что одним из самых забавных качеств, присущих почти каждому человеку, является ощущение себя в чём-то уникальным и неповторимым, и, как следствие, стремление доказать это себе за счёт других. Как и вам, мне приходилось быть собеседуемым людьми, основной задачей которых (по ощущениям) было стремление доказать, что я не знаю чего-то, что знает собеседующий. Ну и самым неприятным для меня собеседованием было то, на котором я знал больше, чем собеседующий.

И всё-таки чаще мне попадались вполне адекватные собеседующие, т.е. не всё так плохо, как кажется :)

Missing-male
+1

Все таки имеется большая разница когда ты программируешь в конторе, а когда в свое свободное время или ради удовольствия и скорее этот пост подходит под второе и то с большой натяжкой ИМХО. Когда ты зарабатываешь этим деньги то на первый план выходит именно то что хочет заказчик и при этом в кратчайший срок - это конкурентность продукта, а заплатки можно и позже.

А про переработку нет смысла и говорить - есть дела и поважнее :) лучше уж выпить пивка с шашлычком.

И еще - если на конторе постоянные авралы то проблемы уж точно не с программистами.

ИМХО - главное это общение и саморазвитие!

Missing
+1

Хороший пост. Правильно, конечно, было бы снабдить его предисловием, указав, что это перевод, взятый из блога бизнесмена от программирования из United Kingdom. Тогда текст бы читался в нужном контексте.

Если ваша фирма разрабатывает программные продукты, то большинство советов вам подойдут. Я бы только добавил:

Хороший программист должен обладать системным мышлением.

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

Picture_1409?1356409840
+1

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

Missing-male

Кстати, только что вспомнил. Некто Дейкстра начал программировать в 26 лет, до этого он был физиком-аспирантом. Вы что-то там о программировании в школьные годы говорили?

Picture_1442?1356409841
+1

то были другие времена, все же... тогда еще и PC - та еще проблема была :)

Missing-male

Зато тогда была уже машина Поста и машина Тьюринга, программируй сколько хочешь. А вот леди Ада прекрасно справилась без PC. Я к чему: утверждение о том что программист должен начинать программировать в школьные годы, чтобы стать хорошим программистом более чем спорно. Да и сам текст описывает скорее идеального программиста. Лично я выделяю один критерий для хорошего программиста :"Работу делает качественно и в срок"- моя скромная, практичная точка зрения.

P.S. сам кстати начал программировать в кружке, в 5 классе, так что ничего личного

Picture_968?1356409826
Dreamer
– Software Engineering Team Leader в EPAM

+2

Исключительно позитивный и правильный пост! Подписываюсь почти под всеми постулатами! Автору респект и уважение!

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

Тем, кто на проджект-менеджмент кивает, попутно добавляя такие характеристики как дисциплинированность, исполнительность и т.п. Ребята, это все конечно приветствуется, но в данном случае второстепенно. Пост не о том.

Пост - реально порадовал, на фоне засилия меркатильных статей про деньги, продажи, сэйлсов, ПМов и прочих. Куда уходит искусство из программирования? Все смотрят на IT, как на средство заколачивания баблоса, забывая о истоках, классиках, истории.


Авторизуйтесь, чтобы оставлять комментарии

© 2008-2017 Частное предприятие "Дев Бай"
Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси