Привет.
Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.
Некогда, забавы для и пользы ради, я подрабатывал в одном неплохом кадровом агентстве — собеседовал приходящих программистов на предмет знания C#/.NET. В мои обязанности не входило полное техническое интервью — скорее, начальный скрининг кандидатов чтобы понять who is who, отфильтровать совсем уж ужас и в случае чего дать советы что почитать и как усовершенствовать навыки. И был у того кадрового агентства один интересный клиент. Он у всех на слуху, но тогда мне про него мало что сказали — я только понял, что вроде как ищет он rock stars — высококвалифицированных разработчиков, при том независимо от используемых технологий. После того, как я порекомендовал для них несколько человек — со мной связалась заместитель ген. директора и пригласила на встречу, ибо мои рекомендации не совсем устраивали заказчика. Так я познакомился с учредителем. Там мне была рассказана очень интересная история о том, зачем им нужны rock stars и как это всё вместе работает. Оказалось что вовсе не rock stars нужны. Нужны, как дал мне понять руководитель — люди с крепкими фундаментальными знаниями (алгоритмы, проектирование, операционные системы, сетевые технологии), которые будут готовы к росту и развитию. И вот они их берут и развивают, а затем отправляют реализовывать довольно сложные аутсорс-проекты. Заодно мне рассказали какие проблемы в этом плане испытывает компания. Я ушел в раздумьях и довольно долго катал в голове эту бизнес-модель, равно как и мысли о российской IT-индустрии в целом и политике работы с кадровым составом в частности.
В конечном итоге, через несколько лет я, наконец, утряс всю имеющуюся у меня в голове информацию и уложил её в модель, которая согласуется с окружающей реальностью. Это дало ответ на вопрос почему кадровый пайплайн упомянутой выше компании идеологически не может работать, а заодно и много другой интересной побочной информации. Так родилась моя классификация разработчиков по типажам.
Важно понимать что нет "плохих" типажей. Если какой-то из типажей вам кажется плохим, то вы просто не умеете его готовить. Помним: каждой задаче — подходящий инструмент. Я расскажу про все 4 типажа в виде карточек, давая краткую характеристику, указывая бэкграунд, цели и мотивацию, а так же рассказывая про сильные и слабые стороны. Особенно стоит уделить внимание бэкграунду, так как в конкретный типаж люди вырастают из своего бэкграунда. Начнем мы с чего по-проще.
Линейный программист
Соль индустрии IT-шной. На таких людях, говорят, мир держится. Он же "хомячок". Он же "гребец на галере", но я предпочитаю избегать таких ярлыков, поэтому просто — "линейный программист". Он не хватает звезд с неба, не пишет своих компиляторов и СУБД. Ну максимум — сделает пару инструментов, чтобы облегчить себе жизнь, в остальном — просто решает рабочие задачи. Редко меняет место работы. Усидчив. К работе относится как к работе, без особого энтузиазма. В меру ленив. Дисциплинирован (но бывают исключения), однако без надлежащего управления быстро "расхлябывается" и теряет фокус. Управлять такими людьми можно по стандартным методикам — описанным например в книге Дж. Рейнвотера — Как пасти котов. Квалификация может варьироваться и определяется исключительно опытом и количеством проектов, в которых линейный программист принял участие. Иногда квалифицированные линейные программисты попадают на минимальные управленческие должности — их нарекают team lead и тут-то вышеуказанная книга им и пригождается. Но самая главная особенность линейного программиста — весьма частое отсутствие желания развиваться и экспериментировать. Он прекрасно решит даже очень нудную задачу, которую вы ему предложите, если та не будет слишком сложной. Он выберет как можно более быстрый и прямолинейный инструмент из тех, что знает. Развитие для этих людей носит спорадический характер и в основном идет "вширь": изучить новый фреймворк или новый инструмент, который поможет лучше решать повседневные рабочие задачи. Или "пришел заказчик, который использует вот такую штуку — ну что уж, будем разбираться". Примечательно, что знания полученные в результате спорадического развития отдельных линейных программистов как раз и составляют опыт аутсорс-компании. Однако, двигать горы и исследовать окружающий мир "вглубь" самостоятельно линейного программиста чаще всего просто не тянет. Например изучать новый, хайповый язык программирования ему просто не интересно. Только если новый язык помогает в решении повседневных задач. И уж тем более разрабатывать свой язык — увольте. И это — нормально. Хуже всего то, что линейные программисты "каменеют" когда долго сидят на одном месте. То есть если у вас есть человек, который стабильно занимается концептуально одними и теми же проектами на протяжении 3-5 лет — то очень маловероятно, что он сменит типаж и будет развиваться "вглубь". Но вот раньше этого эмпирического срока — все возможно и зависит от бэкграунда.
Бэкграунд: разный. В "линейных программистах" могут оказаться и люди, прошедшие онлайн-курсы, и выпускники ВУЗов, некоторые олимпиадники, бывшие ученые технических направлений и даже люди из концептуально другой профессии (известны случаи когда дальнобойщики становились разработчиками на PHP). Важно понимать, что линейный программист — само по себе является бэкграундом и почвой для прыжка в другой типаж. Но! Прыгнет человек или нет — зависит прежде всего от его личных желаний, а не от навыков. Наличие того или иного бэкграунда определяет лишь направление потенциального прыжка, а не его вероятность! А вот вероятность прыжка с течением времени резко падает. Однако если вам нужен верный сотрудник на долгосрочный контракт — научитесь выявлять желающих "прыгнуть" заранее. Сбежит с проекта — будет неприятно.
Ценит: стабильность, среднюю, но 2-раза-в-месяц-стабильную зарплату, покой и личные отношения в коллективе, нормированный рабочий день, офисные плюшки вроде бильярдной, фруктов по выходным, оплаты проезда или тренажерного зала, мед. страховку и (возможно нудную, но) ненапряжную работу.
Сильные стороны: усидчивость, ответственность, коммуникабельность (раз на раз), полная контролируемость, спокойное поведение в стрессовых для проекта ситуациях
Слабые стороны: сложные и/или нестандартные задачи, абстракции, поведение в стрессовых для компании ситуациях, говнокод опять же
Собеседование: стоит уделить внимание психологии: усидчивость, дисциплинированность, коммуникативные навыки, стремления, вот это всё. Так же имеет смысл поговорить о предыдущем опыте и посмотреть в резюме. Дать стандартное тестовое задание а-ля "написать чат на web sockets", смотреть на сроки выполнения, "вылизанность" задачи и адекватность подобранных инструментов. Хорошо идут технические вопросы на знание языков, протоколов, паттернов и стандартных бибилотек. Плюсом будет если соискатель уже имеет опыт конкретно с вашим набором фреймворков, но если нет — не беда. Если все остальное в порядке — разберется. Это его работа.
Чего спрашивать не стоит: не спрашивайте почему люки круглые (вообще ни у кого это не спрашивайте), не просите его развернуть красно-черное дерево маркером на доске, дать оценку сложности алгоритма, произвести топологическую сортировку или спроектировать высоконагруженную систему. От этого линейному программисту нехорошо, хочется врезать вам по тыкве и убежать.
Rock star (Software Scientist)
Концентрированный исследователь. Такие больше похоже на классических ученых, но только от IT. Им интересны алгоритмы, теоретические исследования, концептуально новые направления в индустрии, но прежде всего — им интересно экспериментировать. Ради этих экспериментов их и нанимают, собственно. Они готовы часами копаться в сложных штуках и решать задачи, постановка которых другим людям даже не понятна. Они — эксперты в сложных вопросах. Они точно знают в каких случаях q-sort стоит заменить на heap sort и чем они отличаются, или может быть какие алгоритмы кластеризации подойдут для анализа потока биржевых котировок, а иные знают какие оптимизации используются внутри g++ и как они помогают жить. Костяк таких людей, например, способен разработать новый язык программирования и компилятор к нему. Или значительно улучшить какую-бы то ни было существующую систему. Еще они часто предрасположены к функциональному программированию. Ни на что не намекаю — просто статистическая закономерность. Кстати, говнокодить rock stars могут (особливо на стадии прототипирования идей), но в массе своей не допускают плохой код до финальных версий разрабатываемых ими вещей, стараются сделать все красиво, с комментариями и удобными программными интерфейсами.
Но.
Как всегда есть "но", которое все портит. Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им. За ваши деньги. И при том — за большие деньги. И при том — не факт что будет какой-то результат. То, что ваши задачи совпали с задачами, которые интересны rock star — очень и очень большая удача и счастливое стечение обстоятельств, не более. Но если завтра rock star-у взбредет в голову контрибьютить в GHC вместо улучшения вашей сборки MySQL — то у вас будет ограниченное количество времени чтобы быстро и решительно его уволить. При попытке заставить оного вернуться к своим задачам — получите, в зависимости от темперамента и ваших soft skills, или конфликты или тихий провал сроков. Ну хорошо хорошо, чтобы людей так капитально разворачивало — это бывает редко и происходит постепенно, да. А вот обратная ситуация — если пересадить rock star с улучшения вашей сборки MySQL на улучшение GHC против его желания — бывает достаточно часто. И, как нетрудно заметить, приводит к аналогичным последствиям. И именно это обстоятельство делает rock star категорически неприемлемым для аутсорса.
Именно поэтому rock stars лучше всего чувствуют себя в продуктовых компаниях (например JetBrains), где им дают полную свободу в рамках одного продукта и полностью исключают внезапную смену скоупа задач (разве что только через увольнение). Люди получают возможность заниматься теми задачами, которые им интересны, самореализовываться, раскрываться и их при этом особо никто не дергает. Получается хорошая штука — окей, идет в релиз. Нет? Ну и черт с ним. В таких условиях rock stars пускают корни, живут весьма долго (до десятка лет) и им хорошо.
Со стороны менеджмента здесь требуется легкий и ненавязчивый контроль — так, чтобы rock star не разбредались и их не "заносило" в бесперспективные эксперименты. Ну и так же мягко доносить, что та или иная интересная ему разработка нерелевантна.
Есть другой замечательный пример работы с rock stars — это Google, в котором rock star-у дают возможность заниматься тем, что он хочет. Google их кормит, поит, одевает и защищает от внешних угроз. Взамен — все, что rock star наизобретает — будет принадлежать и продвигаться Google, превращаясь в его продукты. Fair enough. Эдакие посевные инвестиции в отдельно взятой компании.
Бэкграунд: лицей или другая хорошая школа, высшее образование в хорошем ВУЗе по IT-специальности или же математике. Круглый (хотя бы овальный) отличник. Вероятно, участие в серьезной научно-исследовательской деятельности (научные публикации как плюс) и/или олимпиадное программирование прямо со школы.
Ценит: покой (пока решает задачу), свободный ненормированный график с возможностью удаленной работы, адекватность менеджмента, возможность поработать с другими rock stars, сложные, интересные и нестандартные задачи, стабильное финансирование. Офисные плюшки или воспринимает как должное или игнорирует напрочь, но в целом не испытывает к ним особого пиетета.
Сильные стороны: сложные задачи, исследовательская деятельность, нередко проектирование.
Слабые стороны: зачастую наличествуют проблемы в коммуникации, отсутствует стрессоустойчивость, нестабильность в компании или проекте легко спугивает rock stars, жестко поставленные сроки превращаются в стресс, невозможность переключаться по предметным областям — только разве что по своему желанию. Не смотря на всю творческость, несамостоятелен за пределами своих задач.
Собеседование: алгоритмы и структуры данных, оценки сложности, олимпиадные задачи — ваши надежные друзья. Можно заставить разворачивать дерево на доске (но зачем?) — но гораздо лучше дать несложную математическую задачу. Главное не спешите и не торопите: дайте человеку подумать столько, сколько ему нужно. Творческие задачи, задачи на соображалку (ну только не про люки же!) и задачи на проектирование в формате "давайте порассуждаем" и "предложите решение" так же неплохи. В резюме смотрите на образование и публикации. Поспрашивайте про участие в олимпиадах, научно-практических конференциях, поинтересуйтесь темой дипломной работы. Если рассказывает с горящими глазами — вы нашли то, что нужно. Так же стоит удостовериться, что соискатель знает в совершенстве какой-нибудь язык программирования (любой), иначе не очень понятно как он будет реализовывать свои эксперименты.
Чего спрашивать не стоит: не задавайте глупых вопросов. К глупым вопросам относится: детали реализации чего-либо а-ля "а что делает HTTP-заголовок Content-Length?", вопросы про коммуникативные навыки и прочая психология (да, rock stars могут обладать абсолютно мерзким характером — но что поделаешь, такова плата за них), и уж тем более не заикайтесь и даже не думайте проверять стрессоустойчивость. Пунктуальность проверяйте только на уровне "не пропадает на неделю и ладно".
Делец (Software Engineer)
Редкий зверь в наших краях. Его иногда называют "ориентированный на результат", "любой каприз за ваши деньги". Эдакий линейный программист, который неожиданно (а на самом деле — предсказуемо) обзавелся самостоятельностью, самомотивацией и начавший расти туда, куда считает нужным. Это не rock star, потому что его не интересуют глубокие и абстрактные задачи. Его интересуют работающие инструменты, приносящие конкретную, ощутимую пользу, которую можно потрогать руками здесь и сейчас (зачастую — в виде хрустящих купюр в кармане, но об этом позже). Если работающего инструмента нет — делец делает его для себя сам. Очень любит конкретику в постановках задач, в технологиях и — что самое важное — в общении. Про таких еще говорят "строгий, но справедливый". Коммуникативные навыки хорошие. Политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Делец таков не от хорошей жизни, потому как грубиянов и молчунов суровая реальность дельца быстро ставит на место. Будешь грубить — угрохаешь репутацию. Будешь молчать — не получишь заказы. Не будешь избегать и разрешать конфликты, лезть на рожон — останешься без денег. Материалист. Работает с теми задачами, которые ставит для него объективная реальность. Если чего-то не понимает — спрашивает и добивается конкретного ответа. Его хлеб — тщательно подобранный или разработанный собственноручно инструментарий, опыт, умение разбираться во всякой гадости в приемлемые сроки и работа на скорость и на качество. Инструментарий подбирает сам или посоветовавшись с другими дельцами — и не дай вам б-же дать ему совет в этот момент. Ответственный. Хороший делец не срывает сроки и обеспечивает рабочий и поддерживаемый продукт. К говнокоду относится как к одному из инструментов. Может занять технического долга, если это уместно и полезно в конкретной ситуации, учитывая специфику проекта. Сведущ в менеджменте. Нередко понимает в нем больше, чем непосредственный начальник. На основании этого может рекомендовать ad-hoc управленческие решения. Из профессиональных изъянов стоит отметить невнимательность к мелочам, но и это у хороших дельцов лечится.
Крутое описание — не правда ли? В чем же подвох? Подвоха тут два. Первый заключается в том, что делец не терпит над собой никакого начальства, особенно если оно менее квалифицированно чем сам делец. Во многом это обусловлено той самой осведомленностью о способах менеджмента. Ну еще и тем, что делец сам прекрасно понимает как делаются деньги в IT-индустрии. Как следствие — делец не подчиняется приказам. Делец сотрудничает в рамках контрактов. Любая попытка заставить дельца делать что-либо за пределами контракта (если не формально подписанного — то хотя бы устно оговоренного) — ведет к вежливому отказу в лучшем случае или к расторжению контракта в худшем. Если делец не подписывался отсылать вам ежедневные отчеты — он этого делать не будет. Если не подписывался тратить на вас 8 часов в день (при наличии сроков сдачи задания) — то он этого делать не будет. Если не подписывался на правки по проекту — ну вы поняли. Однако если вы выкупаете оптом какое-то кол-во рабочего времени дельца (без конкретных сроков и конкретных задач), то он с радостью будет выслушивать ваши стенания, невнятные требования, поддакивать и участвовать в любой корпоративной шизе — ну а что? Уплочено же. Любой каприз за ваши деньги.
Второй подвох заключается в самом отношении дельца к деньгам. Делец не подвержен нематериальной мотивации. На ваши "компания будет оплачивать вам тренажерный зал, обеды и котиков по пятницам" скорее всего ответит "давайте лучше деньгами". А денег делец любит много. И не просто много, а очень много. Да, он лоялен к нестабильности выплат, к переработкам и к оплате за результат, однако эта оплата должна быть большая.
Долгосрочными контрактами на маленькие ежемесячные суммы его не заманишь. Только на большие — выкупайте рабочее время оптом, да. Как следствие — делец часто меняет место работы (в той мере, в которой для него существует это понятие). Засидишься — станешь линейным программистом. Как следствие — квалифицирован решать довольно широкий спектр задач. Помните — хороший делец всегда стоит своих денег. А если вы не дадите ему достаточно денег — делец попытается реквизировать рычаги управления. Разными способами — от наглого увода заказчика и команды (если у него есть такие полномочия), до честного разговора по душам. Если это не удастся — он вас быстро и решительно покинет, потому как а зачем? Хорошие дельцы заканчивают открытием собственных компаний, но, как было сказано выше, дельцов в нашей стране в принципе мало.
Бэкграунд: часто самоучка. Занимается программированием потому что интересно. Высшее образование наличествует, но стоит смотреть на репутацию учебного заведения. Если учебное заведение серьезное — то троечник. Ибо как работает с первого курса. Да и вообще изучению всяких наук предпочитает по-скорее добраться до реальной работы. Очень часто фрилансит. У некоторых дельцов проблемы с фундаментальными знаниями. Однако если это точно делец — то эти проблемы легко решаются.
Ценит: высокую оплату своих услуг (именно в такой формулировке), соблюдение договоренностей, качественные решения проблем. График и плюшки — по договоренности, но обычно предпочитает свободный график, не привязанный к месту работы с фиксированными целями, а плюшки — да выдайте лучше деньгами.
Сильные стороны: широкая и в меру глубокая квалификация, самостоятельность, ответственность, ориентированность на результат, толерантность к нестабильности в компании (пока соблюдаются его контракты), толерантность к недолгосрочным контрактам и внезапным их расторжениям (не нарушениям, а расторжениям я сказал!), слоновья стрессоустойчивость.
Слабые стороны: высокая стоимость (в 2 раза выше чем у линейных программистов и это только начало), могут и сами нарушать обязательства договора (это если делец плохой и ни на что не годный — или просто начинающий), неуправляемость в режиме "я начальник-ты дурак" (если не уплочено), краткосрочность планов, непунктуальность если иного не предусмотрено договором.
Собеседование: хорошего дельца найти трудно. Ваш друг — репутация. Посмотрите резюме, не поленитесь связаться с человеком, который сотрудничал с соискателем ранее. Если речь идет об удаленной работе — посмотрите что у соискателя с доступностью. Как быстро он отвечает на почту и сообщения, телефонные звонки. Если лично — насколько пунктуален по назначенным встречам. Дальше расспросите о знаниях требуемой технологии. Но только так — без фанатизма. Конечно неплохо если делец точно знает какой адрес в памяти у функции закрытия подключения в проприетарной библиотеке, которую вы используете — но поверьте, это не то, что следует спрашивать. Неплохо будет попросить примеры проектов, которые делец уже реализовал на вашем стеке/с использованием вашей технологии. У хорошего дельца всегда найдется что показать и рассказать. Задачи на проектирование и "как решить вот эту проблему с заданной технологией" идут на ура, особенно если приправлять проектными деталями (например решить задачу в условиях когда заказчик требует релиза каждую неделю и т.п.).
Чего спрашивать не стоит: алгоритмические вопросы, математика, задачки на внимательность и прочая чепуха, которую спрашивают у rock stars. Разве что только на уровне концепции. Ну то есть делец может в общих чертах знать что такое, скажем, бикубическая интерполяция, но не заставляйте его реализовывать её на бумаге или на компьютере без интернета — будете справедливо (но вежливо) посланы. Отдельным пунктом следует упомянуть тестовое задание. Не давайте стандартных тестовых заданий: хороший делец таких заданий за всю жизнь переделал столько, что вам и не снилось и еще одно ему вот вообще не нужно. Далее. Смиритесь с тем фактом, что тестовое задание — это трата рабочего времени дельца. Приготовьтесь к тому, что оно будет платным. Предложите заключить NDA, временный контракт и сделать, например, коммит с фиксом бага для какого-нибудь вашего продукта или какой-либо системы с условием оплаты по выполнению и оговоренными требованиями к качеству. Это — самый эффективный метод. Не забудьте рассказать как настроить окружение. У хорошего дельца это не займет много времени, но бывают казусы.
Пассажир (business bullshitter)
У этого типажа много "ласковых" названий в народе. Наименее квалифицированные коллеги ему подчиняются, более квалифицированные его не любят. Начальники таких обожают и дальше я объясню почему. Кратко: пассажир харизматичен. Всё. Много и красиво говорит, но катастрофически мало (или некачественно) делает. Повышенная коммуникабельность — его хлеб и зачастую пассажир попадает на менеджерские должности, так как не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить начальника что именно он и должен руководить проектом. Во всем он демонстрирует серьезность, рвение и уверенность в себе, стремится порешать любую проблему, организовать совещание и обсудить, обязательно учитывая мнение команды. Со стороны может показаться что у него шило в известном месте. Он почти всегда на связи, всем отвечает на письма, показательно вежлив (так, что врезать порой хочется извините вырвалось) и может найти подход хоть к самому дьяволу. Один только минус — техническая квалификация. По правде говоря, ему не очень нравится программирование (вплоть до отвращения), но очень нравится покомандовать. Поэтому слабую техническую квалификацию (или её полное отсутствие) он часто "замазывает" красивыми словами, показным участием, заинтересованностью, дружелюбием и коммуникабельностью. Одна из самых страшных ошибок — ставить таких людей на средние менеджерские должности в командах. Как только вы это сделали — всё. Вы больше не получите достоверных данных о том, что происходит внутри команды с технической точки зрения. У вас будет красиво представленный бриф по происодящему, но те места, которые пассажир не понимает на техническом уровне будут из него исключены. А это в 90% случаев — скрытые проблемы и разнообразные детонаторы.
Тем не менее, грамотно подобранный пассажир может помочь команде общаться с заказчиком. Например, для пассажира ничего не стоит убедить заказчика перенести дату релиза — и при этом последний еще и будет думать что это наилучшее решение. Использовать пассажиров в роли дипломатов для заказчиков — одно удовольствие. Однако помните: харизматичные пассажиры — это как токсичный анестетик широкого спектра действия. Имеет смысл периодически опрыскивать им заказчиков, однако утечка бочки анестетика внутри команды приводит к весьма плачевным последствиям.
Бэкграунд: "лидер класса", "альфа-самец" в университете (жалко что не проверишь никак). Мистер обаяние. Образование может быть разным. Однако имейте в виду, что оценки могли получаться так же через ораторский навык. Программированием мог начать заниматься потому что интересно, но с таким обаянием у него были вещи в жизни и по-важнее. Нередко имеет свой персональный web-сайт на отдельном домене. Сделал его сам.
Ценит: все то же, что и линейный программист минус работа, плюс возможность поруководить.
Сильные стороны: коммуникабельность, способность убеждать, способность доносить информацию красочно, с шутками-прибаутками, про стрессоустойчивость лучше спрашивать отдельно
Слабые стороны: техническая квалификация. Многие технические вещи способен понимать лишь тезисно. Активен, но быстро теряет интерес и концентрацию на сложных и средних технических задачах. А в худшем случае — и вообще на любых задачах.
Собеседование: определитесь с тем нужен вам пассажир или нет. Если нет — при повышенной общительности и дружелюбности соискателя — держать ухо востро. Настоящие специалисты ведут себя спокойно. Старайтесь отсеивать красивые слова, общие утверждения, а выделять суть сказанного. Поинтересуйтесь достижениями в техническом плане. Попросите показать свой домашний проект, объяснить как он работает. Хорошо помогают те же вопросы что и для линейных программистов. Следите за тем, чтобы там, где соискатель не знает — честно говорил "не знаю", а не пускался в пространные рассуждения. Ну и тестовое задание как всегда. Если к тестовому заданию будет объемное пояснение, в коде — не продраться от комментариев и соискатель рвется объяснить как он это сделал — перед вами пассажир. Ежели пассажир вам все-таки нужен, то поинтересуйтесь как бы он объяснил заказчику срыв сроков релиза. Так же душевный разговор на предмет знания методик управления — SCRUM, PMBOK и разбор управленческих кейсов — могут возыметь положительный эффект. Но это уже история не про программирование.
Чего спрашивать не стоит: в случае с пассажиром — запретных тем нет (в рамках приличия). Если возникли подозрения на то, что перед вами пассажир — попробуйте вот что: задайте какой-нибудь вопрос, на который технический соискатель бы отказался отвечать по причине нерелевантности. Поговорите… Ну я даже не знаю. Про то, какую музыку любит соискатель, или фильмы, или игры. Или куда он ездил путешествовать. Если перед вами пассажир — то будет длинный рассказ. Если вы ошибаетесь — то вам ответят кратко и тезисно.
Выводы
Отдельной строкой стоит заметить, что четкой границы между этими типажами нет. Человек вполне может находиться где-то между дельцом и rock star, или rock star может дрейфовать в сторону пассажира. А прямо сейчас какой-нибудь линейный программист может перепрыгивать в дельца, увольняясь с уютной галеры и заводя аккаунт на UpWork. Поздравим же его с этим! Однако концептуально я склонен считать, что стабильно и в долгосрочной перспективе любой программист плотно обосновывается в одном из этих четырех типажей.
Возвращаясь к описанной первоначально ситуации. Если вы набираете и растите потенциальных rock stars, то использовать их на аутсорсных проектах — это как забивать микроскопом гвозди. Если же вы выращиваете дельцов — будьте готовы делиться деньгами и полномочиями. А для решения задач аутсорса вполне подходят крепкие линейные программисты. Если это сложный аутсорс — то с добавлением одного rock star или дельца в команду на "птичьих правах". В противном случае, если вы культивируете rock stars в своей компании, но у вас аутсорс — то смиритесь с тем, что единственный возможный способ на этом заработать — забирать себе промежуточные артефакты их работы. После того, как они вырастают — их надо отпускать. При том отпускание должно быть встроенно в саму бизнес-модель и кадровый пайплайн компании. Так вижу.
Именно это я бы и хотел объяснить учредителю компании из начала статьи. Но сейчас для него, боюсь, эти знания уже нерелевантны.
Спасибо за внимание! Хороших вам кадров!
Комментарии (410)
atamur
23.08.2017 16:39+14Но опять же не стоит забывать, что люди всегда смешивают в себе разные черты и кроме ярких представителей есть и смешанные типы.
lavrend
24.08.2017 01:27+2Я бы сказал, что все мы по большей части, все-таки, склонны относить себя к дельцам, так как большее количество «привлекательных» совпадений описывается именно в этой категории.
Для себя выделил очень много совпадений, узнаваемых как в себе (как мне кажется), так и в большинстве знакомых, конечно хотелось бы, чтоб это кто-нибудь со стороны подтвердил: -«да ты определенно делец, редкий брыльант», но на деле не имеет значения к какому типу человек себя хочет относить. Мы те кто мы есть, всегда хотим большего, оставаясь при этом абсолютно линейными, всегда требуем надлежащего отношения к себе и хорошего вознаграждение своих трудов, нас всех довольно сильно раздражает не компетентность окружающих людей (особенно если приходится напрямую с ними взаимодействовать), все мы хотим стать самостоятельными и предприимчивыми, и это далеко не редкость.
Абсолютно согласен, что для каждого человека можно выделить некий уникальный, смешанный, промежуточный тип. Причем этот набор человеческих качеств закладывается еще в детстве: темперамент, воспитание, тип личности (интроверт, экстраверт), все это напрямую влияет на показатель коммуникабельности и стресоустоичивости. Также есть некие приобретаемые параметры, ограниченные лишь усидчивостью, восприятием действительности, и интересом к обучению в конкретной технической области.
И конечно каждый, все равно предпочитает держать под рукой Гугл (обобщил, не хотел задеть чувства любителей Яндекса), какой бы большой ходячей энциклопедией он не был (как мне кажется, это относится даже к Rock star). =)
nporaMep
24.08.2017 08:45+6Разница между rock star и дельцом при гуглении в том, что rock star откроет ссылку, оканчивающуюся на .edu, или какой-нибудь научный .pdf и поймет суть формул. Делец же сконцентрируется на поиске куска кода и поиска описания зачем эта формула и как её юзать в прикладных задачах.
kmg4e
24.08.2017 18:46Разница между rock star и дельцом при гуглении в том, что rock star откроет ссылку, оканчивающуюся на .edu, или какой-нибудь научный .pdf и поймет суть формул.
Да ладно
;)
bay73
24.08.2017 15:52+2Я бы сказал, что все мы по большей части, все-таки, склонны относить себя к дельцам, так как большее количество «привлекательных» совпадений описывается именно в этой категории.
Собственное восприятие разных людей тоже разное. Далеко не все черты, описанные в категприи делец безусловно привлекательны. Поэтому отнюдь не все себя будут к дельцам относить.
malinichev
23.08.2017 16:41+5Спасибо, прочитал на одном дыхании, очень интересно и поучительно) Я походу дела смесь линейного и дельца, т.к. если меня мотивируют деньгами — я горы сверну)
Q001
24.08.2017 01:28+3Я походу дела смесь линейного и дельца, т.к. если меня мотивируют деньгами — я горы сверну)
Я так понял что делец это с обратной стороны подходит к денежной мотивации.
Не «если его мотивируют», а он работает «там где всегда мотивируют»
abiboka
23.08.2017 16:42+5А как происходил процесс «утряски» всей информации? Как удалось минимизировать влияние ну хотя бы таких когнитивных искажений, как иллюзия кластеризации,
иллюзорная корреляция, стереотипизация, эффект ожидания наблюдателя? Спасибо.
pnovikov Автор
23.08.2017 16:51+9Я просто долго пытался понять как охарактеризовать людей, с которыми я бы хотел работать. И как их отделить от всех остальных. У меня нет иллюзии кластеризации, поэтому я постарался не то, чтобы сказать "есть вот такие и других нет", а скорее выставить некие опорные точки для определения типажей. Ну и плюс анализировал кейсы, с которыми столкнулся… дайте подумать… за 7 лет :) Ну например я знал каких-то людей 7 лет назад и посмотрел как они начинали и где они сейчас. Взял бы я их в нашу команду или нет? А если бы взял — то что спросил бы? Говорил, задавал вопросы, получал ответы. Да, я сам не люблю всяческие кластеризации, но если сталкиваешься с задачей подбора персонала — то для ускорения процесса лучше иметь некоторые ориентиры, чтобы хотя бы понимать чего хотеть и какие сочетания рассматривать априорно бесперспективно.
Как минимизировать влияние не знаю. Правда :) Я просто систематизировал заново и заново, покуда не пришел к системе, в которую укладываются решительно все, кого я знаю (а знаю я много). Если честно, этой классификации не хватает "второго измерения", но пока что и так сойдет.abiboka
23.08.2017 17:00+1Иллюзия отсутствия иллюзий — еще одна иллюзия :) Шучу.
Спасибо за развернутый ответ. В сущности вопрос скорее насколько применимо это все, скажем, в другом городе/стране или в каких-то специфически направленных конторах? Ну и себя, как водится, я никуда не могу отнести. Разве что не балагур, но всему можно научиться, было бы время и желание.
DrFdooch
23.08.2017 16:42+9сразу что-то стало напоминать. конечно с натяжкой, но подходит:
1. меланхолик
2. сангвиник
3. флегматик
4. холерик
Eldhenn
23.08.2017 17:02+4А полноту классификации сможете обосновать?
pnovikov Автор
23.08.2017 17:12+9Нет, и я вам больше скажу: классификация не полна, так как есть куча людей, находящихся в переходных стадиях с разными показателями, например стрессоустойчивости. Эта классификация создана не для того, чтобы сказать "есть вот такие, а других нет", а для того чтобы тезисно обозначить чего стоит ожидать от определенных типажей а чего от них ожидать не стоит, как их распознать и как с ними эффективно работать. Так же неплохо подходит для определения "кто же нам все-таки нужен?" и концептуального понимания какие качества могут сочетаться в человеке, а какие — нет.
anton1234
24.08.2017 01:38Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вижу противоречие
Нет, и я вам больше скажу: классификация не полна,
А еще по моему мнению существует отдельная группа, в которой можно наделать множество подгрупп — «люди которых не надо брать в ИТ».
Для наглядности представьте на секунду, что быть боксером стало бы в одночасье также круто как и программистом. Хорошие офисы с плюшками, зп выше чем в среднем в вашем городе, да и в целом гордо звучит. А самое главное можно всего пару месяцев позаниматься с тренером и вас уже готовы взять. И вот толпы людей, которых ни жизнь ни природа к этому не готовила уже строчат свои резюме и начинают ходить по собеседованиям.
Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вам это утверждение не кажется несколько неточным?pnovikov Автор
24.08.2017 02:03+2Дорогой друг, мой тезис — провокационный, признаюсь :) Однако, если быть предельно точным и упоминать все формальности, то заголовок статьи был бы не "Четыре типажа программистов", а "Ориентировочные точки для идентификации типажей программистов, предусматривающие промежуточные состояния" и по содержанию напоминал бы скорее научное исследование (тут бы у меня еще выкладок попросили, ага). И тогда бы её никто не прочел, ибо как целевая аудитория (HR, управленцы и сами программисты) не имеет достаточно времени на чтение тонн подобной лабуды, а еще с успехом ломает об неё мозг. И смысл статьи бы сводился к "ну вы знаете, тут куча возможных комбинаций — так что думайте сами", что не несет в себе никакого практически применимого смысла. Очень хорошо, что вы заметили эту неточность, но. Я не отрицаю что реальная жизнь во много раз сложнее и многограннее чем "4 типажа". Но понимаете в чем штука — подобные классификации не строятся с целью включить туда все-все-все возможные на планете случаи, а подобные статьи нарочито не носят научный характер. Они строятся, как упрощенная модель, дабы простым языком донести до компаний, менеджеров и HR-ов хоть немного понимания о том, какие программисты вообще бывают и с чем их надо употреблять. А так же в статье — о ужас — присутствует сугубо пропагандистская составляющая — призвать хоть немного упорядочить сумбур компаний в наборе кадров (нам нужен самый лучший рокстар, ага), не нанимать высококвалифицированных программистов, когда можно обойтись линейными — равно как и не пытаться решить научную задачу силами пассажиров. Вы удивитесь, но просто потрясающее количество людей, ответственных за найм, реально, искренне не понимает как идентифицировать человека, сидящего перед ними, но самое печальное обстоятельство состоит в том, что компании не могут для себя четко решить кто же все-таки им нужен. Отсюда и рождаются вопросы про люки и мячики, когда по факту компании требуется пилить аутсорс. И эта статья — быстрый и краткий "крэш-курс", который может дать хотя бы отправную точку кто существует на рынке, чего он ожидает от работодателя и как с ним строить разговор. Sapienti sat — дальше сами разберутся, мне кажется.
anton1234
24.08.2017 10:53Я хотел донести немного другую мысль.
Наверное она больше для другой статьи, например с названием 10 признаков непрограммиста, которую я бы с интересом прочитал.
Я не слишком опытен в найме сотрудников, и вот из личного опыта понял, что достоинства и область применения сотрудников определить не единственно важное.
Я бы сказал, что прежде всего нужно понять, а хочет ли он работать в ИТ или это просто стечение обстоятельств или вовсе не его решение( о да, один сотрудник нисколько не смущаясь сказал, что он программист потому, что жена так сказала).
Работа с такими людьми это боль.
Если кто-нибудь раскроет мне тайны ранней диагностики таких кандидатов, я буду счастлив. В реальности это становится понятным только спустя пару месяцев и пяток приватных бесед.pnovikov Автор
24.08.2017 10:57+1Эмм… ну я предлагаю например… кхм… Просто спросить почему человек пошел в IT :) Нет? Вроде должно работать.
anton1234
24.08.2017 12:32+1Нет.
Никто на собеседовании не скажет, что ему нравится идея быть программистом, нравится зарплата программиста, или что он разочаровался в профессии и ему просто нужно платить за ипотеку, а работы он давно уже ненавидит.
Myosotis
24.08.2017 14:14Никто на собеседовании не скажет, что ему нравится идея быть программистом
А я честно ответила бы, что меня так впечатлили уроки Turbo Pascal в школе, что я непременно решила пойти в IT.
LazyProger
24.08.2017 14:24Тут немного же о другом, это вы с ранних лет поняли что хотите стать программистом и это здорово. Но будь у вас ипотека (приманила в ИТ именно зп) и пройденные онлайн курсы, не думаю что такая правда бы понравилась бы работодателю
anton1234
24.08.2017 14:31В этом и разница.
Вам понравился turbo pascal в школе, после этого наверное были другие языки, алгоритмы и крутые штуки.
А есть те кому это все безразлично. Кто-то закончив вуз открыл hh и выбрал то, где больше платят. Или поработав 10 лет в профессии в которой опытный специалист получает меньше чем джуниор решил тоже этим заняться. Да есть те кто смог, и к ним никаких вопросов.
Но также есть и достаточно большая аудиториях тех, кто в программистах вопреки своим желаниям и\или способностям.
В этой статье я вижу посыл, любому человека с резюме программиста можно найти применение. ИМХО — нет.
kmg4e
24.08.2017 14:56А я честно ответила бы, что меня так впечатлили уроки Turbo Pascal в школе, что я непременно решила пойти в IT
А что именно?
У меня сейчас дочь начинает.
Попытался заинтересовать её написанием игр на Паскале, — что-то не вижу интереса. Хотя она говорит, что хочет быть программистом.Myosotis
24.08.2017 16:12Мы как раз таки писали игры: от простых типа "угадай число" до змейки и тетриса.
pnovikov Автор
24.08.2017 14:26А я вот считаю что если работодатель адекватный, а не косит под недостартап и не носит розовые очки — то финансовую мотивацию он прекрасно поймет. И честно ответит "хочешь денег — не вопрос — помоги заработать нам и мы поможем заработать тебе".
Вот только из моего опыта, компании на собеседованиях как правило пытаются показаться лучше, чем они есть.
anton1234
24.08.2017 14:39+2Деньги не решают всех задач к сожалению.
Человеческая мотивация имеет гораздо более сложную механику нежели купюроприемник.pnovikov Автор
24.08.2017 14:41Да, но понимаете, "деньги не решают всех проблем" — это фраза не для собеседования. Лучше говорить это не при приеме человека на работу, а когда он уже у вас отработал, сделал много полезного, получил пару повышений и ему мало. Как-то так.
alexeykuzmin0
24.08.2017 22:14+1Делец с вами не согласится
VolCh
24.08.2017 22:57Возможно согласится, но либо когда он мотивирует, а не го, либо, когда затрагиваются более базовые потребности, чем материальный достаток.
kmg4e
24.08.2017 23:53+1Делец с вами не согласится
Согласится. Нормальный делец должен видеть границы, за которыми он уже не выдаст результат, сколько бы бабла ему не обещали.
Иначе как тех. профи — он недостаточно хорош.
asm0dey
24.08.2017 21:49Я говорю что в IT было больше возможностей для быстрого заработка чем по моей специальности.
kmg4e
24.08.2017 14:55+1Если кто-нибудь раскроет мне тайны ранней диагностики таких кандидатов, я буду счастлив. В реальности это становится понятным только спустя пару месяцев и пяток приватных бесед.
Собеседовал кандидатов по тех. вопросам. Уже после HR.
Беседую на разные темы — и чисто технически, и как была организована работа на прежнем месте и пр. и пр.
Минут за 40 выясняется очень и очень многое.
По негорящим/горящим глазам когда обсуждение проходит по разным темам.
Это нескромно, но мои ощущения были довольно точными.
Каждый раз когда сотрудников брали вопреки моим категорическим анти-рекомендациям — спустя пару месяцев их увольняли.
anton1234
24.08.2017 15:02Если сможете формализовать свои ощущения с интересом почитаю, ибо у меня пока, что так не получается.
kmg4e
24.08.2017 15:07+1Я пытаюсь просто беседовать, узнать, что у нас в городе делают, в других фирмах. Какое ПО делают, какие большие или маленькие конторы работают и т.п.…
То есть просто примерно как как коллега с коллегой в курилке беседуют об их прошлых местах работы.
Тут главное разговор чтобы раскрутился, чтобы пошел.
Выясняется очень много интересного.
Markscheider
24.08.2017 15:35+5Тут главное разговор чтобы раскрутился, чтобы пошел.
Товарищ майор? :)
Выясняется очень много интересного.
Gor40
24.08.2017 20:35Я хочу в IT, возьмёте? Только я стар для новичка (по меркам отрасли). Без жены. Мне никто не говорит кем работать, кроме рынка…
3aicheg
24.08.2017 10:20+1Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вам это утверждение не кажется несколько неточным?
В литературе часто встречаются классификации типажей боксёров. Давно ничего такого не читал, боюсь наврать в деталях, но, вроде бы есть термин «puncher» для боксёра, который умеет только бить и в бою полагается, в основном, на силу удара. Вроде бы, какие-то названия есть как для типажа, который вообще не очень умеет в бокс, но выезжает за счёт физической силы и выносливости, так и для типажа, который, наоборот, искусно защищается-юлит-финтит, вот это вот всё. И т. п.
ildarz
24.08.2017 11:13+1Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Вам это утверждение не кажется несколько неточным?
Вы не поверите, но… https://en.wikipedia.org/wiki/Boxing_styles_and_technique. И именно 4 больших типажа. :D
anton1234
24.08.2017 12:36+1А как вы назовете боксера, которому нравятся боксерские перчатки и шорты, но которому не нравится драться на ринге? Это какой стиль?
По моему мнению в айти сейчас имеются именно такие люди.
PS: Чертовы метафоры. Кажется вот ты приводишь идеальное сравнение чтобы все стало понятно, но нет все становиться еще запутаннее.
DS28
24.08.2017 12:47Я вас понял… Но это, наверное, другая классификация.
Ведь можно пойти в программисты из-за желания мамы / мечты о больших деньгах / случайно / за компанию, но стать хорошим программистом (скажем, линейным) и работать, выполнять задачи…
То, что человек не любит программировать — не значит, что он не может делать это хорошо… (А вы считаете, что нет)
А плохой программист не обязательно пришёл за деньгами /лаврами / и т.д.
Ему вполне может нравиться программирование, но у него не выходит хорошо (и такие тоже есть)
p.s. В вашей метафоре — неизвестен стиль боксёра, нужно на ринге смотреть…anton1234
24.08.2017 13:02Я говорю о наболевшем из личного опыта.
Приходят ребята на собеседования, с нормальным резюме и в целом не сыпятся на техническом интервью.
А потом ты начинаешь с ним работать, и понимаешь, что человек не выполняет и половины объема работы которые мог бы.
Начинаешь с ним много общаться, пытаешься выяснить, что не так.
И приходишь в итоге к мысли, что человек просто не на своем месте и работа от него требует собственных сверх усилий.
По формальным признакам его можно однозначно причислить к одной их категорий автора. Но проблема в том, что ИТ просто не его.
Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.
Я бы предпочел никогда не брать таких людей на работу.Markscheider
24.08.2017 15:38Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.
А из тех кто способен признаться — дай бог 1% способен решиться и сменить сферу деятельности.
DS28
24.08.2017 19:10+2Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.
А некоторые даже и не знают, что бывает «своё дело» и просто работают (как-нибудь)…
Ваше описание подходит под большинство профессий. И это действительно проблема, но это проблема не it. Это проблема выбора профессии, осознанности, ответственности и т.д.
kuznetsovin
25.08.2017 10:10Приходят ребята на собеседования, с нормальным резюме и в целом не сыпятся на техническом интервью.
Ну это только всего лишь один из показателей, надо же еще оценивать не только техническую сторону, но и человеческую, ведь из хобби человека можно много чего подчерпнуть о его характере.
marshinov
27.08.2017 09:18А кассир в супермаркете — это призвание? Я конечно намеренно утрирую, но мне кажется, что наша отрасль стремительно меняется: раньше в it шли действительно только гики. Сейчас объективно гиков не хватает для удовлетворения потребностей рынка. Спрос рождает предложение. Видимо, старичкам нужно учиться работать и с теми, для кого it — не призвание, а средство заработка.
anton1234
27.08.2017 09:31Хороший пример.
Я думаю, что есть профессии в которых можно работать, даже не по призванию.
Это профессии в которых разница между «как-то решить задачу» и «хорошо решить задачу» ничтожно мала.
Вот в ит разница грандиозна, а кассир, если не вдаваться в гиперболы, то лучший от худшего отличается не так уж и сильно.VolCh
27.08.2017 10:31Вот в ит разница грандиозна
По-моему, подобные утверждения являются излишней элитизацией "тру-айтишников". Бизнес, заказчика обычно интересует именно решение задачи, грубо — прохождение приемочных тестов как можно быстрее и дешевле с момент апостановки задачи. Внутренняя красота и чистота кода, оптимизации и прочее обычно начинает интересовать только когда основная задача уже решена и начинается промышленная эксплуатация.
anton1234
27.08.2017 10:41Речь не про элитность, а про сложность.
Возможность тестов и приемки ограничена. Слишком много нюансов и вариантов.
Когда вы можете однозначно оценить качество работы численными, формальными параметрами проблем нет.
Грубо говоря если бы у программиста был применим kpi в виде напечатанных символов, разницы с кассиром для которого kpi в виде обслуженные клиентов вполне приемлем, не было бы.
Речь не про элитность, исключительно сложность.VolCh
27.08.2017 12:04Большинство реальных ИТ-задач большинство программистов функционально решить в состоянии, пускай и в стиле "write only code". Квалификация рядового программиста выражается в качестве, в нефункциональных метриках, предоставляемых им решений.
khim
27.08.2017 17:51Большинство реальных ИТ-задач большинство программистов функционально решить в состоянии, пускай и в стиле «write only code».
Ну вот собственно туда и можно набирать «поточников» за три копейки. Но есть много вещей, которые «большинство программистов» функционально решить НЕ в состоянии. Скажем написать хоть какой-нибудь компилятор. Или ядро OS. Или даже банальную библиотеку для декодирования видео в реал-тайм.
mike1
27.08.2017 20:52Если нет конкретных требований по памяти, CPU и проч. и проч., то это под силу практически любому желающему за 3 коп., но получится дико плохо и тормозно… Нету же конкретных требований? Компилятор? Какой-нибудь? Почему нет? Все знают _примерно_, как делают компиляторы. Но надо ж все это спроектировать нормально, сделать, чтобы летало и не падало и проч. и проч. В этом же загвоздка, так?
khim
27.08.2017 17:49По-моему, подобные утверждения являются излишней элитизацией «тру-айтишников»
Причём тут «тру-айтишники»? Та же самая ситиуация существует с авиа- и автоконструкторами, модельерами и архитекторами. Всегда, когда один человек клияет на то, что будет с тысячами (а иногда и миллионами, миллардами!) людей — возникает эта проблема.
IT обладает важным отличием: проект двухэтожного особняка для Васи Пупкина никто не будет переделывать в проект комплексной застройки Пекина — а в IT подобное происходит регулярно.
kmg4e
24.08.2017 14:59А как вы назовете боксера, которому нравятся боксерские перчатки и шорты, но которому не нравится драться на ринге? Это какой стиль?
Мы не будем называть его боксером.
Это будет или «спортивный стиль одежды».
Или просто перчатки как сувенир, висящие на стене, как украшение комнаты — «спортивный стиль оформления квартиры»
zzoommgg
23.08.2017 17:14+1Есть тут еще кто-нибудь, работавший в сфере рекрутинга (помимо автора)? Интересует, к какому типу чаще всего относятся девушки-программисты и насколько часто вам попадались девушки каждого из типов.
izard
23.08.2017 17:35+4По моему опыту (17 лет фулл тайм, отсобеседовал под сотню кандидатов), было примерно поровну программисток — линейных, rock star и пассажирок, дельцов было очень мало.
ildarz
24.08.2017 11:18Это какая-то совершенно нерелевантная статистика (безотносительно к полу), если только вы все это время не собеседовали кандидатов целенаправленно на должности для rock stars. Их должны быть считанные единицы (просто по определению), а основной поток — линейные/пассажиры.
izard
24.08.2017 11:51Последние 10 лет собеседую на позиции, где надо понимать, как работают внутренности процессора, платформы и операционки, и уметь быстро находить причины ухудшения производительности в больших и незнакомых проектах.
kmg4e
24.08.2017 15:01-2основной поток — линейные/пассажиры.
;)
Вовсе нет.
Основной поток — процентов 80% называется «страшный шлак».
Но, что удивительно, этот шлак где-то работал программистом до этого и где то будет работать, когда не пройдет мое собеседование.
Из оставшихся:
Линейных много больше всех.
Пассажиров примерно сопоставимо по количеству по сравнению с количеством дельцов и рок-звездkuznetsovin
25.08.2017 10:13+1Лихо вы людей не прошедших ваше собеседование назвали. Как можно судить о возможностях человека не поработав с ним. Есть люди которые тупо не умеют проходить собеседования, а есть те кто их пройдет но работать будет хуже, чем никак.
amambaru
25.08.2017 11:27+2Вполне.
Я вот собеседовал админов: достойная по городу зарплата, одно из требований стояло «администрирование Linux, командная строка, не GUI»
Как назвать того, кто приходит на такую вакансию и не знает зачем одновременно с IP-адресом самого компьютера в настройках ОС нужно задавать еще и IP-адрес шлюза.
И таких было процентов 80%.
Вы думаете их следовало бы принять на работу, полгода выяснять квалификацию?
Шлак он и есть шлак. Его сразу видно.DistortNeo
25.08.2017 14:48-2> Как назвать того, кто приходит на такую вакансию и не знает зачем одновременно с IP-адресом самого компьютера в настройках ОС нужно задавать еще и IP-адрес шлюза.
И правда, зачем в одноранговой сети его задавать?
mayorovp
25.08.2017 10:40+3"Страшного шлака" — далеко не 80%, если смотреть среди всех программистов, а не только среди безработных.
Есть такой эффект: чем хуже программист программирует — тем меньше он работает и тем чаще он ходит по собеседованиям. :-)
kuznetsovin
25.08.2017 11:44+1… и тем лучше он их проходит =)
amambaru
25.08.2017 11:59+2Не завидуйте. Таких берут или из желания сэкономить.
Или они проходят в неспециализирующиеся на ИТ конторы, в конторы со слабым ИТ-отделом — да, лучше проходит.
Например, ровно также как и пройдет «собеседование» с вами плохой специалист по шпаклевке помещений, которого вы наймете для ремонта своей квартиры. Не потому что вы дурак. Просто вы специалист в другой сфере.
khim
25.08.2017 17:53+2… и тем лучше он их проходит =)
Мой опыт этого не подтверждает. Мои знакомые по собеседованиям ходят редко, раз в несколько лет, проходят десяток интервью, получают 3-4-5 офферов и выбирают среди них. В тоже же время на разных сайтах (да и хотя бы на Хабре — люди, посетившие буквально сотни компаний перед тем, как найти работу). Вот они и обеспечивают «90% шлака» на собеседованиях.
Так-то в среднем в отрасли вменяемых людей больше, чем невменяемых — но на собеседованиях, увы, наоборот.
Та же самая, что и с фильтров на кухне: так-то водопроводная вода не то, шоб уж совсем грязная, но прямо возле сетки фильтра — там жуткая муть. Так и было задумано, в общем-то, в обоих случаях — и в случае с фильтром и в случае с собеседованиями…
questor
23.08.2017 19:49+2Практически 95% попадут в первые две категории, две другие останутся почти пустыми.
izard
24.08.2017 11:47+1Для пассажирок в крупных корпорациях очень питательная среда, так что их я видел достаточно. И кстати линейные и тем более rock stars которые развились потом в пассажирок — очень полезны.
kmg4e
24.08.2017 15:05Видел пассажиров и в компаниях где программистов всего 4. И не ИТ-шников порядка 100.
kisel
23.08.2017 17:19+2Шикарная классификация. И не только программистов, ко всем айтишникам подойдет.
nightwolf_du
23.08.2017 17:21+11Всё это уже было в «Как пасти котов» (Ханк Рейнвотер). Причем там классификация более полная.
pnovikov Автор
23.08.2017 17:46+6Считайте что это — тезисное краткое изложение Дж. Ханка Рейнвотера для тех, кому лень искать книжку :)
StjarnornasFred
23.08.2017 17:24Прочитал про «пассажира» — сразу вспомнился Луо Йонгхао и его компания Smartisan.
Сам в бизнесе и технологиях разбирается явно не очень, переоценивает свою продукцию.
Зато как шоумен и представитель — просто огонь. Много ли мы знаем руководителей китайских небольших компаний? Да их там не сосчитать. А вот Йонгхао — многие знают. И про то, как он побеждал холодильники. И про то, как он для презентации смартфона арендовал крупнейший в Китае выставочный центр. И про то, как в кафе сосисками торговал, попутно продавая курсы английского языка и получая миллиардные инвестиции непонятно откуда. В общем, герой прогрессивной молодёжи.SystemFault
24.08.2017 15:21+1Пожалуй, самый известный «пассажир» — Стив Джобс.
Пассажир и делец.kmg4e
24.08.2017 15:26Скорее Илон Маск.
У детища Стива Джобса хоть прибыли сумашедшие и давным давно все окупилось.
Илон Маск — за счет инвесторов в основном существует.evocatus
24.08.2017 16:15+5Во-первых Илон Маск совсем не умеет говорить и выступать — посмотрите его вживую — он косноязычен.
Во-вторых он сооснователь PayPal. Я не знаю каков был его вклад, но PayPal определённо успешен.
В-третьих, тот факт, что он занимается сейчас бизнесами, в которых очень трудно получить прибыль, не значит, что он типичный болтун-харизматик. Конечно, он не сам разрабатывает ракеты, автомобили и батареи, но нельзя не признавать за его компаниями высоких технических достижений, которые были бы невозможны без грамотного менеджмента.kmg4e
24.08.2017 17:09+1Это чисто ораторское искусство, без относительно того пассажир ты иль нет.
Если Маску дают такие деньги — значит, он достаточно хорошо умеет болтать с инвесторами.
После PayPal у него больше ничего не окупалось.
PayPal используется как раз как «пассажирская» замануха, да.
dimm_ddr
24.08.2017 17:47Конечно, он не сам разрабатывает ракеты, автомобили и батареи
Где-то я слышал, что в SpaceX именно он — главный инженер и именно за ним последнее слово в больших инженерных вопросах. Если правда, то он именно rock star по данной классификации, может быть с небольшим смещением в пассажира.
ttools
23.08.2017 17:36-4Очень сомнительная у вас классификация и не очень полезная. Предпочтения или пофигизм к фруктам в офисе, уровень ответственности, коммуникабельности, какие вопросы на собеседовании ему не понравятся и т.п. никак не коррелирует с уровнем знаний программиста и стремлением к развитию. Это всё из разных категорий. И всё это, как мне показалось, у вас на фоне пренебрежительного отношения к людям. По моим наблюдениям, если человек употребляет слово «говнокод» по отношению к чужой работе в своей речи то скорее всего он окажется заносчивым идиотом
aquamakc
23.08.2017 17:37+8А что если там действительно говнокод?
ttools
23.08.2017 18:30+3Слово «говнокод» все понимают очень по разному. Строгое определение не найти в словаре Даля. Наверняка можно сказать одно: оно состоит из слов «говно» и «код». Последний раз, когда я общался с человеком, много рассуждающим о «говнокоде», так получилось, что я заказывал у него часть работ по проекту. Когда он мне прислал результат, его код обвалился сразу же при запуске. После моих замечаний и исправления первое же тестирование первого юзеркейса закончилось с ошибкой. Так было на каждом шагу работы с ним. Когда мы закончили через гораздо больше дней, чем я ожидал, я спросил его, считает ли он свой код «говнокодом»? Обиделся, видимо не считает. И это случай когда эти оба слова можно было бы применить к выполненной работе объективно. Когда люди рассуждают о чужом работающем коде, мне судить трудно. Конечно есть какие-то вещи, которые в любом коде делать не стоит, потому что это приведет к проблемам при работе с ним/ при отладке, но вот если человек тычет пальцем в чужой код со словами «говнокод» впечатления у меня об этом человеке неприятные. Я за то, чтобы использовать другие слова вместо этого. Когда человек рассуждает о вообще каком-то абстрактном коде, которого еще нет, или о другом программисте словом «говнокодит» для меня человек выглядит еще неприятнее
pnovikov Автор
23.08.2017 18:35+6Я вас очень уважаю, но пожалуйста почитайте что такое технический долг. И не путайте его с функциональностью продукта. Спасибо.
ttools
23.08.2017 19:14+4Я вас тоже очень уважаю, но почему то слышится мне в вашем высказывании снисходительная интонация. Может быть мне показалось, простите. Я знаю, что такое технический долг. Но речь шла о смысле термина «говнокод» и его толковании, и я думаю, по смыслу составляющих его слов, им можно охарактеризовать и работоспособность продукта
pnovikov Автор
23.08.2017 19:17+3Смысл термина говнокод, как я его имею в виду — код, который ухудшает поддерживаемость продукта, как я уже говорил. Работоспособность продукта можно характеризовать, не используя постфикс "код", если на то пошло :)
ttools
23.08.2017 20:03+8Хорошо, я теперь понимаю, что вы имели в виду и вы гораздо более приятный человек в общении, чем мне показалось после прочтения вашей статьи, извините
123
24.08.2017 01:51+13Извините, что вмешиваюсь, но это, похоже, образцовый трэд ведения дискуссии на хабре )
pnovikov Автор
24.08.2017 02:05-1Все в порядке, не переживайте. Очень рад что удалось избежать конфликта и недопонимания.
aquamakc
23.08.2017 19:56+2Приведу пример, с которым знаком лично:
модель данных реализованная на контролах типа TextBox на скрытых формах. Причём приложение многопоточное (по ТЗ до 10000 уникальных потоков) с отдельным экземпляром этой модели на каждый поток.
Надо ли говорить, как оно работало?ttools
23.08.2017 20:49Да что говорить, это очень богатое поле для примеров
Ivan22
24.08.2017 15:20у меня, как к человека знакомого с Data Modeling, фраза «Модель данных реализованная на контролах» вызывает какие-то странные эмоции в голове
aquamakc
25.08.2017 15:34Я вам больше скажу, у любого более-менее адекватного программиста эта фраза вызывает «эмоции». Уже сколько лет прошло с того дня. Я лично тот продукт переписал с нуля на другом стеке, а всё-равно забыть не могу.
bratishchev
23.08.2017 23:53Случай из моей практики — обратился заказчик с просьбой срочно_немедленно_чтобы_сегодня_уже_работало. Объяснил, что в указанные сроки смогу сделать, но будет ряд ограничений, а если потребуется расширять функционал, то всю мою работу придётся переделывать заново. Он согласился, и почти через год снова обратился ко мне. Улыбнуло, когда я в коде увидел //лютые костыли, никогда так не делайте. — Это был говнокод, который с поставленной задачей без сбоев почти год справлялся. А в приведённом примере даже не код, а просто набор символов, я считаю.
ShamanR
23.08.2017 17:41Более того, я например и к своей тоже его употребляю, и к чужой, если собеседник относится к этому как и я, непринужденно. Потому что, говнокод это всего-лишь технический долг, и все его пишут. Главное писать его осознанно, а не случайно)
ttools
23.08.2017 18:37+1Если вы с человеком знакомы давно, и в вашем общении вы точно уверены, что говнокод — это технический долг, тут вопросов нет. Но с незнакомыми людьми лучше так не делать, потому что слово спорное, негативное, содержит «говно». Ваше общение может быть затруднено, если вы на его код посмотрите и скажете, вот тут у тебя говнокод, не смотря на то, что вы имеете ввиду технический долг, рискуете быть непонятыми
VolCh
24.08.2017 15:11+1Технический долг — несколько другое в моём понимании. Технический долг — сознательное нарушение явных и неявных правил, соглашений, лучших практик и т. п. ради скорости решения задачи. Говнокод — неподдерживаемый код, написанный в твёрдом убеждении, что это практически идеальное технически решение задачи, что абстракции, декомпозиция, оптимизации, использование готовых библиотек и т. д. — для слабаков. Или другая крайность — оверинженеринг.
На самом деле, без знания контекста создания и эксплуатации кода зачастую нельзя сказать говнокод это, технический долг или выстраданная реальной эксплуатацией оптимизация.
pnovikov Автор
23.08.2017 17:42+6Вы перепутали причину и следствие. Не человек — делец, потому что ему пофиг на фрукты, а человеку пофиг на фрукты потому что он делец. Да это из разных категорий, однако я объясняю почему делец будет скорее всего не склонен к фруктам в офисе: потому что предпочитает взять деньгами.
Говнокод в данном случае — не применительно к какой-либо конкретной работе, а как обстоятельство и собирательный образ некачественно, спешно выполненной работы.
ttools
23.08.2017 18:45Это вообще не причина и не следствие. Человеку могут нравиться фрукты в офисе и он может быть равнодушен к ним и он при этом политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Материалист". Или он не грубоват и не склонен к занудным формальностям. Или не материалист. При это работает исключительно по контрактам и фрилансит. Не объединяется той совокупностью свойств то, что вы объединяете категорией «делец»
А говнокод у всех свой. По- разному все его интерпретируютlavrend
24.08.2017 02:26+3Отношение к слову «говнокод» у всех одинаковое, категорически не приемлемое, однако в силу некоторых обстоятельств, иногда приходится переступать через свое «я никогда не буду так писать», для экономии времени и нервов, особенно когда получаешь уже поюзанный проект, а дедлайн на сегодняшнюю поставленную задачу закончился еще вчера.
При первом взгляде на код, есть, конечно, огромное желание сделать именно «Ctrl + A -> Del -> написать с нуля», но обстоятельства, за частую, не позволяют такой роскоши, и поэтому рано или поздно наступает момент, когда к «говнокоду» относишься, действительно, как к одному из быстрых инструментов для решения конкретной проблемы. «Костыльнул по быстрому» (с надеждой, что когда-нибудь перепишешь этот кусок кода «по нормальному», с некоторой ноткой самоиронии), выдохнул и все принципы морали и общественных убеждений уже отходят на второй план.
Я 7 лет пишу код, и не считаю себя каким то Гуру, но смело могу сказать, что программист начинает свой путь именно с «говнокода» и лишь с опытом начинает писать уже более «грамотно», заранее оптимизирует все и вся, погружается в паттерны, полиморфизм и вот в это все, но при этом иногда использует «костылики», различные TODO и прочие временные заглушки (про комменты я вообще молчу, если будет время), с целью ускорить решение конкретной задачи (потому что иначе не бывает, всегда нужно: подешевле, покачественней, и еще на прошлой неделе). И каждый раз, снова и снова приходится рефакторить свой и чужой код (потому что всегда думаешь о нем, в контексте менее приятной консистенции), и вот уже тогда реально «скилловый» программист раздвигает границы понятия «говнокодер», и уже не совсем ясно, что есть хорошо, а что тогда плохо. Главное относится ко всему с иронией, и смотреть на вещи, как на промежуточный вариант для достижения цели, практический опыт, и еще один толчок к саморазвитию.
Прошу прощения, за большое количество текста и за ошибки в пунктуации. «Яж программист», я так вижу. =)ttools
24.08.2017 10:25только в этом обсуждении встречаются как минимум 4 интерпретации слова «говнокод»: технический долг, плохой стиль программирования, не работоспособный код и костыльность — вариант от вас :) Обсуждать хорошо/плохо это или допустимо/не допустимо стоит для каждой интерпретации отдельно
lavrend
24.08.2017 12:14Согласен с Вами, каждый понимает это по своему, и каждый может почерпнуть для себя, как плохие, так и хорошие стороны в каждой конкретной интерпретации (потому что у каждого свое понимание этого определения). Я же просто привел один из возможных примеров, когда возникает некая необходимость в костыльности (и это не всегда плохо, хотя я сам весьма не лестно отношусь к этому понятию). Особенно необходимость хорошо прослеживается, как мне кажется, на коммерческих проектах, принадлежащих работодателю, где решения принимаются другим человеком, который зачастую к написанию кода не имеет отношения, но которому важны сроки и финансовая выгода, завязанная на этих сроках.
Писать «чистый код», в свое удовольствие, опять же по моему мнению, возможно только в нескольких случаях:
1) При разработке собственного проекта в одиночку и с нуля, где решения принимаются самостоятельно, и тогда уже человек сам для себя формирует понятия, что есть «чистый код», а что «говнокод», и сам в праве выбирать что для него важнее, свои этические убеждения или сроки.
2) При коллективной разработке, при условии, что человек уполномочен принимать решения, имеет рычаги контроля на остальных участников команды, и сам формирует архитектуру и паттерны «чистого кода» на этом проекте (при непосредственном участии в написании кода).
3) Или же в том случае, если принятие решения доставляет человеку некий дискомфорт (таких людей не мало), тогда ему нужен «шарящий» наставник, который всегда готов подсказать более красивое решение (если работать в таком ключе успешно, это тоже может приносить удовольствие, о того что человек является частью чего-то большего).
В остальных же случаях, все всегда будет упираться в сроки и подниматься вопросы о финансировании для поддержания этих сроков. Это просто мое мнение и настаивать на нем я конечно не буду, но мне очень приятно было поддержать дискуссию, спасибо за это. От себя еще хотелось бы пожелать всем, побольше успешных проектов приносящих не только прибыль, но и удовольствие (желательно в ключе одного из пунктов описанного выше). =)
timfactory
24.08.2017 04:32+4Тут, наверное, тоже есть, своего рода, классификация. Думаю, для линейного программиста, говнокод — это бесконечная борьба со следствиями, вместо того, чтобы сесть и пристально исследовать причины. Для rock star, скорее всего, говнокод — это такая грубая «заглушка», в не очень ответственном (а, стало-быть, и не очень интересном) месте кода, которую, всё-таки, однажды, придётся довести до ума, иначе совесть замучает. Для дельца, это, очевидно, — инструмент, применяемый, например, в ситуации, когда клиент не знает, чего хочет. А для пассажира, вероятно — какая-нибудь копипаста, которую, он, очень выразительно, тут-же и опровергнет, если ему на неё указать.
mayorovp
24.08.2017 09:19Не совсем так. Для линейного программиста как раз бесконечная борьба со следствиями — нормальный код, он сам такой пишет. А вот заглушка в не очень ответственном месте, написанная rock star, в глазах линейного программиста будет уже говнокодом. И наоборот.
Gokudera
23.08.2017 20:04+3Ничего оскорбительного не вижу в слове «говнокод», сам практикую если задачу нужно сделать в сжатые сроки.
З.Ы. А перфекционисты и люди с «паттерном головного мозга» к какому типажу относятся?pnovikov Автор
23.08.2017 20:05+3Первые — могут быть кем угодно, перфекционизм не характеризует интересы человека, а лишь его усердие при выполнении задачи. Вторые — как правило линейные программисты или пассажиры. Для rock star паттерны нерелевантны, для дельцов — не самый интересный инструмент работы.
ttools
23.08.2017 21:04Вне контекста, конечно, слово как слово, что в нем оскорбительного. А если представить такую гипотетическую ситуацию: вы устроились на новую работу, ваш новый непосредственный руководитель немногословный интроверт с всегда одинаково суровым выражением лица, вы получили задачу, и выполняя её дошли до момента, который нужно обсудить с руководителем. И вот смотрит он в ваш экран и произносит одно единственное слово: «говнокод» и замолкает. Понятно, что дальше у вас будет какой-то диалог и всё скорее всего выяснится. Но в этот момент у вас эмоциональный фон какой? Позитивный, нейтральный или негативный? А если вы руководитель, допустите такое общение с новым незнакомым человеком?
crazy_llama
23.08.2017 22:00Я понимаю, если говнокод явление временное и никому снаружи невидное, но если предполагается код ревью или командная работа, то говнокод — это очень плохо. Вы отнимаете уже не только свое время, но и время коллег.
ttools
23.08.2017 22:20+1Не люблю слово «говнокод» в том числе потому, что не все одинаково понимают что это. Вот ниже вы пишите, что это " функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы, непонятные переменные и функции… ", т.е. плохой стиль программирования, а с топикстартер, например, объяснил, что имеет ввиду под этим словом технический долг
crazy_llama
23.08.2017 21:53Да, но когда видишь функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы, непонятные переменные и функции…
Я к тому, что довольно много людей прикрывается спешкой и сроками, пишут дикий ужас, а потом долго ищут ошибки и приводят все в порядок. Я за то, чтобы локально код, все-таки, сразу был простым и понятным. Тогда и с модулями, архитектурой и прочей радостью потом проще.Free_Hand
24.08.2017 17:24Тогда, наверное, придется изменить подход бизнеса в текущем виде. Т.к. обычно бизнес заинтересован в получении чистой прибыли как можно быстрее, то и подход у него соответствующий. Все делается быстро и решительно. И далеко не факт, что качественно и лаконично. Но я все питаю надежду, что у дельцов в этом плане мозги все таки повернуться в нужную сторону :)
VolCh
24.08.2017 23:09Как правило, время потраченное при начальной разработке на выделение функции или приватного метода в современной IDE для бизнеса практически ничего не значит, а окупиться мозже может тысячекратно. Очень многообещающая инвестиция.
kmg4e
24.08.2017 23:54Для того чтобы это оценить да еще и правильно абстрагироваться — нужно быть даже не миддлом.
Renius
25.08.2017 10:23Поэтому спрос на джуниоров резко упал. Признать, что даже мидла брать опасно, в суровых условиях российских рынков, под силу редким.
VolCh
25.08.2017 11:20Речь не про какие-то заумные абстракции, речь лишь о "функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы". Секунды, потраченные на extract function/method, позже могут сэкономить как минимум минуты, когда потребуется этот код модифицировать.
И речь не о градациях типа джун/миддл/сеньор, а об общем отношению к коду.
franzose
24.08.2017 09:55Знаете, если «погружаться» (вспоминается соответствующая картинка) приходится каждый день, то вряд ли такой код можно назвать искусством.
zuborg
23.08.2017 17:41+7Интересная статья, прочитал с удовольствием.
Только не хватает голосовалки ))
unabl4
23.08.2017 17:56+1Интересная, а главное близкая к истине классификация.
Я почти на стопроцентов линейный. Узнал себя во всём из описанного, кроме того, что мои коммуникационные навыки из разряда «казалось, нащупал дно, но снизу постучались». Ну и зарплату 2 раза в месяц у нас никто не платит.
brom_portret
23.08.2017 18:20Ну вот чем плоха любая типология, так это тем что в природе «чистые» типы встречаются редко.
Человек вполне может частично обладать качествами как и дельца, так и линейного программиста + отлично знать алгоритмы сортировки и т.д. Или вот еще феномен, с которым я встречался дважды, вроде человек все знает, отвечает на все вопросы правильно, а код пишет полное г.
NewMan_by
23.08.2017 18:32Пока читал, раскидал многих своих знакомых и коллег по категориям. И мой не малый опыт в IT говорит мне, что вы во многом тут правы.
marshinov
23.08.2017 18:38+5Согласуется с классификацией руководителей по Адизесу. Линейный — P тип. Rock Star — E. Делец — PEa (самый разносторонний, поэтому и открывает своё дело). Пассажир -I. Здесь речь конечно не про руководителей, а про программистов, но я заметил, что эта классификация основана на психике, поэтому можно использовать и не для руководящих позиций.
Спасибо за материал: статья хорошо структурированы и я вспомнил несколько знакомых представителей каждого типа.
pnovikov Автор
23.08.2017 18:40+2Благодарю. Очень сильное сравнение.
ToSHiC
24.08.2017 00:18+5Есть более общая классификация, не руководства, а в целом психотипа: мотор-контролёр-поддержка-анализатор, www.tomyself.ru/mpostsocio/49-socio3part. Причём это именно 4 вектора, все вместе в одинаковой пропорции встречаются крайне редко, один чистый тип тоже не особо часто, и могут быть даже перекрёстные типа мотор-анализатор.
Линейный — A — анализатор
Rock star — E — мотор
Делец — P — контролёр
Пассажир — I — поддержка
Кстати, я чёт сильно не уверен в бэкграунде отличника у Rock Star — это же слишком скучно :) Скорее уж отличником будет Пассажир (договорится, если не топовый ВУЗ), или Линейный, потому что усидчивый.marshinov
24.08.2017 12:06У Rock Star может быть «неровная» успеваемость. Пятерки по спеиализации и тройки по «истории родного края» и прочей «ерунде»:)
ExplosiveZ
24.08.2017 12:39Ну или вообще двоечником может быть, у него же характер скверный. Оценки ведь не робот выставляет.
kmg4e
24.08.2017 15:10У Rock Star может быть «неровная» успеваемость.
Это у кого угодно может быть.
Давно известно, что образование на последующую работу ИТ-шника мало влияет для подавляющего большинства специализаций.
Исключения редки.
marshinov
24.08.2017 12:06Кстати, если пассажир все-таки компетентен, но склонен к демагогии (PI) можно дать ему джуниоров, пусть менторит. Но вот программу развития должен разрабатывать другой специалист.
Если пассажир организован (AI), то перед нами Scrum Master.kmg4e
24.08.2017 15:11Кстати, если пассажир все-таки компетентен, но склонен к демагогии (PI) можно дать ему джуниоров, пусть менторит.
Ни в коем случае.
Выступить перед джунами с лекцией — как вы будете круты, но пока получайте гроши, развивайтесь — это да.
Но технически менторить — ни в коем разе.
У пассажиров у самих уровень около-джунов, пусть даже они и осели на более высоких должностях.marshinov
27.08.2017 09:30Вы решили проигнорировать часть фразы "если пассажир все-таки компетентен". Я имел в виду не чистый тип из статьи, а гибрид линейного и пассажира. Это крепкий середнячок с хорошо развитыми навыками общения. Его болтовню можно таким образом направить в полезное русло.
Pycz
23.08.2017 18:46+1Что-то я не очень понял про тестовое задание и пассажира:
Если к тестовому заданию будет объемное пояснение, в коде — не продраться от комментариев и соискатель рвется объяснить как он это сделал — перед вами пассажир.
Почему пояснения и комментарии — это показатель технической некомпетентности (насколько я понял, это один из критериев, который отличает пассажира от других типов)? Комментарии и пояснения действительно, по моему мнению, помогают поддерживать код и злом не являются.pnovikov Автор
23.08.2017 18:48+2Это лишь косвенный признак. Само по себе конечно же это не плохо. Однако надо четко фиксировать момент, при котором желание соискателя поговорить превалирует над желанием сделать работу. Пример: Javadoc в коде — хорошо. А вот обилие инлайн-комментариев там, где они не нужны — показатель.
Pycz
23.08.2017 18:51+1Любопытно, просто я, например, когда пишу в тестовом задании комментарии, наоборот хотел бы, чтобы меня меньше беспокоили вопросами по коду, минимизировать живое общение, так сказать. Но это строго индивидуально, полагаю.
pnovikov Автор
23.08.2017 18:53+2Так я и не говорю оценивать вас исключительно по коду. Спокойный и ненавязчивый кандидат с детальными комментариями в коде — скорее всего не пассажир. Пассажир именно что норовит показать "смотри! я сделал! видишь, да, видишь?! я сделаааал… хахаха, боже, это так круто..."
VolCh
24.08.2017 15:21+1Сильно зависит от их содержания. Комментарии, дублирующие код, зачастую как раз следствие некомпетентности, малого опыта. Грубо, человек открыл для себя библиотечную функцию и восторженно комментирует то, что она делает, а не зачем он её вызывает.
Другой вариант — «звёздная болезнь» с
kimisa
23.08.2017 18:58+3Мы все с возрастом становимся дельцами. Т.к. почти все проходим период работать за копейки и вдохновение и понимаем что сыт от этого не будешь и что нужно работать и совершенствоваться дальше.
Развитие идет этапами. Заканчивается один этап и у тебя 2 пути — либо остаться на этом уровне, быть профи, либо пойти выше и развиваться.pnovikov Автор
23.08.2017 19:00+2А вот и нет. Rockstars, работающие долгие годы в R&D Google — тому пример. У меня вот знакомая работает в JetBrains 6 лет и уходить не собирается (она по духу Rock star, по квалификации — растет непрерывно). С другой стороны — я вижу как многие линейные программисты уже потихоньку уходят на пенсии. А пассажиры — ну на то они и пассажиры чтобы о них не говорить. :)
Для дельца необходима самостоятельность и профессионализм. А это далеко не все приобретают с возрастом. "Есть взрослые, у которых и в 30 лет виновата скамейка", как говорится.
kimisa
23.08.2017 19:02А вот это зависит от конторы. Я живу в глубинке, поэтому у нас тут нет серьезных контор. И невозможно сразу взять и стать асом. Вначале придется работать там где берут и накапливать медленно опыт.
pnovikov Автор
23.08.2017 19:04+2Кстати проживание в глубинке тоже можно отнести к косвенному признаку дельца. Но оооочень косвенному. И такая "дельцовость" — чуть другой природы.
kimisa
23.08.2017 19:07Боюсь дельцами становятся не из-за этого. Тут еще влияет и материальная сторона в детстве и юности. Постоянное чувство нехватки денег дает хороший стимул работать.
pnovikov Автор
23.08.2017 19:10Очень верно, но мне кажется на собеседовании до такого психоанализа все же не доходят. Но вы описали очень хороший эффект, да. Он в принципе позитивно влияет на работоспособность, но человека это едва ли делает счастливым.
Singaporian
23.08.2017 22:22+2Я бы поостерегся обосновывать высокую финансовую мотивацию былым голодом. Обычно к вершинам пробиваются те, кто бросил гарварды, а не жизнь в шалаше.
zorggroz
23.08.2017 22:54+1Истину говорите, сложная материальная и зачастую психологическая ситуация + высокая стрессоустойчивость и порождает людей с максимально практичным материальным подходом.
Замечу что есть нюанс, если такой человек достигает потолка, часто переходит в состояние линейного программиста.
S_A
24.08.2017 06:02+1Я тоже живу в глубинке. У нас мало серьезных контор. В одну я пришел, ничего не зная в том, что они делают на позицию «линейного». Стал «дельцом» за полгода, с начала этого года (а в сумме уже два в этой конторе) работаю на позиции rock star — если что-то кто-то не может, не знает, или надо что-то что никто не может и/или не знает — то я. Дали лычки… но все равно меняю работу. Потому что для rock star неприемлемо, как было указано в статье, «насилие» в выборе задач. Не скажу что я постоянно делал не то что нужно, но полдня-день в неделю уходило на не то что нужно. Чтобы потом то что нужно — делалось легко. Меня не поняли, теперь обратно в «дельцы» пойду…
ncix
23.08.2017 19:54+6Видел множество "линейных программистов", ковыряющих в свои 40 с чем-то лет какой-нибудь замшелый 1С или Lotus как и 20 лет назад.
VolCh
24.08.2017 15:29+1«Делец» — это не выше в смысле проф. роста по сравнению с, например, «рок-стар», это отношение к работе и конкретным задачам в целом. Хорошую зарплату может получать любой тип, но для «дельца» она будет основной мотивацией работать и развиваться в принципе, он легко забросит программирование и ИТ в целом, если вдруг какие-то другие его навыки окажутся востребованнее. Грубо, делец-одинэсник легко станет аудитором
kmg4e
24.08.2017 15:31Хорошую зарплату может получать любой тип, но для «дельца» она будет основной мотивацией работать и развиваться в принципе, он легко забросит программирование и ИТ в целом, если вдруг какие-то другие его навыки окажутся востребованнее.
Основное умение дельца добывать деньги, не зависеть от абстоятельств.
Поэтому «навыки не востребованы» для него не может оказаться.
PapaBubaDiop
23.08.2017 19:10+18Все мы рок-стары, но гугл лишь один. Приходится притворяться программистом.
franzose
24.08.2017 09:59Ну не каждый же программист мечтает работать в Гугле :)
Steed
24.08.2017 12:59Линейный программист мечтает работать в гугле, рок-стар — сделать свой гугл, делец — заработать кучу бабла на убийце гугла.
kana-desu
24.08.2017 15:29+1Должен сказать, что рокстару абсолютно не интересно делать свой гугл, его в принципе все эти компании мало заботят. Платят, дают свободу, есть с кем поделиться идеями — вот и хорошо.
Gor40
23.08.2017 19:51+2Слово «Делец», мне кажется, как правило, носит негативный характер. В вашем же описании, человек просто относится к компании так, как она к нему. Если все хорошо, то хорошо, не нравится кому-то — уволить/уволится. Мне кажется все честно и взаимно.
ncix
23.08.2017 20:05+1В целом с классификацией соглашусь, только "пассажир" — не слишком удачное название, я бы назвал "паразитом". Характерная черта — очень любит у всех просить помощи вместо того чтобы хотя бы попытаться разобраться самому. Пользы такие программисты как правило не приносят. Лучше двигать их в продавцов или поддержку. Кстати могут стать неплохими руководителями проектов.
У "Рокзвезд" есть одна неприятная черта — из всех четырех типажей только они никак не переносят критику. Причем независимо от уровня своей компетенции. Вместо того чтобы сказать такой "звезде" "твой код — говно, переделывай", придется долго и нудно подводить его самостоятельно к этому пониманию, чтобы не дай бог, не обидеть. С другой стороны, они никогда не скажут "у меня не получается". Это же вопрос их самооценки и престижа. Костьми лягут, но сделают. Можно это использовать.
pnovikov Автор
23.08.2017 20:10+3Способность переносить критику — это тоже к коммуникативным навыкам. А я предупредил, что у rock star-ов может быть мерзейший характер :) "Костьми лягут но сделают" — это скорее к дельцам. Для них это — контракт, репутация и деньги.
Паразит — ну как вам сказать… Паразит — негативная оценка. Это кто-то, кто высасывает соки и ничего не делает взамен. Я привел как минимум один способ сделать пассажира полезным для команды.
И да, человек который у всех просит помощи — не обязательно пассажир. Вероятно, он просто начинающий и ему правда нужна помощь — тут зависит от ситуации. Однако предпосылки есть, да.
ncix
23.08.2017 20:18+3"Костьми лягут но сделают" — это скорее к дельцам. Для них это — контракт и репутация.
Это так, но делец никогда не подпишется под слишком рискованной (неопределенной) задачей. "Рокзвезду" же можно взять на банальное "слабо".
Я привел как минимум один способ сделать пассажира полезным для команды.
Да, но в этом примере он уже не в роли программиста.
pnovikov Автор
23.08.2017 20:20+7"Рокзвезду" же можно взять на банальное "слабо".
Ох, я такие психологические игры не поддерживаю. Отдает бытовым мошенничеством. Уж лучше мотивировать какой-нибудь морковкой в духе того же респекта и уважухи (нематериально), если на то пошло. Нематериальная стимуляция кнутом — это что-то новенькое :)
khim
24.08.2017 03:56+3Нематериальная стимуляция кнутом — это что-то новенькое :)
Почему «кнутом»? Для rock start — это нормальная мотивация. Тем более, что он сам на неё напрашивается.
То есть он может вместо банальной и простой задачи предложить сделать что-то «красивое и большое» — и если вы ему скажите «давай, валяй — я не верю, что у тебя получится», то он за месяц сделает вещь, которая хороший линейный программист будет писать год и напишет при этом в 10 раз больше кода.
Однако есть и обратная сторона медали — если после этого вы скажите «это, конечно, прекрасно, но нам это не нужно — сделай, пожалуйста, попроще, чтобы Коля (такой средний-средний „линейщик“) смог это поддерживать», то тут будет уже тааакой откат, что мало не покажется. Вы не только не получите работающего кода через пару месяцев (за которые вышеупомянутый Коля решил бы исходную, «некрасивую» задачу) — хорошо если вы получите какое-то решение задачи через полгода.DistortNeo
24.08.2017 04:39+2> то он за месяц сделает вещь, которая хороший линейный программист будет писать год и напишет при этом в 10 раз больше кода.
Но вот поддерживать такой проект, скорее всего, не получится.khim
24.08.2017 04:48+2Но вот поддерживать такой проект, скорее всего, не получится.
Средним «линейщиком» — может быть и нет. Исследователем (пусть даже не тем, который написал код)? Легко. До первого кардинального изменения техзадания, понятно… но — тогда же можно ещё раз за месяц написать совсем другой код! Делов-то…
kana-desu
24.08.2017 15:37+2Рокстары только и делают, что ставят себе задачи на "слабо". И когда им говорят, что они что-то не смогут, они только рады и делают все, чтобы показать, что они намного круче, чем о них думают, изучат материал и таки сделают. И они рады, и заказчик.
В школе на уроках математики рокстары ведут себя так же, постоянно соревнуясь в том, кто сделает сложнейшее задание быстрее и пытаясь обойти друг друга.
tyomitch
25.08.2017 10:24Паразит — ну как вам сказать… Паразит — негативная оценка. Это кто-то, кто высасывает соки и ничего не делает взамен. Я привел как минимум один способ сделать пассажира полезным для команды.
По моему опыту, из тех, кого вы называете «пассажирами» («не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить...») получались самые лучшие менеджеры, от PM до CTO.
Работа менеджера — общаться с людьми и делегировать задачи; умение кодить самому, а ещё хуже, стремление кодить самому — менеджера будет только отвлекать от своей работы.Zakyann
27.08.2017 12:06От размера команды зависит. Если обычный тим-лид на 5 человек — то вполне справится и со своим и со сторонним.
VolCh
27.08.2017 13:37Пост всё же о программистах и том, что с ними делать менеджеру. Уволить (не брать) или перевести (предложить другую вакансию) — одно, по сути, решение — вычеркнуть из рядов программистов.
abiboka
23.08.2017 20:30+8«твой код — говно, переделывай» — это хамство, а не критика. переносить хамство начальника, это, наверно, очень выгодно как раз начальнику, а для работника может обернуться плачевно (субдепрессивные и депрессивные эпизоды, выученная беспомощьность и прочие несчастья). В качестве примера хорошей критики можно обратить внимание на принцип бутерброда (сэндвича). Но есть у этого принципа существенный минус — тяжело все время его применять, гораздо проще сказать «говно» и удивляться, почему люди так безрадостно это воспринимают :)
ncix
23.08.2017 21:35+1«твой код — говно, переделывай» — это хамство, а не критика.
Ага, вот и рокзвезда пожаловала :) А в чем хамство, простите? Почему бы не называть вещи своим именами? Речь же про код, а не про вас лично.
pnovikov Автор
23.08.2017 21:37+17В том, что "называть вещи своими именами" не состоит в том, чтобы хамить человеку. Можно подойти и вместо "код говно — переделывай" — сказать "так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай" — и вуаля. Чуть больше слов и вы уже не такой уж и мудак. Впрочем… так способны делать дельцы. Rock stars не склонны кому-то что-то объяснять.
ncix
23.08.2017 21:41-1так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Вот вы попробуйте такое рокзвезде сказать. Неадекватную реакцию гарантирую.
"Код-говно" конечно же образное выражение. Имеется в виду просто прямая критика решения.
pnovikov Автор
23.08.2017 21:44+3Ну я считаю так: по умолчанию всегда надо критиковать аккуратно, по делу и не апеллируя к личности. Максимально детально, чтобы до человека дошло. Таким образом я, как бы, снимаю с себя ответственность за его говнокод. Если человек не понял — то остается признать — да, зазвездился. Т.е. смотрите, штука простая: причина и следствие. Не то, что человек rock star и зазвездился должно служить причиной для критики, а невосприятие критики как раз служит причиной и показателем того, что человек зазвездился.
ncix
23.08.2017 21:57Не то, что человек rock star и зазвездился должно служить причиной для критики
Разумеется нет.
невосприятие критики
С этой проблемой лучше отсеивать на первых же собеседованиях. Дороже потом выйдет.
ncix
23.08.2017 22:03-1так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Это собственно и есть "код-говно". Для отрудника с непростым отношением к критике заход был бы иной:
"Отлично задумано! И вот-тут круто придумал, молодец… Слушай, а что будет, если вот такие условия? Что-то я пока не очень понимаю, как оно будет работать… Переделаешь? Ну ок, спасибо."
khim
24.08.2017 04:24+3По-моему вы тут описываете не людей, которые хорошо или плохо реагируют на критики, а в чистом виде отличие между линейными программистами и «концентрированными исследователями».
Для первого какой-нибудь SOLID — это одна из вещей, который он стремится соблюдать в своей программе… просто потому что «так положено». Соответственно когда вы говорите ему «вот как это» — и показываете на, скажем, «нарушение принципа открытости» — то он, вполне логично, реагирует на это как на разумное замечание.
Для последнего — это всего лишь некоторые «эмпирические приёмы» полезность которых в каждом конкретном случае нужно рассматривать отдельно. На заявление «тут нарушен принцип открытости и наружу выставлена кодировка команд x86» вы вполне можете услышать довод «x86 существует уже почти 40 лет, кодировка команд за это время принципиально не менялась и, насколько мне известно, есть по меньшей мере 10 причин по которым этот код ни для чего другого в ближайшие 10 лет никто использовать не будет».
Это ни хорошо и ни плохо — это просто разные подходы. Я наблюдал как потерю многих лишних человеко-лет на то, чтобы соблюдать SOLID'ную архитектуру, которая была рождена из соображений «открытости» и «принципов разделения интерфейсов», так и катастрофы из-за того, что какая-то вещь, которую «концентрированный исследователь» считал невозможной в принципе таки реализовалась на практике.
В реальности «линейный программист» склонен порождать решения, требующие в разы больше ресурсов и содержащие в разы больше кода (и, соответственно, требующие больше времени на написание), чем «исследователь», однако использование его творений редко ведёт к неожиданному «краху», когда оказывается что архитектура чего-то не поддерживает в принципе.
С другой стороны тот факт что человек может решать задачи только определённого уровня сложности никто не отменял, так что совсем сложные задачи «линейный программист» решить просто не сможет…ncix
24.08.2017 09:47Нет, я имею в виду именно отношение людей к критике. Одному можно указать на очевидные ошибки, другого надо подвести чтобы он сам их увидел. Второй вариант конечно отнимает гораздо больше времени у руководителя.
marshinov
24.08.2017 12:13+2Так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Для большинства программистов это не очень удачная формулировка, потому что присутствует «тыкание» и менторский тон. Так допустимо общаться с джуниором. Линейные скорее всего проглотят, а рок звезды, они все-такие не просто так рок-звезды. Если бы они не умели делать уникальные вещи, никто бы их не держал с таким характером.
Управленцу важно уметь говорить с сотрудниками на их языке, просто именно вам психологически это не нравится и вы считаете такой подход манипулятивным. Но нет никаких манипуляций, в том что вы говорите с итальянцем по-итальянски, а с китайцем на его родном языке, если вы его знаете.ncix
24.08.2017 13:40Вы уверены, что ответ адресован именно мне? Моя позиция идентична вашему коментарию. И да, в управлении индивидуальный подход никто не отменял. И без манипуляций управления не бывает, sad but true.
rfq
23.08.2017 23:33-4Рок-стар таких долгих объяснений не выдержит. Так что приходится ему говорить «твой код-говно», в надежде, что он и сам это знает. Он же рок-стар, должен знать.
khim
24.08.2017 04:32+2Извините, но это чушь. Я вообще не знаю откуда термин Rock Star взялся. Описание «концентрированный исследователь» описывает ситуацию гораздо лучше. Если бы код казался бы говном его автору, то вы бы его не увидели. Наоборот — скорее всего он таки считает, что код — достаточно близок к оптимуму, если он вам его вообще показывает. Потому тыкать куда-то бесполезно — если там уже не стоит замечение «временная затычка, нужно будет переделать» и так, то «исследователь» вас просто не поймёт. Ну да — в этом месте мы различаем насекомых и птичек по «количеству лап». Почему это плохо если у нас в системе никого, кроме москитов и ласточек не планируется? А вот замечание в стиле ncix на тему «у нас в планах кроме ласточек завести ещё и черепах и хрюшек и важно, чтобы и ласточки и черепахи яйца несли, а хрюшки — нет» — другое дело. Это — конкретная проблема и использование количества лап плюс дополнительного признака начинает выглядеть как костыль, да…
kmg4e
24.08.2017 10:58Извините, но это чушь. Я вообще не знаю откуда термин Rock Star взялся. Описание «концентрированный исследователь» описывает ситуацию гораздо лучше.
Термин «концентрированный исследователь» не несет в себе эмоционального окраса.
В то время как термин «звезда» как бэ неявно намекает на «звездную болезь», на то, какие возможны проблемы с этим типом.
Singaporian
24.08.2017 07:22+2Ага, вот и рокзвезда пожаловала :) А в чем хамство, простите? Почему бы не называть вещи своим именами? Речь же про код, а не про вас лично.
Извините, но ваш пост — говно! Не вы сами. Но ваши мысли, ваш текст — говно.
Приятно было?
Говно — это характеристика, а не конструктивная критика. И воспринимается это как характеристика производимого вами труда. Если я скажу вам, что все, что вы написали за последнюю неделю — говно, что конкретно вы побежите исправлять? Ничего. Потому что это был вердикт, а не призыв к действию.ncix
24.08.2017 09:50+1Приятно было?
Да нормально, никаких проблем.
Если я скажу вам, что все, что вы написали за последнюю неделю — говно, что конкретно вы побежите исправлять?
Если вы — мой босс, я потребую подробностей, иначе ничего исправлять не буду.
VitaliiDel
24.08.2017 19:17+1Правильный тимлид-делец сказал бы: «Давай по-новой Миша, все #@йня. Нам за это денег не дадут»
kmg4e
24.08.2017 19:22+1Правильный тимлид-делец сказал бы: «Давай по-новой Миша, все #@йня. Нам за это денег не дадут»
К сожалению или к счастию — деньги слабо связаны с тем, что на экране программист увидел хрень.
aquamakc
23.08.2017 20:42Я бы судя по описанию, «пассажир» — это банальный менеджер среднего звена, имеющий навыки и опыт программирования, не ушедший из предметной области, но перемещающийся из разработчиков в управленцы.
roman_kashitsyn
24.08.2017 14:49+4только они никак не переносят критику
Я бы сказал, что они не переносят неконструктивную критику. Я тоже с трудом переношу, как и похвалу, впрочем. Вот это:
"твой код — говно, переделывай"
яркий пример неконструктивной критики. Грамотным инженерам так излагать мысли не пристало, фразы вроде этой ни в коем случае нельзя писать на код-ревью, не важно, рок-звезда перед тобой или нет.
Нужно указать на проблемные места и объяснить, что именно с ними не так, и какой профит будет, если сделать по-другому. На такое даже рок-звёзды не обидятся. Если вы не можете нормально объяснить, что не так с кодом, то проблема в вас, а не в коде.
Viacheslav01
23.08.2017 20:48Осталось найти свое место в этой классификации :)
Singaporian
24.08.2017 07:24+3Бесполезно. Я нашел себя аж в трех и четырех :-D И по другому ни у кого быть не может.
anydasa
23.08.2017 20:59Искренне хотел найти своё место. Увы. Но зато буду знать как не выглядеть пассажиром).
ne_zabudka
23.08.2017 21:11Сильные стороны:
Такая философия наверное приходит уже в зрелом возрасте, конец творчества и начало анализа. Попробую дорасти до "… не релевантна" и "… особого пиетета".
Слабые стороны:
Жалко нет анкеты результирующей принадлежность к описанным типажам.)
Небольшой завал в сторону памятки для приспособленца.pnovikov Автор
23.08.2017 21:14Да уж скорее гайда для HR-а если на то пошло. Иначе к чему графа "что не надо спрашивать".
chuchelo_myauchelo
23.08.2017 21:13+1Встречал ли автор гибриды «RockStar» и «Пассажира» в дикой природе? Не могу себе представить такую гремучую смесь, они же противоречат друг другу — первый имеет исключительную техническую подготовку и скверные коммуникационные навыки, в то время, как у второго всё в точности наоборот. Да и само отношение к программированию у них диаметрально противоположное.
pnovikov Автор
23.08.2017 21:19+2Ну… как говорится "опыт не пропьешь", но Rock Star с ораторскими скиллами ИМХО становится кем-то вроде "популяризатора науки" или визионера, аки Стив Джобс. Но я могу ошибаться.
joker512
23.08.2017 22:38+1Совершенно согласен с вашим комментарием.
По идее это крутое сочетание, но здесь стоит заметить, что для работодателя вариант «RockStar» + «Пассажир» может нести свои неприятности. То есть, с одной стороны, для человека удовлетворение собственного интереса и амбиций первичнее самой работы, с другой — такого довольно сложно прижать к стенке, так как он хорошо умеет пускать пыль в глаза, да ещё и хорошо знает мат. часть. :)
Из плюсов — такой человек может хорошо подходить в качестве инструмента для обучения сотрудников, деления опытом внутри компании: круто выступить на конференции, прочитать интересный курс лекций, заразить всех своей идеей — это про него.DistortNeo
24.08.2017 01:02+1> Из плюсов — такой человек может хорошо подходить в качестве инструмента для обучения сотрудников, деления опытом внутри компании: круто выступить на конференции, прочитать интересный курс лекций, заразить всех своей идеей — это про него.
Не факт. Подготовка лекционных материалов и обучение — эта неинтересная рутина.joker512
24.08.2017 06:36+1Пример с лекциями, наверное, лишний… Я лишь хотел сказать, что этот тип людей может уметь интересно и понятно объяснять сложные вещи. Но конечно, это не этом, чтобы потом годами читать их в университете. Вспоминается пример Фейнмана, который согласился прочитать курс лекций, но при условии, что это будет всего один раз. И сделал это блестяще.
Proteck
23.08.2017 23:14+1Стив Джобс и Rock Star? Не преувеличивайте :)
pnovikov Автор
23.08.2017 23:14Ну окей, окей. Билл Гейтс :) Он как-никак операционную систему сделал руками (DOS), если я не ошибаюсь.
khim
24.08.2017 04:37+8Он Бейсик написал сам, а операционку купил. Пусть только те, кто смеются над написанием простейшего интерпретатора вспомнят не про то, что это всё-таки в 70е годы было, но, что гораздо более важно — то, что Бейсик Билл Гейтс писал для компиьютера, который он впервые увидел «живьём» во время презентации этого Бейсика заказчику. До этого у него была только документация.
Вот вы бы так смогли? А «концентрированный исследователь» — смог.
Comdiv
24.08.2017 08:27+1DOS была куплена и доделана. Руками он сделал интерпретатор BASIC, и особое отношение компании к этому языку прояаляется до сих пор.
kmg4e
24.08.2017 15:22Руками он сделал интерпретатор BASIC, и особое отношение компании к этому языку прояаляется до сих пор.
Не сказал бы. Причем зная об этой страсти Гейтса, который даже будучи уже богатым человеком — называл себя частенько basic-programmer — сильно удивлен почему так мало Basic в MS.
Ну есть он (в сильно переработаном виде) внутри МС Офиса как скриптовый язык.
Но более нигде значимо он не используется. Даже как скрипт для ОС не стал основным. Даже как вторичный язык для .NET он где-то в попе, хотя уж чего, чего, а языков под .NET фирма MS много больше одного реализовала.Comdiv
24.08.2017 23:38Под особым отношением я не имел ввиду, что он должен быть основным языком в компании, а то, что его отдалённым производным уделяется куда больше внимания, чем заслуживает сам язык.
roman_kashitsyn
24.08.2017 14:53Стив Джобс
Нет уж, этот точно никакой не Rock Star. На мой взгляд, квинтэссенция Rock Star — это Simon Peyton Jones.
DistortNeo
24.08.2017 01:01Конечно. Когда рокстар убеждает заказчика, что интересная фича, из-за которой сдача проекта задерживается на месяцы, будет серебряной пулей, и выбивает на это дополнительные деньги.
kmg4e
24.08.2017 15:21Я убеждаю заказчика что интересная технология на которой мы сделаем следующую версию стоит потраченных денег.
Но на самом деле это вранье.
Да технические это будет круче.
Но на окупаемость мне плевать.
Зато повозится будет интересно.
Ведутся довольно часто, если только нет жестких ограничений по бюджету. Впрочем, с такими стараюсь не работать.
Gorthauer87
24.08.2017 09:50Линус Торвальдс кажется подходит как пример такого гибрида.
marshinov
24.08.2017 12:18Нет, Торвальдс известен своим жестким стилем коммуникации. Пассажир — это человек-человек. У Торвальдса — это слабая сторона.
PashaNedved
23.08.2017 21:19Я так понимаю, что всему написанному нужно слепо верить? Ибо никаких научных, псевдонаучных, статистических и даже логических пояснений в посте нет.
pnovikov Автор
23.08.2017 21:20+1Я вас не заставляю верить. Не хотите — не верьте. Однако многие из отписавшихся выше людей с опытом отметили, что написанное весьма близко к реальности. Если для вас это не показатель — ну… б-га ради. Я не навязываюсь.
pokabudki
23.08.2017 21:59+1+1 к «весьма близко к реальности»… Спасибо за структурированное изложение мыслей!
И да… голосовалки не хватает. Кстати интересно на сколько совпадает то как человек видит себя и к какому классу вы его относили (на примере тех программистов с которыми вы работали).
NoRegrets
24.08.2017 02:20+1Это так же близко к реальности как и знаки зодиака. Большинство людей обязательно находят в себе и других соответствующие черты.
pnovikov Автор
24.08.2017 02:23+1Удивительно, не так ли? А вы бы хотели чтобы они их не находили? :)
NoRegrets
24.08.2017 21:13Я не против подобных классификаций, если только она поставляется в обертке «пятничное чтиво под пиво». Серьезно относить кого-то в какую-то группу, пфф, — а вы еще что-то про найм пишете.
kmg4e
24.08.2017 21:46+1Не классифицировать людей при поиске сотрудника = плохо выполнять работу, не найти человека, чтобы он был на своем месте.
oleg_shishkin
24.08.2017 23:03+1я например благодарен автору за такую форму представления очень важной и нужной информации. И здесь хочется процитировать великий труд «Хуайнань-цзы»
«В то время как глаз видит кончик осенней паутинки, ухо не слышит раскатов
грома; когда ухо прислушивается к звучанию нефритового цина, глаз не
видит и горы Тайшань. Когда воля устремлена на малое, тогда забываем
о большом.»NoRegrets
24.08.2017 23:42Вы же понимаете, в чем проблема этой классификации? Классифицировав наемного работника в одну из групп, на основании схожести определенных критериев, вы автоматически присваиваете ему другие черты, как свойственные этой группе. Черты, которые у него не обязательно проявляются. Дальше начинает работать инерционность мышления и человеку понадобится время, чтобы его переопределили в другую группу, если вообще получится. Мы, конечно, все разные и это нужно учитывать при организации работы. Но учитывать нужно успешность и мотивацию при выполнении определенной деятельности, а классификация — слишком грубая модель. Так что я чего-то важного, большего, чем просто глупая классификация, не увидел.
Но, тем не менее, автору спасибо, прочел как гороскоп.oleg_shishkin
24.08.2017 23:54+1Я могу здесь вам разнести все вышеуказанные группы в категории элементов теории У-Син. Указать все взаимосвязи и взаимозависимости (положительные и отрицательные связи) каждой группы. Способы решения основных проблем коллективов программистов по принципу Мать-Сын. Но для Вас я думаю это будет просто гороскоп. А для китайской медицины — это тысячелетия изучения законов Природы. Конечно каждый смотрит со своей колокольни. И как сказано в Чжуан-цзы «С лягушкой, живущей в колодце, не поговоришь об океане, ведь она привязана к своей дыре, — ответил Дух Океана Жо. — Летней мошке не объяснишь, что такое лед, ведь она стеснена сроком ее жизни. С ограниченным ученым не поговоришь о Великом Пути — ведь он скован своим учением. Ты сейчас вышел из своих берегов, увидел великий Океан и понял свою ничтожность. Значит, с тобой теперь можно толковать о великой истине.» Только не обижайтесь.
NoRegrets
25.08.2017 00:03+2У-Син, инь-янь, феншуй, чакры, все дела. У каждого есть право делать своих сотрудников несчастными по-своему.
oleg_shishkin
25.08.2017 00:07-1Если Вы на практике например никогда не сталкивались с «эзотерическими творческими решениями», то Вам никогда понять например взаимоотношений линейщиков и рок звезд, и так можно продолжать и продолжать. У меня друган в ходит в пятерку людей по Союзу, который может конфигурить протокол x.25 и его железо. Понять таких людей не возможно — а только воспринимать как данность.
pnovikov Автор
25.08.2017 09:08+1Послушайте, как нетрудно заметить — в статье специально не приведен метод "как за 10 минут понять кто перед вами", потому что я склонен считать что его нет, а тот кто заявляет что нашел его — тот лицемер. Нельзя на основе статьи взять и сделать классификатор. Надо сначала понять кто именно перед вами, а потом уже почитать что концептуально ожидать от человека. Т.е. если вы пытаетесь, как один коллега выше, сказать "ага, он не любит фрукты в офисе — значит точно делец" — то вы применяете статью неправильно.
oleg_shishkin
23.08.2017 22:0525 лет в программировании — и правда очень точно все подмечено (учитывая что чистых типов почти нет)
newpy
23.08.2017 22:21+1Типажи, как было упомянуто, не абсолютные, но, как мне кажется, верно определено примерное количество. Если задать больше — будет размазано, меньше — не точно. А эти четыре, и их комбинации, действительно, могут описать, тип соискателя, обеспечив приемлемый и достаточный уровень точности в помощь кадровым работникам.
Данных описаний хватило, чтобы узнать в себе что-то от rock star, оттенки от lazy «дельца». Видимо как раз, если перемешать, добавить волшебный пендаль, то может из меня бы вышло что-то более стоящее :)
Спасибо за интересную статью и легкий стиль изложения.
haldagan
23.08.2017 22:26+3...Гороскопы — теперь на Хабре! Ставь лайк, если узнал себя!pnovikov Автор
23.08.2017 23:48+2Вы так пишете, будто я запрещаю вам взять в руки клавиатуру и сформулировать/написать лучше, чем я и мое жалкое графоманство :)
Singaporian
24.08.2017 07:27+2Он только что объяснил, почему этого не стоит делать ни вам ни ему, а вы тут же дали ему совет это сделать лучше, чем вы.
pnovikov Автор
25.08.2017 09:14Ну просто совет сводится к тому, что "давайте не строить никаких классификаций — будем, как говорится, резать по живому". Мне такой подход кажется… маленько немасштабируемым. Люди в принципе склонны вешать ярлыки, потому как оценивать каждое явление заново — трудно и неудобно. Я и решил немного помочь проводящим собеседование в этом нелегком деле.
Если имеется в виду апелляция к корреляции статьи с реальностью — то, как было замечено, она-таки коррелирует. При том так, что люди вон узнают себя и коллег, при том не во всех 4х категориях одновременно, что отличает её от гороскопов, которые суть — юмористически обыгранная зависимость характера или ситуации от рандомных факторов (ИМХО) или просто общие слова.
Еще. Учтите такую важную вещь, пожалуйста, что человек "изнутри" воспринимает себя иначе, чем его воспринимают снаружи. Поэтому реакция "ну вот я же ни под одну категорию не подхожу!11" нормальна. Постарайтесь понять подходят ли ваши коллеги и поймете о чем я говорю. Да — вас тоже кто-то со стороны видит иначе, чем вы видите сами себя :)
Singaporian
25.08.2017 09:43Из крайности в крайность бросаетесь. Классификация нужна — без нее не сориентироваться. Но комбинации классификаций не нужны. Потому что как только вы добавляете туда что-то неатомарное, а какую-то структуру (рок-стар любит делать только то, что хочет + фантастические зарплатные ожидания), то сразу эта группа становится нерабочей, потому что те, кто туда попадают как люди, любящие делать, что хотят, но не требующие денег, сразу оттуда и вылетают. А кто не вылетел из-за зарплатных ожиданий, тот вылтеит по списку других определений этой группы.
В результате получается, что люди отдельно, классификация отдельно и все классификационные группы стоят пустые и ни в одну не попадает ни один человек. Тогда зачем они нужны?
Ведь основной практический смысл — понять, как работать с конкретной группой. А в группе никого — по данной схеме не с кем работать. А чтобы работать с теми, кто не в группе, подходы не описаны.
А вот если бы классификация была более атомарная и без комбинаций — тогда другой разговор. Или, на крайний случай, были бы все варианты комбинаций, а не только 4.
В любом случае, ваша статья очень интересная и читал я ее с удовольствием. То, о чем я пишу — лишь направление, куда можно дальше развивать классификацию.
DS28
25.08.2017 10:49(Рок-стар любит делать только то, что хочет + фантастические зарплатные ожидания), то сразу эта группа становится нерабочей, потому что те, кто туда попадают как люди, любящие делать, что хотят, но не требующие денег, сразу оттуда и вылетают.
Нет, не вылетают, ведь классификация не строгая и деньги не являются определяющими…
Тут уже сравнивали классификацию с типами темперамента. Чистых темпераментов тоже мало, и для более полного описания нужны пограничные типы (флегматичный сангвиник и т.д.)
Но есть нюанс — здесь две шкалы(4 типа), а у автора статьи шкал больше, поэтому и типов должно бы получится больше.
Но шкалы у автора не независимы и потому некоторые типы почти не встречаются (либо какая-то шкала игнорируется) и автор ссылаясь на свой опыт выделяет 4 основных (на его взгляд). Можно конечно сделать «Деньги + делать, что хочешь»; «делать, что хочешь без денег»; «Деньги и делать, что скажут»; «Делать, что скажут без денег», но это только 2 шкалы…
Возможно вам больше понравилось бы если бы автор назвал все шкалы, расчертил бы n-мерный куб и показал бы о каких типах он рассказывает, но автор сделал так, как сделал и сказал:Вы так пишете, будто я запрещаю вам взять в руки клавиатуру и сформулировать/написать лучше, чем я и мое жалкое графоманство
Гороскопы же здесь вообще никаким боком.
Гороскоп завязан на дате/звёздах/выдумке (даже теоретически невозможно описать как этонеработает)
Классификация — на навыках/стиле работы/предпочтениях человека/и т.д.
Гороскоп не подразумевает изменения исходных данных для классификации (родился стрельцом — стрельцом и помрёшь)
Классификация подразумевает возможность перехода из одного типа в другойSingaporian
25.08.2017 13:34-1Половина цитат не мои, а ответ мне :-)
DS28
25.08.2017 18:48Первая часть ответа на вашу цитату. Возможно следовало цитировать несколько раз, чтобы легче было понять — моя ошибка.
Вторая часть комментария (про гороскопы) — просто дополнение. Если вы не считаете, что авторская классификация похожа на гороскоп (хотя вы поддержали haldagan? ) — то игнорируйте.Singaporian
25.08.2017 18:56Она не только не похожа на гороскоп, она даже дает обратную схему: в гороскопе все на столько абстрактно, чтобы подходило всем. В этом описании все на столько детализировано, что не подходит никому :-)
Поэтому игнорирую.
haldagan
25.08.2017 10:41+3Ну, давайте разбирать написанное.
совет сводится к тому, что «давайте не строить никаких классификаций..
Нет, совет сводится к тому, что „раз уж занимаемся составлением классификации — давайте делать это научно“.
Научный подход:
— вы придумываете с нуля (или берете за основу какую-то уже зарекомендовавшую себя как рабочую) некоторую теорию
— согласно придуманной теории вы строите классификацию со строгими критериями, по которым любого человека на собеседовании можно однозначно отнести к тому или иному классу
— для каждого из классов вы составляете некоторое конкретное предсказание (например: „этот класс склонен к авантюризму, уволится в течении 6-12 месяцев“ или „представители этого класса имеют тенденцию к забиванию болта на работу“)
— вы собираете статистику: вы проводите 100500 собеседований и, согласно заполненному опроснику, причисляете кандидата к тому или иному классу + берете на работу ВСЕХ подходящих по квалификации (чтобы исключить ошибку выжившего), не опираясь на вашу классификацию
— если по истечении оговоренного срока ваше предсказание для класса кандидата сбылось (ушел из фирмы или начал класть болт) — вы ставите галочку в перечне кандидатов „предсказание сбылось“
— по окончанию некоторого заранее установленного периода эксперимента вы смотрите статистику:
Если точность предсказаний 50-60% — поздравляю, ваша теория не работает, нужно придумывать заново. Если 80+% — отлично, вы близки к истине — можно показать коллегам по цеху.
Не научный метод:
— Исходя из личного опыта подогнать выборку задним числом и составить классификацию без четких критериев классов.
Первый метод даст рабочую классификацию, второй просто покажет некоторую статистику, взятую из вашего личного опыта. Статистику можно принять к сведению, но никаких выводов из нее делать не стоит, т.к. выборка непонятна (пол/возраст/местность), а методология, на которую вы опирались при сборе статистики, не озвучена.
… она-таки коррелирует. При том так, что люди вон узнают себя и коллег ...
Как вам такая классификация: „На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят“. Абсолютно точна, но не несет предсказательной ценности.
Вот с предсказательной частью:»На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят.
Первые в большинстве своем будут одну-две руки.
Вторые же — один-два глаза."
Вуаля — имеем уже рабочую и точную классификацию.
Почему работает совершенно точно (исключения — небольшой процент людей, лишившихся 2 конечностей/глаз)?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
Почему не имеет никакой ценности?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
haldagan
24.08.2017 07:49+2К вам как к автору статьи претензий никаких — вы написали статью, ее тепло приняло сообщество, значит статья сообществу понравилась.
Меня просто смутила эта самая позитивная реакция сообщества на гороскоп с этой замечательной оговоркой в конце «ну, на самом деле в чистом виде встречаются редко, чаще — комбинации».
Я просто оставлю это тут: Эффект БарнумаS_A
24.08.2017 08:03+3Если хотите науки… если взять например гештальтпсихологию/гештальттерапию, там да, действительно, такого феномена как характер нет (ибо всё ситуативно или запрограммированно прошлым опытом циклов контактов). Если взять психоанализ, там тоже нет типизаций особых, есть структура личности (ну эти там ид, эго, суперэго). Нет типизаций и в НЛП (кроме пожалуй по ведущим системам). А вот в той же клинике типизаций много (начиная от невротиков-пограничников, и заканчивая психиатрическими классификациями, которых вагон).
Я скорее поддержу то, что классификация поведения людей — это весьма чрезмерное упрощение. Но и поддержу автора тем, что наше общество, несмотря на индивидуальность каждой личности, имеет характерные паттерны (аутсорсинговые и продуктовые «ООО», типичные клиенты и договора, практики и прочее), в которых люди действуют достаточно однообразно — в зависимости от их прошлого бэкграунда и социальных ограничений. Также не думаю, что автор претендовал на научное открытие, скорее на некоторый entertainment с моралью на выбор.
Один человек (я могу и про себя это сказать) в разных компаниях и коллективах и в разном возрасте может являться в различных ипостасях. Где-то я тяну только на пассажира, а где-то на звезду. Более того, в одной компании (я выше про себя писал) человек может меняться. С точки зрения психологии вся описанная картинка динамична, как в рамках групп, так и в рамках отдельного человека.haldagan
24.08.2017 17:01+3которых вагон
— Это классификации отклонений от некоторой абстрактной «нормы» (читай болезней), а не людей.
— Эти классификации мало что говорят о самом пациенте — они по большому счету определяют подход к лечению и режим содержания.
— Эти классификации утверждены комитетно: много ученых мужей собрались вместе, поделились статистикой и договорились о том, что вот таких вот можно не лечить, вот этим вот — побольше седативов и все ок, а вот этих — принудительно и только с диспансеризацией, иначе делов натворят.
оффтопВы же согласитесь, что высказывание «сотрудник, больной гриппом менее производителен, чем здоровый сотрудник» не верно? Чтобы оно стало верным, его необходимо привести к форме «сотрудник, больной гриппом, с большой вероятностью будет менее производителен, чем этот же сотрудник, но здоровый».
То есть при приеме на работу учитывать пункт «как часто болеете?» для сравнения сотрудников можно только в совокупности с пунктом «сколько кубометров леса рубите в день, когда здоровы?».splav_asv
25.08.2017 21:17Есть очень хорошая книга про структуру личности в психоанализе. Один из вариантов классификации и довольно полный там тоже есть — www.group-analysis.ru/publications/Nancy_McWilliams/Nancy_McWilliams_PSYHOANALYTIC_DIAGNOSIS_Understanding_Personaly_Structure_in_the_Clinical_Process.php
marshinov
24.08.2017 12:23-1Гороскопы основаны на «звездах», а эта классификация на особенностях психики человека. Связь между звездами и поведением человека я найти не могу, а вот связь между психологией и поведением вполне понятна.
Кроме этого, эта классификация согласуется со многими другими. Я давно заметил, что если несколько человек независимо «изобретают» похожие модели, то это значит, что модели «работают».oleg_shishkin
24.08.2017 17:22Кстати такое деление очень легко объясняется китайской теорией У-Син (теория 5 элементов). Также она легко объясняет и соответствующее взаимодействие между этими выделенными группами.
bo883
23.08.2017 22:28классная статья, немного смахивает на гороскоп )))
Узнал себя и коллег в описании, я так думаю ))
Maccimo
23.08.2017 23:36+2Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им.
…
Круглый (хотя бы овальный) отличник.Вася Пупкин с детства слушался учителей и родителей, усердно делал все задания, даже самые неинтересные и старался учиться на одни пятёрки. А потом, внезапно, зазвездился и начал заниматься только тем, что интересно ему.
Логично, что уж.pnovikov Автор
23.08.2017 23:39-1Я еще раз говорю — нет плохих типажей. Вероятно Вася Пупкин хорошо решает интересные ему задачи — и по закону больших чисел он рано или поздно встретит своего работодателя. :)
joker512
24.08.2017 00:05+4Мне кажется, вы путаете причины и следствия.
«Rock Star», скорее всего, будет отличником, но не обязательно отличник станет «Rock Star». Тот тип отличника, который вы описали, скорее всего, станет линейным программистом, ну или вообще не станет программистом.
Отличники они тоже разные бывают)ToSHiC
24.08.2017 00:26+3Rock star, скорее всего, не будет отличником, потому что для этого нужно делать много всякой нудной и неинтересной работы типа домашних заданий, изучения неинтересных предметов, какое нибудь обязательное посещение лекций или другая ерунда.
DistortNeo
24.08.2017 01:19Зависит от кругозора человека и его способностей. Есть рокстары-пятьнольщики, а есть — двоечники. Знаю по нескольку рокстаров обоих типов. Первые с лёгкостью тянут заломную математику, это именно они придумывают новые математические теории и воплощают их в жизнь. Вторые же зациклены исключительно на программировании. Несмотря на то, что они не способны создавать вещи, которые создают первые, они обычно более успешны.
ToSHiC
24.08.2017 01:43+2Отличник != придумывать новые теории. Зачем-то нужно ещё запоминать странные факты, чтобы получить зачёт по истории, например, или правила грамматики английского языка. В целом, конечно, в ВУЗе намного проще с этим, чем в школе — на диплом влияют далеко не все предметы.
DistortNeo
24.08.2017 02:02> Отличник != придумывать новые теории
А что в вашем понимании отличник? Есть студенты, у которых просто пятёрок больше, чем остальных цифр. Если студенты с красными дипломами. А есть абсолютные отличники — только пятёрки по всем предметам.
Так вот последние — очень специфические люди и работать с ними традиционными способами практически невозможно.ToSHiC
24.08.2017 10:18Красный диплом.
DistortNeo
24.08.2017 14:30Как ни странно, но люди с красными дипломами часто бывают пассажирами, которые просто умеют сдавать экзамены. А вот абсолютные отличники — это рокстары.
kmg4e
24.08.2017 15:29Красный диплом.
Не показатель.
Во первых есть такое понятие «склонен к завышению» — если человек хорошо учился с самого начала, когда все было просто, то в дальнейшем преподы его тянут на красный диплом.
Во вторых примеров, когда программер с красным дипломом даже не программером стал работать, попытался, но выяснилось, что не смотря на диплом он не программер все же — более чем достаточно.
alexeykuzmin0
25.08.2017 08:28Есть вузы, где можно получить красный диплом почти без усилий. Нужно просто хорошо сдать экзамены, что rock star вполне по силам
JediPhilosopher
24.08.2017 01:35+1Но он может быть дофига умным, так что будет справляться с этим без проблем.
Встречал рокстаров обеих категорий — большая часть либо не доучилась в вузе по указанным вами причинам, либо были троечниками-пофигистами, но часть доучилась, и даже на красный диплом. Потому что им просто было это легко и ненапряжно, пока все другие потели и тужились — они по-быстрому ловили свои зачеты автоматом и шли заниматься более интересными вещами.khim
24.08.2017 04:45Потому что им просто было это легко и ненапряжно, пока все другие потели и тужились — они по-быстрому ловили свои зачеты автоматом и шли заниматься более интересными вещами.
Именно так. Я в МГУ учился и мне было невероятно обидно, когда на третьем курсе я не смог уехать к родственникам на каникулы до Нового Года из-за того, что не сдал экзамен. Один.
Просто на всякий случай: в те времена, когда когда я там учился первый экзамен официально сдавался 2-3го января.
Adel-S
24.08.2017 00:15известны случаи когда дальнобойщики становились разработчиками на PHP
Хех… я с одним бывшим таксистом работал, которому надоело работать в такси, он прочитал книжку по PHP и пошёл программистом работать.
decomeron
24.08.2017 05:44-1Доброго времени. А по возрасту есть какая-нибудь классификация? Ведь в молодости и "море по колено" и "горы по плечу", в зрелом возрасте и лениво и "сам с усам"
neurocore
24.08.2017 08:30Видел где-то классификацию в другой плоскости (исполнительской чтоли), может даже на хабре. Приводились следующие типажи: парень 90% (проблемы с завершением), любитель библиотек (добавление огромного количества библиотек для решения всего), оптимизатор (многократное и усердное переписывание кусков кода для достижения лучших показателей везде), дальше память подводит.
Насколько такая типизация существенна в выборе персонала?
fishca
24.08.2017 09:11+1Обычно не очень люблю не технические статьи на хабре, но эту просто «выпил» огромными глотками, спасибо, очень понравилось!
AslanKurbanov
24.08.2017 10:26+4Статья понравилась. Вот только по-моему линейные программисты не совсем такие простые и линейные ребята. На самом деле эти скрытные Кибальчиши могут потихому пилить свой собственный проектик в личное время, впрочем и в неличное тоже: как отдушину от серых будней. И через это развивать свои навыки, что на самом деле плюс, т.к. впоследствии положительно отражается на основной работе. Одного такого программера я знаю.
Так что это может только со стороны кажется что линейщик застрял в 1с или FoxPro, а на самом деле он пилит свой проект имея стабильный доход на основной работе, это и ответ на вопрос почему он не дергается с насиженного места 20 лет.
AndreyShafirin
24.08.2017 10:28Спасибо за статью. В ней возможно и не хватает, как Вы сказали, "второго измерения". Но оно усложнит восприятие. А так сохранена предельная простота. Я бы на Вашем месте (с Вашим опытом) добавил бы как и в каких ситуациях комбинировать эти типы в проектных комманды. Кто с кем эффективно уживается и работает. По аналогии с Юнгом, который не только предложил психотипы, но и показал их совместимость или несовместимость. Очевидно есть ситуации, в которых только линейные программисты приведут к провалу. Только rockstars не попадут в требования, а дельцы не впишутся в бюджет, пассажиры сведут все к балагану. А смешанная комманды могла бы быть эффективна.
pnovikov Автор
24.08.2017 10:29Я бы с радостью написал про комбинации, но увы. Мне пока никто не дал достаточно бюджета и простора для деятельности чтобы построить комбинированную и сбалансированную команду как я её вижу. Видимо для этого придется открывать собственную компанию. :( Но это тоже будет построение команды под какую-то конкретную задачу. И не факт, что она будет согласовываться с задачами у других игроков в индустрии.
alexeydg
24.08.2017 10:34-1очень жизненно. только не хватает 5 категории — мажор, это такой микс из рок стар и пассажира. очень много понтов, очень много знает, часто ненужного, очень много говорит, заносчив, высокомерен, на практике полный ноль.
borisxm
24.08.2017 10:44Не хватает классификации типа «творец» или «художник». У меня есть знакомый, которого приглашаем на работу по развитию новых проектов. Если ему интересна задача, то он ей займется за любой разумный гонорар. Сам изучит предметную область, реализует прототип, идентифицирует и раздаст задачи сотрудникам. Код, написанный им, можно распечатывать и вешать в рамочку на стену.Но как только все заработало и стало продаваться, он начинает терять интерес к проекту и передает бразды правления другим.
На этом, обычно, наше сотрудничество заканчивается до следующей интересной темы. К сожалению, не знаю чем он занимается в свободное время, но вроде пилит что-то свое.
Интересно, что фундаментальное математическое образование у него слабое, что не мешает ему сформулировать задачу для профессионалов в этой области.
antivoland
24.08.2017 11:09Не добавили в статье самый распространенный/популярный у людей из других отраслей тип — тыжпрограммист
pnovikov Автор
24.08.2017 11:11Это не типаж, а характеристика программистов как класса с позиции не участвующих в индустрии людей. Так что не проходит по формату.
oleg_shishkin
24.08.2017 11:10+6В дополнение — пару замечаний о коллективах разработчиков (О себе — 25 лет разработки, типичный линейщик, красный диплом, не отличник)
— линейные программисты — основа коллектива, его связующая ткань. Основная болезнь — постепенное одеревенинение, а затем и каменение. Самостоятельно болезнь не лечится.
— рок звезды — в малом количестве являются украшением коллектива. Не создают внутренних конфликтов. Линейные программисты снисходительно относятся к причудам характера рок звезд. Отсутствует конфликт между ними и линейщиками. Самое главное — не дают линейщикам деревенеть, заставляя последних к внутреннему движению — т.е. являются лечением основной болезни линейщиков.
— пассажиры — в малом количестве играют важную роль в обеспечении взаимодействия основного коллектива (линейщики плюс рок звезды) с начальниками и прочее.
— дельцы — разрушают любой коллектив, так как по своей природной натуре не являются коллективными работниками. Привлечение дельцов оправдано только в случае «горящих» ситуаций. Создают внутренний конфликт с линейщиками, которые понимают что все равно задание упадет с дельцов на них по истечение какого-то времени. С дельцами эффективна торговля знаниями по принципу «ты мне — я тебе». Использование дельцов должно быть в отрыве от коллектива.marshinov
24.08.2017 12:31+1Про дельцов не совсем верно. Делец — это руководитель, а не исполнитель. В качестве CTO / тим-лида вполне может хорошо работать. Дайте ему зарплату и высокую премиальную часть за достижение показателей и он может ориентировать команду на достижение результатов. Главное, чтобы «делец» хотя-бы немного оставался «человечным» и не шел к успеху по трупам коллег.
oleg_shishkin
24.08.2017 12:55Делец — будет работать ВСЕГДА только на себя. Ему интересен только свой рост (знаний и денежный). Тим-лид подразумевает ответственность за коллектив. На этой должности как указывали другие хороши совместный тип пассажир+линейщик(перевес пассажира). Раньше были еще очень немногочисленный класс архитекторы задач(не путать со scrum master). Которые направляли ownerов и взаимодействовали с линейщиками. Это тоже совместный тип линейщик+пассажир(перевес линейщик).
marshinov
24.08.2017 13:21Думаю, мы с вами просто по разному определяем «дельца». Ваш «делец» — крайний случай индивидуализма. Это, например, внешний консультант. Ему ваша компания и команда, действительно, по барабану. Мой «делец» — это ваш + немножко ориентации на людей. Таких дельцов еще меньше, чем индивидуалистов, но они все-таки есть. Если чуть-чуть изменить ваш комментарий:
Делец — будет работать СКОРЕЕ ВСЕГО только на себя.
то я согласен.oleg_shishkin
24.08.2017 13:33если посмотреть на мой пройденный опыт — то Ваша оценка верна
Хотя не обязательно, что это будет внешний консультант. Работодатель часто нанимает таких людей — пытаясь за короткий срок работы с ними выжать из него знания по принципу «ты нам знания, мы тебе деньги и знания»marshinov
24.08.2017 13:53Видимо менеджмент и делец не договорились друг с другом о сумме и объеме работ. Менеджмент хотел и рыбку съесть и все остальное, а делец считал, что за эту сумму полагается только рыбка. Отсюда и отсутствие желания делиться знаниями бесплатно. Не могу сказать, что такое желание не законно:)
oleg_shishkin
24.08.2017 13:53+3Единственная проблема работы с дельцами — то, что они хранят свои знания. Потому что это их деньги. Линейщики миряться с этим как с неизбежным злом. Но реально вытащить знания с дельцов — это отдельная наука. Легче заинтересовать рок звезду и потом понять их решения.
kmg4e
24.08.2017 16:05Делец — это руководитель, а не исполнитель.
Во вне привязке к профессии программиста — да.
Но с точки зрения типажей — это обязательно квалифицированный программист.
Он совсем не обязан быть руководителем.
Фриленсеры, к примеру.
Я не о тех, что крохи подбирают и перебиваются с хлеба на воду, а о квалифицированных и успешныхmarshinov
24.08.2017 16:11Вы правы. Точнее сказать у дельца больше шансов стать руководителем. Он лучше понимает значения слов «ограничения», «ответственность», «результат» и приемлет риск.
Если делец умеет сходиться с людьми и увлекать их за собой, то он открывает компанию. Если он четко понимает, что брать ответственность не только за себя, но и за других — не его, то остается успешным фрилансеров (self employeed). Нельзя сказать, что одно лучше другого: люди разные, каждому — свое.
kmg4e
24.08.2017 15:36+1дельцы — разрушают любой коллектив, так как по своей природной натуре не являются коллективными работниками. Привлечение дельцов оправдано только в случае «горящих» ситуаций. Создают внутренний конфликт с линейщиками, которые понимают что все равно задание упадет с дельцов на них по истечение какого-то времени. С дельцами эффективна торговля знаниями по принципу «ты мне — я тебе». Использование дельцов должно быть в отрыве от коллектива.
Конфликтовали лично с этим типом отсюда такое отношение?
Делец в понимании автора статьи — это еще и крепкий технический специалист, а не просто бизнесмен.
Делец в моем понимании выдает вполне качественный результат, так как думет и о своем будущем, закладывает себе фундамент под будущее взаимодействие с этой фирмой, заботся о репутации, она еще принесет ему денег — и даже если результат работы дельца упадет потом на поддержку линейщиков — это не будет обязательно страшным говнокодом.oleg_shishkin
24.08.2017 16:32Нет не конфликтовал — и Вы совершенно правы, что Дельцы выдают очень качественный продукт. Если было бы не так — то они бы не зарабатывали столько. Их очень легко отличить от других тем, что я указывал — они БЕРЕГУТ свои ЗНАНИЯ и просто так УДОЧКОЙ с Вами не поделятся, а вот РЫБЫ вам «продадут» сколько угодно. Вот это вызывает внутреннее напряжение у линейщиков, работающими с Дельцами и только у них. В термине Делец нет ничего обидного или плохого. Главное их достоинство — они СОБИРАТЕЛИ и ХРАНИТЕЛИ знаний. Но как и любой метал, который разрушается от внутреннего напряжения — так и Дельцы изнутри разрушают коллективы. Линейщики обособляются, нарастают конфликты уже между ними — и все коллектива нет.
kmg4e
24.08.2017 17:15+2они БЕРЕГУТ свои ЗНАНИЯ и просто так УДОЧКОЙ с Вами не поделятся, а вот РЫБЫ вам «продадут» сколько угодно.
Знания технического характера, не сказал бы — тут больше зависит есть ли у дельца склонность к учительству, к передаче знаний новым поколениям или нет.
Мне нравится учить молодежь.
Знания как добывать деньги…
Ну скажем, я, работая на фриленсе уже много лет — только и делал, что уговаривал своих друзей бежать из контор, рассказывал о ньюансах.
Знаниями такого свойства делиться дельцу безполезно с другим типажом программистов — на то он и другой типаж.
oleg_shishkin
24.08.2017 16:44+1Я учился в классе (в советское время) — в котором собрали одних отличников, ну и хорошистов для дополнения. Это страшное дело я вам честно признаюсь. Ни чьим детям этого не пожелаю.
tehSLy
24.08.2017 11:12+1Есть мнение, что слишком смешали теплое с мягким (личностные и профессиональные качества). Не уверен, что существует явная корреляция любви к фруктам в офисе с психотипом человека, там может быть много факторов :)
pnovikov Автор
24.08.2017 11:14Само собой, но послушайте. Когда вы нанимаете человека — вы нанимаете не набор навыков и не машину, а живого человека со своими особенностями, в т.ч. не относяшимся к профессии напрямую. Я просто счел нужным предупредить какие основные типажи встречаются и чего от них ожидать (не только в плане работы)
VolCh
24.08.2017 15:50Тут не фрукты как таковые, а «соцпакет» в целом. Кто-то считает его бесплатным бонусом, а кто-то в уме подсчитывает сколько эти «бонусы» стоят на рынке, сколько личного времени он будет тратить на их получение и сравнивает оценки.
guai
24.08.2017 13:05Единственная годная статья по этой теме за всю историю сначала хабра, потом того ответвления, куда выгрузили всякое балабольство (забыл название), и теперь опять хабра
marshinov
24.08.2017 13:48+4Я думаю, забыли один «чистый» тип («дельца» я считаю комбинацией, причем «дельцы», сдается мне, еще и бывают разные)
«Педант» или «Поборник чистоты».
Встречается редко, в основном в корпоративной среде. Не пропустит ни один пулл реквест с отклонениями от корпоративных стандартов, пусть даже это будут лишние пробелы в конце строки. После ревью «педанта» джуниор может получить десятки или сотни развернутых комментариев и следующий реквест прислать только на следующий день.
Обожает статические анализаторы, тесты, гайдлайны, всегда первым делом настраивает CI и автоматизирует выкладку. К сожалению из-за внимания к мелочам страдает недостатком производительности.
Не давайте ему задачи, требующие «хуяк-хуяк и в продакшн», он вас разочарует. Лучше всего объедините его в команду с Rock Star для решения mission critical — задач. «Педант» без труда отыщет все мелкие проблемы, которые Rock Star с высоты своего полета не разглядит. Кроме, этого он забракует все эзотерические творческие решения, чем заметно облегчит поддержку в будущем.
Только не забудьте выделить им кабинет со звукоизоляцией. В особенно сложных случаях, подключайте в команду «пассажира», чтобы тот следил, чтобы эти двое не поубивали друг друга.
В свободное от критики рок звезд время может на 100% быть загружен код-ревью младших специалистов. Он быстро приучит их к дисциплине. А вот в команде с линейными программистами он будет выглядеть вяло. Команда будет справедливо отмечать, что производительность «педанта» может быть в разы ниже средней по больнице. Код-стайл и скобки — вещь конечно важная, но не важнее достижения целей проекта.oleg_shishkin
24.08.2017 14:07+2Полностью согласен со всем — хотя на практике встретил один раз. В жизни было точь — в точь. Бывает крайне полезен в корпоративной среде. Про помещение со звукоизоляцией — обязательно к употреблению.
nikaforward
24.08.2017 14:20Интересно, а могут ли внешние факторы быть причиной смены типажа?
К примеру, работал человек в аутсорсе, клепал скучные задачи линейно. А потом перешёл в компанию, развивающую свой продукт, и стал rock star.wispoz
24.08.2017 14:31Думаю вряд ли, переход из линейного в дельцы или пассажира возможен, а вот в rock start нереально, так как там нужны качества которые врожденные и были изначально.
kimisa
24.08.2017 15:44+1А если он изначально был rock start, но его взяли на скучные задачи? Естественно он повел себя как линейный. В такой классификации очень большое влияние оказывает где работает человек. Если в конторе делают только скучные задачи и эта контора единственная куда его взяли…
DistortNeo
24.08.2017 15:46> А если он изначально был rock start, но его взяли на скучные задачи? Естественно он повел себя как линейный.
Нет. Рокстар бы приложил все возможные усилия, чтобы эти скучные задачи стали ему интересными. Фактически, эксперементировал бы за деньги работодателя, а не тупо писал код.
wispoz
24.08.2017 15:46Сомневаюсь, если rock star взяли как линейного, через некоторое время он просто уйдет из-за рутины. Тут именно врожденные качества. Если их нет то не быть rock star увы и ах. Зато можно стать дельцом что я считаю довольно таки не плохо)
kimisa
24.08.2017 15:49+1А как отличить кто он у начинающего программиста? У него же на лбу ничего не написано. А чтобы взяли как rock start нужен опыт и знания. Откуда их взять? Конечно же поработав вначале линейщиком.
DistortNeo
24.08.2017 16:55> А как отличить кто он у начинающего программиста? У него же на лбу ничего не написано.
Очень просто. Если на простые вопросы смотрит на вас как на идиота — это рокстар.
> А чтобы взяли как rock start нужен опыт и знания.
Отличительная способность рокстара — это любознательность и желание исследовать. Без опыта рокстар не сможет писать поддерживаемый код — это факт. А вот отсутствие знаний здесь не помеха — рокстару, наоборот, будет интересно возиться в новой области.
> Откуда их взять? Конечно же поработав вначале линейщиком.
Ну хз, вот я, как типичный рокстар, ни разу не работал линейщиком. Более того, ни разу не работал фуллтайм и ни разу не работал в полноценной команде. И да, в команде работать очень тяжело — смотрю на других программистов как на говно.kmg4e
24.08.2017 17:16Вы разве не препод?
DistortNeo
24.08.2017 17:17Нет. Терпеть не люблю преподавать.
kmg4e
24.08.2017 17:21А откуда так много информации об том как программируют неопытные
habrahabr.ru/post/319606DistortNeo
24.08.2017 17:41Потому что под преподаванием я понимаю подготовку материалов, чтение лекций, проведение семинаров. Это всё скучно и неинтересно.
Но т.к. я всё-таки работаю в университете, то падаваны мне нужны. И эта штука с заданиями, факически, и есть попытка определить, имеет ли смысл плодотворно работать со студентом или он не стоит потраченного времени.
SergioPredatore
24.08.2017 14:20+1Интересно, но есть у меня один знакомый, судя по этой статье — 100% пассажир, но я его хорошо знаю, тот ещё делец!
Что я хочу сказать, люди не только могут быть чуть-чуть того, чуть-чуть этого, они зачастую бывают совершенно не тем, чем кажутся на первый, на второй и даже на третий взгляд.
mike1
24.08.2017 14:31Возьму на себя смелость представить свой классификатор программистов:
- мясники
- хирурги
- ювелиры
- художники
- маляры (ни в коем случае не обижаю представителей сей прекрасной профессии)
- искусствоведы
и другие...
AnthonyBY
24.08.2017 14:41Спасибо за статью, очень понравилось. Последний раз были такие яркие впечатления от прочтения Адизиса. Узнаёшь каждого персоонажа и понимаешь что всё так и есть, люди они все конечно уникальны, но с классификациями оно как-то легче живётся )
Artygreed13
24.08.2017 15:10Что же, отлично описаны варианты встречавшиеся мне в жизни, да и себя нашел)
Можно даже сделать квадрат, где грани будут спектром между крайностями.
poznawatel
24.08.2017 15:14А почему про люки нельзя спрашивать никого? Хороший же вопрос на тест аналитических способностей (старенький, правда).
pnovikov Автор
24.08.2017 15:15+2Потому что ответ на него все уже знают и это настолько избито, что сразу говорит о том, что компания подходит к собеседованию абы как.
poznawatel
24.08.2017 17:20Как давно я не проходил собеседование! Сам нашёл ответы, полез в Сеть, порадовался, что верные. Иногда приятно быть в чем-то ограниченным )
DistortNeo
24.08.2017 15:44+1Потому что уже давно показано, что программистские способности этот тест не выявляет.
DmitryKogan
24.08.2017 15:38+4Не линейный программист, а кодировщик
Не делец, а разработчик
Не рок-звезда, а программист-исследователь
Пассажир — это типаж не программиста, а менеджера
А так все верноpunkkk
24.08.2017 16:57А чем кодировщик от разработчика отличается?
DmitryKogan
24.08.2017 17:15Кодировщик кодирует части системы, обычно по точной спецификации, и может даже не понимать существо задачи. Идеал для аутсорсинга. Разработчик понимает задачу, создает алгоритм и раздает задания кодировщикам, если такие у него есть.
punkkk
25.08.2017 08:56Разве делец не так же делает по спецификации?
Как вообще можно писать код не понимая существа задачи?DmitryKogan
25.08.2017 09:33+2Разработчик работает по техзаданию, которое обычно пишет сам со слов клиента и с ним согласовывает
Кодировщику не обязательно понимать задачу в целом, достаточно той части, которая ему порученаpnovikov Автор
25.08.2017 09:38От себя добавлю что не стоит на этом специально играть Mushroom management — плохая практика.
VolCh
25.08.2017 11:30Как вообще можно писать код не понимая существа задачи?
Грубый пример такой задачи "вот есть формула, пускай компьютер её считает. Ещё: "при кредите счёта 361 5% должно автоматически кредитовать счёт 378". И это примеры постановок от заказчика. Постановки задач от других программистов могут выглядеть вообще типа "твоя функция должна возвращать сумму вот этих двух столбцов этой таблицы при условии, что существует связанная запись по этим полям вот в этой таблице."
amambaru
25.08.2017 11:53+4Присоединюсь:
Большинство программистов и не стремиться понимать существо задачи, если эта задача не чисто ИТ-шная.
Именно по этому многие программисты и не любят 1С — там все базовые вещи, понятные ИТ-шнику, типа логирования или отображения окон или работы с БД — решены на уровне платформы.
И программист не занимается этими далекими от прикладной области вещами. А занимается именно решением прикладных задач.
Вот тут то и возникает у программиста батхерт: «блииииин, дебет-кредит, это такая бухгалтерская муть».
Нам целые системы API проще вручную посоздавать вместо того чтобы решать конкретные прикладные задачи, далекие от ИТ-сферы.mayorovp
25.08.2017 12:13+1Нет, 1С не любят по другой причине. Потому что когда прикладная задача на готовые базовые вещи "не налезает" — остается либо увольняться, либо писать костыли.
amambaru
25.08.2017 12:19Инструментом надо пользоваться по назначению.
А не пытаться натянуть единственный инструмент на все возможные задачи.
Можно про «прикладная задача не налезает на базовые вещи» поподробнее? Пример. А то непонятно что вы именно имеете ввиду.mayorovp
25.08.2017 12:25Точно не знаю, но где-то тут в комментариях мне рассказывали что стандартный клиент HTTP в 1C не умеет декодировать сжатые ответы. И для того чтобы такое обойти, некоторые одинэсники пишут вот таких монстров: https://infostart.ru/public/238584/
amambaru
25.08.2017 12:45- По стандарту веб-сервер не должен посылать сжатый ответ, если клиент не выразил явным образом свое желание работать с сжатыми ответами.
- Описано расширение платформы 1С штатными средствами. Эта технология существует уже лет 20. Используется в тех редких случаях, когда необходим какой-то доп. функционал и одновременно требуется жесткая интеграция модуля с платформой 1С. Например, для подключения какого-либо специального оборудования.
- Я бы для обхода это косяка сервера (а не косяка клиента 1С) просто сделал бы http-прокси, а не стал бы делать внешнюю компоненту. но с начала — поигрался бы заголовками. А вдруг в каком то сочетании косячный веб-сервер начнет работать адекватно.
- Вы привели в пример специфическую задачу, не имеющую никакого отношения к прикладной области для работы в которой и создана платформа 1С. Собственно, вы и подтвердили мою гипотезу, что я высказал выше. Программистов, в массе своей, напрягает решение непосредственно прикладной задачи, если она далека от ИТ. Им бы попрограммировать понятные базовые вещи — http, к примеру.
mayorovp
25.08.2017 12:48То есть такой способ расширения считается нормальным?
Ну, это и объясняет почему 1С не любят.
amambaru
25.08.2017 13:24То есть такой способ расширения считается нормальным?
Требовать/ожидать от веб-сервера работать по стандартам?
Это везде является нормальным.
Описанная проблема нестандартного веб-сервера не имеет отношения к прикладным задачам для решения которых и создана платформа 1С.
Только что проверил. Мне удалось получить с веб-сервера сжатые данные. Там просто нужно самому заголовок «Accept-Encoding: желаемый метод сжатия» в http-клиенте 1С выставить.
Сдается мне, что этим ребятам из вашей ссылки интереснее решать не прикладную проблему в 1С, а чисто понабивать скиллы в .NET. Иначе зачем тратить так много времени? Допускаю, что они недостаточно компетентны в 1С. Но при этом компетентны в .NET. Что и предопределило способ решения задачи.
mayorovp
25.08.2017 13:49Не могли бы вы в таком случае объяснить мне вот этот комментарий?
PS человек по ссылке — точно 1С-ник, а не C#-пер. Видно по русскому языку в идентификаторах.
amambaru
25.08.2017 13:57-1PS человек по ссылке — точно 1С-ник, а не C#-пер. Видно по русскому языку в идентификаторах.
Не показатель.
Я тоже, когда начинал в 1С, всё писал на английском. Язык позвволяет. Вы можете писать «если тогда», а можете писать «if then».
Потому перестал. Потому что идентификаторы прикладной области слишком нетривиальные, чтобы писать их на неродном языке.
При том на языке Go, к примеру, у меня английские идентификаторы используются.
Контекст вашего разговора по ссылке непонятен.
Задайте прямой полный вопрос здесь.
VolCh
25.08.2017 13:02+1Инструментом надо пользоваться по назначению.
А не пытаться натянуть единственный инструмент на все возможные задачи.Увы, в случае именно с 1С наиболее характерно, что других инструментов особо и нет — или ограничение заказчика, или незнание других инструментов на уровне достаточном для соблюдения сроков/бюджета. На других платформах тоже встречается, на наиболее яркие случаи мне встречались именно в экосистеме 1С.
amambaru
25.08.2017 13:34или незнание других инструментов
Ну дык знать то инструменты — задача разработчика.
А не заказчика.
И задача разработчика — показать имеющиеся альтернативы заказчику.
VolCh
25.08.2017 13:45Предлагать инструменты достаточные для реализации задачи заказчика — задача разработчика. Выбор того разработчика, который предложит наиболее эффективные инструменты — задача заказчика. В задачу разработчика не входит предложение заказчику всех теоретически доступных инструментов для решения его задачи. Грубо — это задача аналитиков и менеджеров. Разработчик лишь сообщает заказчику (напрямую или через аналитиков): "с помощью таких-то инструментов, мы решим задачу в рамках таких-то технико-экономических рамок, с помощью других — в рамках таких-то, за решение задачи с помощью таких-то инструментов, которые по идее могут подойти, мы даже не возьмёмся, если знаете ещё какие-то — назовите, а мы оценим".
amambaru
25.08.2017 14:02в случае именно с 1С наиболее характерно, что других инструментов особо
О чем тогда говорить?
Любое ПО может и должно быть лучше — хоть 1С, хоть Android. А толку об этом мечтать если нет альтернатив (ну и ты сам эту альтернативу не пилишь).
VolCh
25.08.2017 16:23Я о том, что специалисты (или фирмы, специализирующиеся) по 1С, часто предлагают решения исключительно на базе 1С. Даже хранимку на SQL с которым 1С работает не предложат.
amambaru
25.08.2017 16:26+1Ну как минимум — это очень и очень не круто в дальнейшей поддержке.
Имхо как раз хранимка — не то, ради чего стоит заморачиваться.
У меня вот есть СУБД на 1С интегрированная с отдельным веб-сервисом. Целый отдельный веб-сервис написать я еще понимаю смысл есть.
А хранимка — она забудется, потеряется, затрется при очередном обновлении 1С. То есть за ней нужно следить.
oleg_shishkin
25.08.2017 12:39+11С не любят из-за того что это один огромный костыль. Если бы видели, что он посылает на SQL(не важно какой) сервер — вы просто матом изошли. Есть единственная толковая книга по 1С — называется «Профессиональная робота в 1с» вроде и там в некоторых местах мелким шрифтом пишут, что не надо делать на 1с — хотя до этого целые главы посвящены, что это и надо делать :) И работа с 1С возможно, если только выкинуть все из коробки и писать заново всю конфигурацию. Публикации ( infostart.ru/public/78413 и др )
amambaru
25.08.2017 13:11+1Ровно такая же ситуация с запросами в развитых CMS. Ровно такая же проблема будет с любой универсальной системой.
Вы протипопоставляете универсальное решения для работы с нетривиальными задачами — и узкоспециализированную систему.
Узкоспециализированная система всегда будет быстрее работать.
Но при этом научить узкоспециализированную систему делать что то дополнительное — будет оходится очень дорого.
Однако в случае т.н. «прямых запросов из 1С», ссылку на которые вы тут привели, позволю себе усомниться в целесообразности. В версии 1С V77 еще была иногда необходимость в прямом доступе к SQL, то в версии 1C V8 (которая появилась около 15!!! лет назад) — очень мощный язык запросов.
По вашей ссылке же я наблюдаю то, о чем я уже написал выше — вместо решения прикладных задач люди предпочитают тратить свое время на базовые ИТ-задачи.
Язык запросов в 1С очень гибок. Структура БД в 1С легко корректируется под задачу. И оптимизировать выполнение запроса можно вполне средствами 1С. Мне лично доводилось на ранних этапах написания запроса в 1С для какой-нибудь аналитики получать и по часу и по 2 часа выполнение запроса, которое после надлежащих оптимизаций превращалось в 30 секунд.
1С тут ничем не отличаются. Те кто пишут на SQL какую нибудь сложную аналитику в других системах — могут вам рассказать такие же истории.oleg_shishkin
25.08.2017 13:36+1Очень часто проектировщики систем допускают одну, но решающую ошибку — они не учитывают накладные расходы. Как в школе когда дается физика — школьникам не дают понятия силы трения — так и здесь в большинстве случаев проектанты не понимают что 10 объектов, это не одно и тоже что 1000, а уж тем более не 100000 объектов. И когда такие горе разработчики попадают в ловушку расширения системы — начинаются охи и ахи. Как же так вы нам обещали!!! Сразу говорю что курсы 1С учат людей строить запросы НЕПРАВИЛЬНО. Потому что то что посылается на сервер — это вообще не то что подразумевается пользователем. И приведенная публикация (моя) — это итог упрашиваний писателей конфигурации, когда на крошечные запросы система вешает систему на полчаса. При этом честно признаюсь — люди пишущие большие конфигурации об этом прекрасно знают. Также они знают, что запрос 1С это не запрос SQL — и в большинстве своем он преобразуется в запрос SQL не оптимально или неправильно. При этом вы наверно не знаете, что движок БД 1С используется без изменения со времен DBF файлов.
amambaru
25.08.2017 13:45При этом вы наверно не знаете, что движок БД 1С используется без изменения со времен DBF файлов.
Я знаю это про версию 1C V77.
Там действительно SQL-версия 1С была реализована поверх движка DBF, что прилично подтормаживало.
Но эта версия была разработата еще в прошлом веке.
А с современной V8 — сильно сомнительно чтобы это было так.
По крайней мере скорость работы грамотно написанных запросов — чрезвычайно высока. Несопоставимо с V77oleg_shishkin
25.08.2017 14:03Выложенная надстройка работает (ла) под 1.8 — просто Вы никогда не сидели в трассировщике запросов сервера. И вы например ничего не знаете о выбираемом по умолчанию 1С уровне изолированности транзакций и прочих плюшках, а также способе хранения реальных данных и их выборе из БД 1С
amambaru
25.08.2017 16:01-1Сидел давно в трассировщике — на 1C V77, в начале века.
В 1C V8 подумывал про трассировщик — так как в начале освоения этой версии полагал, что язык запросов так же убог как и в версии прошлого века. К счастию, вовремя разобрался с возможностями новой версии. И умею писать так чтобы работало быстро без захода в трассировщик теперь.
Понимаете в чем дело — бизнесу важно чтобы решались их задачи. За это они и платят. Гы, я «делец» по типажу из статьи наверное…
Что там внутри — начинает волновать только, когда все это тормозит или выдает результат, который не должно выдавать.
У меня — не тормозит. Не знаю почему. Наверно потому что я занимаюсь 1С профессионально уже 15 лет. Наверное потому, что и до 1С и параллельно с 1С я работал и с другими СУБД — Oracle, Tarantool, Cache.
oleg_shishkin
25.08.2017 13:42+1Поэтому люди, которые изначально учились правильному SQL просто выпадают в осадок от результатов того, что им возвращает 1C
amambaru
25.08.2017 13:51Поэтому люди, которые изначально учились правильному SQL просто выпадают в осадок от результатов того, что им возвращает 1C
Наверное потому что они не понимают, что «правильный SQL» — это всего лишь база, основа для более сложных прикладных построений?
А 1С манипулирует с несколько иными структурами.
Скажем, запрос по регистрам работает не с одной таблицей, как это ожидал бы человек, знающий «правильный SQL», а с двумя таблицами сразу — таблицей итогов и таблицей движений. Которые на прикладном уровне видны как единое целое.oleg_shishkin
25.08.2017 14:10Еще раз повторю — эту надстройку писал я — и я сопостовлял все объекты 1С видимые пользователю с реальными таблицами БД. И то безобразие, которое творилось с реальной БД — повергло бы в шок любого специалиста по реляционным БД. Просто я помогал реальным людям-конфигураторам 1С ускорять в ДЕСЯТКИ раз их скрипты — зная всю подноготную 1С
amambaru
25.08.2017 14:17ОК. Я верю что вы круче инженеров 1С.
Так как любые узкоспециализированные запросы будут эффективнее универсальных.
Не пользовался вашей разработкой на V8
Умею писать быстро на 1С V8 без прямых запросов.
На V77 пользовался подобной вещью. Сейчас это не нужно уже.
Однако, допускаю, что многим ваша разработка нужна и полезна.oleg_shishkin
25.08.2017 14:28Вы просто не видели и никогда не использовали крутые инструменты — и это не ваша беда. Например в свое время лучшим инструментом для 4G разработки SQL был PowerBuilder. Это просто небо и земля по сравнению с 1С — и мне удосужилось видеть разработки — копии по функциональности с 1С — но которые работают в десятки раз быстрее. Потому что и были правильно спроектированы и сам инструмент позволял в разы больше чем 1С. И писали его люди, которые не один год окучивали огород 1С
amambaru
25.08.2017 15:53Дайте угадаю: но любой новый чих закона поддерживать начинали только через полгода?
oleg_shishkin
25.08.2017 13:571C — это попытка натянуть объектную(сущностную) модель данных на реляционное хранилище данных. И попытка полностью провальная. Но качество любого продукта никогда не коррелируется с его продажами. Это две разные вещи. Как например процессоры Intel и процессоры Vax машин. Как операционная система Windows и OS/2 или VMS
amambaru
25.08.2017 14:12Да ладно вам.
С тех пор как ввели сервер в 1С — объектная модель стала хорошо работать с реляционными БД.
Объектная модель плохо ложится на реляционные БД, когда есть наследование. Без наследование — несовместимость минимальная.
kmg4e
24.08.2017 17:19Это как отличие техника от инженера.
Техник следует инструкциям (по крайней мере должен следовать, инициатива техника крайне нежелательна).
Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.
На Западе в этом очень четкое деление.
У нас — страна левшей, потому не столь очевидно.
Однако, отсуствие культуры техников в нашей стране есть не гуд для производительности труда.SystemFault
24.08.2017 18:01Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.
Задача «чистого» инженера — решить поставленную задачу, комбинируя известные и хорошо опробованные технологии. Как у архитектора — построить дом с заданными параметрами, используя материалы с известными характеристиками. Сложность в том чтобы правильно согласовать все между собой, выполнив все требования.
А изучение чего-то принципиально нового — скорее задача для научного сотрудника. Конечно, инженеры часто занимаются и НИОКР — не сказал бы что это плохо. Но в некоторых отраслях «инициатива» (стремление использовать что-то новое, нестандартное, свое) инженера не то что нежелательна, а даже наказуема.kmg4e
24.08.2017 18:23Но в некоторых отраслях «инициатива» (стремление использовать что-то новое, нестандартное, свое) инженера не то что нежелательна, а даже наказуема.
В ИТ это не так.
В ИТ как раз задача engeneer исследовать те или иные проблемы, в том числе.
Я как то работал в канадской компании, нам там старший разработчик так и говорил, когда у команды были затруднение — «вы же ребята инженеры, как вам не стыдно найти решение, тем более что исследования оплачиваются за счет фирмы»
VolCh
24.08.2017 23:27+1Задача "чистого" инженера — предоставить оптимальное по технико-экономическим параметрам техническое решение бизнес-задачи. Будет в решении много НИОКР или будет лишь композиция уже известных решений — это его область отвественности. "Инициатива" тут скорее будет в предложениях бизнесу решить бизнес-задачу не техническими, а, например, административными методами. Или наоборот.
VolCh
24.08.2017 23:23Почему "как"? По российскому классификатору есть техник-программист — выпускник техникума в общем случае, — и инженер-программист — выпускник вуза. По программам подготовки можно точно сказать, что первый "заточен" на решение технических задач ("должен следовать инструкции" — перегиб палки, в целом хорошему технику и архитектуру довольно сложной системы доверить можно), а второй — на решение бизнес-задач путем постановки и решения технических.
evocatus
24.08.2017 16:35+2Возможно, именно поэтому многих так раздражают проповедники Agile, Роберт Мартин и пр.
Они предлагают всем строго следовать добродетелям дельца (возможно, даже с некоторым уклоном в линейного программиста)
devalone
24.08.2017 17:07-1Идея делить людей на несколько категорий изначально бессмысленна, зачастую в человеке смешано много разных черт и нет какого-то определённого типа
SystemFault
24.08.2017 17:28+3Интересная классификация. Мне кажется разделение здесь основано на мотивации:
Линейный — остаться в зоне комфорта минимальными усилиями, интроверт.
РокСтар — удовлетворить собственное любопытство в сфере, профильной деятельности компании.
Делец — максимальная выгода минимальными усилиями.
Пассажир — остаться в зоне комфорта минимальными усилиями, экстраверт.
Поясню про «зону комфорта». В отношении работы, оставаться в зоне комфорта — значит выполнять возложенные на тебя обязательства и получать за это материальные и моральные/репутационные плюшки.
Линейный выполняет обязательства (выполняет работу в срок, учит новые технологии), не требуя взамен ничего сверх положенного и стараясь не перетруждаться.
Пассажир идет на диалог, стремясь во-первых получить больше нематериальных плюшек (ему общение в радость), а во-вторых уменьшить обязательства (уболтать того, кто эти обязательства определяет либо переложить часть работы на других).
ra2003
24.08.2017 17:34Биг спс автору. Являюсь по факту пассажиром в АйТи (не соответствует классификации автора, а как признак полного непрофа, спец из другой отрасли — info b2b). Моя классификация много проще (повторюсь, чайник в IT, но разбор двойников телефонов пришлось самому написать): кодер(=линейный), топ кодер с наличием хорошей соображалки (=рокстар), понторез-разводчик (обычно много разных красивых дипломов и курсов, кол-во реального кода близко к нулю, близок к дельцу с понтами и без кода), тестер ПО, джуниор + начинающий кодер(чайник) по необходимости вынужденный кодить. Так же заметил особенность, что с 95-99% из отрасли IT (программирование) бывает сложно коммуницировать и пускать на коммуникацию с клиентами (люди в себе и в коде), может это только у меня так, а в целом по статистике не показательно. И по моей статистике в любой отрасли (не только в программинге) реальных профи (супер разлива) в районе 1-3%.
Zakyann
24.08.2017 20:48Интересно, спасибо. Замечу, что классификация ограничена наёмными работниками. Что не всегда так.
oleg_shishkin
25.08.2017 12:55+1Еще маленькое замечание. Наверное для умного руководителя не столько важна данная градация, сколько динамика движения коллектива и главное НАПРАВЛЕНИЕ(ВЕКТОР) движения коллектива. Наверно многие согласятся (а может и нет), что выбранный типаж может двигаться только к своим соседским типажам (хотя двигаться в сторону Порождающего типажа намного сложнее. Например Рок звезды — порождающий типаж к Линейщикам, поэтому с возрастом Рок звездам легче перейти в линейщики. И наоборот двигаться Линейщикам в сторону рок звезд едва ли возможно :) Дальние переходы возможны, но это как сказать — ломать карму :)
Evil_Punker
25.08.2017 16:36Я правильно понимаю, что классификация производилась без привлечения статистики и унифицированного опросника? Как проводили оценку мотивации — по валидной методике или личным мнением?
pnovikov Автор
25.08.2017 16:38Вы перечислили кучу способов составления таких классификаций исключая, собсно, общение и работу непосредственно бок о бок с испытуемыми людьми. Мне кажется здесь что-то не так...
Evil_Punker
25.08.2017 17:13Наблюдение в психологии — хороший метод сбора первичной информации. Для вашей классификации можно было фиксировать поведенческие акты. Накопив достаточное количество — провести кластерный анализ (статистика!), если выявлены четкие однородные группы, то можно их описать. Параллельно можно собирать сведения о «бэкграунде» и мотивации. Вполне достойное исследования уровня дипломной работы.
Идея-то отличная. Если она работает, то сужает перечень рассматриваемых качеств кандидатов. Это снижает риски неудачного подбора из-за неподходящего сценария взаимодействия сотрудника и работодателя. Повышает результативность и общую удовлетворенность.
Есть отличные пример подобной работы — модель командных ролей Белбина.pnovikov Автор
25.08.2017 17:45Это отлично. Однако еще раз — я не психолог-исследователь, я — разработчик и время от времени управляю командами. У меня нет ни времени ни ресурсов ни интереса проводить полномасштабное исследование.
w1ld
25.08.2017 19:47+1Понравилась статья. Для руководителей скорее подходит, для решения кадровых вопросов. Для программиста она полезна, разве что, осознанием своего типажа и соответственно своих возможностей и соответствующей компенсации. Можно типажи еще описать на основании реальных стремлений: к комфорту, к открытиям, к деньгам, к общению. Но так это, не думаю, что будет полным перечнем. Например, вот куда поставить тех, кто разрабатывает только опен сорс, т.е. какие-то альтруисты.
Luc6
26.08.2017 14:15+1Интересное чтиво, спасибо. Но чем-то напоминает типы личности Майер-Бриггс, надеюсь никто не будет это использовать на работе)
Daddy_Cool
27.08.2017 18:02Веселая классификация!
Я работаю в науке — у нас переизбыток чистых Рок-Стар — три штуки в лаборатории. )))
Есть смесь дельца с пассажиром — собирается увольняться.
Ну и наиболее адекватные — смесь линейщика с рок-стар.
«типы личности Майер-Бриггс,» — сюда же соционику. Как правило оно связано — т.е. вполне можно найти соответствие, но… скажем «пассажир» — это более социальное явление как мне кажется. Наш лабораторный «пассажир» по идее мог бы очень хорошо работать в науке — но… его мотивы где-то в другом месте.
alexeykuzmin0
28.08.2017 11:53Чего спрашивать не стоит: алгоритмические вопросы, математика
А почему? Казалось бы, делец с его мотивацией заработать все деньги мира в первую очередь хорошенько разберётся в том, что часто спрашивают на собеседованиях (то есть, как раз эти темы). А если он их хорошо знает — с чего бы ему не радоваться возможности показать себя с хорошей стороны?
Markscheider
Статья годная, спасибо. От себя добавлю, что аналогичное деление на типажи имеет место не только в IT-среде. В процессе чтения лично я узнал в описаниях многих своих друзей и коллег (ни разу не программистов).
Kaigorodov
А мне кажется, что человек написавший такую статью принадлежит к 4-й категории.
QASANDR
«Кто не умеет работать — учит»?