Соблазн не писать ерунду? Или если заставлять писать ерунду, то везде?
Методы с аннотацией ни на один бит не более документированы, чем методы без аннотации, если там тупо повторение названия методов и переменных.
Мы исходим из разных положений. Вы по-умолчанию считаете, что комментарии — это хорошо. Поэтому видимо такой вывод: создает нехорошие соблазны их не писать.
Я же думаю наоборот. Иногда комментарии полезны. Ну не сверхчеловек я, точнее, не сверхпрограммист. Чтобы смысл идеально закодить, чтобы код читался как книга, был кратким, ясным, лаконичным. И вот тогда появляются комментарии — как признание своего поражения. Иногда пишу аннотацию. Но только на тот параметр, который непонятен. Например, возврат булевского значения, а имя метода и так перегружено, чтобы понять, что значит истина, что ложь. Когда редко появляется комментарий, то он становится более полезным на фоне их отсутствия. Он больше притягивает внимание. Зачем писать бесполезный мусор? Это анти-DRY. Потом, при любом рефакторинге в смысле переименования (из другого места в коде), добавления переменных, изменения интерфейсов — аннотации устаревают и вводят в заблуждение.
Недавно писал сравнительно большой проект. Он зависел не только от моего кода, но была уже БД, поэтому был местами связан с кривым кодом. Пришлось писать комментарии в местах, чтобы пояснить, почему я так нестандартно написал код.
Комментария было за всё время штук 10. Но они так быстро устаревали, еще до того, как я класс допишу. В итоге осталось штук 2 комментария.
Да, и аннотации — это еще вопрос стиля, принятого в команде. Вообще, тут не о чем спорить, писать их не так напряжно. А для библиотек для внешнего использования может быть даже соглашусь с натяжкой, что нужны. Ну там, в док-файл выгрузить, схемы построить.
Код надо (в идеале) писать так, чтобы он выражал требования. А не реализацию. И правильно писали, что вместо комментариев эти требования прекрасно выражаются еще и тестами, если кодом не удается.
Суть поста, насколько я понял, и того, что я думаю — не в том, что надо запретить комментарии, а в том, чтобы определить куда стремиться и что хорошо, что плохо. Комментарии — это плохо. И их надо писать, когда уже не осталось других способов. Комментарии — это худший способ улучшить читаемость.
Чтобы немного сместить взгляд, представьте себе, что такое функция и что такое класс в другом русле. Тут где-то было и в комментариях к другим постам, что не имеет смысла выносить код в функцию, который используется один раз. Это механический способ рефакторинга, когда вы следуете DRY. Но можно кроме механики, ввести другой критерий. Допустим, вы написали довольно длинное полотно — код функции. Далее, хотите поставить комментарии на какие-то куски, объясняя, что они делают или как. Именно в этот момент, когда рука потянется комментировать, этот кусок и становится кандидатом для получения названия. И комментарий — по сути название новой функции. Тогда ваш код станет легко читать, как и комментированный. С той разницей, что смысл выражен в коде, а не в комментариях.
Всё это конечно спорно и требует чувства баланса. Языки программирования к сожалению не идеальны. Или я таких не знаю. Сила выражения мыслей на языке программирования зависит от языка, очевидно. Например, на Си, где нет эксепшинов, даже маленькое действие в методе превратится в много проверок и выходов. Но в С#, на котором сейчас работаю, действительно можно неплохо выразить мысль, без никаких дополнительных комментариев.
Если так, то переменная и должна назваться ageOfPersonInDays. Если в примере написали код, оставив переменную с названием age, а написал, что она в днях, то здесь и кроется ошибка программиста. В том то и зло комментариев, что они скрывают говнокод.
Язык программирования первичен и именно на нем по возможности надо выражать мысли, а не в комментариях.
Какие еще могут быть хитрости у этого метода? Иногда нужна аннотация из-за невыразительности некоторых аспектов языка. Например, это был C# и там как-то в сигнатуре нельзя указать, какой эксепшин будет.
Может быть int не подходит, т.к. отрицательные значения имеет. Опять же, смотрим на эту ситуацию и сразу думаем о коде, потом о комментариях. Если в коде, то есть uint. Если надо любое число, до секунд, с отсутствием отрицательных значений, то опять же, глупо внутри городить проверки и эксепшины и описывать их в комментарии — можно ввести специальный тип Age. То же и с телефоном.
Сигнатуры — тоже код. Аннотации — тоже комментарии и на них распространяются те же аргументы. Как думаете, насколько информативно такое комментирование?
/// <summary>
/// Adds Person
/// </summary>
/// <param name="age">Age of Person</param>
/// <param name="phoneNumber">Phone Number of Person</param>
void AddPerson(int age, string phoneNumber)
Ответ — ни насколько. Думаете это рафинированная ситуация? Отнюдь. При нормальном наименовании переменных, имен методов, параметров, комментировать практически везде бессмысленно.
Другое дело, что совсем иногда, когда какая-то хитрость и нельзя очевидным образом ее в коде выразить — тогда и комментируем. Понимая, что зло как раз в хитрости и вы сдаетесь, пытаясь прикрыть ее комментарием как фиговым листочком.
Почему не надо?
Перечитайте еще раз на цитату Макконела orionll
Константы, в отличие от комментариев — это код. Со всеми вытекающими. Это значит, что коду больше внимания. Это значит, что имя константы устаревает гораздо реже. Лично я вообще не помню, чтобы они устаревали, т.к. IDE прекрасно справляются по переименованию константы. Комментарии не компилируются. И не переименовываются во всех местах с помощью каких-то технических средств.
Да и самое главное — язык программирования — это в первую очередь язык. Ваша задача — выразить замысел требований на языке программирования.
Если код читается плохо, надо учиться что-то с кодом делать, чтобы он читался лучше. Код для программиста должен стать родным языком. Ни ЮМЛ, ни комментарии. С чего вдруг программисты когда-то решили, что комментарии так нужны? Похоже, что это были либо программисты, для которых язык программирования не родной, либо уже такой язык программирования, не позволяющий кратко/емко выражать мысли. Приходится мысли дублировать на естественном языке, разжевывая, что делает код, или даже цель/намерение кода.
Код говорящий? — пусть новичок читает.
Код говорящий, новичок не умеет читать? — не умеющий читать тот язык, на котором пришел работать, не нужен проекту.
Код не говорящий? Переписываем код, потому что он говно.
Код не говорящий, но его переписать понятнее нельзя (потому как хитрая оправданная оптимизация, например) — тогда и начинаем думать о комментировании.
Да да. Меня всегда принцип Парето формально удивлял. Люди с ГСМ очень его любят. Но при этом никто не думает, что для того, чтобы 20 процентов выстрелило, надо пропахать и 80 процентов.
А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
Понимаете, решения не могут приниматься просто так. За каждое решение кто-то несёт ответственность.
Это и есть корень ваших заблуждений. Как раз это и связанно с психологией. Вы не представляете себе процессов, не построенных на иерархии и подчинении. Армейско-зоновский вариант управления. Водопад. Поиск виновного. Вроде про это уже не мало написано. В программировании это несет только негативные последствия.
Какая ответственность, вы о чем? Людей должна мотивировать не ответственность, а заинтересованность в конечном результате и вовлеченность.
безусловно, держать в голове всю реализацию системы — не возможно. А вот какую то её часть, или общую схему — вполне.
конечно
Да, люди, выполняющие роль архитектора могут меняться. Но в данный конкретный момент времени должен быть конкретный человек, который отвечает за некую часть архитектуры (или за архитектуру в целом).
Тут где-то я пропустил целый пласт логики — вывод, что нужен/нужны архитекторы. Подмените кругом слово «архитектура» на слово «код», уберите слова «отвечает» — потому как программист не отвечает ничем и времена инквизиции прошли, а в тюрьму не посадят — и всё снова сходится.
В противном случае, на вопрос «почему мы потеряли гибкость системы» Вы получите ответ в стиле «ну… так получилось».
Так и получается. Вне зависимости, «отвечаете» вы или нет.
Архитектор и рядовой программист — такое деление хуже чем по рассам. Это подразумевает разделение работ. Т.е. будет значит некто, кто «творит» и кто это воплощает. Просто это и есть нонсенсом. Если должен человек держать в голове кусок абстракции — как работает система, то лучше, чем тот кто этот кусок и пишет — никто знать не может. Поэтому архитекторы, как выделенные люди, не нужны.
Знаете, это абсолютно не понятный для меня момент. Программист (10 лет опыта работы). Вот что мне с этим делать? Что вообще значит 10 лет опыта?
То и значит. Видимо как-то надо к объяснению статистики перейти.
Если перед вами описание знаний двух разных людей, совсем одинаковое, но у одного написано — год работы, а у другого десять. Кому предпочтение? Это называется «при других равных условиях».
Почему предпочтение второму? Потому что скорее всего он меньше врет о своих навыках.
Сложнее. Если два резюме, одинаковых, по скилам, но у одного возраст 23, а у второго 30. Кому предпочтение? Второму. И хотя Вы на самом деле не знаете, может 30-летний в 29 начал карьеру, а 23 с 13 лет писал сайты и вообще гений. Но, среднестатистически у второго больше опыта. Почему? Потому что опыт растет с годами, а не уменьшается с годами. Поэтому статистически, чем старше человек, тем вероятно он получил больше опыта.
А вот, перепрыгивать не надо в плане — а может у него другой опыт в другой сфере. Это уже не равные условия. Мы сейчас рассматриваем только конкретный вопрос, не включая другие. И очень вряд ли, я думаю, вы вообще рассматриваете кандидатов на микроконтроллеры, у которых в резюме только сайты на ПХП.
Насчёт остального — Вы работали в крупных проектах? Если обьём проекта достаточно большой, то удержать всё в голове программисту просто невозможно. Ни задачи, ни архитектуру.
Упс, это уже другая тема. Но вообще, как раз, по сути, по смыслу у вас противоречие. Если проект достаточно большой, то в голове вообще, человека удержать всё невозможно. Именно поэтому и работают эти практики — кодом и проектом владеют все. Меняются местами, если что. А то получается, что рядовому программисту невозможно, зато есть полубог, которому это возможно — называется архитектор. (я не зря и раньше сказал, что это бог. Его наделяют божественными полномочиями — знать всё и присутствовать везде).
Хороший программер за 2-3 недели может вытянуть стиль наименования переменных и отступы. Но не сделать из джуниора хорошего программера. Код и архитектура — это как Ленин и партия — одно и то же. Кодирование равно созданию архитектуры. И поэтому джуниор не вытягивается за недели. За год, возможно. Если мозги на месте и хорошо ему объясняют, а также дают потренироваться. Но это всё затраты.
Работа без архитекторов возможно. Скорее с ними невозможно нормальный код писать. Потому что (снова) — код и архитектура — одно и то же. Мало того, даже разрабатывается в кой каких методиках одновременно.
Но давайте закончим тему архитектур, потому что я и раньше об этом много писал и думаю, не стоит снова начинать.
Вообще — деление людей по какому то признаку (возраст, пол, «опыт», раса, национальность) — уже явный признак неуверенности в себе, и попытка преподнести себя с лучшей стороны как представителя «лучшей» части людей.
А перевод разговора из точных наук в гуманитарную область вообще не люблю. Когда-то писал в каментах. Был у меня коллега-начальник как-то, который настолько был заражен православием, что это мешало работе. Как только я предлагал что-то сделать или применить другой подход, критиковал что-то — это воспринималось не прямо, не по смыслу, а как гордыня.
Деление по признаку возраста я четко обосновал — небольшой возраст -> небольшой опыт (не факт, может быть возраст большой, а опыта год) -> плохой код.
Менеджеры — не позор, а позорище. Дело не в их молодости, а в том, что мешают работе. Но деньги зато делят )))
Наличие менеджеров или их отсутствие — это не проецируется на людей и никак я не считаю, что молодые люди плохие, что менеджеры плохие. Есть и друзья среди менеджеров.
Это просто мой взгляд на процесс разработки. Он далеко не уникальный. Многие компании отказываются от этого балласта. Аджайлы, ТДД, эволюционное проектирование, ДДД. Нет места там архитекторам, управляющему персоналу. Он номинально часто там существует для решения задач, не связанных с разработкой. А команды, наверное, должны саморганизовываться. Сюда же — отсутствие нянек и джуниоров. Отсутствие выделенного бога, который говорит, как кодить, а проектирует сам. Где-то так.
Это не имеет отношения к психологии. Только к взглядам, как работать эффективнее.
Нет, обиды нет. Просто везде катастрофа, а меня это не касается ))
Сейчас я делюсь с Вами и другими молодыми опытом: надо стремиться к знаниям и учиться всё время. И 30-35 (скоро и 40) — не являются пределом и глубокой старостью. И опыт и знания, если есть конечно, привычка учиться — растут.
Дос-программы: нет в общем ничего плохого. Даже еще лет 10 не будет. Когда Вы учитесь программировать, то по сути просто нужно уметь запустить программу из командной строки. Когда вы изучаете структуры данных — рисование мышкой красивой формы отвлекает.
Но вообще, да, образование устарело. Думаю, нас в ближайшие 10 лет ждет полный пересмотр. Образование уйдет в интернет.
Мир изменится. О да. Особенно подростки об этом думают, когда считают радикальным изменением — у каждого в кармане смартфон с злыми птичками.
Мир меняется. Факт. Но есть базовые знания. Которые не меняются десятилетиями. Вы выше про Лисп написали. Как-то это не устаревает. Кнуты, Дейкстры. Меняется в основном — Magento, Twitter Bootstrap, всякие укоз и еще какая-то хрень. HTML 5 появляется, свершается невиданная вещь доселе — в теги можно добавить проигрыватель музыки. Кнопочку покрасивее добавить.
Ну и тому подобное.
Это всё тоже надо. Это всё хорошо и прекрасно. Я бы советовал только смотреть на суть и не считать эти фантики чем-то радикальным. Хорошие знания почти не устаревают.
Единственное что я хочу сказать — возраст и номинальный опыт — это не то мерило, которое нужно считать приоритетным
Это буквально единственный объективный критерий, если вы видите человека впервые и собеседуете. К сожалению, собеседования в течении месяца с разными заданиями — не проводят. И просто не стоит думать вообще никак, что человек способен быть синьером (по способности решать задачи) до двух лет опыта работы. Дальше будут варианты. Хотя, может быть, это по разному в разных языках и технологиях. Если Вы думаете, что человек справляется — возможно это так. Но возможно, что а) задачи у вас простые (хотя, а где они сложные) б) вы просто не сравниваете качество кода и производительность с реально опытным человеком.
Если справляется — то в общем ничего больше не нужно, всё прекрасно.
От кода тошнит, не от программистов. Не единым программированием живем, чтобы на людей проецировать недостатки при написании кода.
Жаль конечно, но одним «опытом» сотрудника, просто так, сами по себе дела не делаются.
Ну да, конечно. Надо взять и еще код написать. Опыт на клавиатуру не нажимает сам по себе. Но что-то Вы никак не хотите воспринимать аргументы, которые мне кажутся обоснованными. Без опыта вообще ничего не делается. Знания из Космоса не передаются, чтобы написать вменяемый код.
И да, это очень не приятно, я знаю, но все люди разные
Развожу руками. Или Вы меня сразу записали в тупого, но опытного, а есть умнее, но в 20. И мне должно быть очень неприятно это осознавать. Повторю, я не считал себя тупым. И сейчас не считаю, что был слабым интеллектуально в 20. Аспирантура, математика, научные задачи — всё было. Скорее, я решал тогда часто и гораздо поумнее задачи, чем сейчас. И скорее всего, тогда решал задачи (и сейчас их могу решать), которые многие не решат. Так что про ощущение своей беспомощности перед 20-летними интеллектуалами — это не ко мне.
И да, был у нас случай. Взяли человека с большим опытом. 37 лет. А то, что он написал в коде — никак не классифицируется, даже в тупые не запишешь.
Но все равно: код у меня был говно поначалу. Сейчас я разгребаю довольно знатный говнокод такого молодого, но архитектора. Вот прямо сейчас. Г на Г и Г погоняет. Человек он неплохой. Я не злюсь на него. Мало того, я помню, что в первые два года, когда я набирался опыта, я думал и писал ТОЧНО ТАК ЖЕ.
Если Вы думаете, что у меня мозоль… Не знаю, не копался так глубоко в себе. В ответ, могу сказать, что Вам скорее всего еще нет 25-ти. Поэтому Вы так и рассуждаете. До 25-ти так мыслят все поголовно. В университете тоже немного преподавал. И даже когда-то учился. Чтобы разрушить миф о том, что вы уже умные и вам хватит, то я помню два разных преподавателя говорили так:
1. Я в вашем возрасте уже был. Вы в моем еще не были.
Второй задал такой вопрос:
2. Вы не думайте о других, подумайте о себе сейчас и о себе через 10-20 лет. Вам бы хотелось прямо сейчас иметь знания и опыт, который будет у вас потом?
Т.е. молодые люди всегда думают о ком-то другом. Все люди разные. Так легче обосновать свою значимость для себя.
Возраст при приеме на работу — один из важных объективных показателей. Когда человеку 22 или 23 и он заявляет, что он синьер/мидл — ну как-то я не знаю даже, как назвать. ЧСВ у молодых людей выше крыши. А еще до 25 лет люди часто думают, что в 30 они обязательно будут владельцами крупного предприятия. Желательно с ГУГЛ, но в принципе можно согласиться и на что-то меньшее.
Я пару раз слышал такое: если человек в 30 лет еще не управляет, то он неудачник. От начинающего программиста, который еще даже ООП не понимал. Сейчас ему за 30, делает до сих пор самую примитивную работу.
Менеджер, которому 25, будет думать, что он нужен, чтобы своей рукой направлять безвольных технических специалистов. Для него, лучше, чтобы они были помладше. Потому как дядьки за 35 не особо понимают, что не могут ничего решить без проницательного, мудрого не по годам, хоть и не разбирающегося в технических деталях, но ведущего слепых через лес, управляющего персонала )) Пусть этот менеджер и не знает, как устроена система. Пусть не соображает, как она может развиваться. Ведь его дело — быть магом, чародеем, специалистом 80-левела в психологии, особенно в НЛП, — это обязательно ему помогает выбрать правильное решение.
У вас был опыт? Мой опыт говорит мне, что в коллективе, где есть хороший code review очень быстро стирается разница в стиле кодирования.
Конечно был. Как дежавю, повторяется постоянно. В большинстве случаев даже плохого code-review нигде нет. Потом, code-review дает улучшение качества кодирования в коллективе, если там «есть у кого списать», а не все двоечники. Последнее очень распространено. Сейчас такая везде война происходит — опыт против единомышленников. Если собираются несколько неопытных, то они как соловей и кукушка друг друга поддерживают. Потом пишут статьи на хабр. Потом другие, такие же, находят «подтверждение» своим «убеждениям». И так по кругу.
Кстати, здесь вполне вменяемое сообщество. Если зайти почитать обсуждение на украинском сайте DOU, то плакать хочется ((. Любой вредный совет будет считаться хорошим. А самый вредный — самым лучшим. Тесты — отстой, оптимизировать заранее очень правильно и самый шик, джаваскрипт — идеал, хаскель — отстой. Ну и в таком духе. Мол бабушка сказала, что на джаваскрипте можно работу найти )))
По этим обсуждениям можно судить о мнении большинства. Если соберется 10 четверокурсников в офис, на один проект, они ни в жизнь не поверят, что люди за 30-ть будут умнее их. Конечно, они тупее, они не понимают в новых веяниях, они консервативны и не хотят вводить новые фишечки.
Именно поэтому я говорю, что нельзя человека оценивать исключительно по годам опыта.
… Да вроде как я везде добавлял, что это не достаточное условие. Но необходимое. Опыты разные. Но хоть и Била Гейтса будет учить первых два года — джуниор. По задачам, по уму и по количеству знаний. Мозги, знания, не прекращают развиваться ни в 16, ни в 25. Если ими пользоваться.
Да, я понимаю, что с 10 годами опыта обидно наблюдать, что существуют «23х летние синьоры».
Не обидно. Это просто самоназвания. Как мне говорила одна знакомая HR — называй себя хоть «их бин экспертом» — твое дело.
Хреново с кодом таких синьйеров работать. И себя я не считаю тупым, но хорошо помню, как я писал код первые два года. И на самом деле процесс улучшения качества никогда не прерывался. И на самом деле я после почти 10 лет опыта тоже еще хочу некоторые книги почитать, еще не всё знаю. Спросите у любого с опытом работы, не в плане, обидно ему или нет из-за выскочек, а спросите так: был ли у него лишним опыт работы? Стал ли он хуже писать за последние 5 лет? Или все таки лучше?
Мидл, джуниор, синьор, тимлид — все эти «звания» не описывают опыт работы, знание технологий, алгоритмов, дипломы, возраст и так далее. Они описывают то, как человек справляется со своей работой (и какие функции он может выполнять).
Если провести аналогию, то это высказывание примерно такого плана: «Не надо чистить зубы. Смысл не в чистке зубов, а чтобы они были здоровыми»
1. Менеджер обьяснял проблему, возможные решения и риски.
Если менеджер может объяснить «возможные» решения — то это уже не тот менеджер, о котором я говорил. Но даже хорошо разбирающийся в технических деталях менеджер, но не участвующий прямо в разработке — все равно лишнее звено. Часть работы, такой менеджер, все таки может выполнять. Так что однозначно нельзя сказать. Но все же. В посте как раз про лидерские качества. Безвольных программистов набираете, что им нужен «сильный лидер»? ))
Один человек — не статистика. Я не знаю ни одного, который бы согласился работать даже в хорошем коллективе, зная, что ему в других местах платить будут в полтора-три раза больше.
Второй момент — джуниоры бывают разные.
Конечно. Я вообще-то лично не отношусь плохо к джуниорам. Потому как я не владелец компании, который тратит на них деньги. И программисты должны откуда-то появляться, где-то набираться опыта.
Но я рассуждал с т.з. компании. Невыгодно.
На моих глазах, человек, которого брали джуниором (первая работа на 4курсе) через месяц считался хорошим мидлом
Мне недавно родственники рассказывали с умилением, что видели по телевизору, что во Львовском каком-то университете 6-летний ребенок ведет лекции по истории. И еще добавили, что увидели (это всё в какой-то попсовой передаче), что 14-летний написал суперсистему какую-то и заработал миллионы. Мол у нас очень умная молодежь растет. И не надо думать, что мои 10 лет опыта работы что-то значат. Молодые обскакают.
)))
Это всё реалии нашего рынка труда. Считался человек опытным мидлом, среди видимо таких же опытных мидлов. Уже оскомину набила тема 23-летних синьеров. Не хочу сказать, что люди тупые. Но за красивые глаза и за большой ум, который в потенциале, где-то лет через пять начнет работать при наличии знаний — деньги платить не честно. Мидлом давайте честно считать человека с минимум 5-лет опыта работы, а синьером с минимум 8. Это, конечно, не достаточные условия.
И самое главное — если Вы не понимаете того, как Ваш руководитель принимает решение — то спросите его об этом. Считать человека заведомо дураком — просто некрасиво.
Я дураком руководителя не называл и не считаю. Но может быть умнейший повар в ресторане, с огромным интеллектом. Но нет никакого смысла спрашивать его экспертное мнение о изотопах гелия в свехрновых звездах. Вроде в сообщении написал причину, почему ситуация дурацкая в принятии решений. Там надо несколько факторов:
1. Мозги. Какой-то уровень интеллекта.
2. Исходную объективную информацию. Т.е. мало иметь мозги. Для обработки информации — нужна эта самая информация. (это как раз знание технических аспектов разрабатываемой системы)
3. Иметь знания, как обрабатывать эту информацию. Т.е. иметь опыт в решении технических проблем.
Те, кто могут решать проблемы (технические), должны и решать. «Давайте скажите как решать, а я выберу, что мне кажется (потому как книги по психологии читал, а также магию и экстрасенсорику знаю)» — это и есть дурацкая ситуация.
С т.з. компании воспитывать кадры не выгодно. Во-первых, потому что в первые года производительность близка к нулю или даже отрицательна. Джуниор отвлекает, требует внимания. Часто он пишет такой код, который надо вообще переписывать. Код сложный в поддержке — отнимает время и деньги при поддержке.
Даже при запрлате в три раза меньшей — он дает «ничего» — поэтому лишние траты.
Но, предположим, это временное явление и джуниор с мозгами, быстро проходит этап обучения. После этого у джуниора резко меняется представление о своем месте на рынке труда. Он требует повышения зп или без зазрения совести уходит в другую компанию. В итоге если брать всё во внимание, выгодно брать уже опытного, пусть с бОльшей зарплатой. К этому Вы и так приходите, только позже и с потерями.
Берете опытного — есть риск «не сработаться». Почему? Чем выгоднее кажется джуниор? Как раз тем, что если он нигде не работал, только здесь, то он перенимает все способы местного «говнокодинга» и эти способы часто не вызывают подозрений. Человек из другой конторы или с опытом, может смотреть на код критически. Может, конечно, превозносить способы говнокодинга, к которым привык в других компаниях. Но в общем, критический взгляд — как раз возможность сделать код и работу лучше. Поэтому в совокупности, опять вывод — лучше брать опытного. В случае промаха — просто быстрее решать вопрос с увольнением и заменой.
Я уже несколько раз встречался с тем, что в разных компаниях образуются «тепленькие местечка», где собираются программисты и занимаются «фаном» за деньги работодателя. Очень не любят, если кто-то придет новый и будет критиковать работу. А ведь производительность может отличаться в десятки раз. Приходишь, например, в компанию, видишь, что 10 человек разрабатывают уже пару лет систему, которую от силы при нормальном подходе два человека за три месяца делают. А работодатель верит, что они хорошие программисты, что у них дружный коллектив. Этот коллектив х… р… й мается, вешает на проект необоснованно всякие технологии, библиотеки, только ради того, чтобы попробовать, потому что им интересно. Коллектив весь горит энтузиазмом. Понятное дело, где ж они за чужие деньги будут всё что можно будут пробовать. Кстати, энтузиазм — это звоночек — человек не опытный.
Рядом с программистами за деньги работодателя также существует беззаботная каста менеджеров. Которые верят в свои «лидерские качества». И при этом менеджеры совершенно не оценивают полезность себя в производственной цепочке. Они на самом деле в большинстве случаев вредят, но они верят, что мифическое умение управлять и лидерство заменяют им объективные знания о системе и предметной области. Типичное общение с менеджером:
Менеджер: Вы технические специалисты, объясните, какие варианты решения проблемы?
специалист 1:…
специалист 2:…
специалист 3:…
специалист 4:…
Менеджер: Хорошо, я вас понял, тогда я принимаю решение, что проблему будем решать так:…
С хрена он принимает решение, не понятно. На чем основана его обработка «полученной информации» — не понятно. Просто добавляет в полученную информацию свой шум.
И при этом в компании царит мир и гармония. Заказчик ждет качественного продукта еще лет 5, пока не разгонит всю эту веселую компанию.
хорошего менеджера или ПМ-а проще обучить приемам аналитики, а не лидерским качествам
Вся суть менеджмента. Ничего еще не умеет, а уже хороший.
Любая компания ищет соискателей, обладающих комбинацией опыта и энтузиазма.
Причиной этому может быть и незамеченные пробелы в знаниях соискателя, да и ситуации вида «не сработались» внутри команды никто не отменял.
Очевидно, что прием на работу только полностью сформированных специалистов и «звезд» чем-то напоминает латание дыр на дороге, по которой едут машины. В ходе работе такому сотруднику придется что-то в себе менять, а чему-то и учиться заново, а это всегда сложнее, чем пройти весь пусть с нуля изначально.
Т.е. Вы думаете, что можно воспитать раба, который будет работать из благодарности, за то, что его воспитали? На энтузиазме. «Звезде» придется в себе что-то менять? Так это значит, что вы уже ставите на другую «звезду», которая считает, что имеет самую правильную мерку. Не сработается новая «звезда» с другими? ЧСВ также присутствует и в молодых кадрах. Даже скорее больше. А попытка «воспитывать под себя» и ждать пожизненной благодарности — заведомо обречена.
Соблазн не писать ерунду? Или если заставлять писать ерунду, то везде?
Методы с аннотацией ни на один бит не более документированы, чем методы без аннотации, если там тупо повторение названия методов и переменных.
Мы исходим из разных положений. Вы по-умолчанию считаете, что комментарии — это хорошо. Поэтому видимо такой вывод: создает нехорошие соблазны их не писать.
Я же думаю наоборот. Иногда комментарии полезны. Ну не сверхчеловек я, точнее, не сверхпрограммист. Чтобы смысл идеально закодить, чтобы код читался как книга, был кратким, ясным, лаконичным. И вот тогда появляются комментарии — как признание своего поражения. Иногда пишу аннотацию. Но только на тот параметр, который непонятен. Например, возврат булевского значения, а имя метода и так перегружено, чтобы понять, что значит истина, что ложь. Когда редко появляется комментарий, то он становится более полезным на фоне их отсутствия. Он больше притягивает внимание. Зачем писать бесполезный мусор? Это анти-DRY. Потом, при любом рефакторинге в смысле переименования (из другого места в коде), добавления переменных, изменения интерфейсов — аннотации устаревают и вводят в заблуждение.
Недавно писал сравнительно большой проект. Он зависел не только от моего кода, но была уже БД, поэтому был местами связан с кривым кодом. Пришлось писать комментарии в местах, чтобы пояснить, почему я так нестандартно написал код.
Комментария было за всё время штук 10. Но они так быстро устаревали, еще до того, как я класс допишу. В итоге осталось штук 2 комментария.
Да, и аннотации — это еще вопрос стиля, принятого в команде. Вообще, тут не о чем спорить, писать их не так напряжно. А для библиотек для внешнего использования может быть даже соглашусь с натяжкой, что нужны. Ну там, в док-файл выгрузить, схемы построить.
Суть поста, насколько я понял, и того, что я думаю — не в том, что надо запретить комментарии, а в том, чтобы определить куда стремиться и что хорошо, что плохо. Комментарии — это плохо. И их надо писать, когда уже не осталось других способов. Комментарии — это худший способ улучшить читаемость.
Чтобы немного сместить взгляд, представьте себе, что такое функция и что такое класс в другом русле. Тут где-то было и в комментариях к другим постам, что не имеет смысла выносить код в функцию, который используется один раз. Это механический способ рефакторинга, когда вы следуете DRY. Но можно кроме механики, ввести другой критерий. Допустим, вы написали довольно длинное полотно — код функции. Далее, хотите поставить комментарии на какие-то куски, объясняя, что они делают или как. Именно в этот момент, когда рука потянется комментировать, этот кусок и становится кандидатом для получения названия. И комментарий — по сути название новой функции. Тогда ваш код станет легко читать, как и комментированный. С той разницей, что смысл выражен в коде, а не в комментариях.
Всё это конечно спорно и требует чувства баланса. Языки программирования к сожалению не идеальны. Или я таких не знаю. Сила выражения мыслей на языке программирования зависит от языка, очевидно. Например, на Си, где нет эксепшинов, даже маленькое действие в методе превратится в много проверок и выходов. Но в С#, на котором сейчас работаю, действительно можно неплохо выразить мысль, без никаких дополнительных комментариев.
Язык программирования первичен и именно на нем по возможности надо выражать мысли, а не в комментариях.
Какие еще могут быть хитрости у этого метода? Иногда нужна аннотация из-за невыразительности некоторых аспектов языка. Например, это был C# и там как-то в сигнатуре нельзя указать, какой эксепшин будет.
Может быть int не подходит, т.к. отрицательные значения имеет. Опять же, смотрим на эту ситуацию и сразу думаем о коде, потом о комментариях. Если в коде, то есть uint. Если надо любое число, до секунд, с отсутствием отрицательных значений, то опять же, глупо внутри городить проверки и эксепшины и описывать их в комментарии — можно ввести специальный тип Age. То же и с телефоном.
Ответ — ни насколько. Думаете это рафинированная ситуация? Отнюдь. При нормальном наименовании переменных, имен методов, параметров, комментировать практически везде бессмысленно.
Другое дело, что совсем иногда, когда какая-то хитрость и нельзя очевидным образом ее в коде выразить — тогда и комментируем. Понимая, что зло как раз в хитрости и вы сдаетесь, пытаясь прикрыть ее комментарием как фиговым листочком.
Перечитайте еще раз на цитату Макконела orionll
Константы, в отличие от комментариев — это код. Со всеми вытекающими. Это значит, что коду больше внимания. Это значит, что имя константы устаревает гораздо реже. Лично я вообще не помню, чтобы они устаревали, т.к. IDE прекрасно справляются по переименованию константы. Комментарии не компилируются. И не переименовываются во всех местах с помощью каких-то технических средств.
Да и самое главное — язык программирования — это в первую очередь язык. Ваша задача — выразить замысел требований на языке программирования.
Если код читается плохо, надо учиться что-то с кодом делать, чтобы он читался лучше. Код для программиста должен стать родным языком. Ни ЮМЛ, ни комментарии. С чего вдруг программисты когда-то решили, что комментарии так нужны? Похоже, что это были либо программисты, для которых язык программирования не родной, либо уже такой язык программирования, не позволяющий кратко/емко выражать мысли. Приходится мысли дублировать на естественном языке, разжевывая, что делает код, или даже цель/намерение кода.
Код говорящий, новичок не умеет читать? — не умеющий читать тот язык, на котором пришел работать, не нужен проекту.
Код не говорящий? Переписываем код, потому что он говно.
Код не говорящий, но его переписать понятнее нельзя (потому как хитрая оправданная оптимизация, например) — тогда и начинаем думать о комментировании.
Выше цитата из Макконела где-то о том же.
А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
Это и есть корень ваших заблуждений. Как раз это и связанно с психологией. Вы не представляете себе процессов, не построенных на иерархии и подчинении. Армейско-зоновский вариант управления. Водопад. Поиск виновного. Вроде про это уже не мало написано. В программировании это несет только негативные последствия.
Какая ответственность, вы о чем? Людей должна мотивировать не ответственность, а заинтересованность в конечном результате и вовлеченность.
Есть
конечно
Тут где-то я пропустил целый пласт логики — вывод, что нужен/нужны архитекторы. Подмените кругом слово «архитектура» на слово «код», уберите слова «отвечает» — потому как программист не отвечает ничем и времена инквизиции прошли, а в тюрьму не посадят — и всё снова сходится.
Так и получается. Вне зависимости, «отвечаете» вы или нет.
Архитектор и рядовой программист — такое деление хуже чем по рассам. Это подразумевает разделение работ. Т.е. будет значит некто, кто «творит» и кто это воплощает. Просто это и есть нонсенсом. Если должен человек держать в голове кусок абстракции — как работает система, то лучше, чем тот кто этот кусок и пишет — никто знать не может. Поэтому архитекторы, как выделенные люди, не нужны.
Но в общем спор бессмыслен.
Это и есть большая выборка. В мире не всего лишь два программиста. И не обязательно на своих личных опытах выбора выводить закономерности.
То и значит. Видимо как-то надо к объяснению статистики перейти.
Если перед вами описание знаний двух разных людей, совсем одинаковое, но у одного написано — год работы, а у другого десять. Кому предпочтение? Это называется «при других равных условиях».
Почему предпочтение второму? Потому что скорее всего он меньше врет о своих навыках.
Сложнее. Если два резюме, одинаковых, по скилам, но у одного возраст 23, а у второго 30. Кому предпочтение? Второму. И хотя Вы на самом деле не знаете, может 30-летний в 29 начал карьеру, а 23 с 13 лет писал сайты и вообще гений. Но, среднестатистически у второго больше опыта. Почему? Потому что опыт растет с годами, а не уменьшается с годами. Поэтому статистически, чем старше человек, тем вероятно он получил больше опыта.
А вот, перепрыгивать не надо в плане — а может у него другой опыт в другой сфере. Это уже не равные условия. Мы сейчас рассматриваем только конкретный вопрос, не включая другие. И очень вряд ли, я думаю, вы вообще рассматриваете кандидатов на микроконтроллеры, у которых в резюме только сайты на ПХП.
Упс, это уже другая тема. Но вообще, как раз, по сути, по смыслу у вас противоречие. Если проект достаточно большой, то в голове вообще, человека удержать всё невозможно. Именно поэтому и работают эти практики — кодом и проектом владеют все. Меняются местами, если что. А то получается, что рядовому программисту невозможно, зато есть полубог, которому это возможно — называется архитектор. (я не зря и раньше сказал, что это бог. Его наделяют божественными полномочиями — знать всё и присутствовать везде).
Хороший программер за 2-3 недели может вытянуть стиль наименования переменных и отступы. Но не сделать из джуниора хорошего программера. Код и архитектура — это как Ленин и партия — одно и то же. Кодирование равно созданию архитектуры. И поэтому джуниор не вытягивается за недели. За год, возможно. Если мозги на месте и хорошо ему объясняют, а также дают потренироваться. Но это всё затраты.
Работа без архитекторов возможно. Скорее с ними невозможно нормальный код писать. Потому что (снова) — код и архитектура — одно и то же. Мало того, даже разрабатывается в кой каких методиках одновременно.
Но давайте закончим тему архитектур, потому что я и раньше об этом много писал и думаю, не стоит снова начинать.
А перевод разговора из точных наук в гуманитарную область вообще не люблю. Когда-то писал в каментах. Был у меня коллега-начальник как-то, который настолько был заражен православием, что это мешало работе. Как только я предлагал что-то сделать или применить другой подход, критиковал что-то — это воспринималось не прямо, не по смыслу, а как гордыня.
Деление по признаку возраста я четко обосновал — небольшой возраст -> небольшой опыт (не факт, может быть возраст большой, а опыта год) -> плохой код.
Менеджеры — не позор, а позорище. Дело не в их молодости, а в том, что мешают работе. Но деньги зато делят )))
Наличие менеджеров или их отсутствие — это не проецируется на людей и никак я не считаю, что молодые люди плохие, что менеджеры плохие. Есть и друзья среди менеджеров.
Это просто мой взгляд на процесс разработки. Он далеко не уникальный. Многие компании отказываются от этого балласта. Аджайлы, ТДД, эволюционное проектирование, ДДД. Нет места там архитекторам, управляющему персоналу. Он номинально часто там существует для решения задач, не связанных с разработкой. А команды, наверное, должны саморганизовываться. Сюда же — отсутствие нянек и джуниоров. Отсутствие выделенного бога, который говорит, как кодить, а проектирует сам. Где-то так.
Это не имеет отношения к психологии. Только к взглядам, как работать эффективнее.
Сейчас я делюсь с Вами и другими молодыми опытом: надо стремиться к знаниям и учиться всё время. И 30-35 (скоро и 40) — не являются пределом и глубокой старостью. И опыт и знания, если есть конечно, привычка учиться — растут.
Дос-программы: нет в общем ничего плохого. Даже еще лет 10 не будет. Когда Вы учитесь программировать, то по сути просто нужно уметь запустить программу из командной строки. Когда вы изучаете структуры данных — рисование мышкой красивой формы отвлекает.
Но вообще, да, образование устарело. Думаю, нас в ближайшие 10 лет ждет полный пересмотр. Образование уйдет в интернет.
Мир изменится. О да. Особенно подростки об этом думают, когда считают радикальным изменением — у каждого в кармане смартфон с злыми птичками.
Мир меняется. Факт. Но есть базовые знания. Которые не меняются десятилетиями. Вы выше про Лисп написали. Как-то это не устаревает. Кнуты, Дейкстры. Меняется в основном — Magento, Twitter Bootstrap, всякие укоз и еще какая-то хрень. HTML 5 появляется, свершается невиданная вещь доселе — в теги можно добавить проигрыватель музыки. Кнопочку покрасивее добавить.
Ну и тому подобное.
Это всё тоже надо. Это всё хорошо и прекрасно. Я бы советовал только смотреть на суть и не считать эти фантики чем-то радикальным. Хорошие знания почти не устаревают.
Это буквально единственный объективный критерий, если вы видите человека впервые и собеседуете. К сожалению, собеседования в течении месяца с разными заданиями — не проводят. И просто не стоит думать вообще никак, что человек способен быть синьером (по способности решать задачи) до двух лет опыта работы. Дальше будут варианты. Хотя, может быть, это по разному в разных языках и технологиях. Если Вы думаете, что человек справляется — возможно это так. Но возможно, что а) задачи у вас простые (хотя, а где они сложные) б) вы просто не сравниваете качество кода и производительность с реально опытным человеком.
Если справляется — то в общем ничего больше не нужно, всё прекрасно.
Ну да, конечно. Надо взять и еще код написать. Опыт на клавиатуру не нажимает сам по себе. Но что-то Вы никак не хотите воспринимать аргументы, которые мне кажутся обоснованными. Без опыта вообще ничего не делается. Знания из Космоса не передаются, чтобы написать вменяемый код.
Развожу руками. Или Вы меня сразу записали в тупого, но опытного, а есть умнее, но в 20. И мне должно быть очень неприятно это осознавать. Повторю, я не считал себя тупым. И сейчас не считаю, что был слабым интеллектуально в 20. Аспирантура, математика, научные задачи — всё было. Скорее, я решал тогда часто и гораздо поумнее задачи, чем сейчас. И скорее всего, тогда решал задачи (и сейчас их могу решать), которые многие не решат. Так что про ощущение своей беспомощности перед 20-летними интеллектуалами — это не ко мне.
И да, был у нас случай. Взяли человека с большим опытом. 37 лет. А то, что он написал в коде — никак не классифицируется, даже в тупые не запишешь.
Но все равно: код у меня был говно поначалу. Сейчас я разгребаю довольно знатный говнокод такого молодого, но архитектора. Вот прямо сейчас. Г на Г и Г погоняет. Человек он неплохой. Я не злюсь на него. Мало того, я помню, что в первые два года, когда я набирался опыта, я думал и писал ТОЧНО ТАК ЖЕ.
Если Вы думаете, что у меня мозоль… Не знаю, не копался так глубоко в себе. В ответ, могу сказать, что Вам скорее всего еще нет 25-ти. Поэтому Вы так и рассуждаете. До 25-ти так мыслят все поголовно. В университете тоже немного преподавал. И даже когда-то учился. Чтобы разрушить миф о том, что вы уже умные и вам хватит, то я помню два разных преподавателя говорили так:
1. Я в вашем возрасте уже был. Вы в моем еще не были.
Второй задал такой вопрос:
2. Вы не думайте о других, подумайте о себе сейчас и о себе через 10-20 лет. Вам бы хотелось прямо сейчас иметь знания и опыт, который будет у вас потом?
Т.е. молодые люди всегда думают о ком-то другом. Все люди разные. Так легче обосновать свою значимость для себя.
Возраст при приеме на работу — один из важных объективных показателей. Когда человеку 22 или 23 и он заявляет, что он синьер/мидл — ну как-то я не знаю даже, как назвать. ЧСВ у молодых людей выше крыши. А еще до 25 лет люди часто думают, что в 30 они обязательно будут владельцами крупного предприятия. Желательно с ГУГЛ, но в принципе можно согласиться и на что-то меньшее.
Я пару раз слышал такое: если человек в 30 лет еще не управляет, то он неудачник. От начинающего программиста, который еще даже ООП не понимал. Сейчас ему за 30, делает до сих пор самую примитивную работу.
Менеджер, которому 25, будет думать, что он нужен, чтобы своей рукой направлять безвольных технических специалистов. Для него, лучше, чтобы они были помладше. Потому как дядьки за 35 не особо понимают, что не могут ничего решить без проницательного, мудрого не по годам, хоть и не разбирающегося в технических деталях, но ведущего слепых через лес, управляющего персонала )) Пусть этот менеджер и не знает, как устроена система. Пусть не соображает, как она может развиваться. Ведь его дело — быть магом, чародеем, специалистом 80-левела в психологии, особенно в НЛП, — это обязательно ему помогает выбрать правильное решение.
ПЫСЫ. Стебусь специально
Конечно был. Как дежавю, повторяется постоянно. В большинстве случаев даже плохого code-review нигде нет. Потом, code-review дает улучшение качества кодирования в коллективе, если там «есть у кого списать», а не все двоечники. Последнее очень распространено. Сейчас такая везде война происходит — опыт против единомышленников. Если собираются несколько неопытных, то они как соловей и кукушка друг друга поддерживают. Потом пишут статьи на хабр. Потом другие, такие же, находят «подтверждение» своим «убеждениям». И так по кругу.
Кстати, здесь вполне вменяемое сообщество. Если зайти почитать обсуждение на украинском сайте DOU, то плакать хочется ((. Любой вредный совет будет считаться хорошим. А самый вредный — самым лучшим. Тесты — отстой, оптимизировать заранее очень правильно и самый шик, джаваскрипт — идеал, хаскель — отстой. Ну и в таком духе. Мол бабушка сказала, что на джаваскрипте можно работу найти )))
По этим обсуждениям можно судить о мнении большинства. Если соберется 10 четверокурсников в офис, на один проект, они ни в жизнь не поверят, что люди за 30-ть будут умнее их. Конечно, они тупее, они не понимают в новых веяниях, они консервативны и не хотят вводить новые фишечки.
… Да вроде как я везде добавлял, что это не достаточное условие. Но необходимое. Опыты разные. Но хоть и Била Гейтса будет учить первых два года — джуниор. По задачам, по уму и по количеству знаний. Мозги, знания, не прекращают развиваться ни в 16, ни в 25. Если ими пользоваться.
Не обидно. Это просто самоназвания. Как мне говорила одна знакомая HR — называй себя хоть «их бин экспертом» — твое дело.
Хреново с кодом таких синьйеров работать. И себя я не считаю тупым, но хорошо помню, как я писал код первые два года. И на самом деле процесс улучшения качества никогда не прерывался. И на самом деле я после почти 10 лет опыта тоже еще хочу некоторые книги почитать, еще не всё знаю. Спросите у любого с опытом работы, не в плане, обидно ему или нет из-за выскочек, а спросите так: был ли у него лишним опыт работы? Стал ли он хуже писать за последние 5 лет? Или все таки лучше?
Если провести аналогию, то это высказывание примерно такого плана: «Не надо чистить зубы. Смысл не в чистке зубов, а чтобы они были здоровыми»
Если менеджер может объяснить «возможные» решения — то это уже не тот менеджер, о котором я говорил. Но даже хорошо разбирающийся в технических деталях менеджер, но не участвующий прямо в разработке — все равно лишнее звено. Часть работы, такой менеджер, все таки может выполнять. Так что однозначно нельзя сказать. Но все же. В посте как раз про лидерские качества. Безвольных программистов набираете, что им нужен «сильный лидер»? ))
Конечно. Я вообще-то лично не отношусь плохо к джуниорам. Потому как я не владелец компании, который тратит на них деньги. И программисты должны откуда-то появляться, где-то набираться опыта.
Но я рассуждал с т.з. компании. Невыгодно.
Мне недавно родственники рассказывали с умилением, что видели по телевизору, что во Львовском каком-то университете 6-летний ребенок ведет лекции по истории. И еще добавили, что увидели (это всё в какой-то попсовой передаче), что 14-летний написал суперсистему какую-то и заработал миллионы. Мол у нас очень умная молодежь растет. И не надо думать, что мои 10 лет опыта работы что-то значат. Молодые обскакают.
)))
Это всё реалии нашего рынка труда. Считался человек опытным мидлом, среди видимо таких же опытных мидлов. Уже оскомину набила тема 23-летних синьеров. Не хочу сказать, что люди тупые. Но за красивые глаза и за большой ум, который в потенциале, где-то лет через пять начнет работать при наличии знаний — деньги платить не честно. Мидлом давайте честно считать человека с минимум 5-лет опыта работы, а синьером с минимум 8. Это, конечно, не достаточные условия.
Я дураком руководителя не называл и не считаю. Но может быть умнейший повар в ресторане, с огромным интеллектом. Но нет никакого смысла спрашивать его экспертное мнение о изотопах гелия в свехрновых звездах. Вроде в сообщении написал причину, почему ситуация дурацкая в принятии решений. Там надо несколько факторов:
1. Мозги. Какой-то уровень интеллекта.
2. Исходную объективную информацию. Т.е. мало иметь мозги. Для обработки информации — нужна эта самая информация. (это как раз знание технических аспектов разрабатываемой системы)
3. Иметь знания, как обрабатывать эту информацию. Т.е. иметь опыт в решении технических проблем.
Те, кто могут решать проблемы (технические), должны и решать. «Давайте скажите как решать, а я выберу, что мне кажется (потому как книги по психологии читал, а также магию и экстрасенсорику знаю)» — это и есть дурацкая ситуация.
С т.з. компании воспитывать кадры не выгодно. Во-первых, потому что в первые года производительность близка к нулю или даже отрицательна. Джуниор отвлекает, требует внимания. Часто он пишет такой код, который надо вообще переписывать. Код сложный в поддержке — отнимает время и деньги при поддержке.
Даже при запрлате в три раза меньшей — он дает «ничего» — поэтому лишние траты.
Но, предположим, это временное явление и джуниор с мозгами, быстро проходит этап обучения. После этого у джуниора резко меняется представление о своем месте на рынке труда. Он требует повышения зп или без зазрения совести уходит в другую компанию. В итоге если брать всё во внимание, выгодно брать уже опытного, пусть с бОльшей зарплатой. К этому Вы и так приходите, только позже и с потерями.
Берете опытного — есть риск «не сработаться». Почему? Чем выгоднее кажется джуниор? Как раз тем, что если он нигде не работал, только здесь, то он перенимает все способы местного «говнокодинга» и эти способы часто не вызывают подозрений. Человек из другой конторы или с опытом, может смотреть на код критически. Может, конечно, превозносить способы говнокодинга, к которым привык в других компаниях. Но в общем, критический взгляд — как раз возможность сделать код и работу лучше. Поэтому в совокупности, опять вывод — лучше брать опытного. В случае промаха — просто быстрее решать вопрос с увольнением и заменой.
Я уже несколько раз встречался с тем, что в разных компаниях образуются «тепленькие местечка», где собираются программисты и занимаются «фаном» за деньги работодателя. Очень не любят, если кто-то придет новый и будет критиковать работу. А ведь производительность может отличаться в десятки раз. Приходишь, например, в компанию, видишь, что 10 человек разрабатывают уже пару лет систему, которую от силы при нормальном подходе два человека за три месяца делают. А работодатель верит, что они хорошие программисты, что у них дружный коллектив. Этот коллектив х… р… й мается, вешает на проект необоснованно всякие технологии, библиотеки, только ради того, чтобы попробовать, потому что им интересно. Коллектив весь горит энтузиазмом. Понятное дело, где ж они за чужие деньги будут всё что можно будут пробовать. Кстати, энтузиазм — это звоночек — человек не опытный.
Рядом с программистами за деньги работодателя также существует беззаботная каста менеджеров. Которые верят в свои «лидерские качества». И при этом менеджеры совершенно не оценивают полезность себя в производственной цепочке. Они на самом деле в большинстве случаев вредят, но они верят, что мифическое умение управлять и лидерство заменяют им объективные знания о системе и предметной области. Типичное общение с менеджером:
Менеджер: Вы технические специалисты, объясните, какие варианты решения проблемы?
специалист 1:…
специалист 2:…
специалист 3:…
специалист 4:…
Менеджер: Хорошо, я вас понял, тогда я принимаю решение, что проблему будем решать так:…
С хрена он принимает решение, не понятно. На чем основана его обработка «полученной информации» — не понятно. Просто добавляет в полученную информацию свой шум.
И при этом в компании царит мир и гармония. Заказчик ждет качественного продукта еще лет 5, пока не разгонит всю эту веселую компанию.
Вся суть менеджмента. Ничего еще не умеет, а уже хороший.
Т.е. Вы думаете, что можно воспитать раба, который будет работать из благодарности, за то, что его воспитали? На энтузиазме. «Звезде» придется в себе что-то менять? Так это значит, что вы уже ставите на другую «звезду», которая считает, что имеет самую правильную мерку. Не сработается новая «звезда» с другими? ЧСВ также присутствует и в молодых кадрах. Даже скорее больше. А попытка «воспитывать под себя» и ждать пожизненной благодарности — заведомо обречена.