Не программист — тот кто вообще не может решить проблему (написанием кода).
Плохой программист — тот, кто может ее решить. Но решает так, что пользоваться этим не возможно, и проблем от его решения становится только больше.
Средний программист — это тот, кто уже может решить проблему. Но, со временем, его решение обрастает соплями и ведет к большей проблеме (но уже на длительном промежутке времени).
Хороший программист — тот кто решает проблему и заодно предвидит/предотвращает будущие возможные проблемы.
Отличный программист — тот, кто знает, что действительно стоит предотвращать и предвидеть, а что не стоит решать сейчас, так как потом это вероятнее всего и проблемой не окажется.
Осталось найти средства, которыми можно отделить хороших от плохих, ибо сейлам (sales) всех времен и народов по большому счету пофик — они делать на непрограммист (1 категория) и программисты (4 категория), а далее продают червивые воздушные замки, созданные «программистами».
Еще, на мой взгляд, неплохо бы про collab skill упомянуть 🙂 ибо такова природа задач, что кроме как сгруппировавшись, решить их невозможно. Но это уже про разработчиков, а не «сухо» программистов.
Да, с точки зрения sales (особенно не хотящих утруждать себя деталями) есть только две категории.
Насчет collaboration skills — в целом надо упомянуть. Но, все же личные знания — первичны, а collaboration вторичен (как по мне).
> Отличный программист — тот, кто знает, что действительно стоит предотвращать и предвидеть
Далеко не все зависит от программиста. Программист может прекрасно видеть перспективу, но с него требуют сделать просто заплатку.
А с другой стороны, если этот программист 5-ой категории так все хорошо далеко и глубоко видит, то какого черта он сидит в программистах?
Согласен не все зависит от программиста.
И если его просят сделать ненужную зарплатку, он вполне может попытаться объяснить почему она ненужная.
Насчет 5-й категории. Обычно люди в ней остаются, потому что им нравиться программировать. Те кому не нравится, уходят в management, sales или еще что-то не добравшись до этой категории.
Кроме программистов есть еще алгоритмисты и архитекторы. Но если под словом «программист» понимается все в одном лице (а так бывает очень часто, и всегда в мелких компаниях или мелких проектах), то определения интересные и близкие к истине.
Маленькая добавка: отличный программист не будет оптимизировать код до бесконечности и выдаст готовую программу, уже отлаженную и оттестированную в заранее логоворенные сроки.
Да, скорее понимает «программист» в широком понимании слова.
Я себе вообще не могу представить программиста 5-ой категории, который слаб в алгоритмах и архитектуре.
Смотря что понимать под алгоритмами и архитектурами.
Все же алгоритмы это более мат. задачи и решать их должны математики. Алгоритмы криптографии, архивирования и т.д. придумывают далеко не программисты. Аналогично и с архитектурами.
Так что «математик» всегда может сказать, что «программист» слаб в алгоритмах. 🙂
ok. Естественно, программист не должен идеально понимать криптографию и т.п.
Алгоритмы на этом уровне — удел математика.
Что я понимаю под алгоритмами — это скорее нормальное понимание, того какие есть алгоритмы, где можно их найти, как из них собрать в единое целое то что нужно.
Ну, очень упрощенно говоря. Для программиста не должно возникать проблемы задача, поиска чего-то в массиве.
В каком-то критическом случае, когда массив скажем занимает 100Gb, то ясно что изобретать свой алгоритм — тут может быть дурацкой идеей. В этом случае скорее нужно воспользоваться чем-то готовым.
Полностью согласен.
Отличный программист — тот кто делает ровно столько сколько нужно. Предвидеть всё нельзя. Предыдущий опыт может иногда даже мешать, именно тем что «будущих» проблем может видно слишком много (в силу опыта), да и решить какое решение создаст проблемы, а какое нет, не всегда возможно. И как результат (идиотский конечно) — лучше вообще ничего не «решать». (Не ошибается тот, кто ничего не делает 🙂 )
И как только хороший программист становится отличным, он тут же перестает сидеть в программистах. 🙂
Потому что хороших/отличных менеджеров, аналитиков, архитекторов, и прочих тоже не хватает.
Собственно это я о отличных программистах и писал. Они начинают понимать, что предвидеть невозможно и сделать идеальное решение тоже нельзя. Поэтому они очень аккуратно делают хорошо сколько нужно и хоть делают заделы на будущее, но разумные.
А насчет, того, что отличные программисты сразу уходят из программистов. Да как когда. Бывают уходят в менеджеров, аналитеков, архитекторов, а бывают остаются программистами.
Программистов надо категоризировать не только по критерию как они пишут код, но и по отношению к менеджеру, к тестироващику, по желанию учится, по использованию/знанию новых/старых технологий, по отношениею к другим программистам.
Ну, если надо, то категоризируем ;))
Кстати статья была не только про код, а про умение решать проблемы (да, таки спомощью программирования).
Без желания учится и использований знаний и технологий до последней категории просто не доберешься.
А вот отношения с менеджером и тестировщиками, слегка перпендикулярное измерение. Отличный программист по совместительству может быть очень сложным человеком.
Можно добраться. Консерватизм может противостоять желанию учиться новым технологиям. А многолетный опыт помогает предвидеть и предотвращать.
Характер может быть скверный у всех людей, но понимае разное. Скажем так в школе большинство думает, что это все зря и зачем туда ходить. А когда люди становятся старше, то приходит понимание. С программистами и их отношением к менеджерам, тестировщикам и клиентам, примерно тоже самое.
Скажем так, потенциально возможны очень разные комбинации, но если говорить о их вероятности, то вероятнее до последней категории доберутся люди, которые привыкли учить новое.
Если чего не учит новое и чрезвычайно консервативен, то вероятнее всего ему просто не хватит информации что-бы обобщить опыт и выйти на следующий уровень.
Книжка по ITIL Foundations стоит недорого. Крайне рекомендую приобрести для чтения на сон грядущий. Там неплохо изложено отличие инцидентов от проблем, дано определение известной проблемы, а также рассказано, почему не стоит решать некоторые проблемы и инциденты.
Я, безусловно, восхищен Вашим стремлением создать аналогичную теорию с нуля, но все же очень, очень рекомендую полистать какие-нибудь абвгдейки по ITIL и MOF.
Ну просто для того, чтоб опираясь на уже наработанный кем-то базис, пойти дальше, не тратя времени на начала 🙂
Сейчас пойду закажу книгу.
Хотя у меня еще пару книг непрочтенных, но лучше чтобы в запасе была пара интересных книг.
Единственное, теорию я особо даже не пытаюсь создать, просто записываю пришедшие в голову мысли.
Проблемы в создании теорий заключается в том, что в результате теории выходит книга на 500 страниц, исписанная определениями, исключениями, формулами и т.п. И в результате книга есть, а читать ее скучно, да и толку от нее чуть. (Я не говорю о ITIL Foundations, так как ее не читал, но о некоторых теоретических книгах, на которые я нарывался).
Не программист — это я =)
Более полной категоризации программистов я еще не встречал. Восхищен!
Наиболее яркой и новой для меня идеей стало то, что программисты решают проблемы… Никогда об этом раньше не задумывался.
>>Наиболее яркой и новой для меня идеей стало то, что программисты решают проблемы… >>Никогда об этом раньше не задумывался.
Это типа шутка юмора?
Нет, что Вы. Я абсолютно серьезен.
Много лет работал программистом, начальником программистов… Но никогда ни в должностных инструкциях, ни в описаниях вакансий, ни где-то еще я не видел подобной формулировки. Поэтому искренне считал, что программисты пишут программы. Обычно — по чьему-то заданию, иногда — по собственной инициативе. Если они пишут хорошие программы (т.е. выполняют задание) — значит, они хорошие программисты. Если не справляются с заданием — значит, плохие. А здесь — более глубокий подход, очевидно.
Открою секрет: ПРЕЖДЕ чем писать программы, нужно знать какую задачу она будет выполнять(решать проблему). Эти сакральные знания, о решении проблемы, нужно как-то придумать и где-то хранить( в голове, в документации, в UML, на салфетке) а потом уже писать программы, даже по собственной инициативе 😉
2smp & dzh: Собственно говоря, написание программ — это уже результат решения проблемы.
Как точно заметил smp — где-то должна описываться проблема.
Я конечно не говорю, что программисты должны решать ЛЮБЫЕ проблемы. Поэтому именно в первой строке я таки написал, что проблемы должны решаться написанием кода.
А дальше, уже можно разбираться, что понимать под проблемой. В целом в моем понимании проблема — это какая-то необходимость (не обязательно плохая или неприятная).
Я вот не программист, я за свою жизнь и трех программ не написал (одна из них довольно неплохо решала квадратные уровнения, кстати).
Но расскажите мне, неужели программист должен общаться с заказчиком и уточнять, какие задачи(проблемы) она будет решать?
Может, это задача других людей, совершенно далеких от программирования?
Вот, например, клиент говорит, что он хотел бы лабать таблички с цифрами. Мы ему Corel Draw будем писать или MS Excel?
«неужели программист должен общаться с заказчиком и уточнять, какие задачи(проблемы) она будет решать»
Так вроде о заказчиках речь то и не шла.
Но вот общаться и уточнять какую задачу он вообще должен решать — конечно ему нужно.
Иначе таки придут к нему и скажут — нам лабать таблички с цифрами… а он через месяц им тетрис выдаст.
Хотя бесспорно, формулировка задач и их уточнение чаще всего должна делать не программистами.
Кстатте, вот порадокс:
Я работаю project manger’ом — такая вот модная должность. Суть обязанностей общение с клиентами, составление ТЗ, постановка задачи, контроль качества и сроков.
По сути ПМ не должен обладать знаниями программистов и т.д. Но на себе знаю 100%, что без этого практически никак. Я работаю по направлению веба. В каком-то смысле конвеер сайтов. Так вот программисты, верстальщики и дизайнеры постоянно пытаются навешать лапшу: это невозможно, это делается долго и т.д. Народ на столько избалован ситуацией на рынке, что вообще не хочет ничего делать и получать большие деньги.
По теме: таких людей я вообще не считаю ни программистами, ни дизайнерами, ни кем! Любой человек работющий в коммерческой структуре должен понимать, что деньги платятся за выполненную работу (а точнее за сданую работу), а не за знания/умения и т.д. По этому критерию тоже надо рандировать программистов.
Ну, совсем без знаний как оно работает внутри управлять действительно сложно. Не скажу, что нельзя, но все же сложно.
Насчет навешивания лапши. Самый лучший способ вместо одного человека — на estimate садить двух. Мгновенно уровень фигни уменьшается во много раз. Одно дело пытаться эту лапшу вешать менеджеру, а другое дело другому программисту, который сразу ее раскусит.
Однако, может быть что-то и не лапша. Тоже не стоит оказываться в такой ситуации, что если один раз кто-то соврал, то значит, все врут.
Насчет выполняемой работы. Есть у меня такое «золотое правило», которое я применяю к людям. В абсолютном большинстве люди работают так, что просто избежать проблем. То есть они находят минимальный приемлемый уровень и на нем работают.
Так вот, если они работают спустя рукава, это не столь их проблема, сколь проблема фирмы. Значит требования к ним поставлены так, что они могут работать спустя рукава.
Согласен с Вами.
С моей стороны это скорее крик души 🙂
В прошлом году заказывал одной могучей кучке программистов солидный (для меня) и нестандартный сайтик. По приведенной в статье классификации — оказались средними… 🙁
Ужос, все бабки, считай, в попу засунул
Бывает. Собственно говоря, нужно смотреть как все идет. Чем раньше появляются проблемы в том, что качества желаемое отрывается от качества получаемого — тем вероятнее всего более слабые программисты делают проект.
Я, к сожалению, не встречал программистов категории выше средней 🙁