В куче разнообразных мест (замечу, именно русскоязычных) по разным IT темам натыкаюсь на очень похожую фраза: «Так то ж тупой кодер, а вот настоящий Программист …».
Такие фразы меня просто корежат.
Ну, начнем с понятия кодер. По идее, кодер – это человек, который умеет только кодировать (набивать код четко описанного алгоритма). Как я понимаю, вылезло это понятие из глубокого прошлого, когда алгоритмы в основном составляли математики, но например набить на перфокарты весь алгоритм и проверить, что набито все правильно мог делать вспомогательный персонал (кодировщик). Соответственно, первые выполняли интеллектуальную работу, вторые же выполняли рутинную работу.
Вот тут нашел ссылочку на слово кодер в Википедии.
Буду благодарен, если кто-то может кинуть более интересные ссылки на то, откуда же точно пошло это слово.
Почему существовала такая профессия как кодер? Да, просто потому, что можно было набивать эти перфокарты часами и это не требовало слишком больших знаний и умений. Ну и соответственно, пытаясь оптимизировать было разделение на тех, кто пишет алгоритмы и тех, кто их кодирует.
Сейчас же процесс кодирования занимает ну очень маленькую часть от написания программы. И не одному здравомыслящему человеку не придет в голову разделить процесс написания алгоритма (близкого к уровню кода), от самого процесса кодирования. Никакого выигрыша на этом уже получить невозможно. Кстати разделение между архитекторами и программистами — это новая граница, как можно разделить работу разной сложности.
Итак, что мы имеем, что слово кодер, которым тыкают в кого попало, на самом деле абсолютно не описывает, то чем человек занимается. Ну, не существует сейчас кодеров, хоть убей. Что есть — это множество слабеньких программистов натренированных на решение простых прикладных задач.
Второе, что меня напрягает в той фразе — это слово Программист (именно с большой буквы). Как только идет о речь о Программисте, то все начинают описывать рыцаря в блистающих латах на белом бинарном коне. И этот рыцарь должен идеально знать все предметные области, разбираться в математике не хуже Ферма, а в физике не хуже Эйнштейна. Также, этот Программист должен одинаково легко уметь проектировать архитектуру для проектов на сотни тысяч человеко-лет и отлаживать в бинарном коде для неизвестному никому микропроцессора.
Так вот, напрягает меня нелинейность. Разница между обычный(средний) программист- хороший программист и отличный программист – вполне линейна. То есть они обладают одними и теме же знаниями и умениями, просто в разном количестве, имеют разный опыт. Но тем не менее, к отличному программисту выставляются те же требования, что и к обычному. Отличный программист не должен вдруг уметь играть на свирели, для того, чтобы быть отличным.
А как только первая буква становится заглавной, то сразу появляется какая-то мифичность и требования скачком становятся абсолютно другого уровня.
К чему это я…. Так, вот – это я к тому, что по большему счету программирование – это ремесло. Да, ремесло требующее интеллекта, выдумки и хорошего абстрактного мышления. И так же как в любом ремесле, есть средние, хорошие, отличные и даже гениальные ремесленники. Но, так как это ремесло, то требования к ремесленникам заранее известны, и не должно быть никакой нелинейности в том, что для самых лучших требования кардинально отличаются от требований к просто хорошим программистам.
Вероятнее всего, на этом месте куча людей начнет рвать рубаху и кричать, мы люди искусства, а не ремесла…. Скажите, когда вы включаете и смотрите телевизор, вы получаете эстетическое удовольствие от того как разведена плата в телевизоре или от телепередачи? То же самое, никто из конечных потребителей не получает эстетическое удовольствие от кода программы и алгоритмов, всех интересует просто конечный продукт.
Ну и возвращаясь к фразе про кодера и Программиста. Третье, чем мне чуждо это сравнение — это тем, что на программиста начинают навешивать знание кучу вещей, которые он не должен знать. Именно исходя из того, что программист – это ремесленник, он должен знать свое ремесло и не обязательно ему знать чужое ремесло. Замечу, хотя математики становятся хорошими программистами, это не обозначает что программист обязан должен знать математику. Это тоже самое, как скажем, люди с идеальным слухом часто становятся музыкантами, но не обязательно иметь идеальный слух, для того, чтобы им стать.
А что вы думаете насчет ремесла vs. искусство и кодер vs. Программист?
P.S. В процессе дискуссии, дополнилась одно важное замечание. Хотя, работа у программистов и является ремесленничеством, но тем не менее она может быть творческой.
P.P.S. Еще одна вещь, которая обнаружилась, что под словом кодер, люди зачастую понимаю — малоопытны программист или плохой программист. Именно это меня и беспокоит, что слишком много разнообразных значений навешены на одно слово. Причем на то слово, которое изначально имело другой смысл.
Все верно. Самого удивляют разговоры о «кодерах» — смысла в таких работниках нету.
Про ремесло — тоже согласен.
Есть только одно «но».
И так же как в любом ремесле, есть средние, хорошие, отличные и даже гениальные ремесленники. Но, так как это ремесло, то требования к ремесленникам заранее известны, и не должно быть никакой нелинейности в том, что для самых лучших требования кардинально отличаются от требований к просто хорошим программистам.
Вот беда в том, что сформулировать требования к очень хорошему программисту сложно.
У других ремесленников есть понятие «токарь 6го разряда». И сразу все понятно. Четкая градация. А у программистов так не получается. Уж очень разнообразны задачи решаемые разными людьми, а меру «умения решать задачи», имхо, еще не придумали…
Вот и получается, что с одной стороны программисты это ремесленники (инженеры), а с другой уж очень все разные и индивидуальные (как творческие работники).
>Вот беда в том, что сформулировать требования к очень хорошему программисту сложно.
Я бы даже сказал по другому. Сформулировать требования достаточно легко. А вот измерить их по какой-то шкале — сложно.
Например вполне нормальные требования к программисту:
— знания языка программирования и умение изучить новы
— знание платформы и умение изучить новую
— хорошее абстрактное мышление
— умение формализовывать задачи
— умение разрабатывать алгоритмы
Фактически все из параметром очень сложно измеримы.
Кстати, задачи действительно творческие. Я добавлю это к статье в P.S.
У меня есть знакомый токарь. Так вот, токарь 6 разряда, способен найти ошибки в чертежах, которые ему принес нерадивый инженер и исправить их без всяких лишних вопросов при изготовлении детали. Но таких очень мало.
Примерно тоже самое и с программистами 🙂
Ну есть взять деятельность токаря, при чем любого разряда — то это как раз и есть в нашем понимании «Кодер». То есть человек который по спецификации выполняет работу, в нашем случае токарь по чертежам делает деталь. Чертежи делает инжерер — тобеж в нашем случае «Программист».
Тоесть я хочу сказать что пример не совсем правильный для сравнения, так как заведом разграничены сферы работ. Причем замечу что это конечно не определяет уровень знаний и опыта вашего знакомого токаря, просто в системе его обязанностей он как раз и является Кодером.
Я уже несколько раз писал что информационная отрасль она и молодая и специфичная одновременно, поетому многие вещи либо еще не разделены либо возможно разделены и не могут быть! То есть мы зачастую во многих случаях имеем дело с искусством больше а не с технологией как в производстве- нет у нас толком ГОСТов но производству, качеству, допускам и тд. Те же должности архитектора и тестировщика появились не так уж и давно 🙂
Я пока что не видел, чтобы схема «человек по спецификации выполняет работу» была хоть как-то эффективна.
Автор справедливо указал:
И не одному здравомыслящему человеку не придет в голову разделить процесс написания алгоритма (близкого к уровню кода), от самого процесса кодирования. Никакого выигрыша на этом уже получить невозможно.
Тут много нюансов. Когда алгоритм и код практически одного уровня то действительно разработчик алгоритма может без проблем используя синтаксис языка его описать. А вот если надо какой-то алгоритм оптимизировать и написать на ассемблере, то тут возможен вариант что это алгоритм специалист по ассемблеру сидит и кодирует 🙂
А вот более высокоуровневый пример: архитектор описывает интерфейсы и функциональность отдельных модулей, классов и тд., программист их реализует по этому описанию 🙂
Так что когда «человек по спецификации выполняет работу» — это очень эффективно! Так как разделение труда стало столпом промышленного развития.
Поэтому, кстати я и написал, что не имеет смысла разделять написание алгоритма (близкого к уровню кода).
С другой стороны, отделение архитектуры — очень разумный ход.
Согласен с Gef. Все таки токарь является кодером. То, что он понимает и может изменять чертежи, просто значит, что он перерос кодерство.
Поэтому сравнение не совсем правильное.
А я не согласен. Есть именно кодеры — люди, которые могут реализовать только то, что им скажешь/напишешь и только так, как объяснишь. Ну нет у них логического/абстрактного и т.д. мышления. Они на память помнят почти весь WinAPI, разбуди ночью — назовут все параметры любой функции языка программирования, но вот сами создать ничего не могут. Это не голые слова, это опыт.
С другой стороны, я не знаю программистов с большой буквы. Программист — это не титул, не статус в обществе и т.д. Но программист — это не кодер! Даже самый слабый программист, умеющий сам сделать небольшую, но полезную программку — выше любого кодера (для меня), который может реализовать полностью готовое ТЗ, но в принципе не способный сделать сам ничего полезного.
Теперь по поводу ремесло vs искусство. Для каждого кодера — это ремесло, т.е. факт зарабатывания на знаниях. Все. Но вот для большинства программистов — это искусство. Из той-же википедии:
Заметьте — процесс и итог. Т.е., искусство, это не только конечный результат. А для программистов, чаще всего, важен не конечный результат, а именно процесс. Программист стремится простейшую и примитивную задачу выполнить так, чтобы итог (программа) была уникальна по своему, со своими отличительными, запоминающимися деталями (вот вам еще одно отличие между кодером и программером: кодеру все равно, что он получит в итоге).
Считаю, что понятие — небольшая,но полезная программка — весьма расплывчато, например если я беру и пишу программку, которая исполняет какие-нибудь математические действия, выводит результат и этим помогает мне по учебе (то-есть полезна для меня), то кем я являлся во время написания кода, если смотреть по вашему описанию кодеров и программистов, мне лично не понятно. В хорошем ТЗ не должна присутствовать реализация, там должно быть написано, что сделать, а не как сделать, то-есть простора для творчества достаточно.
Если программа полезна и создана вами — соответственно вы программист :).
Я говорю не о четком разделении, а о своем опыте. Не надо придираться к словам и формулировкам, к хорошему это никогда не приводит.
А вот насчет ТЗ могу сказать четко — хорошее ТЗ содержит не реализацию, а четкий алгоритм, в котором описаны все возможности до мелочей. Кодеру остается только взять готовые, сделанные кем-то или же им самим, модули, возможно кое что доделать. Но, т.к. описано все, включая «какие кнопочки где должны быть», то кодеру и думать то особо не приходится. Любой кодер спарсит вам любую интернет-страницу за минут 30, но вот написать защиту для сайта от спама, от парсинга, от взлома — ни один кодер не сможет.
Дело не в просторе для творчества, а в том, что кодер не может придумать что-то существенное. Повторить что-то может, а вот с нуля, без ТЗ — нет.
Кстати, иногда кодер намного полезнее программера ;).
Даже не знаю. Может, кто-то и может и быть кодером, но пользы от него в комании ноль.
Если ему надо нарисовать алгоритм и пошагово все описать, то это займет дольше, чем человеку написать самому.
“Иску́сство — процесс и итог значимого выражения чувств в образе. Также высокая степень умения, мастерства в любой сфере деятельности.”
Замечу, дальше за словами «процесс» и «итог» идут слова «выражение чувств в образе».
Программисты не выражают чувств в программе (точно также как токарь).
Очень даже выражают чувства в коде!
Для меня например есть такие понятия как «логическая симметрия» и «красота архитектуры».
Я не знаю как эти понятия объяснить другими словами, но я это реально чувствую когда стараюсь написать хороший код. Именно ЧУВСТВУЮ смотря на всю картину как-бы в целом.
Так что не все так однозначно как вы думаете! :))
все «Программисты» поначалу были «кодерами».
Такими понятиями разграничивают программистов-новичков от матерых зубров. Просто кто-то называет начинающих «кодерами», подчеркивая их ограниченный опыт.
Из личного наблюдения: термином «кодер» обычно пользуются далеко не самые хорошие программисты.
Далеко не все, а вернее, только единицы становятся зубрами. Программист — профессия. И как в любой профессии есть новички и спецы. А есть гении, именно которых и называют Программист. Но таких очень мало. Мне даже кажется, судя по описанию, которым наделяют Программиста, что это больше мифическая личность.
Смею возразить на счет «процесса и итога».
И «программиста» и «кодера» интересуют результат. Только программисты берутся за сложные задачи (именно с целью их решить, а не просто порешать и бросить), а «кодеры» просто не достаточно опытны для этого и занимаются более простыми задачами.
Что-то в этом есть…
Кстати, «кодера» интересует именно результат — оплата своей работы, в то время как программиста — сам продукт. Может в этом вся разница? =)
Не согласен. Это полностью перпендикулярная плоскость. Нацеленность на финансы или на получение удовольствия.
Может быть есть какая-то связь, но очень непрочная.
В том то и проблема, что с одной стороны этим словом разграничивают опыт, а сдругой стороны показывают что человек не способен на составление алгоритмов.
Это не слишком правильный подход. Это тоже самое, что называть яблоком — яблоко и арбуз.
Ну ты зыгнул. Я осилил, правда согласен не со всем.
Во-первых тоже не понимаю когда говорят мифическт про программистов. Это бред. Хотя деление на кодера и программиста у меня свое. Я обычно называю кодером человека, который тупо пишет что ему говорят, не отклоняясь от лини ни в право ни в лево. Очнгь редко думает на написанным кодом и как его сделать лучше. То есть просто пишет, проверяет что работет и кладет в CVS. Ему часто наплевать на соблюдение модульности, на соблюдение архитектуры, про которую ему не раз говорят. Самое главное, чтобы работало. Для меня такие опаснее всего. А потом, когда на его место приходит другой человек, то он начинает разбираться в куче дерьма, что наворотил первый. Вот такого типа людей для себя я зову кодерами.
А программирование — это «ремесло». Это ты прав на все 1000%. И, к стати скзать, хорошие программист, всегда думает не только о том что пишет, он всегда думает о том, что его под буду читать и исправлять другие люди. И их время надо уважать. Писать правильно, делать коментарии. Соблюдать стиль проекта. Следовать кодинг стандарту (не фанатично конечно). Это все не так просто, как кажется на первый взгляд.
«все “Программисты” поначалу были “кодерами”.
Такими понятиями разграничивают программистов-новичков от матерых зубров. » — с этим согласен. Я думаю что это и имелл ввиду. Просто не все кодеры, в конечном счете, смогут стать программистами.
думаю как-то так.
кодеры — это новички, которые слушают и советуются со спецами. и следуют их советам не отступая ни вправо ни влево. набираются опыта.
я не считаю, что люди, которые пишут «кучу говна» — кодеры. простите, но это просто «производители говна». Случается такое, если плохо работаю менеджеры. Случается такое, если новичкам поручают сложные задачи, которые им решать пока рано.
Может такое происходит из-за большого спроса на программистов. Вот и идут в программеры все, кому не лень, толком не разобравшись.
Что все идут кому не лень — это правда. Но я вот наблюдаю картину, когда люди уже не новички, а просто кодеры. Им нравится (мне так кажется) делать то что просят и не в право и не в лево, хотя никто не запрящет. Просто основной принцип: пока прикрутите на скорую руку, чтобы работало, а потом исправим. Это бесит больше всего, потому что остается это навсегда.
А такой стиль работы прививают с самого начала.
Я дописал один P.P.S насчет этого ответа.
Проблема, что с словом кодер связано жуткое количество разных значений, причем, которые не совпадают с начальным и как я считаю правильным значением.
понятие «кодер» не связано с перфокартами — это 100%. на постсовке всех набойщиков в ВЦ называли «девочками» :). процесс програмирования тогда мой отец описывает так: «пишешь программу на листочке, относишь в ВЦ, а на следующий день забираешь стопку перфокарт и сидишь с читалкой — проверяешь, правильно ли всё набили».
так что кодер — это тот, кто пишет код. английская википедия даже не отличает coder и programmer.
по нашим суровым реалиям кодер = слабый програмист. такой просто удобное слово, которым напысченные придурки называют всех остальных 🙂
ха-ха 3 раза. это розовая мечта брукса — чтобы кодирование (создание кода) занимало маленькую часть от создания программы. но по факту на кодирование отводится от 30% (очень-очень хорошо), через 70% (обычно), до 90% (запущенный случай) времени создания программного продукта.
метры управления разработкой ПО (листер, демарко, брукс) посчитали в своё время, что разница между обычным и хорошим программистом легко может составить ПОРЯДОК. то есть хороший бывает лучше в 10 и в 20 раз. а вот плохой программист, но ещё не вредитель, может быть хуже обычного в 2-3 раза.
так что с нелинейностью как раз всё в порядке.
смотря какие требования — функциональные вобщем-то не отличаются: програмист должен делать то, что просят.
а вот нефункциональные отличаются очень и очень: качество с которой решается поставленная задача очень отличается, как и скорость, но скорость это главный образом функция высокого качества.
это кстати применимо не только к програмистам — вот 2 примера из жизни:
1. у меня на машине заедал замок — так вот его обычные мастера чинили 5 ДНЕЙ и сошлись на том, что надо заказывать запчасть из Киева. а потом с больничного вышел Мастер и починил за 20 МИНУТ.
по факту и так и так бы починили (функциональные требования), но скорость работы разная (нефункциональные)
2. индийские наставления по военному ремеслу (какая-то там часть Вед) говорит: хороший лучник должен не просто всегда попадать в цель — это не требует упоминания, ты не лучник, если промахиваешься — у хорошего лучника стрелы должны литься непрерывным потоком.
и обычные лучник и хорошй попадают в цель (функциональные), но хороший поражает больше целей за один и тот же отрезок времени.
программист, чтобы быть эффективным ДОЛЖЕН знать много чего помимо АПИ. смежные области имхо обязательно — например базы данных, html\css для вёберов… и желательно предметную область.
так что с одной стороны знать вроде и не обязательно, а с другой если не знать, то задача на 20 минут делается 5 дней. я уже писал про это: http://cotoha.info/thoughts/being-on-the-same-line-2/
отойдём от программирования и подумаем — должен ли знать гончар химию? токарь черчение? кузнец и каменщик сопромат? водитель устройство автомобиля? имха да. несогласны?
забыл вписать самое главное:
“пишешь программу на листочке, относишь в ВЦ, а на следующий день забираешь стопку перфокарт у ДЕВОЧЕК и сидишь с читалкой — проверяешь, правильно ли всё набили”
Да, возможно конечно этимология слова и не столько связано с кодирование vs алгоритмы.
>ха-ха 3 раза. это розовая мечта брукса — чтобы кодирование (создание кода) занимало >маленькую часть от создания программы. но по факту на кодирование отводится от 30% >(очень-очень хорошо), через 70% (обычно), до 90% (запущенный случай) времени создания >программного продукта.
Ну не знаю, у меня именно кодирование занимает небольшой процент времени. Большой процент времени занимают
— ресеарчи, как и что сделать
— отладка
— чтение документации
— обсуждение задачи
Относительно этого, само время которое я кодирую очень небольшое.
>так что с нелинейностью как раз всё в порядке.
Я имел в виду не нелинейность эффективности, а нелинейность требований, для того, чтобы быть Программистом (с большой буквы).
>смотря какие требования — функциональные вобщем-то не отличаются: програмист должен >делать то, что просят.
>а вот нефункциональные отличаются очень и очень: качество с которой решается >поставленная задача очень отличается, как и скорость, но скорость это главный образом >функция высокого качества.
Тем не менее, качество и скорость, вполне измеримые параметры.
Да, действительно лучшие программисты в 10-20 раз быстрее, хорошие в 3-5, средние как раз и есть то, от чего отмеряются разы.
Я в общем-то говорил о том, что до того, как первая буква становится заглавной, требования планомерно растут — выше скорость, выше качество, большие размеры проектов, более сложные задачи. Как только начинают говорить о программистах с большой буквы, то мгновенно требования прыгают в заоблочные дали.
>отойдём от программирования и подумаем — должен ли знать гончар химию? токарь >черчение? кузнец и каменщик сопромат? водитель устройство автомобиля? имха да. >несогласны?
Несогласен.
Итак, возвращаемся к ремесленничеству. Для того, чтобы стать профессионалом высокого полета, чаще всего приходится захватить __куски__ ближайших областей. Однако глубокое и полное понимание областей не обязательно.
Гонщик на ралли вероятнее всего знает, но тем не менее, оно ему не нужно, как работывает впрыскивание в мотор.
Токарь, должен понимать чертежи, но чертить сам не обязан уметь.
Кузнецы прекрасно ковали тысячи лет, без знания сопромата.
Есть единственное «но». Когда задача того требует, то ясно, что можно заняться изучением требуемой области. Но это скорее требование конкретной задачи, а не профессии в целом.
ну… возможно тут опять проблема терминологии. ресерч ресерчу рознь. можно «ресерчить» АПИ — время можно смело записывать в кодирование, а можно иследовать новые методики сжатия звука, чтобы подвинуть мп3 по популярности. чтение документации тоже по-большому счёту можно записывать в кодирование, а вот её написание — это совсем другой коленкор. отладка это 100% кодирование. потому что если её не записывать в кодирование, то перед неё должна следовать фаза не «кодирования», а «багирования» 🙂
не вижу логического противоречия. если нелинейность эффективности налицо, то почему требования должны быть линейны?
то есть на самом деле согласен 🙂
я не имел в виду, что надо знать в совершенстве смежные области — это невозможно, но понимание иметь надо.
нуууу. слова такого они и правда не знали, но законы знали и понимали прекрасно. хотя это конечно оффтоп.
тоже касается и водителя — не зная устрояства коробки передач нет возможности эффекстивно управлять автомобилем. мой случай 🙁 надо разбираться…
Насчет кодирования. У нас разное понимание. Для меня кодирование — это непосредственное время писания кода.
Отладка, исследование (в том числе API), чтение документации я к кодированию не отношу.
А насчет коробки передач. Есть базовые знания, конечно которые нужно знать. Но например, знать размер шестеренок, абсолютно не нужно.
Тоже оффтоп, слава богу, что у меня автоматическая коробка, вообще не нужно думать, как она работает и педали сцепления тоже нету.
>Гонщик на ралли вероятнее всего знает, но тем не менее, оно ему не нужно, как >работывает впрыскивание в мотор.
>
>Токарь, должен понимать чертежи, но чертить сам не обязан уметь.
>
>Кузнецы прекрасно ковали тысячи лет, без знания сопромата.
Ну на счет кузнецов без знаний ты погорячился. Конечно их знания не были скомпонованы в научные теории, но тем не менее, у них были знания, основанные на практическом опыте.
А тот, кто использует чужие чертежи и карбюраторы, чтобы выточить деталь без брака или пройти поворот на максимальной скорости, очень быстро становится достаточно опытен, чтобы иметь возможность оценить, на сколько хорошо начерчен чертеж или на сколько хорошо работает коробка передач. И они прекрасно понимают, что эти вещи, в которых они не обязаны разбираться, тем не менее важны для их успеха. И они понимают, что они могут повлиять своим мнением при выборе инструмента для себя. Вот те кто это понимают и учатся, и знают, и влияют на свое будущее. Те в будущем могут стать из токаря инженером, из гонщика — конструктором, из кузнеца — физиком. Если будет на то желание. Даже из официанта или швейцара — директором ресторана или отеля. А те кто считают, что оно им «нахрен не нада» и «это не их дело» — те до пенсии точат детали, метут пол и открывают двери.
Да собственно говоря я и писал, что они вполне могут знать кусочек другой области. Но вероятнее всего они эти знанию почерпывают по ходу работы, маленькими кусочками и в тот, момент когда задача того требует.
Опять же, даже слабый конструктор авто, заткнет за пояс знающего автолюбителя.
И очень средний чертежник будет знать гораздо лучше как чертить, чем профессиональный токарь.
несогласен.
вернее не понимаю градации — слабый конструктор заткнёт знающего автолюбителя, но на профессионального токаря нужен уже средний чертёжник.
вот я смотрю на программистов и говорю, что сильный программист сверстает лучше, чем средний верстальщик. сильный программист спроектирует базу лучше, чем слабый ДБА.
под сильный, слабый и средний я понимаю силу моска, а не опытность. то есть ДБА в моём примере имеет энциклопедический набор знаний в своей области, но применить его толком не умеет. а сильный программист не знает и трети того, что знает ДБА, но базы у него стабильно работают и масштабируются.
тоже неоднократно мать рассказывала про токарей-фрезеровщиков — мастера рисовали от руки лучше, чем чертёжники после института чертили с линейками, лекалами и кульманами.
мать работала инженером на ХАЗе
Я думаю мы уже углубились в борьбу мнений.
Я даже точно не понимаю о чем мы спорим :)))
Так, что я решил согласиться 🙂
и это правильно 🙂
Что, опять «сложности перевода»?
Читаем — Code monkey, и Programmer. Вникаем в глубинный смысл, а не в «национальные изыски» русской кальки. И снимаем данный вопрос раз и навсегда.
P.S. Именно из-за таких опусов с определением «кто есть кто» (я имею в виду и тех, кто якобы создает миф о Программисте, и автора данного блога), я и использую термин «Разработчик ПО» — Sofware Developer. А конкретные требования определяет набор РОЛЕЙ в конкретном проекте + перечень требований, которые нужно выполнить (из отображение на умения и навыки конкретных участников проектной команды). Чего и Вам советую 🙂
>Вникаем в глубинный смысл, а не в “национальные изыски” русской кальки.
Что вы таки емеете против национальных изысков? 🙂 Наши национальные изыски основаны на том же, что вы тут приводите в качестве примера + собственный опыт, так что мы в своих изысках уже пошли дальше Вас 🙂
Не воспринимайте серьезно. Просто нужно относится к статье так, как ее преподносит автор, а именно субьективный анализ мнений, а вы пытаетесь ее сравнивать с энциклопедией.
Я скорее предпочитаю пользовать термин программист именно в том смысле, как вы пользуете термин Разработчик ПО.
А насчет Code Monkey. Хотя, мое понимание кодер слега с другой стороны пришло, но оно идеально соотвествует первой части:
>More specifically, it refers to a person only capable of grinding out code, but unable to perform the >more intellectually complex tasks of software architecture, analysis, and design.
То есть человек по набиванию кода, но который не умеет сам составить алгоритм и продумывать дизайн и архитектуру.
> often applied to the most junior people on a programming team.
Вот это как раз меня и беспокоит, что в термин влились два понятия
а) Отсутствие мозга
б) Отсутствие опыта
А это абсолютно разные вещи.
Вить, что есть опыт? Опыт — это накопление знаний и умений. Но знания и умения бывают разными. Бывает что человек знает 1000 инструментов (функций, классов, библиотек, технологий), их названия и единственный способ применения каждого и при этом его поведение при использовании его вне системы. А бывает человек знает 1-2 инструмента, но досконально может этим инструментом сделать все, что угодно быстро, при этом практически в любых условиях. Оба опытны, шо трындец. Один в масштабах, другой в глубине. Кто из низ лучше? Кого ты возьмешь в свой длительный бизнес (я имею ввиду, если ты или твой заказчик рассчитываете зарабатывать на продажах проекта и вам нужно качество?) Я лично не возьму ни первого ни второго, если они не способны изучать незнакомую или малознакомую технологию по ходу работы…. 🙂 Для меня решает не опыт, а способность обучаться.
Согласен с тобой на 100%.
Я всегда предпочитаю специалиста с одним глубоким знанием и хорошим запасом разнообразных мелких вторичных знаний. Обычно эта комбинация значит, что человек
умеет копать и в глубь и в ширь.
Кстати, именно поэтому я и написал
а) Отсутствие мозга
б) Отсутствие опыта
От пункта б) вылечиться можно. От пункта а) нельзя.
С чего вы взяли, что «most junior people» означает отсутствие мозга?
Для того, что бы кодировать мозг НЕОБХОДИМ. Включительно с пониманием спецификации, чтением API и отладкой с оформлением кода. Без них невозможно получить результат — компилирующийся и запускающийся исходный код. Не нужно Code monkey считать полным дебилом — ведь такой кадр не пройдет собеседование, да и в резюме ни строчки написать не сможет (если не соврет).
А вот отсутствие знаний, опыта и навыков (советую изучить эти 3 понятия пристально — они объективны, хотя вы считаете их субъективными, а потому неизмеримыми) — как раз и решает. При этом навыки наибольшую роль играют как раз в ТВОРЧЕСКОЙ составляющей разработки ПО.
В самом общем случае:
— Из знаний кодировщику ДО начала работы необходимо лишь одно знание — знание синтаксиса.
— Из умений — умение работы со средой разработки (причем понимать принципы ее функционирования не обязательно) + умение искать доку.
— Минимальный навык — набор текста (с форматированием) на ПК.
Наличие и/или скорость получения определенного набора навыков для определенной области разработки ПО в определенной компании-участнике рынка (потребляющего это ПО) — вот отличие кодировщика от профессионального разработчика ПО.
При всем при этом, переместив супер-пупер разработчика из привычной среды в совершенно новую (не будем уточнять причину, но обычно это деньги 🙂 ) мы можем получить опять кодировщика. Много факторов вляют на оценку конкретных знаний и опыта. А большинства навыков в новой среде не может быть по определению.
P.S. Предлагаю изучить такое понятие как «уровни готовности» из методики Ситуационное руководство (Situational Leadership) — множество вопросов отпадет и извилины встанут на свои места 🙂
>С чего вы взяли, что “most junior people” означает отсутствие мозга?
Не в коем случае, я так не считаю.
Я как раз писал, о том, что в понятии кодер смешалось две вещи
а) most junior person = отсутствие опыта
б) программист который толком ничего не умеет (code monkey) = отсутствие мозга.
>Не нужно Code monkey считать полным дебилом — ведь такой кадр не пройдет >собеседование, да и в резюме ни строчки написать не сможет (если не соврет).
Ну, может не полным дебилом. Но, для меня программист, который не может сам
составлять хотя простые программисты, не заслуживает почетного звания умного человека (особенно в том случае, если у него приличный опыт работы).
Это, конечно, оффтопик, но раз уж мы ищем различия между названиями профессий в IT, то может мне кто-нибудь объяснит, чем отличаются тестеры от QA? Один мой знакомый упорно обижался когда я его называл тестером и хотел слышать только QA. А какая разница?
ты его «Тостером» называй во избежание разгогласий 🙂 будет ясно что ты шутишь и в то же время понятно, о чем идеть речь.
Я лично употребляю слово «кодер» ко всем программистам просто потому, что это слово короче и его быстрее сказать 🙂 Тем более что зачастаю заказчики нам, прикладным программерам, ставят задачи, которые сложно назвать написанием программы 🙂 Мы просто берем сотни различных библиотек, классов и собираем из них, как из конструктора готовый продукт. Ибо так быстрее и дешевле, чем изготавливать все детали самим. Я бы сравнил такую работу с работой монтажника. Правда вот как раз именно «слабые» и «неопытные» программисты все чаще норовят воткнуть в общую стройку, собственноручно изготовленный «кирпич» или «балку» 🙂 и там где нада и там где не нада. Они не понимают, что уже выложенный в инет для общего пользования либа или класс, скорее всего уже оттетсирован и проверен не один раз, а собственный класс 100% содержит баги и его еще прийдется сто раз отлаживать, и вам очень повезет в итоге, если этот собственный класс не лежит где нибудь в фундаметне продукта, а его недостатски будут обнаружены на этапе бета-тестирования. 🙂
А бывает еще круче. Возьмут человека на проект, который пишется с использованием фреймверка. И программист он вроде бы не плохой. Но вот постоянное желание воткнуть что-то свое и нежелание или лень изучать что-то новое приводит к тому, что он все равно пишет больше половины кода не используя фреймверк, в итоге пишет дольше, реализует чуть ли не на четверть уже готовые части фреймверка при чем все это у него безбожно глючит 🙂
Ну не знаю. Я еще не видел ни одного, подчеркиваю, ни одного проекта, который можно собрать из готовых блоков.
В каждом проекте где я участвовал, в лучшем случае есть API на нужную тему плюс библиотеку на нужную тему. После этого, долгими зимними вечерами все это собирается воедино, ставятся собственноручно сделанные балки, кирпичи и т.п.
Потом все дотачивается напильником.
Я ж не зря написал «и там где нада и там где не нада». Я знаю что это таки всегда нада. Я еще не натыкался на продукт в котором нет багов. Не далее как сегодня я потратил целый день и пол предыдущих дня на отыскивание бага, который оказался не нашим, а php-ешным (точнее одним из его модулей) и способом его обойти (при чем способ не потребовал написания ни единой строчки кода). В итоге я полтора дня не написал ни строчки кода, но 50-т из 100-ни текущих багов по проекту можно смело закрывать. А вообще лучше все сотню отправить на «регрессию», потому что у меня нет времени разбираться какой из них был вызван этой проблемой которую я решал, а какой действительно баг. И главное я знаю, что кроме меня щас никто в мире наверное за полтора дня не понял бы в чем тут собака порылась. Потому что я на проекте уже почти год. А код такой презвезденый, что мамамия. Я потому и пытаюсь щас ПМ-а уговорить переписать код проекта на питон+джанго. другое дело, что на конторе кроме меня их щас никто не знает, да и я на них опыта не имею… А проект таки дорогой. И переписывать его будет дорого. Но я таки эту тему пробью, потому что по большому счету собственно непосредственно девелоперский код у нас это лишь 20% проекта, если неменьше.
>А код такой презвезденый, что мамамия. Я потому и пытаюсь щас ПМ-а уговорить >переписать код проекта на питон+джанго. другое дело, что на конторе кроме меня их >щас никто не знает, да и я на них опыта не имею… А проект таки дорогой. И >переписывать его будет дорого. Но я таки эту тему пробью, потому что по большому >счету собственно непосредственно девелоперский код у нас это лишь 20% проекта, >если неменьше.
М… Не слишком люблю давать советы впрямую. Просто выражу свое мнение, а там уж тебе решать.
Из собственного опыта и книжечного опыта. Лучше текущий проект приводить в чистый и причесанный вид (рефакторингом), чем переписывать весь проект, тем более на технологую, которой владеет (да и то не в полной мере) один челове.
А уж php’истов найти, которые код расчистят — вполне можно.
Увы, бывают ситуации урезанного бюджета. Когда нормального программиста нанять не на что и приходится брать «кодеров», которые дают чудовищный оверхед как наверх так и вниз 🙁
Угу… Знаю такую ситуацию. И по этому поводу есть отличная русская пословица — скупой платит дважды.
Нанимать плохих программистов при урезанном бюджете, тоже самое, что лечить вшей с помощью гильотины.
Вить, и все читатели, вот сегодня на ДОУ выудил линк на интервью интересного товарища. В одном из ответов на вопросы он касается темы данной статьи 🙂
http://www.profosvita.org.ua/ru/success/interview/12.html
А именно читаем ответ на вопрос «- За что любите свою профессию?». 🙂
Забавное интервью. И что приятно, товарищу еще программирование не сильно приелось.
Я бы написал бы в темных тонах.
Кодер — набивальщик кода.
Программист — человек, способный придумать самый эффективный в данном случае алгоритм и его же воплотить самым оптимальным способом.
Кстати, еще одна линка на тему программирования-искусства.
http://cylib.iit.nau.edu.ua/Mirrors/ask.km.ru/unics/programming.html
Правда лично мне статья показалась слишком непродуманной. Скорее криком души что ли.
Больше всего меня добила в выводах фраза «Уровень консультаций в конференциях Интернет за последние десять лет сильно упал. Профессионалы не желают терять время на то, чтобы просвещать своих потенциальных конкурентов». Автор не осознает, что это обусловлено прежде всего тем, что 10 лет назад инженер-программист не считалось особо престижной профессией. Да конечно тогда все специалисты твердили, что компьютеры скоро будут обычной бытовой техникой и что для этой техники потребуется куча программ, но не все ведь серьезно относятся к прогнозам. Потом новичков было мало, а опытных программистов и того меньше. Новички хотели учиться прежде всего и прощали профессионалам их стеб или еще ворчание, но хватали на лету все умное и дважды не переспрашивали, да и когда их посылали читать мануал, то они шли и добросовестно читали. С такими новичками профессионалу приятно общаться. Другое дело сейчас. Два из трех новичков-программистов ненавидят учиться, а тем более читать. Они хотят все и сразу. После пару ответов в конференции типа «да нету у меня времени там лазить… скажите мне просто как вывести на экран «хэллоу ворлд!» и я пойду. » отпадает всякое желание отвечать кому — то на вопросы 🙂
Я думаю дело еще в другом.
Раньше программирование больше походило на черную магию. И вот маги собирались и делились своими заклинаниями.
Сейчас программирование больше стало похоже на клепание гаек (в лучшем случае на строительство многоэтажки). Из-за этого
а) Не так интересно делиться данными
б) Уже есть гигантское количество информации, которые и так можно найти в Google (кстати, его как раз 10 лет назад не хватато).
Это еще раз подтверждает, что я тупой кодер…)))
>Сейчас программирование больше стало похоже на клепание гаек (в лучшем случае на строительство >многоэтажки).
Мда, «best practices» и прочие шаблоны сильно подкосили и без того слабое желание использовать голову. В результате можно найти сколь угодно много специалистов, способных реализовать типовую задачу на стандартной платформе, по которой у них тьма сертификатов. Но лишь только условия задачи становятся чуть менее стандартными — труба. Не могут, ибо думать надо, а стандартные решения не прокатывают.
Особенно часто подобные ситуации случаются в области систем реального времени и высокопроизводительных алгоритмов.
Отличная статья про программирование