Comments 548
Статья годная, спасибо. От себя добавлю, что аналогичное деление на типажи имеет место не только в IT-среде. В процессе чтения лично я узнал в описаниях многих своих друзей и коллег (ни разу не программистов).
Любопытная статья. Спасибо!
Но опять же не стоит забывать, что люди всегда смешивают в себе разные черты и кроме ярких представителей есть и смешанные типы.
Я бы сказал, что все мы по большей части, все-таки, склонны относить себя к дельцам, так как большее количество «привлекательных» совпадений описывается именно в этой категории.
Для себя выделил очень много совпадений, узнаваемых как в себе (как мне кажется), так и в большинстве знакомых, конечно хотелось бы, чтоб это кто-нибудь со стороны подтвердил: -«да ты определенно делец, редкий брыльант», но на деле не имеет значения к какому типу человек себя хочет относить. Мы те кто мы есть, всегда хотим большего, оставаясь при этом абсолютно линейными, всегда требуем надлежащего отношения к себе и хорошего вознаграждение своих трудов, нас всех довольно сильно раздражает не компетентность окружающих людей (особенно если приходится напрямую с ними взаимодействовать), все мы хотим стать самостоятельными и предприимчивыми, и это далеко не редкость.
Абсолютно согласен, что для каждого человека можно выделить некий уникальный, смешанный, промежуточный тип. Причем этот набор человеческих качеств закладывается еще в детстве: темперамент, воспитание, тип личности (интроверт, экстраверт), все это напрямую влияет на показатель коммуникабельности и стресоустоичивости. Также есть некие приобретаемые параметры, ограниченные лишь усидчивостью, восприятием действительности, и интересом к обучению в конкретной технической области.
И конечно каждый, все равно предпочитает держать под рукой Гугл (обобщил, не хотел задеть чувства любителей Яндекса), какой бы большой ходячей энциклопедией он не был (как мне кажется, это относится даже к Rock star). =)
Для себя выделил очень много совпадений, узнаваемых как в себе (как мне кажется), так и в большинстве знакомых, конечно хотелось бы, чтоб это кто-нибудь со стороны подтвердил: -«да ты определенно делец, редкий брыльант», но на деле не имеет значения к какому типу человек себя хочет относить. Мы те кто мы есть, всегда хотим большего, оставаясь при этом абсолютно линейными, всегда требуем надлежащего отношения к себе и хорошего вознаграждение своих трудов, нас всех довольно сильно раздражает не компетентность окружающих людей (особенно если приходится напрямую с ними взаимодействовать), все мы хотим стать самостоятельными и предприимчивыми, и это далеко не редкость.
Абсолютно согласен, что для каждого человека можно выделить некий уникальный, смешанный, промежуточный тип. Причем этот набор человеческих качеств закладывается еще в детстве: темперамент, воспитание, тип личности (интроверт, экстраверт), все это напрямую влияет на показатель коммуникабельности и стресоустоичивости. Также есть некие приобретаемые параметры, ограниченные лишь усидчивостью, восприятием действительности, и интересом к обучению в конкретной технической области.
И конечно каждый, все равно предпочитает держать под рукой Гугл (обобщил, не хотел задеть чувства любителей Яндекса), какой бы большой ходячей энциклопедией он не был (как мне кажется, это относится даже к Rock star). =)
Разница между rock star и дельцом при гуглении в том, что rock star откроет ссылку, оканчивающуюся на .edu, или какой-нибудь научный .pdf и поймет суть формул. Делец же сконцентрируется на поиске куска кода и поиска описания зачем эта формула и как её юзать в прикладных задачах.
Я бы сказал, что все мы по большей части, все-таки, склонны относить себя к дельцам, так как большее количество «привлекательных» совпадений описывается именно в этой категории.
Собственное восприятие разных людей тоже разное. Далеко не все черты, описанные в категприи делец безусловно привлекательны. Поэтому отнюдь не все себя будут к дельцам относить.
Спасибо, прочитал на одном дыхании, очень интересно и поучительно) Я походу дела смесь линейного и дельца, т.к. если меня мотивируют деньгами — я горы сверну)
Правильно подмечено, человека со 100% одного типажа не бывает.
Хорошая статья. Узнал себя в некоторых местах.
Хорошая статья. Узнал себя в некоторых местах.
А как происходил процесс «утряски» всей информации? Как удалось минимизировать влияние ну хотя бы таких когнитивных искажений, как иллюзия кластеризации,
иллюзорная корреляция, стереотипизация, эффект ожидания наблюдателя? Спасибо.
иллюзорная корреляция, стереотипизация, эффект ожидания наблюдателя? Спасибо.
Я просто долго пытался понять как охарактеризовать людей, с которыми я бы хотел работать. И как их отделить от всех остальных. У меня нет иллюзии кластеризации, поэтому я постарался не то, чтобы сказать "есть вот такие и других нет", а скорее выставить некие опорные точки для определения типажей. Ну и плюс анализировал кейсы, с которыми столкнулся… дайте подумать… за 7 лет :) Ну например я знал каких-то людей 7 лет назад и посмотрел как они начинали и где они сейчас. Взял бы я их в нашу команду или нет? А если бы взял — то что спросил бы? Говорил, задавал вопросы, получал ответы. Да, я сам не люблю всяческие кластеризации, но если сталкиваешься с задачей подбора персонала — то для ускорения процесса лучше иметь некоторые ориентиры, чтобы хотя бы понимать чего хотеть и какие сочетания рассматривать априорно бесперспективно.
Как минимизировать влияние не знаю. Правда :) Я просто систематизировал заново и заново, покуда не пришел к системе, в которую укладываются решительно все, кого я знаю (а знаю я много). Если честно, этой классификации не хватает "второго измерения", но пока что и так сойдет.
Иллюзия отсутствия иллюзий — еще одна иллюзия :) Шучу.
Спасибо за развернутый ответ. В сущности вопрос скорее насколько применимо это все, скажем, в другом городе/стране или в каких-то специфически направленных конторах? Ну и себя, как водится, я никуда не могу отнести. Разве что не балагур, но всему можно научиться, было бы время и желание.
Спасибо за развернутый ответ. В сущности вопрос скорее насколько применимо это все, скажем, в другом городе/стране или в каких-то специфически направленных конторах? Ну и себя, как водится, я никуда не могу отнести. Разве что не балагур, но всему можно научиться, было бы время и желание.
сразу что-то стало напоминать. конечно с натяжкой, но подходит:
1. меланхолик
2. сангвиник
3. флегматик
4. холерик
1. меланхолик
2. сангвиник
3. флегматик
4. холерик
А полноту классификации сможете обосновать?
Нет, и я вам больше скажу: классификация не полна, так как есть куча людей, находящихся в переходных стадиях с разными показателями, например стрессоустойчивости. Эта классификация создана не для того, чтобы сказать "есть вот такие, а других нет", а для того чтобы тезисно обозначить чего стоит ожидать от определенных типажей а чего от них ожидать не стоит, как их распознать и как с ними эффективно работать. Так же неплохо подходит для определения "кто же нам все-таки нужен?" и концептуального понимания какие качества могут сочетаться в человеке, а какие — нет.
Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вижу противоречие
Нет, и я вам больше скажу: классификация не полна,
А еще по моему мнению существует отдельная группа, в которой можно наделать множество подгрупп — «люди которых не надо брать в ИТ».
Для наглядности представьте на секунду, что быть боксером стало бы в одночасье также круто как и программистом. Хорошие офисы с плюшками, зп выше чем в среднем в вашем городе, да и в целом гордо звучит. А самое главное можно всего пару месяцев позаниматься с тренером и вас уже готовы взять. И вот толпы людей, которых ни жизнь ни природа к этому не готовила уже строчат свои резюме и начинают ходить по собеседованиям.
Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вам это утверждение не кажется несколько неточным?
Дорогой друг, мой тезис — провокационный, признаюсь :) Однако, если быть предельно точным и упоминать все формальности, то заголовок статьи был бы не "Четыре типажа программистов", а "Ориентировочные точки для идентификации типажей программистов, предусматривающие промежуточные состояния" и по содержанию напоминал бы скорее научное исследование (тут бы у меня еще выкладок попросили, ага). И тогда бы её никто не прочел, ибо как целевая аудитория (HR, управленцы и сами программисты) не имеет достаточно времени на чтение тонн подобной лабуды, а еще с успехом ломает об неё мозг. И смысл статьи бы сводился к "ну вы знаете, тут куча возможных комбинаций — так что думайте сами", что не несет в себе никакого практически применимого смысла. Очень хорошо, что вы заметили эту неточность, но. Я не отрицаю что реальная жизнь во много раз сложнее и многограннее чем "4 типажа". Но понимаете в чем штука — подобные классификации не строятся с целью включить туда все-все-все возможные на планете случаи, а подобные статьи нарочито не носят научный характер. Они строятся, как упрощенная модель, дабы простым языком донести до компаний, менеджеров и HR-ов хоть немного понимания о том, какие программисты вообще бывают и с чем их надо употреблять. А так же в статье — о ужас — присутствует сугубо пропагандистская составляющая — призвать хоть немного упорядочить сумбур компаний в наборе кадров (нам нужен самый лучший рокстар, ага), не нанимать высококвалифицированных программистов, когда можно обойтись линейными — равно как и не пытаться решить научную задачу силами пассажиров. Вы удивитесь, но просто потрясающее количество людей, ответственных за найм, реально, искренне не понимает как идентифицировать человека, сидящего перед ними, но самое печальное обстоятельство состоит в том, что компании не могут для себя четко решить кто же все-таки им нужен. Отсюда и рождаются вопросы про люки и мячики, когда по факту компании требуется пилить аутсорс. И эта статья — быстрый и краткий "крэш-курс", который может дать хотя бы отправную точку кто существует на рынке, чего он ожидает от работодателя и как с ним строить разговор. Sapienti sat — дальше сами разберутся, мне кажется.
Я хотел донести немного другую мысль.
Наверное она больше для другой статьи, например с названием 10 признаков непрограммиста, которую я бы с интересом прочитал.
Я не слишком опытен в найме сотрудников, и вот из личного опыта понял, что достоинства и область применения сотрудников определить не единственно важное.
Я бы сказал, что прежде всего нужно понять, а хочет ли он работать в ИТ или это просто стечение обстоятельств или вовсе не его решение( о да, один сотрудник нисколько не смущаясь сказал, что он программист потому, что жена так сказала).
Работа с такими людьми это боль.
Если кто-нибудь раскроет мне тайны ранней диагностики таких кандидатов, я буду счастлив. В реальности это становится понятным только спустя пару месяцев и пяток приватных бесед.
Наверное она больше для другой статьи, например с названием 10 признаков непрограммиста, которую я бы с интересом прочитал.
Я не слишком опытен в найме сотрудников, и вот из личного опыта понял, что достоинства и область применения сотрудников определить не единственно важное.
Я бы сказал, что прежде всего нужно понять, а хочет ли он работать в ИТ или это просто стечение обстоятельств или вовсе не его решение( о да, один сотрудник нисколько не смущаясь сказал, что он программист потому, что жена так сказала).
Работа с такими людьми это боль.
Если кто-нибудь раскроет мне тайны ранней диагностики таких кандидатов, я буду счастлив. В реальности это становится понятным только спустя пару месяцев и пяток приватных бесед.
Эмм… ну я предлагаю например… кхм… Просто спросить почему человек пошел в IT :) Нет? Вроде должно работать.
Нет.
Никто на собеседовании не скажет, что ему нравится идея быть программистом, нравится зарплата программиста, или что он разочаровался в профессии и ему просто нужно платить за ипотеку, а работы он давно уже ненавидит.
Никто на собеседовании не скажет, что ему нравится идея быть программистом, нравится зарплата программиста, или что он разочаровался в профессии и ему просто нужно платить за ипотеку, а работы он давно уже ненавидит.
Никто на собеседовании не скажет, что ему нравится идея быть программистом
А я честно ответила бы, что меня так впечатлили уроки Turbo Pascal в школе, что я непременно решила пойти в IT.
Тут немного же о другом, это вы с ранних лет поняли что хотите стать программистом и это здорово. Но будь у вас ипотека (приманила в ИТ именно зп) и пройденные онлайн курсы, не думаю что такая правда бы понравилась бы работодателю
В этом и разница.
Вам понравился turbo pascal в школе, после этого наверное были другие языки, алгоритмы и крутые штуки.
А есть те кому это все безразлично. Кто-то закончив вуз открыл hh и выбрал то, где больше платят. Или поработав 10 лет в профессии в которой опытный специалист получает меньше чем джуниор решил тоже этим заняться. Да есть те кто смог, и к ним никаких вопросов.
Но также есть и достаточно большая аудиториях тех, кто в программистах вопреки своим желаниям и\или способностям.
В этой статье я вижу посыл, любому человека с резюме программиста можно найти применение. ИМХО — нет.
Вам понравился turbo pascal в школе, после этого наверное были другие языки, алгоритмы и крутые штуки.
А есть те кому это все безразлично. Кто-то закончив вуз открыл hh и выбрал то, где больше платят. Или поработав 10 лет в профессии в которой опытный специалист получает меньше чем джуниор решил тоже этим заняться. Да есть те кто смог, и к ним никаких вопросов.
Но также есть и достаточно большая аудиториях тех, кто в программистах вопреки своим желаниям и\или способностям.
В этой статье я вижу посыл, любому человека с резюме программиста можно найти применение. ИМХО — нет.
А я честно ответила бы, что меня так впечатлили уроки Turbo Pascal в школе, что я непременно решила пойти в IT
А что именно?
У меня сейчас дочь начинает.
Попытался заинтересовать её написанием игр на Паскале, — что-то не вижу интереса. Хотя она говорит, что хочет быть программистом.
А я вот считаю что если работодатель адекватный, а не косит под недостартап и не носит розовые очки — то финансовую мотивацию он прекрасно поймет. И честно ответит "хочешь денег — не вопрос — помоги заработать нам и мы поможем заработать тебе".
Вот только из моего опыта, компании на собеседованиях как правило пытаются показаться лучше, чем они есть.
Деньги не решают всех задач к сожалению.
Человеческая мотивация имеет гораздо более сложную механику нежели купюроприемник.
Человеческая мотивация имеет гораздо более сложную механику нежели купюроприемник.
Да, но понимаете, "деньги не решают всех проблем" — это фраза не для собеседования. Лучше говорить это не при приеме человека на работу, а когда он уже у вас отработал, сделал много полезного, получил пару повышений и ему мало. Как-то так.
Делец с вами не согласится
Возможно согласится, но либо когда он мотивирует, а не го, либо, когда затрагиваются более базовые потребности, чем материальный достаток.
Делец с вами не согласится
Согласится. Нормальный делец должен видеть границы, за которыми он уже не выдаст результат, сколько бы бабла ему не обещали.
Иначе как тех. профи — он недостаточно хорош.
Деньги это отсекающий фактор, иногда разговариваешь и думаешь да это то что тебе будет интересно, но они предлагают заведомо меньше чем тебе хватит чтобы не думать каждый день о том, а может и не настолько нравиться насколько не до получил.
Я говорю что в IT было больше возможностей для быстрого заработка чем по моей специальности.
Ну почему же всегда рассказывал когда спрашивали почему попал в отрасль и какие были предпосылки.
Вы на мой взгляд слишком идеализирует профессию, для большинства людей есть различия между работой и хобби и в нашем мире приходится признавать что хобби не часто может быть работой обеспечивающей потребности.
Если кто-нибудь раскроет мне тайны ранней диагностики таких кандидатов, я буду счастлив. В реальности это становится понятным только спустя пару месяцев и пяток приватных бесед.
Собеседовал кандидатов по тех. вопросам. Уже после HR.
Беседую на разные темы — и чисто технически, и как была организована работа на прежнем месте и пр. и пр.
Минут за 40 выясняется очень и очень многое.
По негорящим/горящим глазам когда обсуждение проходит по разным темам.
Это нескромно, но мои ощущения были довольно точными.
Каждый раз когда сотрудников брали вопреки моим категорическим анти-рекомендациям — спустя пару месяцев их увольняли.
Если сможете формализовать свои ощущения с интересом почитаю, ибо у меня пока, что так не получается.
Я пытаюсь просто беседовать, узнать, что у нас в городе делают, в других фирмах. Какое ПО делают, какие большие или маленькие конторы работают и т.п.…
То есть просто примерно как как коллега с коллегой в курилке беседуют об их прошлых местах работы.
Тут главное разговор чтобы раскрутился, чтобы пошел.
Выясняется очень много интересного.
То есть просто примерно как как коллега с коллегой в курилке беседуют об их прошлых местах работы.
Тут главное разговор чтобы раскрутился, чтобы пошел.
Выясняется очень много интересного.
Я хочу в IT, возьмёте? Только я стар для новичка (по меркам отрасли). Без жены. Мне никто не говорит кем работать, кроме рынка…
Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения.
Вам это утверждение не кажется несколько неточным?
В литературе часто встречаются классификации типажей боксёров. Давно ничего такого не читал, боюсь наврать в деталях, но, вроде бы есть термин «puncher» для боксёра, который умеет только бить и в бою полагается, в основном, на силу удара. Вроде бы, какие-то названия есть как для типажа, который вообще не очень умеет в бокс, но выезжает за счёт физической силы и выносливости, так и для типажа, который, наоборот, искусно защищается-юлит-финтит, вот это вот всё. И т. п.
Мой основной тезис: все боксеры, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Вам это утверждение не кажется несколько неточным?
Вы не поверите, но… https://en.wikipedia.org/wiki/Boxing_styles_and_technique. И именно 4 больших типажа. :D
А как вы назовете боксера, которому нравятся боксерские перчатки и шорты, но которому не нравится драться на ринге? Это какой стиль?
По моему мнению в айти сейчас имеются именно такие люди.
PS: Чертовы метафоры. Кажется вот ты приводишь идеальное сравнение чтобы все стало понятно, но нет все становиться еще запутаннее.
По моему мнению в айти сейчас имеются именно такие люди.
PS: Чертовы метафоры. Кажется вот ты приводишь идеальное сравнение чтобы все стало понятно, но нет все становиться еще запутаннее.
Я вас понял… Но это, наверное, другая классификация.
Ведь можно пойти в программисты из-за желания мамы / мечты о больших деньгах / случайно / за компанию, но стать хорошим программистом (скажем, линейным) и работать, выполнять задачи…
То, что человек не любит программировать — не значит, что он не может делать это хорошо… (А вы считаете, что нет)
А плохой программист не обязательно пришёл за деньгами /лаврами / и т.д.
Ему вполне может нравиться программирование, но у него не выходит хорошо (и такие тоже есть)
p.s. В вашей метафоре — неизвестен стиль боксёра, нужно на ринге смотреть…
Ведь можно пойти в программисты из-за желания мамы / мечты о больших деньгах / случайно / за компанию, но стать хорошим программистом (скажем, линейным) и работать, выполнять задачи…
То, что человек не любит программировать — не значит, что он не может делать это хорошо… (А вы считаете, что нет)
А плохой программист не обязательно пришёл за деньгами /лаврами / и т.д.
Ему вполне может нравиться программирование, но у него не выходит хорошо (и такие тоже есть)
p.s. В вашей метафоре — неизвестен стиль боксёра, нужно на ринге смотреть…
Я говорю о наболевшем из личного опыта.
Приходят ребята на собеседования, с нормальным резюме и в целом не сыпятся на техническом интервью.
А потом ты начинаешь с ним работать, и понимаешь, что человек не выполняет и половины объема работы которые мог бы.
Начинаешь с ним много общаться, пытаешься выяснить, что не так.
И приходишь в итоге к мысли, что человек просто не на своем месте и работа от него требует собственных сверх усилий.
По формальным признакам его можно однозначно причислить к одной их категорий автора. Но проблема в том, что ИТ просто не его.
Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.
Я бы предпочел никогда не брать таких людей на работу.
Приходят ребята на собеседования, с нормальным резюме и в целом не сыпятся на техническом интервью.
А потом ты начинаешь с ним работать, и понимаешь, что человек не выполняет и половины объема работы которые мог бы.
Начинаешь с ним много общаться, пытаешься выяснить, что не так.
И приходишь в итоге к мысли, что человек просто не на своем месте и работа от него требует собственных сверх усилий.
По формальным признакам его можно однозначно причислить к одной их категорий автора. Но проблема в том, что ИТ просто не его.
Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.
Я бы предпочел никогда не брать таких людей на работу.
Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.А из тех кто способен признаться — дай бог 1% способен решиться и сменить сферу деятельности.
Никто или мало кто способен признаться, что n-лет назад он занялся не своим делом.А некоторые даже и не знают, что бывает «своё дело» и просто работают (как-нибудь)…
Ваше описание подходит под большинство профессий. И это действительно проблема, но это проблема не it. Это проблема выбора профессии, осознанности, ответственности и т.д.
Приходят ребята на собеседования, с нормальным резюме и в целом не сыпятся на техническом интервью.
Ну это только всего лишь один из показателей, надо же еще оценивать не только техническую сторону, но и человеческую, ведь из хобби человека можно много чего подчерпнуть о его характере.
А кассир в супермаркете — это призвание? Я конечно намеренно утрирую, но мне кажется, что наша отрасль стремительно меняется: раньше в it шли действительно только гики. Сейчас объективно гиков не хватает для удовлетворения потребностей рынка. Спрос рождает предложение. Видимо, старичкам нужно учиться работать и с теми, для кого it — не призвание, а средство заработка.
Хороший пример.
Я думаю, что есть профессии в которых можно работать, даже не по призванию.
Это профессии в которых разница между «как-то решить задачу» и «хорошо решить задачу» ничтожно мала.
Вот в ит разница грандиозна, а кассир, если не вдаваться в гиперболы, то лучший от худшего отличается не так уж и сильно.
Я думаю, что есть профессии в которых можно работать, даже не по призванию.
Это профессии в которых разница между «как-то решить задачу» и «хорошо решить задачу» ничтожно мала.
Вот в ит разница грандиозна, а кассир, если не вдаваться в гиперболы, то лучший от худшего отличается не так уж и сильно.
Вот в ит разница грандиозна
По-моему, подобные утверждения являются излишней элитизацией "тру-айтишников". Бизнес, заказчика обычно интересует именно решение задачи, грубо — прохождение приемочных тестов как можно быстрее и дешевле с момент апостановки задачи. Внутренняя красота и чистота кода, оптимизации и прочее обычно начинает интересовать только когда основная задача уже решена и начинается промышленная эксплуатация.
Речь не про элитность, а про сложность.
Возможность тестов и приемки ограничена. Слишком много нюансов и вариантов.
Когда вы можете однозначно оценить качество работы численными, формальными параметрами проблем нет.
Грубо говоря если бы у программиста был применим kpi в виде напечатанных символов, разницы с кассиром для которого kpi в виде обслуженные клиентов вполне приемлем, не было бы.
Речь не про элитность, исключительно сложность.
Возможность тестов и приемки ограничена. Слишком много нюансов и вариантов.
Когда вы можете однозначно оценить качество работы численными, формальными параметрами проблем нет.
Грубо говоря если бы у программиста был применим kpi в виде напечатанных символов, разницы с кассиром для которого kpi в виде обслуженные клиентов вполне приемлем, не было бы.
Речь не про элитность, исключительно сложность.
Большинство реальных ИТ-задач большинство программистов функционально решить в состоянии, пускай и в стиле "write only code". Квалификация рядового программиста выражается в качестве, в нефункциональных метриках, предоставляемых им решений.
Большинство реальных ИТ-задач большинство программистов функционально решить в состоянии, пускай и в стиле «write only code».Ну вот собственно туда и можно набирать «поточников» за три копейки. Но есть много вещей, которые «большинство программистов» функционально решить НЕ в состоянии. Скажем написать хоть какой-нибудь компилятор. Или ядро OS. Или даже банальную библиотеку для декодирования видео в реал-тайм.
Если нет конкретных требований по памяти, CPU и проч. и проч., то это под силу практически любому желающему за 3 коп., но получится дико плохо и тормозно… Нету же конкретных требований? Компилятор? Какой-нибудь? Почему нет? Все знают _примерно_, как делают компиляторы. Но надо ж все это спроектировать нормально, сделать, чтобы летало и не падало и проч. и проч. В этом же загвоздка, так?
По-моему, подобные утверждения являются излишней элитизацией «тру-айтишников»Причём тут «тру-айтишники»? Та же самая ситиуация существует с авиа- и автоконструкторами, модельерами и архитекторами. Всегда, когда один человек клияет на то, что будет с тысячами (а иногда и миллионами, миллардами!) людей — возникает эта проблема.
IT обладает важным отличием: проект двухэтожного особняка для Васи Пупкина никто не будет переделывать в проект комплексной застройки Пекина — а в IT подобное происходит регулярно.
"авиа- и автоконструкторами" сложность выхода на нормальный уровень дохода несравнима (собственный опыт 10 лет назад и опыт тех кто остался на тек. момент), в ИТ гораздо проще(время/нагрузка) для одного и тогоже человека выйти на нормальный уровень дохода (понятно что кому-то не дано но в среднем разница в доступности ИТ для конструкторов и прикладных математиков сравнима)
А как вы назовете боксера, которому нравятся боксерские перчатки и шорты, но которому не нравится драться на ринге? Это какой стиль?
Мы не будем называть его боксером.
Это будет или «спортивный стиль одежды».
Или просто перчатки как сувенир, висящие на стене, как украшение комнаты — «спортивный стиль оформления квартиры»
Есть тут еще кто-нибудь, работавший в сфере рекрутинга (помимо автора)? Интересует, к какому типу чаще всего относятся девушки-программисты и насколько часто вам попадались девушки каждого из типов.
По моему опыту (17 лет фулл тайм, отсобеседовал под сотню кандидатов), было примерно поровну программисток — линейных, rock star и пассажирок, дельцов было очень мало.
На фриоансе их больше
Это какая-то совершенно нерелевантная статистика (безотносительно к полу), если только вы все это время не собеседовали кандидатов целенаправленно на должности для rock stars. Их должны быть считанные единицы (просто по определению), а основной поток — линейные/пассажиры.
Последние 10 лет собеседую на позиции, где надо понимать, как работают внутренности процессора, платформы и операционки, и уметь быстро находить причины ухудшения производительности в больших и незнакомых проектах.
основной поток — линейные/пассажиры.
;)
Вовсе нет.
Основной поток — процентов 80% называется «страшный шлак».
Но, что удивительно, этот шлак где-то работал программистом до этого и где то будет работать, когда не пройдет мое собеседование.
Из оставшихся:
Линейных много больше всех.
Пассажиров примерно сопоставимо по количеству по сравнению с количеством дельцов и рок-звезд
Лихо вы людей не прошедших ваше собеседование назвали. Как можно судить о возможностях человека не поработав с ним. Есть люди которые тупо не умеют проходить собеседования, а есть те кто их пройдет но работать будет хуже, чем никак.
Вполне.
Я вот собеседовал админов: достойная по городу зарплата, одно из требований стояло «администрирование Linux, командная строка, не GUI»
Как назвать того, кто приходит на такую вакансию и не знает зачем одновременно с IP-адресом самого компьютера в настройках ОС нужно задавать еще и IP-адрес шлюза.
И таких было процентов 80%.
Вы думаете их следовало бы принять на работу, полгода выяснять квалификацию?
Шлак он и есть шлак. Его сразу видно.
Я вот собеседовал админов: достойная по городу зарплата, одно из требований стояло «администрирование Linux, командная строка, не GUI»
Как назвать того, кто приходит на такую вакансию и не знает зачем одновременно с IP-адресом самого компьютера в настройках ОС нужно задавать еще и IP-адрес шлюза.
И таких было процентов 80%.
Вы думаете их следовало бы принять на работу, полгода выяснять квалификацию?
Шлак он и есть шлак. Его сразу видно.
"Страшного шлака" — далеко не 80%, если смотреть среди всех программистов, а не только среди безработных.
Есть такой эффект: чем хуже программист программирует — тем меньше он работает и тем чаще он ходит по собеседованиям. :-)
… и тем лучше он их проходит =)
Не завидуйте. Таких берут или из желания сэкономить.
Или они проходят в неспециализирующиеся на ИТ конторы, в конторы со слабым ИТ-отделом — да, лучше проходит.
Например, ровно также как и пройдет «собеседование» с вами плохой специалист по шпаклевке помещений, которого вы наймете для ремонта своей квартиры. Не потому что вы дурак. Просто вы специалист в другой сфере.
Или они проходят в неспециализирующиеся на ИТ конторы, в конторы со слабым ИТ-отделом — да, лучше проходит.
Например, ровно также как и пройдет «собеседование» с вами плохой специалист по шпаклевке помещений, которого вы наймете для ремонта своей квартиры. Не потому что вы дурак. Просто вы специалист в другой сфере.
… и тем лучше он их проходит =)Мой опыт этого не подтверждает. Мои знакомые по собеседованиям ходят редко, раз в несколько лет, проходят десяток интервью, получают 3-4-5 офферов и выбирают среди них. В тоже же время на разных сайтах (да и хотя бы на Хабре — люди, посетившие буквально сотни компаний перед тем, как найти работу). Вот они и обеспечивают «90% шлака» на собеседованиях.
Так-то в среднем в отрасли вменяемых людей больше, чем невменяемых — но на собеседованиях, увы, наоборот.
Та же самая, что и с фильтров на кухне: так-то водопроводная вода не то, шоб уж совсем грязная, но прямо возле сетки фильтра — там жуткая муть. Так и было задумано, в общем-то, в обоих случаях — и в случае с фильтром и в случае с собеседованиями…
людей нельзя называть шлаком, независимо от уровня их квалификации.
Практически 95% попадут в первые две категории, две другие останутся почти пустыми.
Шикарная классификация. И не только программистов, ко всем айтишникам подойдет.
Всё это уже было в «Как пасти котов» (Ханк Рейнвотер). Причем там классификация более полная.
Прочитал про «пассажира» — сразу вспомнился Луо Йонгхао и его компания Smartisan.
Сам в бизнесе и технологиях разбирается явно не очень, переоценивает свою продукцию.
Зато как шоумен и представитель — просто огонь. Много ли мы знаем руководителей китайских небольших компаний? Да их там не сосчитать. А вот Йонгхао — многие знают. И про то, как он побеждал холодильники. И про то, как он для презентации смартфона арендовал крупнейший в Китае выставочный центр. И про то, как в кафе сосисками торговал, попутно продавая курсы английского языка и получая миллиардные инвестиции непонятно откуда. В общем, герой прогрессивной молодёжи.
Сам в бизнесе и технологиях разбирается явно не очень, переоценивает свою продукцию.
Зато как шоумен и представитель — просто огонь. Много ли мы знаем руководителей китайских небольших компаний? Да их там не сосчитать. А вот Йонгхао — многие знают. И про то, как он побеждал холодильники. И про то, как он для презентации смартфона арендовал крупнейший в Китае выставочный центр. И про то, как в кафе сосисками торговал, попутно продавая курсы английского языка и получая миллиардные инвестиции непонятно откуда. В общем, герой прогрессивной молодёжи.
Пожалуй, самый известный «пассажир» — Стив Джобс.
Пассажир и делец.
Пассажир и делец.
Скорее Илон Маск.
У детища Стива Джобса хоть прибыли сумашедшие и давным давно все окупилось.
Илон Маск — за счет инвесторов в основном существует.
У детища Стива Джобса хоть прибыли сумашедшие и давным давно все окупилось.
Илон Маск — за счет инвесторов в основном существует.
Во-первых Илон Маск совсем не умеет говорить и выступать — посмотрите его вживую — он косноязычен.
Во-вторых он сооснователь PayPal. Я не знаю каков был его вклад, но PayPal определённо успешен.
В-третьих, тот факт, что он занимается сейчас бизнесами, в которых очень трудно получить прибыль, не значит, что он типичный болтун-харизматик. Конечно, он не сам разрабатывает ракеты, автомобили и батареи, но нельзя не признавать за его компаниями высоких технических достижений, которые были бы невозможны без грамотного менеджмента.
Во-вторых он сооснователь PayPal. Я не знаю каков был его вклад, но PayPal определённо успешен.
В-третьих, тот факт, что он занимается сейчас бизнесами, в которых очень трудно получить прибыль, не значит, что он типичный болтун-харизматик. Конечно, он не сам разрабатывает ракеты, автомобили и батареи, но нельзя не признавать за его компаниями высоких технических достижений, которые были бы невозможны без грамотного менеджмента.
Это чисто ораторское искусство, без относительно того пассажир ты иль нет.
Если Маску дают такие деньги — значит, он достаточно хорошо умеет болтать с инвесторами.
После PayPal у него больше ничего не окупалось.
PayPal используется как раз как «пассажирская» замануха, да.
Если Маску дают такие деньги — значит, он достаточно хорошо умеет болтать с инвесторами.
После PayPal у него больше ничего не окупалось.
PayPal используется как раз как «пассажирская» замануха, да.
Конечно, он не сам разрабатывает ракеты, автомобили и батареи
Где-то я слышал, что в SpaceX именно он — главный инженер и именно за ним последнее слово в больших инженерных вопросах. Если правда, то он именно rock star по данной классификации, может быть с небольшим смещением в пассажира.
Стив Джобс ведь совсем не программист и никогда им не был.
Очень сомнительная у вас классификация и не очень полезная. Предпочтения или пофигизм к фруктам в офисе, уровень ответственности, коммуникабельности, какие вопросы на собеседовании ему не понравятся и т.п. никак не коррелирует с уровнем знаний программиста и стремлением к развитию. Это всё из разных категорий. И всё это, как мне показалось, у вас на фоне пренебрежительного отношения к людям. По моим наблюдениям, если человек употребляет слово «говнокод» по отношению к чужой работе в своей речи то скорее всего он окажется заносчивым идиотом
А что если там действительно говнокод?
Слово «говнокод» все понимают очень по разному. Строгое определение не найти в словаре Даля. Наверняка можно сказать одно: оно состоит из слов «говно» и «код». Последний раз, когда я общался с человеком, много рассуждающим о «говнокоде», так получилось, что я заказывал у него часть работ по проекту. Когда он мне прислал результат, его код обвалился сразу же при запуске. После моих замечаний и исправления первое же тестирование первого юзеркейса закончилось с ошибкой. Так было на каждом шагу работы с ним. Когда мы закончили через гораздо больше дней, чем я ожидал, я спросил его, считает ли он свой код «говнокодом»? Обиделся, видимо не считает. И это случай когда эти оба слова можно было бы применить к выполненной работе объективно. Когда люди рассуждают о чужом работающем коде, мне судить трудно. Конечно есть какие-то вещи, которые в любом коде делать не стоит, потому что это приведет к проблемам при работе с ним/ при отладке, но вот если человек тычет пальцем в чужой код со словами «говнокод» впечатления у меня об этом человеке неприятные. Я за то, чтобы использовать другие слова вместо этого. Когда человек рассуждает о вообще каком-то абстрактном коде, которого еще нет, или о другом программисте словом «говнокодит» для меня человек выглядит еще неприятнее
Я вас очень уважаю, но пожалуйста почитайте что такое технический долг. И не путайте его с функциональностью продукта. Спасибо.
Я вас тоже очень уважаю, но почему то слышится мне в вашем высказывании снисходительная интонация. Может быть мне показалось, простите. Я знаю, что такое технический долг. Но речь шла о смысле термина «говнокод» и его толковании, и я думаю, по смыслу составляющих его слов, им можно охарактеризовать и работоспособность продукта
Смысл термина говнокод, как я его имею в виду — код, который ухудшает поддерживаемость продукта, как я уже говорил. Работоспособность продукта можно характеризовать, не используя постфикс "код", если на то пошло :)
Хорошо, я теперь понимаю, что вы имели в виду и вы гораздо более приятный человек в общении, чем мне показалось после прочтения вашей статьи, извините
Забавно, но в моей практике говнокод писали как раз rock stars. Зная в совершенстве какой-либо язык программирования, они создавали впечатляющие штуки, используя самые хитроумные и эффективные конструкции, какие только могли придумать. Проблема была в том, что в результате получался абсолютно непонятный и неподдерживаемый код.
И да, из всех перечисленных в статье достоинств и недостатков rock stars следует вполне очевидный вывод — командная работа не для них.
И да, из всех перечисленных в статье достоинств и недостатков rock stars следует вполне очевидный вывод — командная работа не для них.
в результате получался абсолютно непонятный и неподдерживаемый код
Я бы не назвал это говнокодом. Трудно поддерживаемым - да. Job security oriented и bus factor - вероятно. Который в итоге станет техдолгом и его будет желательно переписать на более тупой, но стандартный и поддерживаемый - возможно (если на такой время будет, что вряд ли).
Но - в таком коде потом не "копаются", а "изучают".
самые хитроумные и эффективные конструкции
...это как статьи на хабре :-) Время тратится, трудно продраться, но потом у тебя "расширяется сознание". Как минимум узнаешь новый инструмент, а иногда и новый подход.
А бывает именно говнокод, который читаешь - и тебя тошнит. Из-за неряшливости. Из за копипаста длинных строчек с многократными вызовами дорогих функций, вместо пары локальных переменных (и потом ещё пойди заметь, что среди 140 символов с самим разными скобочками и символами в одном месте переменную I заменили на переменную l).
А потом ты сам пишешь такой же код, чтобы модуль был хотя бы в одном стиле написан, и тебя соседи просят заткнуться и перестать материться как бомж (и они правы, но как же хреново писать то, от чего даже при чтении тошнит).
"Заумь" описанная вами может вызывать скуку, зависть с гневом, безнадежность. Но когда от кода начинает физически тошнить как от некоторых запахов - тут термин говнокод очень точный.
Поддерживаю. На мой взгляд, одним из важнейших качеств инженера является умение увидеть цель того, что он делает. Если рокстар пишет сложно поддерживаемый, но эффективный код, то это можно понять. А код с запахом не имеет цели: лишь причины.
Причём с точки зрения рокстар он "ничего такого" не делает. Он просто использует "стандартные возможности, которые должен знать каждый". И в каком-то смысле он даже прав. Во всяком случае, про те же локальные переменные мы бы напоминали копипастеру примерно теми же словами.
Ну или мне порой проще пропатчить в памяти чужую библиотеку, проприетарную с исходниками, чем городить костыли вокруг ошибок при каждом вызове (да и не всегда это возможно), или пытаться собрать её кастомную версию (ещё хрен знает сколько ты косяков при этом непривычно процессе внесёшь). С моей точки зрения там самые примитивные основы ассемблера, проще некуда. Но... Квадратные глаза и священный ужас я видел. Хотя что там такого сложного, зазубрить десяток команд процессора, для патчей этого достаточно.
Можно конечно вознестись и назвать себя гениальной суперзвездой... Ну, процентов на 25% может так и есть. Но в основном-то я линейник.
Автор когда-то популярного WarFTPd сервера как-то писал, что он очень любит аутсорс, потому что там встречаются программы, простое вдумчивое чтение которых до понимания - как пройти курсы, только бесплатно. Вот описанный код рокстара - он зачастую из той же серии.
Другой вопрос, что у бизнеса вполне понятгюный интерес не стать заложником технологии, которую никто (уже) не понимает. И тут нужен баланс, чтобы не скатиться в костылинг (зато можно любого студента за еду нанять). Причём с оглядкой на задачу (в одноразовый казуальной игре ничего больше и не надо. А вот в rise and fall of LISP in NASA JPL противоположная история). На которую чистопородный рокстара положит с прибором и будет делать бескомпромиссный код во имя Высшей Элегантности...
Но это другой недостаток, чем говнокод :-)
Приведу пример, с которым знаком лично:
модель данных реализованная на контролах типа TextBox на скрытых формах. Причём приложение многопоточное (по ТЗ до 10000 уникальных потоков) с отдельным экземпляром этой модели на каждый поток.
Надо ли говорить, как оно работало?
модель данных реализованная на контролах типа TextBox на скрытых формах. Причём приложение многопоточное (по ТЗ до 10000 уникальных потоков) с отдельным экземпляром этой модели на каждый поток.
Надо ли говорить, как оно работало?
Да что говорить, это очень богатое поле для примеров
на C++ Builder 6 делали?
Могу ещё примерчик подкинуть. Загрузка древообразных справочников на 50К-300К элементов, типа ОКВЭД. Выборка чекбоксами и дописывание SQL-запросов, переданных снаружи в виде текста (угу). Ну и хранение выбранных текущих настроек. Все это сделано в виде формы, которая создаётся, но не обязательно показывается на экране (а почему бы и нет, форма тоже объект).
Возникла задача, позволить уточнять выбор внутри уже выбранного. Если в дереве выбран родитель, то должна быть возможность "снимать галочки" у детей, "ставить галочки" у детей детей и т.д. Что там раньше было уже не помню, вероятно "ветки" вообще нельзя было выбирать, только листья. Но - не помню.
Ну, ок. Вроде не сложно. Переписываю хранение галочек в .ini и визуальщину....
...и программа падает со сломанным SQL. Что за ;%;%;.
Пришлось копаться всерьёз. Выясняю, почему окно открывается по две минуты. Справочник грузится в невидимое дерево(контрол), причем в один плоский слой. Потом в этом невидимом контроле ищутся родители и перетаскиваются веточки (здравствуй, квадрат), и это при том, что в таблице заранее есть столбцы/аттрибуты, по котором можно было выстроить дерево ещё на этапе SQL ORDER BY. Потом уже из этого невидимого контрола всё копируется в такой же, но видимый на экране контрол, обвешанный событиями и прочей визуальщиной.
Но всё-таки, почему это начало падать? И как оно вообще работало, ведь в программе постоянно идут запросы к БД, которые эта форма дорабатывала в невидимом режиме, а она создается минуту минимум?
Выясняю, что эту проблему решили радикально, один раз построенное "дополнение к SQL" записывалось в ini-файл. Причем в простейшем виде перечисления ID каждого выбранного элемента (что раньше, вероятно, ограничивалось количеством галочек, которые пользователи реально ставили на каждый "лист" отдельно). При работе в "невидимом" режиме форма просто брала готовый куски запроса из .ini
Но для работы с ini взяли библиотеку, которая была обёрткой над Win32 API, в котором размер .ini ограничен в 64KB (и это, наверное, правильно). А после реализации выборки целыми ветками - размер дополнения к запросу легко улетал за 100КБ, в результате .ini просто обрезался.
Случай из моей практики — обратился заказчик с просьбой срочно_немедленно_чтобы_сегодня_уже_работало. Объяснил, что в указанные сроки смогу сделать, но будет ряд ограничений, а если потребуется расширять функционал, то всю мою работу придётся переделывать заново. Он согласился, и почти через год снова обратился ко мне. Улыбнуло, когда я в коде увидел //лютые костыли, никогда так не делайте. — Это был говнокод, который с поставленной задачей без сбоев почти год справлялся. А в приведённом примере даже не код, а просто набор символов, я считаю.
Более того, я например и к своей тоже его употребляю, и к чужой, если собеседник относится к этому как и я, непринужденно. Потому что, говнокод это всего-лишь технический долг, и все его пишут. Главное писать его осознанно, а не случайно)
Если вы с человеком знакомы давно, и в вашем общении вы точно уверены, что говнокод — это технический долг, тут вопросов нет. Но с незнакомыми людьми лучше так не делать, потому что слово спорное, негативное, содержит «говно». Ваше общение может быть затруднено, если вы на его код посмотрите и скажете, вот тут у тебя говнокод, не смотря на то, что вы имеете ввиду технический долг, рискуете быть непонятыми
Технический долг — несколько другое в моём понимании. Технический долг — сознательное нарушение явных и неявных правил, соглашений, лучших практик и т. п. ради скорости решения задачи. Говнокод — неподдерживаемый код, написанный в твёрдом убеждении, что это практически идеальное технически решение задачи, что абстракции, декомпозиция, оптимизации, использование готовых библиотек и т. д. — для слабаков. Или другая крайность — оверинженеринг.
На самом деле, без знания контекста создания и эксплуатации кода зачастую нельзя сказать говнокод это, технический долг или выстраданная реальной эксплуатацией оптимизация.
На самом деле, без знания контекста создания и эксплуатации кода зачастую нельзя сказать говнокод это, технический долг или выстраданная реальной эксплуатацией оптимизация.
Вы перепутали причину и следствие. Не человек — делец, потому что ему пофиг на фрукты, а человеку пофиг на фрукты потому что он делец. Да это из разных категорий, однако я объясняю почему делец будет скорее всего не склонен к фруктам в офисе: потому что предпочитает взять деньгами.
Говнокод в данном случае — не применительно к какой-либо конкретной работе, а как обстоятельство и собирательный образ некачественно, спешно выполненной работы.
Это вообще не причина и не следствие. Человеку могут нравиться фрукты в офисе и он может быть равнодушен к ним и он при этом политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Материалист". Или он не грубоват и не склонен к занудным формальностям. Или не материалист. При это работает исключительно по контрактам и фрилансит. Не объединяется той совокупностью свойств то, что вы объединяете категорией «делец»
А говнокод у всех свой. По- разному все его интерпретируют
А говнокод у всех свой. По- разному все его интерпретируют
Отношение к слову «говнокод» у всех одинаковое, категорически не приемлемое, однако в силу некоторых обстоятельств, иногда приходится переступать через свое «я никогда не буду так писать», для экономии времени и нервов, особенно когда получаешь уже поюзанный проект, а дедлайн на сегодняшнюю поставленную задачу закончился еще вчера.
При первом взгляде на код, есть, конечно, огромное желание сделать именно «Ctrl + A -> Del -> написать с нуля», но обстоятельства, за частую, не позволяют такой роскоши, и поэтому рано или поздно наступает момент, когда к «говнокоду» относишься, действительно, как к одному из быстрых инструментов для решения конкретной проблемы. «Костыльнул по быстрому» (с надеждой, что когда-нибудь перепишешь этот кусок кода «по нормальному», с некоторой ноткой самоиронии), выдохнул и все принципы морали и общественных убеждений уже отходят на второй план.
Я 7 лет пишу код, и не считаю себя каким то Гуру, но смело могу сказать, что программист начинает свой путь именно с «говнокода» и лишь с опытом начинает писать уже более «грамотно», заранее оптимизирует все и вся, погружается в паттерны, полиморфизм и вот в это все, но при этом иногда использует «костылики», различные TODO и прочие временные заглушки (про комменты я вообще молчу, если будет время), с целью ускорить решение конкретной задачи (потому что иначе не бывает, всегда нужно: подешевле, покачественней, и еще на прошлой неделе). И каждый раз, снова и снова приходится рефакторить свой и чужой код (потому что всегда думаешь о нем, в контексте менее приятной консистенции), и вот уже тогда реально «скилловый» программист раздвигает границы понятия «говнокодер», и уже не совсем ясно, что есть хорошо, а что тогда плохо. Главное относится ко всему с иронией, и смотреть на вещи, как на промежуточный вариант для достижения цели, практический опыт, и еще один толчок к саморазвитию.
Прошу прощения, за большое количество текста и за ошибки в пунктуации. «Яж программист», я так вижу. =)
При первом взгляде на код, есть, конечно, огромное желание сделать именно «Ctrl + A -> Del -> написать с нуля», но обстоятельства, за частую, не позволяют такой роскоши, и поэтому рано или поздно наступает момент, когда к «говнокоду» относишься, действительно, как к одному из быстрых инструментов для решения конкретной проблемы. «Костыльнул по быстрому» (с надеждой, что когда-нибудь перепишешь этот кусок кода «по нормальному», с некоторой ноткой самоиронии), выдохнул и все принципы морали и общественных убеждений уже отходят на второй план.
Я 7 лет пишу код, и не считаю себя каким то Гуру, но смело могу сказать, что программист начинает свой путь именно с «говнокода» и лишь с опытом начинает писать уже более «грамотно», заранее оптимизирует все и вся, погружается в паттерны, полиморфизм и вот в это все, но при этом иногда использует «костылики», различные TODO и прочие временные заглушки (про комменты я вообще молчу, если будет время), с целью ускорить решение конкретной задачи (потому что иначе не бывает, всегда нужно: подешевле, покачественней, и еще на прошлой неделе). И каждый раз, снова и снова приходится рефакторить свой и чужой код (потому что всегда думаешь о нем, в контексте менее приятной консистенции), и вот уже тогда реально «скилловый» программист раздвигает границы понятия «говнокодер», и уже не совсем ясно, что есть хорошо, а что тогда плохо. Главное относится ко всему с иронией, и смотреть на вещи, как на промежуточный вариант для достижения цели, практический опыт, и еще один толчок к саморазвитию.
Прошу прощения, за большое количество текста и за ошибки в пунктуации. «Яж программист», я так вижу. =)
только в этом обсуждении встречаются как минимум 4 интерпретации слова «говнокод»: технический долг, плохой стиль программирования, не работоспособный код и костыльность — вариант от вас :) Обсуждать хорошо/плохо это или допустимо/не допустимо стоит для каждой интерпретации отдельно
Согласен с Вами, каждый понимает это по своему, и каждый может почерпнуть для себя, как плохие, так и хорошие стороны в каждой конкретной интерпретации (потому что у каждого свое понимание этого определения). Я же просто привел один из возможных примеров, когда возникает некая необходимость в костыльности (и это не всегда плохо, хотя я сам весьма не лестно отношусь к этому понятию). Особенно необходимость хорошо прослеживается, как мне кажется, на коммерческих проектах, принадлежащих работодателю, где решения принимаются другим человеком, который зачастую к написанию кода не имеет отношения, но которому важны сроки и финансовая выгода, завязанная на этих сроках.
Писать «чистый код», в свое удовольствие, опять же по моему мнению, возможно только в нескольких случаях:
1) При разработке собственного проекта в одиночку и с нуля, где решения принимаются самостоятельно, и тогда уже человек сам для себя формирует понятия, что есть «чистый код», а что «говнокод», и сам в праве выбирать что для него важнее, свои этические убеждения или сроки.
2) При коллективной разработке, при условии, что человек уполномочен принимать решения, имеет рычаги контроля на остальных участников команды, и сам формирует архитектуру и паттерны «чистого кода» на этом проекте (при непосредственном участии в написании кода).
3) Или же в том случае, если принятие решения доставляет человеку некий дискомфорт (таких людей не мало), тогда ему нужен «шарящий» наставник, который всегда готов подсказать более красивое решение (если работать в таком ключе успешно, это тоже может приносить удовольствие, о того что человек является частью чего-то большего).
В остальных же случаях, все всегда будет упираться в сроки и подниматься вопросы о финансировании для поддержания этих сроков. Это просто мое мнение и настаивать на нем я конечно не буду, но мне очень приятно было поддержать дискуссию, спасибо за это. От себя еще хотелось бы пожелать всем, побольше успешных проектов приносящих не только прибыль, но и удовольствие (желательно в ключе одного из пунктов описанного выше). =)
Писать «чистый код», в свое удовольствие, опять же по моему мнению, возможно только в нескольких случаях:
1) При разработке собственного проекта в одиночку и с нуля, где решения принимаются самостоятельно, и тогда уже человек сам для себя формирует понятия, что есть «чистый код», а что «говнокод», и сам в праве выбирать что для него важнее, свои этические убеждения или сроки.
2) При коллективной разработке, при условии, что человек уполномочен принимать решения, имеет рычаги контроля на остальных участников команды, и сам формирует архитектуру и паттерны «чистого кода» на этом проекте (при непосредственном участии в написании кода).
3) Или же в том случае, если принятие решения доставляет человеку некий дискомфорт (таких людей не мало), тогда ему нужен «шарящий» наставник, который всегда готов подсказать более красивое решение (если работать в таком ключе успешно, это тоже может приносить удовольствие, о того что человек является частью чего-то большего).
В остальных же случаях, все всегда будет упираться в сроки и подниматься вопросы о финансировании для поддержания этих сроков. Это просто мое мнение и настаивать на нем я конечно не буду, но мне очень приятно было поддержать дискуссию, спасибо за это. От себя еще хотелось бы пожелать всем, побольше успешных проектов приносящих не только прибыль, но и удовольствие (желательно в ключе одного из пунктов описанного выше). =)
Тут, наверное, тоже есть, своего рода, классификация. Думаю, для линейного программиста, говнокод — это бесконечная борьба со следствиями, вместо того, чтобы сесть и пристально исследовать причины. Для rock star, скорее всего, говнокод — это такая грубая «заглушка», в не очень ответственном (а, стало-быть, и не очень интересном) месте кода, которую, всё-таки, однажды, придётся довести до ума, иначе совесть замучает. Для дельца, это, очевидно, — инструмент, применяемый, например, в ситуации, когда клиент не знает, чего хочет. А для пассажира, вероятно — какая-нибудь копипаста, которую, он, очень выразительно, тут-же и опровергнет, если ему на неё указать.
Ничего оскорбительного не вижу в слове «говнокод», сам практикую если задачу нужно сделать в сжатые сроки.
З.Ы. А перфекционисты и люди с «паттерном головного мозга» к какому типажу относятся?
З.Ы. А перфекционисты и люди с «паттерном головного мозга» к какому типажу относятся?
Первые — могут быть кем угодно, перфекционизм не характеризует интересы человека, а лишь его усердие при выполнении задачи. Вторые — как правило линейные программисты или пассажиры. Для rock star паттерны нерелевантны, для дельцов — не самый интересный инструмент работы.
Вне контекста, конечно, слово как слово, что в нем оскорбительного. А если представить такую гипотетическую ситуацию: вы устроились на новую работу, ваш новый непосредственный руководитель немногословный интроверт с всегда одинаково суровым выражением лица, вы получили задачу, и выполняя её дошли до момента, который нужно обсудить с руководителем. И вот смотрит он в ваш экран и произносит одно единственное слово: «говнокод» и замолкает. Понятно, что дальше у вас будет какой-то диалог и всё скорее всего выяснится. Но в этот момент у вас эмоциональный фон какой? Позитивный, нейтральный или негативный? А если вы руководитель, допустите такое общение с новым незнакомым человеком?
Я понимаю, если говнокод явление временное и никому снаружи невидное, но если предполагается код ревью или командная работа, то говнокод — это очень плохо. Вы отнимаете уже не только свое время, но и время коллег.
Не люблю слово «говнокод» в том числе потому, что не все одинаково понимают что это. Вот ниже вы пишите, что это " функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы, непонятные переменные и функции… ", т.е. плохой стиль программирования, а с топикстартер, например, объяснил, что имеет ввиду под этим словом технический долг
Да, но когда видишь функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы, непонятные переменные и функции…
Я к тому, что довольно много людей прикрывается спешкой и сроками, пишут дикий ужас, а потом долго ищут ошибки и приводят все в порядок. Я за то, чтобы локально код, все-таки, сразу был простым и понятным. Тогда и с модулями, архитектурой и прочей радостью потом проще.
Я к тому, что довольно много людей прикрывается спешкой и сроками, пишут дикий ужас, а потом долго ищут ошибки и приводят все в порядок. Я за то, чтобы локально код, все-таки, сразу был простым и понятным. Тогда и с модулями, архитектурой и прочей радостью потом проще.
Тогда, наверное, придется изменить подход бизнеса в текущем виде. Т.к. обычно бизнес заинтересован в получении чистой прибыли как можно быстрее, то и подход у него соответствующий. Все делается быстро и решительно. И далеко не факт, что качественно и лаконично. Но я все питаю надежду, что у дельцов в этом плане мозги все таки повернуться в нужную сторону :)
Как правило, время потраченное при начальной разработке на выделение функции или приватного метода в современной IDE для бизнеса практически ничего не значит, а окупиться мозже может тысячекратно. Очень многообещающая инвестиция.
Для того чтобы это оценить да еще и правильно абстрагироваться — нужно быть даже не миддлом.
Поэтому спрос на джуниоров резко упал. Признать, что даже мидла брать опасно, в суровых условиях российских рынков, под силу редким.
Речь не про какие-то заумные абстракции, речь лишь о "функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы". Секунды, потраченные на extract function/method, позже могут сэкономить как минимум минуты, когда потребуется этот код модифицировать.
И речь не о градациях типа джун/миддл/сеньор, а об общем отношению к коду.
Знаете, если «погружаться» (вспоминается соответствующая картинка) приходится каждый день, то вряд ли такой код можно назвать искусством.
Интересная статья, прочитал с удовольствием.
Только не хватает голосовалки ))
Только не хватает голосовалки ))
Интересная, а главное близкая к истине классификация.
Я почти на стопроцентов линейный. Узнал себя во всём из описанного, кроме того, что мои коммуникационные навыки из разряда «казалось, нащупал дно, но снизу постучались». Ну и зарплату 2 раза в месяц у нас никто не платит.
Я почти на стопроцентов линейный. Узнал себя во всём из описанного, кроме того, что мои коммуникационные навыки из разряда «казалось, нащупал дно, но снизу постучались». Ну и зарплату 2 раза в месяц у нас никто не платит.
Ну вот чем плоха любая типология, так это тем что в природе «чистые» типы встречаются редко.
Человек вполне может частично обладать качествами как и дельца, так и линейного программиста + отлично знать алгоритмы сортировки и т.д. Или вот еще феномен, с которым я встречался дважды, вроде человек все знает, отвечает на все вопросы правильно, а код пишет полное г.
Человек вполне может частично обладать качествами как и дельца, так и линейного программиста + отлично знать алгоритмы сортировки и т.д. Или вот еще феномен, с которым я встречался дважды, вроде человек все знает, отвечает на все вопросы правильно, а код пишет полное г.
Пока читал, раскидал многих своих знакомых и коллег по категориям. И мой не малый опыт в IT говорит мне, что вы во многом тут правы.
Согласуется с классификацией руководителей по Адизесу. Линейный — P тип. Rock Star — E. Делец — PEa (самый разносторонний, поэтому и открывает своё дело). Пассажир -I. Здесь речь конечно не про руководителей, а про программистов, но я заметил, что эта классификация основана на психике, поэтому можно использовать и не для руководящих позиций.
Спасибо за материал: статья хорошо структурированы и я вспомнил несколько знакомых представителей каждого типа.
Благодарю. Очень сильное сравнение.
Есть более общая классификация, не руководства, а в целом психотипа: мотор-контролёр-поддержка-анализатор, www.tomyself.ru/mpostsocio/49-socio3part. Причём это именно 4 вектора, все вместе в одинаковой пропорции встречаются крайне редко, один чистый тип тоже не особо часто, и могут быть даже перекрёстные типа мотор-анализатор.
Линейный — A — анализатор
Rock star — E — мотор
Делец — P — контролёр
Пассажир — I — поддержка
Кстати, я чёт сильно не уверен в бэкграунде отличника у Rock Star — это же слишком скучно :) Скорее уж отличником будет Пассажир (договорится, если не топовый ВУЗ), или Линейный, потому что усидчивый.
Линейный — A — анализатор
Rock star — E — мотор
Делец — P — контролёр
Пассажир — I — поддержка
Кстати, я чёт сильно не уверен в бэкграунде отличника у Rock Star — это же слишком скучно :) Скорее уж отличником будет Пассажир (договорится, если не топовый ВУЗ), или Линейный, потому что усидчивый.
У Rock Star может быть «неровная» успеваемость. Пятерки по спеиализации и тройки по «истории родного края» и прочей «ерунде»:)
Ну или вообще двоечником может быть, у него же характер скверный. Оценки ведь не робот выставляет.
У Rock Star может быть «неровная» успеваемость.
Это у кого угодно может быть.
Давно известно, что образование на последующую работу ИТ-шника мало влияет для подавляющего большинства специализаций.
Исключения редки.
Кстати, если пассажир все-таки компетентен, но склонен к демагогии (PI) можно дать ему джуниоров, пусть менторит. Но вот программу развития должен разрабатывать другой специалист.
Если пассажир организован (AI), то перед нами Scrum Master.
Если пассажир организован (AI), то перед нами Scrum Master.
Кстати, если пассажир все-таки компетентен, но склонен к демагогии (PI) можно дать ему джуниоров, пусть менторит.
Ни в коем случае.
Выступить перед джунами с лекцией — как вы будете круты, но пока получайте гроши, развивайтесь — это да.
Но технически менторить — ни в коем разе.
У пассажиров у самих уровень около-джунов, пусть даже они и осели на более высоких должностях.
Что-то я не очень понял про тестовое задание и пассажира:
Почему пояснения и комментарии — это показатель технической некомпетентности (насколько я понял, это один из критериев, который отличает пассажира от других типов)? Комментарии и пояснения действительно, по моему мнению, помогают поддерживать код и злом не являются.
Если к тестовому заданию будет объемное пояснение, в коде — не продраться от комментариев и соискатель рвется объяснить как он это сделал — перед вами пассажир.
Почему пояснения и комментарии — это показатель технической некомпетентности (насколько я понял, это один из критериев, который отличает пассажира от других типов)? Комментарии и пояснения действительно, по моему мнению, помогают поддерживать код и злом не являются.
Это лишь косвенный признак. Само по себе конечно же это не плохо. Однако надо четко фиксировать момент, при котором желание соискателя поговорить превалирует над желанием сделать работу. Пример: Javadoc в коде — хорошо. А вот обилие инлайн-комментариев там, где они не нужны — показатель.
Любопытно, просто я, например, когда пишу в тестовом задании комментарии, наоборот хотел бы, чтобы меня меньше беспокоили вопросами по коду, минимизировать живое общение, так сказать. Но это строго индивидуально, полагаю.
Ну, я вот сначала пишу всю задачу комментариями,
а потом уже вписываю между строк комментариев код (в среднем выходит одна строка комментария на 7..10 строк кода), это уже «Не продраться»?
а потом уже вписываю между строк комментариев код (в среднем выходит одна строка комментария на 7..10 строк кода), это уже «Не продраться»?
Сильно зависит от их содержания. Комментарии, дублирующие код, зачастую как раз следствие некомпетентности, малого опыта. Грубо, человек открыл для себя библиотечную функцию и восторженно комментирует то, что она делает, а не зачем он её вызывает.
Другой вариант — «звёздная болезнь» с
Другой вариант — «звёздная болезнь» с
Мы все с возрастом становимся дельцами. Т.к. почти все проходим период работать за копейки и вдохновение и понимаем что сыт от этого не будешь и что нужно работать и совершенствоваться дальше.
Развитие идет этапами. Заканчивается один этап и у тебя 2 пути — либо остаться на этом уровне, быть профи, либо пойти выше и развиваться.
Развитие идет этапами. Заканчивается один этап и у тебя 2 пути — либо остаться на этом уровне, быть профи, либо пойти выше и развиваться.
А вот и нет. Rockstars, работающие долгие годы в R&D Google — тому пример. У меня вот знакомая работает в JetBrains 6 лет и уходить не собирается (она по духу Rock star, по квалификации — растет непрерывно). С другой стороны — я вижу как многие линейные программисты уже потихоньку уходят на пенсии. А пассажиры — ну на то они и пассажиры чтобы о них не говорить. :)
Для дельца необходима самостоятельность и профессионализм. А это далеко не все приобретают с возрастом. "Есть взрослые, у которых и в 30 лет виновата скамейка", как говорится.
А вот это зависит от конторы. Я живу в глубинке, поэтому у нас тут нет серьезных контор. И невозможно сразу взять и стать асом. Вначале придется работать там где берут и накапливать медленно опыт.
Кстати проживание в глубинке тоже можно отнести к косвенному признаку дельца. Но оооочень косвенному. И такая "дельцовость" — чуть другой природы.
Боюсь дельцами становятся не из-за этого. Тут еще влияет и материальная сторона в детстве и юности. Постоянное чувство нехватки денег дает хороший стимул работать.
Очень верно, но мне кажется на собеседовании до такого психоанализа все же не доходят. Но вы описали очень хороший эффект, да. Он в принципе позитивно влияет на работоспособность, но человека это едва ли делает счастливым.
Я бы поостерегся обосновывать высокую финансовую мотивацию былым голодом. Обычно к вершинам пробиваются те, кто бросил гарварды, а не жизнь в шалаше.
Истину говорите, сложная материальная и зачастую психологическая ситуация + высокая стрессоустойчивость и порождает людей с максимально практичным материальным подходом.
Замечу что есть нюанс, если такой человек достигает потолка, часто переходит в состояние линейного программиста.
Замечу что есть нюанс, если такой человек достигает потолка, часто переходит в состояние линейного программиста.
Я тоже живу в глубинке. У нас мало серьезных контор. В одну я пришел, ничего не зная в том, что они делают на позицию «линейного». Стал «дельцом» за полгода, с начала этого года (а в сумме уже два в этой конторе) работаю на позиции rock star — если что-то кто-то не может, не знает, или надо что-то что никто не может и/или не знает — то я. Дали лычки… но все равно меняю работу. Потому что для rock star неприемлемо, как было указано в статье, «насилие» в выборе задач. Не скажу что я постоянно делал не то что нужно, но полдня-день в неделю уходило на не то что нужно. Чтобы потом то что нужно — делалось легко. Меня не поняли, теперь обратно в «дельцы» пойду…
Видел множество "линейных программистов", ковыряющих в свои 40 с чем-то лет какой-нибудь замшелый 1С или Lotus как и 20 лет назад.
«Делец» — это не выше в смысле проф. роста по сравнению с, например, «рок-стар», это отношение к работе и конкретным задачам в целом. Хорошую зарплату может получать любой тип, но для «дельца» она будет основной мотивацией работать и развиваться в принципе, он легко забросит программирование и ИТ в целом, если вдруг какие-то другие его навыки окажутся востребованнее. Грубо, делец-одинэсник легко станет аудитором
Хорошую зарплату может получать любой тип, но для «дельца» она будет основной мотивацией работать и развиваться в принципе, он легко забросит программирование и ИТ в целом, если вдруг какие-то другие его навыки окажутся востребованнее.
Основное умение дельца добывать деньги, не зависеть от абстоятельств.
Поэтому «навыки не востребованы» для него не может оказаться.
Все мы рок-стары, но гугл лишь один. Приходится притворяться программистом.
Кто-то теги всё-таки читает…
Слово «Делец», мне кажется, как правило, носит негативный характер. В вашем же описании, человек просто относится к компании так, как она к нему. Если все хорошо, то хорошо, не нравится кому-то — уволить/уволится. Мне кажется все честно и взаимно.
В целом с классификацией соглашусь, только "пассажир" — не слишком удачное название, я бы назвал "паразитом". Характерная черта — очень любит у всех просить помощи вместо того чтобы хотя бы попытаться разобраться самому. Пользы такие программисты как правило не приносят. Лучше двигать их в продавцов или поддержку. Кстати могут стать неплохими руководителями проектов.
У "Рокзвезд" есть одна неприятная черта — из всех четырех типажей только они никак не переносят критику. Причем независимо от уровня своей компетенции. Вместо того чтобы сказать такой "звезде" "твой код — говно, переделывай", придется долго и нудно подводить его самостоятельно к этому пониманию, чтобы не дай бог, не обидеть. С другой стороны, они никогда не скажут "у меня не получается". Это же вопрос их самооценки и престижа. Костьми лягут, но сделают. Можно это использовать.
Способность переносить критику — это тоже к коммуникативным навыкам. А я предупредил, что у rock star-ов может быть мерзейший характер :) "Костьми лягут но сделают" — это скорее к дельцам. Для них это — контракт, репутация и деньги.
Паразит — ну как вам сказать… Паразит — негативная оценка. Это кто-то, кто высасывает соки и ничего не делает взамен. Я привел как минимум один способ сделать пассажира полезным для команды.
И да, человек который у всех просит помощи — не обязательно пассажир. Вероятно, он просто начинающий и ему правда нужна помощь — тут зависит от ситуации. Однако предпосылки есть, да.
"Костьми лягут но сделают" — это скорее к дельцам. Для них это — контракт и репутация.
Это так, но делец никогда не подпишется под слишком рискованной (неопределенной) задачей. "Рокзвезду" же можно взять на банальное "слабо".
Я привел как минимум один способ сделать пассажира полезным для команды.
Да, но в этом примере он уже не в роли программиста.
"Рокзвезду" же можно взять на банальное "слабо".
Ох, я такие психологические игры не поддерживаю. Отдает бытовым мошенничеством. Уж лучше мотивировать какой-нибудь морковкой в духе того же респекта и уважухи (нематериально), если на то пошло. Нематериальная стимуляция кнутом — это что-то новенькое :)
Нематериальная стимуляция кнутом — это что-то новенькое :)Почему «кнутом»? Для rock start — это нормальная мотивация. Тем более, что он сам на неё напрашивается.
То есть он может вместо банальной и простой задачи предложить сделать что-то «красивое и большое» — и если вы ему скажите «давай, валяй — я не верю, что у тебя получится», то он за месяц сделает вещь, которая хороший линейный программист будет писать год и напишет при этом в 10 раз больше кода.
Однако есть и обратная сторона медали — если после этого вы скажите «это, конечно, прекрасно, но нам это не нужно — сделай, пожалуйста, попроще, чтобы Коля (такой средний-средний „линейщик“) смог это поддерживать», то тут будет уже тааакой откат, что мало не покажется. Вы не только не получите работающего кода через пару месяцев (за которые вышеупомянутый Коля решил бы исходную, «некрасивую» задачу) — хорошо если вы получите какое-то решение задачи через полгода.
Рокстары только и делают, что ставят себе задачи на "слабо". И когда им говорят, что они что-то не смогут, они только рады и делают все, чтобы показать, что они намного круче, чем о них думают, изучат материал и таки сделают. И они рады, и заказчик.
В школе на уроках математики рокстары ведут себя так же, постоянно соревнуясь в том, кто сделает сложнейшее задание быстрее и пытаясь обойти друг друга.
Паразит — ну как вам сказать… Паразит — негативная оценка. Это кто-то, кто высасывает соки и ничего не делает взамен. Я привел как минимум один способ сделать пассажира полезным для команды.По моему опыту, из тех, кого вы называете «пассажирами» («не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить...») получались самые лучшие менеджеры, от PM до CTO.
Работа менеджера — общаться с людьми и делегировать задачи; умение кодить самому, а ещё хуже, стремление кодить самому — менеджера будет только отвлекать от своей работы.
«твой код — говно, переделывай» — это хамство, а не критика. переносить хамство начальника, это, наверно, очень выгодно как раз начальнику, а для работника может обернуться плачевно (субдепрессивные и депрессивные эпизоды, выученная беспомощьность и прочие несчастья). В качестве примера хорошей критики можно обратить внимание на принцип бутерброда (сэндвича). Но есть у этого принципа существенный минус — тяжело все время его применять, гораздо проще сказать «говно» и удивляться, почему люди так безрадостно это воспринимают :)
«твой код — говно, переделывай» — это хамство, а не критика.
Ага, вот и рокзвезда пожаловала :) А в чем хамство, простите? Почему бы не называть вещи своим именами? Речь же про код, а не про вас лично.
В том, что "называть вещи своими именами" не состоит в том, чтобы хамить человеку. Можно подойти и вместо "код говно — переделывай" — сказать "так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай" — и вуаля. Чуть больше слов и вы уже не такой уж и мудак. Впрочем… так способны делать дельцы. Rock stars не склонны кому-то что-то объяснять.
так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Вот вы попробуйте такое рокзвезде сказать. Неадекватную реакцию гарантирую.
"Код-говно" конечно же образное выражение. Имеется в виду просто прямая критика решения.
Ну я считаю так: по умолчанию всегда надо критиковать аккуратно, по делу и не апеллируя к личности. Максимально детально, чтобы до человека дошло. Таким образом я, как бы, снимаю с себя ответственность за его говнокод. Если человек не понял — то остается признать — да, зазвездился. Т.е. смотрите, штука простая: причина и следствие. Не то, что человек rock star и зазвездился должно служить причиной для критики, а невосприятие критики как раз служит причиной и показателем того, что человек зазвездился.
так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Это собственно и есть "код-говно". Для отрудника с непростым отношением к критике заход был бы иной:
"Отлично задумано! И вот-тут круто придумал, молодец… Слушай, а что будет, если вот такие условия? Что-то я пока не очень понимаю, как оно будет работать… Переделаешь? Ну ок, спасибо."
По-моему вы тут описываете не людей, которые хорошо или плохо реагируют на критики, а в чистом виде отличие между линейными программистами и «концентрированными исследователями».
Для первого какой-нибудь SOLID — это одна из вещей, который он стремится соблюдать в своей программе… просто потому что «так положено». Соответственно когда вы говорите ему «вот как это» — и показываете на, скажем, «нарушение принципа открытости» — то он, вполне логично, реагирует на это как на разумное замечание.
Для последнего — это всего лишь некоторые «эмпирические приёмы» полезность которых в каждом конкретном случае нужно рассматривать отдельно. На заявление «тут нарушен принцип открытости и наружу выставлена кодировка команд x86» вы вполне можете услышать довод «x86 существует уже почти 40 лет, кодировка команд за это время принципиально не менялась и, насколько мне известно, есть по меньшей мере 10 причин по которым этот код ни для чего другого в ближайшие 10 лет никто использовать не будет».
Это ни хорошо и ни плохо — это просто разные подходы. Я наблюдал как потерю многих лишних человеко-лет на то, чтобы соблюдать SOLID'ную архитектуру, которая была рождена из соображений «открытости» и «принципов разделения интерфейсов», так и катастрофы из-за того, что какая-то вещь, которую «концентрированный исследователь» считал невозможной в принципе таки реализовалась на практике.
В реальности «линейный программист» склонен порождать решения, требующие в разы больше ресурсов и содержащие в разы больше кода (и, соответственно, требующие больше времени на написание), чем «исследователь», однако использование его творений редко ведёт к неожиданному «краху», когда оказывается что архитектура чего-то не поддерживает в принципе.
С другой стороны тот факт что человек может решать задачи только определённого уровня сложности никто не отменял, так что совсем сложные задачи «линейный программист» решить просто не сможет…
Для первого какой-нибудь SOLID — это одна из вещей, который он стремится соблюдать в своей программе… просто потому что «так положено». Соответственно когда вы говорите ему «вот как это» — и показываете на, скажем, «нарушение принципа открытости» — то он, вполне логично, реагирует на это как на разумное замечание.
Для последнего — это всего лишь некоторые «эмпирические приёмы» полезность которых в каждом конкретном случае нужно рассматривать отдельно. На заявление «тут нарушен принцип открытости и наружу выставлена кодировка команд x86» вы вполне можете услышать довод «x86 существует уже почти 40 лет, кодировка команд за это время принципиально не менялась и, насколько мне известно, есть по меньшей мере 10 причин по которым этот код ни для чего другого в ближайшие 10 лет никто использовать не будет».
Это ни хорошо и ни плохо — это просто разные подходы. Я наблюдал как потерю многих лишних человеко-лет на то, чтобы соблюдать SOLID'ную архитектуру, которая была рождена из соображений «открытости» и «принципов разделения интерфейсов», так и катастрофы из-за того, что какая-то вещь, которую «концентрированный исследователь» считал невозможной в принципе таки реализовалась на практике.
В реальности «линейный программист» склонен порождать решения, требующие в разы больше ресурсов и содержащие в разы больше кода (и, соответственно, требующие больше времени на написание), чем «исследователь», однако использование его творений редко ведёт к неожиданному «краху», когда оказывается что архитектура чего-то не поддерживает в принципе.
С другой стороны тот факт что человек может решать задачи только определённого уровня сложности никто не отменял, так что совсем сложные задачи «линейный программист» решить просто не сможет…
Нет, я имею в виду именно отношение людей к критике. Одному можно указать на очевидные ошибки, другого надо подвести чтобы он сам их увидел. Второй вариант конечно отнимает гораздо больше времени у руководителя.
так что совсем сложные задачи «линейный программист» решить просто не сможет…
Ну а поскольку процентов 90 задач в ИТ — это ни разу не rocket science (и наврняка по крутящимся деньгам так же ), то может ну его нахрен все эти заумные творения звезд, которые одни хрен, выкинуть и переделать надо так, чтобы линейный персонал мог не ломая голову поддерживать?
Так, вот смотри сюда. вот как это? видишь? знаешь почему неправильно? воооот. А знаешь как правильно? хорошо, идем дальше. а вот это как понимать? Вооот, то-то же. Исправляй давай
Для большинства программистов это не очень удачная формулировка, потому что присутствует «тыкание» и менторский тон. Так допустимо общаться с джуниором. Линейные скорее всего проглотят, а рок звезды, они все-такие не просто так рок-звезды. Если бы они не умели делать уникальные вещи, никто бы их не держал с таким характером.
Управленцу важно уметь говорить с сотрудниками на их языке, просто именно вам психологически это не нравится и вы считаете такой подход манипулятивным. Но нет никаких манипуляций, в том что вы говорите с итальянцем по-итальянски, а с китайцем на его родном языке, если вы его знаете.
Рок-стар таких долгих объяснений не выдержит. Так что приходится ему говорить «твой код-говно», в надежде, что он и сам это знает. Он же рок-стар, должен знать.
Извините, но это чушь. Я вообще не знаю откуда термин Rock Star взялся. Описание «концентрированный исследователь» описывает ситуацию гораздо лучше. Если бы код казался бы говном его автору, то вы бы его не увидели. Наоборот — скорее всего он таки считает, что код — достаточно близок к оптимуму, если он вам его вообще показывает. Потому тыкать куда-то бесполезно — если там уже не стоит замечение «временная затычка, нужно будет переделать» и так, то «исследователь» вас просто не поймёт. Ну да — в этом месте мы различаем насекомых и птичек по «количеству лап». Почему это плохо если у нас в системе никого, кроме москитов и ласточек не планируется? А вот замечание в стиле ncix на тему «у нас в планах кроме ласточек завести ещё и черепах и хрюшек и важно, чтобы и ласточки и черепахи яйца несли, а хрюшки — нет» — другое дело. Это — конкретная проблема и использование количества лап плюс дополнительного признака начинает выглядеть как костыль, да…
Извините, но это чушь. Я вообще не знаю откуда термин Rock Star взялся. Описание «концентрированный исследователь» описывает ситуацию гораздо лучше.
Термин «концентрированный исследователь» не несет в себе эмоционального окраса.
В то время как термин «звезда» как бэ неявно намекает на «звездную болезь», на то, какие возможны проблемы с этим типом.
Ага, вот и рокзвезда пожаловала :) А в чем хамство, простите? Почему бы не называть вещи своим именами? Речь же про код, а не про вас лично.
Извините, но ваш пост — говно! Не вы сами. Но ваши мысли, ваш текст — говно.
Приятно было?
Говно — это характеристика, а не конструктивная критика. И воспринимается это как характеристика производимого вами труда. Если я скажу вам, что все, что вы написали за последнюю неделю — говно, что конкретно вы побежите исправлять? Ничего. Потому что это был вердикт, а не призыв к действию.
Правильный тимлид-делец сказал бы: «Давай по-новой Миша, все #@йня. Нам за это денег не дадут»
Я бы судя по описанию, «пассажир» — это банальный менеджер среднего звена, имеющий навыки и опыт программирования, не ушедший из предметной области, но перемещающийся из разработчиков в управленцы.
только они никак не переносят критику
Я бы сказал, что они не переносят неконструктивную критику. Я тоже с трудом переношу, как и похвалу, впрочем. Вот это:
"твой код — говно, переделывай"
яркий пример неконструктивной критики. Грамотным инженерам так излагать мысли не пристало, фразы вроде этой ни в коем случае нельзя писать на код-ревью, не важно, рок-звезда перед тобой или нет.
Нужно указать на проблемные места и объяснить, что именно с ними не так, и какой профит будет, если сделать по-другому. На такое даже рок-звёзды не обидятся. Если вы не можете нормально объяснить, что не так с кодом, то проблема в вас, а не в коде.
Похоже, «пассажиры» — причина этой статьи ;)
Осталось найти свое место в этой классификации :)
Бесполезно. Я нашел себя аж в трех и четырех :-D И по другому ни у кого быть не может.
И по другому ни у кого быть не может
Говорим за всех? Я на 90-95% именно Software Enginer. Допустимо будет сказать, что «только делец». Чистый.
Был и сотрудником университета, откуда был отчислен за неуспеваемость (ибо пошел работать к ним же… а на сессии — ну как бы я сам «обрабатывал» студентов и успевать в то же время там же все сдавать никак не мог). Был и поваром. Без спец-образования — просто нужны были деньги, смог убедить, что все вытяну.
Теперь java-developer.
Искренне хотел найти своё место. Увы. Но зато буду знать как не выглядеть пассажиром).
Сильные стороны:
Такая философия наверное приходит уже в зрелом возрасте, конец творчества и начало анализа. Попробую дорасти до "… не релевантна" и "… особого пиетета".
Слабые стороны:
Жалко нет анкеты результирующей принадлежность к описанным типажам.)
Небольшой завал в сторону памятки для приспособленца.
Такая философия наверное приходит уже в зрелом возрасте, конец творчества и начало анализа. Попробую дорасти до "… не релевантна" и "… особого пиетета".
Слабые стороны:
Жалко нет анкеты результирующей принадлежность к описанным типажам.)
Небольшой завал в сторону памятки для приспособленца.
Встречал ли автор гибриды «RockStar» и «Пассажира» в дикой природе? Не могу себе представить такую гремучую смесь, они же противоречат друг другу — первый имеет исключительную техническую подготовку и скверные коммуникационные навыки, в то время, как у второго всё в точности наоборот. Да и само отношение к программированию у них диаметрально противоположное.
Ну… как говорится "опыт не пропьешь", но Rock Star с ораторскими скиллами ИМХО становится кем-то вроде "популяризатора науки" или визионера, аки Стив Джобс. Но я могу ошибаться.
Совершенно согласен с вашим комментарием.
По идее это крутое сочетание, но здесь стоит заметить, что для работодателя вариант «RockStar» + «Пассажир» может нести свои неприятности. То есть, с одной стороны, для человека удовлетворение собственного интереса и амбиций первичнее самой работы, с другой — такого довольно сложно прижать к стенке, так как он хорошо умеет пускать пыль в глаза, да ещё и хорошо знает мат. часть. :)
Из плюсов — такой человек может хорошо подходить в качестве инструмента для обучения сотрудников, деления опытом внутри компании: круто выступить на конференции, прочитать интересный курс лекций, заразить всех своей идеей — это про него.
По идее это крутое сочетание, но здесь стоит заметить, что для работодателя вариант «RockStar» + «Пассажир» может нести свои неприятности. То есть, с одной стороны, для человека удовлетворение собственного интереса и амбиций первичнее самой работы, с другой — такого довольно сложно прижать к стенке, так как он хорошо умеет пускать пыль в глаза, да ещё и хорошо знает мат. часть. :)
Из плюсов — такой человек может хорошо подходить в качестве инструмента для обучения сотрудников, деления опытом внутри компании: круто выступить на конференции, прочитать интересный курс лекций, заразить всех своей идеей — это про него.
> Из плюсов — такой человек может хорошо подходить в качестве инструмента для обучения сотрудников, деления опытом внутри компании: круто выступить на конференции, прочитать интересный курс лекций, заразить всех своей идеей — это про него.
Не факт. Подготовка лекционных материалов и обучение — эта неинтересная рутина.
Не факт. Подготовка лекционных материалов и обучение — эта неинтересная рутина.
Пример с лекциями, наверное, лишний… Я лишь хотел сказать, что этот тип людей может уметь интересно и понятно объяснять сложные вещи. Но конечно, это не этом, чтобы потом годами читать их в университете. Вспоминается пример Фейнмана, который согласился прочитать курс лекций, но при условии, что это будет всего один раз. И сделал это блестяще.
Евангелисты же :)
Стив Джобс и Rock Star? Не преувеличивайте :)
Ну окей, окей. Билл Гейтс :) Он как-никак операционную систему сделал руками (DOS), если я не ошибаюсь.
Ну да. Своими руками купил права на неё.
Он Бейсик написал сам, а операционку купил. Пусть только те, кто смеются над написанием простейшего интерпретатора вспомнят не про то, что это всё-таки в 70е годы было, но, что гораздо более важно — то, что Бейсик Билл Гейтс писал для компиьютера, который он впервые увидел «живьём» во время презентации этого Бейсика заказчику. До этого у него была только документация.
Вот вы бы так смогли? А «концентрированный исследователь» — смог.
Вот вы бы так смогли? А «концентрированный исследователь» — смог.
DOS была куплена и доделана. Руками он сделал интерпретатор BASIC, и особое отношение компании к этому языку прояаляется до сих пор.
Руками он сделал интерпретатор BASIC, и особое отношение компании к этому языку прояаляется до сих пор.
Не сказал бы. Причем зная об этой страсти Гейтса, который даже будучи уже богатым человеком — называл себя частенько basic-programmer — сильно удивлен почему так мало Basic в MS.
Ну есть он (в сильно переработаном виде) внутри МС Офиса как скриптовый язык.
Но более нигде значимо он не используется. Даже как скрипт для ОС не стал основным. Даже как вторичный язык для .NET он где-то в попе, хотя уж чего, чего, а языков под .NET фирма MS много больше одного реализовала.
Стив Джобс
Нет уж, этот точно никакой не Rock Star. На мой взгляд, квинтэссенция Rock Star — это Simon Peyton Jones.
Конечно. Когда рокстар убеждает заказчика, что интересная фича, из-за которой сдача проекта задерживается на месяцы, будет серебряной пулей, и выбивает на это дополнительные деньги.
Я убеждаю заказчика что интересная технология на которой мы сделаем следующую версию стоит потраченных денег.
Но на самом деле это вранье.
Да технические это будет круче.
Но на окупаемость мне плевать.
Зато повозится будет интересно.
Ведутся довольно часто, если только нет жестких ограничений по бюджету. Впрочем, с такими стараюсь не работать.
Но на самом деле это вранье.
Да технические это будет круче.
Но на окупаемость мне плевать.
Зато повозится будет интересно.
Ведутся довольно часто, если только нет жестких ограничений по бюджету. Впрочем, с такими стараюсь не работать.
Линус Торвальдс кажется подходит как пример такого гибрида.
Я так понимаю, что всему написанному нужно слепо верить? Ибо никаких научных, псевдонаучных, статистических и даже логических пояснений в посте нет.
Я вас не заставляю верить. Не хотите — не верьте. Однако многие из отписавшихся выше людей с опытом отметили, что написанное весьма близко к реальности. Если для вас это не показатель — ну… б-га ради. Я не навязываюсь.
+1 к «весьма близко к реальности»… Спасибо за структурированное изложение мыслей!
И да… голосовалки не хватает. Кстати интересно на сколько совпадает то как человек видит себя и к какому классу вы его относили (на примере тех программистов с которыми вы работали).
И да… голосовалки не хватает. Кстати интересно на сколько совпадает то как человек видит себя и к какому классу вы его относили (на примере тех программистов с которыми вы работали).
UFO just landed and posted this here
Удивительно, не так ли? А вы бы хотели чтобы они их не находили? :)
UFO just landed and posted this here
Не классифицировать людей при поиске сотрудника = плохо выполнять работу, не найти человека, чтобы он был на своем месте.
я например благодарен автору за такую форму представления очень важной и нужной информации. И здесь хочется процитировать великий труд «Хуайнань-цзы»
«В то время как глаз видит кончик осенней паутинки, ухо не слышит раскатов
грома; когда ухо прислушивается к звучанию нефритового цина, глаз не
видит и горы Тайшань. Когда воля устремлена на малое, тогда забываем
о большом.»
«В то время как глаз видит кончик осенней паутинки, ухо не слышит раскатов
грома; когда ухо прислушивается к звучанию нефритового цина, глаз не
видит и горы Тайшань. Когда воля устремлена на малое, тогда забываем
о большом.»
UFO just landed and posted this here
Я могу здесь вам разнести все вышеуказанные группы в категории элементов теории У-Син. Указать все взаимосвязи и взаимозависимости (положительные и отрицательные связи) каждой группы. Способы решения основных проблем коллективов программистов по принципу Мать-Сын. Но для Вас я думаю это будет просто гороскоп. А для китайской медицины — это тысячелетия изучения законов Природы. Конечно каждый смотрит со своей колокольни. И как сказано в Чжуан-цзы «С лягушкой, живущей в колодце, не поговоришь об океане, ведь она привязана к своей дыре, — ответил Дух Океана Жо. — Летней мошке не объяснишь, что такое лед, ведь она стеснена сроком ее жизни. С ограниченным ученым не поговоришь о Великом Пути — ведь он скован своим учением. Ты сейчас вышел из своих берегов, увидел великий Океан и понял свою ничтожность. Значит, с тобой теперь можно толковать о великой истине.» Только не обижайтесь.
Если Вы на практике например никогда не сталкивались с «эзотерическими творческими решениями», то Вам никогда понять например взаимоотношений линейщиков и рок звезд, и так можно продолжать и продолжать. У меня друган в ходит в пятерку людей по Союзу, который может конфигурить протокол x.25 и его железо. Понять таких людей не возможно — а только воспринимать как данность.
Послушайте, как нетрудно заметить — в статье специально не приведен метод "как за 10 минут понять кто перед вами", потому что я склонен считать что его нет, а тот кто заявляет что нашел его — тот лицемер. Нельзя на основе статьи взять и сделать классификатор. Надо сначала понять кто именно перед вами, а потом уже почитать что концептуально ожидать от человека. Т.е. если вы пытаетесь, как один коллега выше, сказать "ага, он не любит фрукты в офисе — значит точно делец" — то вы применяете статью неправильно.
25 лет в программировании — и правда очень точно все подмечено (учитывая что чистых типов почти нет)
Типажи, как было упомянуто, не абсолютные, но, как мне кажется, верно определено примерное количество. Если задать больше — будет размазано, меньше — не точно. А эти четыре, и их комбинации, действительно, могут описать, тип соискателя, обеспечив приемлемый и достаточный уровень точности в помощь кадровым работникам.
Данных описаний хватило, чтобы узнать в себе что-то от rock star, оттенки от lazy «дельца». Видимо как раз, если перемешать, добавить волшебный пендаль, то может из меня бы вышло что-то более стоящее :)
Спасибо за интересную статью и легкий стиль изложения.
Данных описаний хватило, чтобы узнать в себе что-то от rock star, оттенки от lazy «дельца». Видимо как раз, если перемешать, добавить волшебный пендаль, то может из меня бы вышло что-то более стоящее :)
Спасибо за интересную статью и легкий стиль изложения.
...
Гороскопы — теперь на Хабре! Ставь лайк, если узнал себя!
Восемь психотипов по Юнгу, шестнадцать психотипов по Майерс-Бриггс, четыре типажа программиста по Павлу Новикову…
Ребята, вы серьезно? Стоит помассировать любимую мозоль и все сразу забывают, что такое научный метод и почему «ну я со своей колокольни так вижу» — не аргумент?
Вы так пишете, будто я запрещаю вам взять в руки клавиатуру и сформулировать/написать лучше, чем я и мое жалкое графоманство :)
Он только что объяснил, почему этого не стоит делать ни вам ни ему, а вы тут же дали ему совет это сделать лучше, чем вы.
Ну просто совет сводится к тому, что "давайте не строить никаких классификаций — будем, как говорится, резать по живому". Мне такой подход кажется… маленько немасштабируемым. Люди в принципе склонны вешать ярлыки, потому как оценивать каждое явление заново — трудно и неудобно. Я и решил немного помочь проводящим собеседование в этом нелегком деле.
Если имеется в виду апелляция к корреляции статьи с реальностью — то, как было замечено, она-таки коррелирует. При том так, что люди вон узнают себя и коллег, при том не во всех 4х категориях одновременно, что отличает её от гороскопов, которые суть — юмористически обыгранная зависимость характера или ситуации от рандомных факторов (ИМХО) или просто общие слова.
Еще. Учтите такую важную вещь, пожалуйста, что человек "изнутри" воспринимает себя иначе, чем его воспринимают снаружи. Поэтому реакция "ну вот я же ни под одну категорию не подхожу!11" нормальна. Постарайтесь понять подходят ли ваши коллеги и поймете о чем я говорю. Да — вас тоже кто-то со стороны видит иначе, чем вы видите сами себя :)
Из крайности в крайность бросаетесь. Классификация нужна — без нее не сориентироваться. Но комбинации классификаций не нужны. Потому что как только вы добавляете туда что-то неатомарное, а какую-то структуру (рок-стар любит делать только то, что хочет + фантастические зарплатные ожидания), то сразу эта группа становится нерабочей, потому что те, кто туда попадают как люди, любящие делать, что хотят, но не требующие денег, сразу оттуда и вылетают. А кто не вылетел из-за зарплатных ожиданий, тот вылтеит по списку других определений этой группы.
В результате получается, что люди отдельно, классификация отдельно и все классификационные группы стоят пустые и ни в одну не попадает ни один человек. Тогда зачем они нужны?
Ведь основной практический смысл — понять, как работать с конкретной группой. А в группе никого — по данной схеме не с кем работать. А чтобы работать с теми, кто не в группе, подходы не описаны.
А вот если бы классификация была более атомарная и без комбинаций — тогда другой разговор. Или, на крайний случай, были бы все варианты комбинаций, а не только 4.
В любом случае, ваша статья очень интересная и читал я ее с удовольствием. То, о чем я пишу — лишь направление, куда можно дальше развивать классификацию.
В результате получается, что люди отдельно, классификация отдельно и все классификационные группы стоят пустые и ни в одну не попадает ни один человек. Тогда зачем они нужны?
Ведь основной практический смысл — понять, как работать с конкретной группой. А в группе никого — по данной схеме не с кем работать. А чтобы работать с теми, кто не в группе, подходы не описаны.
А вот если бы классификация была более атомарная и без комбинаций — тогда другой разговор. Или, на крайний случай, были бы все варианты комбинаций, а не только 4.
В любом случае, ваша статья очень интересная и читал я ее с удовольствием. То, о чем я пишу — лишь направление, куда можно дальше развивать классификацию.
(Рок-стар любит делать только то, что хочет + фантастические зарплатные ожидания), то сразу эта группа становится нерабочей, потому что те, кто туда попадают как люди, любящие делать, что хотят, но не требующие денег, сразу оттуда и вылетают.Нет, не вылетают, ведь классификация не строгая и деньги не являются определяющими…
Тут уже сравнивали классификацию с типами темперамента. Чистых темпераментов тоже мало, и для более полного описания нужны пограничные типы (флегматичный сангвиник и т.д.)
Но есть нюанс — здесь две шкалы(4 типа), а у автора статьи шкал больше, поэтому и типов должно бы получится больше.
Но шкалы у автора не независимы и потому некоторые типы почти не встречаются (либо какая-то шкала игнорируется) и автор ссылаясь на свой опыт выделяет 4 основных (на его взгляд). Можно конечно сделать «Деньги + делать, что хочешь»; «делать, что хочешь без денег»; «Деньги и делать, что скажут»; «Делать, что скажут без денег», но это только 2 шкалы…
Возможно вам больше понравилось бы если бы автор назвал все шкалы, расчертил бы n-мерный куб и показал бы о каких типах он рассказывает, но автор сделал так, как сделал и сказал:
Вы так пишете, будто я запрещаю вам взять в руки клавиатуру и сформулировать/написать лучше, чем я и мое жалкое графоманство
Гороскопы же здесь вообще никаким боком.
Гороскоп завязан на дате/звёздах/выдумке (даже теоретически невозможно описать как это
Классификация — на навыках/стиле работы/предпочтениях человека/и т.д.
Гороскоп не подразумевает изменения исходных данных для классификации (родился стрельцом — стрельцом и помрёшь)
Классификация подразумевает возможность перехода из одного типа в другой
Половина цитат не мои, а ответ мне :-)
Ну, давайте разбирать написанное.
Нет, совет сводится к тому, что „раз уж занимаемся составлением классификации — давайте делать это научно“.
Научный подход:
— вы придумываете с нуля (или берете за основу какую-то уже зарекомендовавшую себя как рабочую) некоторую теорию
— согласно придуманной теории вы строите классификацию со строгими критериями, по которым любого человека на собеседовании можно однозначно отнести к тому или иному классу
— для каждого из классов вы составляете некоторое конкретное предсказание (например: „этот класс склонен к авантюризму, уволится в течении 6-12 месяцев“ или „представители этого класса имеют тенденцию к забиванию болта на работу“)
— вы собираете статистику: вы проводите 100500 собеседований и, согласно заполненному опроснику, причисляете кандидата к тому или иному классу + берете на работу ВСЕХ подходящих по квалификации (чтобы исключить ошибку выжившего), не опираясь на вашу классификацию
— если по истечении оговоренного срока ваше предсказание для класса кандидата сбылось (ушел из фирмы или начал класть болт) — вы ставите галочку в перечне кандидатов „предсказание сбылось“
— по окончанию некоторого заранее установленного периода эксперимента вы смотрите статистику:
Если точность предсказаний 50-60% — поздравляю, ваша теория не работает, нужно придумывать заново. Если 80+% — отлично, вы близки к истине — можно показать коллегам по цеху.
Не научный метод:
— Исходя из личного опыта подогнать выборку задним числом и составить классификацию без четких критериев классов.
Первый метод даст рабочую классификацию, второй просто покажет некоторую статистику, взятую из вашего личного опыта. Статистику можно принять к сведению, но никаких выводов из нее делать не стоит, т.к. выборка непонятна (пол/возраст/местность), а методология, на которую вы опирались при сборе статистики, не озвучена.
Как вам такая классификация: „На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят“. Абсолютно точна, но не несет предсказательной ценности.
совет сводится к тому, что «давайте не строить никаких классификаций..
Нет, совет сводится к тому, что „раз уж занимаемся составлением классификации — давайте делать это научно“.
Научный подход:
— вы придумываете с нуля (или берете за основу какую-то уже зарекомендовавшую себя как рабочую) некоторую теорию
— согласно придуманной теории вы строите классификацию со строгими критериями, по которым любого человека на собеседовании можно однозначно отнести к тому или иному классу
— для каждого из классов вы составляете некоторое конкретное предсказание (например: „этот класс склонен к авантюризму, уволится в течении 6-12 месяцев“ или „представители этого класса имеют тенденцию к забиванию болта на работу“)
— вы собираете статистику: вы проводите 100500 собеседований и, согласно заполненному опроснику, причисляете кандидата к тому или иному классу + берете на работу ВСЕХ подходящих по квалификации (чтобы исключить ошибку выжившего), не опираясь на вашу классификацию
— если по истечении оговоренного срока ваше предсказание для класса кандидата сбылось (ушел из фирмы или начал класть болт) — вы ставите галочку в перечне кандидатов „предсказание сбылось“
— по окончанию некоторого заранее установленного периода эксперимента вы смотрите статистику:
Если точность предсказаний 50-60% — поздравляю, ваша теория не работает, нужно придумывать заново. Если 80+% — отлично, вы близки к истине — можно показать коллегам по цеху.
Не научный метод:
— Исходя из личного опыта подогнать выборку задним числом и составить классификацию без четких критериев классов.
Первый метод даст рабочую классификацию, второй просто покажет некоторую статистику, взятую из вашего личного опыта. Статистику можно принять к сведению, но никаких выводов из нее делать не стоит, т.к. выборка непонятна (пол/возраст/местность), а методология, на которую вы опирались при сборе статистики, не озвучена.
… она-таки коррелирует. При том так, что люди вон узнают себя и коллег ...
Как вам такая классификация: „На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят“. Абсолютно точна, но не несет предсказательной ценности.
Вот с предсказательной частью:
»На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят.
Первые в большинстве своем будут одну-две руки.
Вторые же — один-два глаза."
Вуаля — имеем уже рабочую и точную классификацию.
Почему работает совершенно точно (исключения — небольшой процент людей, лишившихся 2 конечностей/глаз)?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
Почему не имеет никакой ценности?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
Первые в большинстве своем будут одну-две руки.
Вторые же — один-два глаза."
Вуаля — имеем уже рабочую и точную классификацию.
Почему работает совершенно точно (исключения — небольшой процент людей, лишившихся 2 конечностей/глаз)?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
Почему не имеет никакой ценности?
— Потому что подогнана к уже имеющейся статистике
— Потому что предсказания для классов не взаимоисключающие
— Потому что предсказания размыты и не дают по сути точной картины
Вот с хорошей предсказательной частью:
«На свете существует два типа людей: те, которые делят людей на типы и те, которые не делят.
Первые в большинстве умные.
Вторые — дураки.»
Почему классификация «хороша» с моей точки зрения:
— Предсказания для совокупности классов взаимоисключающие
— Предсказания довольно однозначны
— Легко проверить
Почему не имеет никакой ценности?
— Потому что при проверке предсказаний имеем процент успешных предсказаний в районе 50% (не работает).
Первые в большинстве умные.
Вторые — дураки.»
Почему классификация «хороша» с моей точки зрения:
— Предсказания для совокупности классов взаимоисключающие
— Предсказания довольно однозначны
— Легко проверить
Почему не имеет никакой ценности?
— Потому что при проверке предсказаний имеем процент успешных предсказаний в районе 50% (не работает).
К вам как к автору статьи претензий никаких — вы написали статью, ее тепло приняло сообщество, значит статья сообществу понравилась.
Меня просто смутила эта самая позитивная реакция сообщества на гороскоп с этой замечательной оговоркой в конце «ну, на самом деле в чистом виде встречаются редко, чаще — комбинации».
Я просто оставлю это тут: Эффект Барнума
Меня просто смутила эта самая позитивная реакция сообщества на гороскоп с этой замечательной оговоркой в конце «ну, на самом деле в чистом виде встречаются редко, чаще — комбинации».
Я просто оставлю это тут: Эффект Барнума
Если хотите науки… если взять например гештальтпсихологию/гештальттерапию, там да, действительно, такого феномена как характер нет (ибо всё ситуативно или запрограммированно прошлым опытом циклов контактов). Если взять психоанализ, там тоже нет типизаций особых, есть структура личности (ну эти там ид, эго, суперэго). Нет типизаций и в НЛП (кроме пожалуй по ведущим системам). А вот в той же клинике типизаций много (начиная от невротиков-пограничников, и заканчивая психиатрическими классификациями, которых вагон).
Я скорее поддержу то, что классификация поведения людей — это весьма чрезмерное упрощение. Но и поддержу автора тем, что наше общество, несмотря на индивидуальность каждой личности, имеет характерные паттерны (аутсорсинговые и продуктовые «ООО», типичные клиенты и договора, практики и прочее), в которых люди действуют достаточно однообразно — в зависимости от их прошлого бэкграунда и социальных ограничений. Также не думаю, что автор претендовал на научное открытие, скорее на некоторый entertainment с моралью на выбор.
Один человек (я могу и про себя это сказать) в разных компаниях и коллективах и в разном возрасте может являться в различных ипостасях. Где-то я тяну только на пассажира, а где-то на звезду. Более того, в одной компании (я выше про себя писал) человек может меняться. С точки зрения психологии вся описанная картинка динамична, как в рамках групп, так и в рамках отдельного человека.
Я скорее поддержу то, что классификация поведения людей — это весьма чрезмерное упрощение. Но и поддержу автора тем, что наше общество, несмотря на индивидуальность каждой личности, имеет характерные паттерны (аутсорсинговые и продуктовые «ООО», типичные клиенты и договора, практики и прочее), в которых люди действуют достаточно однообразно — в зависимости от их прошлого бэкграунда и социальных ограничений. Также не думаю, что автор претендовал на научное открытие, скорее на некоторый entertainment с моралью на выбор.
Один человек (я могу и про себя это сказать) в разных компаниях и коллективах и в разном возрасте может являться в различных ипостасях. Где-то я тяну только на пассажира, а где-то на звезду. Более того, в одной компании (я выше про себя писал) человек может меняться. С точки зрения психологии вся описанная картинка динамична, как в рамках групп, так и в рамках отдельного человека.
которых вагон
— Это классификации отклонений от некоторой абстрактной «нормы» (читай болезней), а не людей.
— Эти классификации мало что говорят о самом пациенте — они по большому счету определяют подход к лечению и режим содержания.
— Эти классификации утверждены комитетно: много ученых мужей собрались вместе, поделились статистикой и договорились о том, что вот таких вот можно не лечить, вот этим вот — побольше седативов и все ок, а вот этих — принудительно и только с диспансеризацией, иначе делов натворят.
оффтоп
Вы же согласитесь, что высказывание «сотрудник, больной гриппом менее производителен, чем здоровый сотрудник» не верно? Чтобы оно стало верным, его необходимо привести к форме «сотрудник, больной гриппом, с большой вероятностью будет менее производителен, чем этот же сотрудник, но здоровый».
То есть при приеме на работу учитывать пункт «как часто болеете?» для сравнения сотрудников можно только в совокупности с пунктом «сколько кубометров леса рубите в день, когда здоровы?».
То есть при приеме на работу учитывать пункт «как часто болеете?» для сравнения сотрудников можно только в совокупности с пунктом «сколько кубометров леса рубите в день, когда здоровы?».
Где-то я тяну только на пассажира, а где-то на звезду
Что и показывает «гороскопичность» данной классификации. Невротик останется невротиком, если не вылечить. Шизофреник не может вдруг стать биполярником на недельку (при этом перестав быть шизофреником).
Если классификация «плавает» на одном человеке ото дня ко дню (как, например, та же Майерс-Бриггс), значит у нее нет предсказательной ценности — можно с таким же успехом принимать/не принимать на работу, основываясь на цвете кожи или еще какой херне, в духе «я слышал, что в вашем районе сплошной криминал и живут одни дураки и пьяницы — брать не буду, что время зря терять?».
Если в классификации много аутлайеров — нужно либо допиливать классификацию так, чтобы они исчезли, либо не использовать ее, а не прикрываться общими фразами вида «ну, аутлайеры встречаются постоянно, но если их отнести к двум-трем классам сразу — то все вроде как норм».
entertainment с моралью на выбор
Я повторюсь: статья в плане чтива хороша — автор делится каким-то опытом и читателю это нравится, ибо опыт похож на его собственный. Он жмакает плюсик. Всем приятно.
Но когда читатель при этом говорит «Ухх ты, ну прям про меня, только здесь чуть-чуть неверно» — типичное проявление эффекта Барнума (из-за размытых описаний класоов), на что я и попытался обратить внимание.
Есть очень хорошая книга про структуру личности в психоанализе. Один из вариантов классификации и довольно полный там тоже есть — www.group-analysis.ru/publications/Nancy_McWilliams/Nancy_McWilliams_PSYHOANALYTIC_DIAGNOSIS_Understanding_Personaly_Structure_in_the_Clinical_Process.php
Описал почему статья такая, какая есть вот тут
Гороскопы основаны на «звездах», а эта классификация на особенностях психики человека. Связь между звездами и поведением человека я найти не могу, а вот связь между психологией и поведением вполне понятна.
Кроме этого, эта классификация согласуется со многими другими. Я давно заметил, что если несколько человек независимо «изобретают» похожие модели, то это значит, что модели «работают».
Кроме этого, эта классификация согласуется со многими другими. Я давно заметил, что если несколько человек независимо «изобретают» похожие модели, то это значит, что модели «работают».
классная статья, немного смахивает на гороскоп )))
Узнал себя и коллег в описании, я так думаю ))
Узнал себя и коллег в описании, я так думаю ))
Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им.
…
Круглый (хотя бы овальный) отличник.
Вася Пупкин с детства слушался учителей и родителей, усердно делал все задания, даже самые неинтересные и старался учиться на одни пятёрки. А потом, внезапно, зазвездился и начал заниматься только тем, что интересно ему.
Логично, что уж.
Я еще раз говорю — нет плохих типажей. Вероятно Вася Пупкин хорошо решает интересные ему задачи — и по закону больших чисел он рано или поздно встретит своего работодателя. :)
Мне кажется, вы путаете причины и следствия.
«Rock Star», скорее всего, будет отличником, но не обязательно отличник станет «Rock Star». Тот тип отличника, который вы описали, скорее всего, станет линейным программистом, ну или вообще не станет программистом.
Отличники они тоже разные бывают)
«Rock Star», скорее всего, будет отличником, но не обязательно отличник станет «Rock Star». Тот тип отличника, который вы описали, скорее всего, станет линейным программистом, ну или вообще не станет программистом.
Отличники они тоже разные бывают)
Rock star, скорее всего, не будет отличником, потому что для этого нужно делать много всякой нудной и неинтересной работы типа домашних заданий, изучения неинтересных предметов, какое нибудь обязательное посещение лекций или другая ерунда.
Зависит от кругозора человека и его способностей. Есть рокстары-пятьнольщики, а есть — двоечники. Знаю по нескольку рокстаров обоих типов. Первые с лёгкостью тянут заломную математику, это именно они придумывают новые математические теории и воплощают их в жизнь. Вторые же зациклены исключительно на программировании. Несмотря на то, что они не способны создавать вещи, которые создают первые, они обычно более успешны.
Отличник != придумывать новые теории. Зачем-то нужно ещё запоминать странные факты, чтобы получить зачёт по истории, например, или правила грамматики английского языка. В целом, конечно, в ВУЗе намного проще с этим, чем в школе — на диплом влияют далеко не все предметы.
> Отличник != придумывать новые теории
А что в вашем понимании отличник? Есть студенты, у которых просто пятёрок больше, чем остальных цифр. Если студенты с красными дипломами. А есть абсолютные отличники — только пятёрки по всем предметам.
Так вот последние — очень специфические люди и работать с ними традиционными способами практически невозможно.
А что в вашем понимании отличник? Есть студенты, у которых просто пятёрок больше, чем остальных цифр. Если студенты с красными дипломами. А есть абсолютные отличники — только пятёрки по всем предметам.
Так вот последние — очень специфические люди и работать с ними традиционными способами практически невозможно.
Красный диплом.
Как ни странно, но люди с красными дипломами часто бывают пассажирами, которые просто умеют сдавать экзамены. А вот абсолютные отличники — это рокстары.
Красный диплом.
Не показатель.
Во первых есть такое понятие «склонен к завышению» — если человек хорошо учился с самого начала, когда все было просто, то в дальнейшем преподы его тянут на красный диплом.
Во вторых примеров, когда программер с красным дипломом даже не программером стал работать, попытался, но выяснилось, что не смотря на диплом он не программер все же — более чем достаточно.
Есть вузы, где можно получить красный диплом почти без усилий. Нужно просто хорошо сдать экзамены, что rock star вполне по силам
Но он может быть дофига умным, так что будет справляться с этим без проблем.
Встречал рокстаров обеих категорий — большая часть либо не доучилась в вузе по указанным вами причинам, либо были троечниками-пофигистами, но часть доучилась, и даже на красный диплом. Потому что им просто было это легко и ненапряжно, пока все другие потели и тужились — они по-быстрому ловили свои зачеты автоматом и шли заниматься более интересными вещами.
Встречал рокстаров обеих категорий — большая часть либо не доучилась в вузе по указанным вами причинам, либо были троечниками-пофигистами, но часть доучилась, и даже на красный диплом. Потому что им просто было это легко и ненапряжно, пока все другие потели и тужились — они по-быстрому ловили свои зачеты автоматом и шли заниматься более интересными вещами.
Потому что им просто было это легко и ненапряжно, пока все другие потели и тужились — они по-быстрому ловили свои зачеты автоматом и шли заниматься более интересными вещами.Именно так. Я в МГУ учился и мне было невероятно обидно, когда на третьем курсе я не смог уехать к родственникам на каникулы до Нового Года из-за того, что не сдал экзамен. Один.
Просто на всякий случай: в те времена, когда когда я там учился первый экзамен официально сдавался 2-3го января.
известны случаи когда дальнобойщики становились разработчиками на PHP
Хех… я с одним бывшим таксистом работал, которому надоело работать в такси, он прочитал книжку по PHP и пошёл программистом работать.
Доброго времени. А по возрасту есть какая-нибудь классификация? Ведь в молодости и "море по колено" и "горы по плечу", в зрелом возрасте и лениво и "сам с усам"
А что не так с люками то? Вроде всем понятно зачем они круглые )))
Видел где-то классификацию в другой плоскости (исполнительской чтоли), может даже на хабре. Приводились следующие типажи: парень 90% (проблемы с завершением), любитель библиотек (добавление огромного количества библиотек для решения всего), оптимизатор (многократное и усердное переписывание кусков кода для достижения лучших показателей везде), дальше память подводит.
Насколько такая типизация существенна в выборе персонала?
Насколько такая типизация существенна в выборе персонала?
Обычно не очень люблю не технические статьи на хабре, но эту просто «выпил» огромными глотками, спасибо, очень понравилось!
Статья понравилась. Вот только по-моему линейные программисты не совсем такие простые и линейные ребята. На самом деле эти скрытные Кибальчиши могут потихому пилить свой собственный проектик в личное время, впрочем и в неличное тоже: как отдушину от серых будней. И через это развивать свои навыки, что на самом деле плюс, т.к. впоследствии положительно отражается на основной работе. Одного такого программера я знаю.
Так что это может только со стороны кажется что линейщик застрял в 1с или FoxPro, а на самом деле он пилит свой проект имея стабильный доход на основной работе, это и ответ на вопрос почему он не дергается с насиженного места 20 лет.
Так что это может только со стороны кажется что линейщик застрял в 1с или FoxPro, а на самом деле он пилит свой проект имея стабильный доход на основной работе, это и ответ на вопрос почему он не дергается с насиженного места 20 лет.
Спасибо за статью. В ней возможно и не хватает, как Вы сказали, "второго измерения". Но оно усложнит восприятие. А так сохранена предельная простота. Я бы на Вашем месте (с Вашим опытом) добавил бы как и в каких ситуациях комбинировать эти типы в проектных комманды. Кто с кем эффективно уживается и работает. По аналогии с Юнгом, который не только предложил психотипы, но и показал их совместимость или несовместимость. Очевидно есть ситуации, в которых только линейные программисты приведут к провалу. Только rockstars не попадут в требования, а дельцы не впишутся в бюджет, пассажиры сведут все к балагану. А смешанная комманды могла бы быть эффективна.
Я бы с радостью написал про комбинации, но увы. Мне пока никто не дал достаточно бюджета и простора для деятельности чтобы построить комбинированную и сбалансированную команду как я её вижу. Видимо для этого придется открывать собственную компанию. :( Но это тоже будет построение команды под какую-то конкретную задачу. И не факт, что она будет согласовываться с задачами у других игроков в индустрии.
очень жизненно. только не хватает 5 категории — мажор, это такой микс из рок стар и пассажира. очень много понтов, очень много знает, часто ненужного, очень много говорит, заносчив, высокомерен, на практике полный ноль.
Это еще одна статья про xored?
Не хватает классификации типа «творец» или «художник». У меня есть знакомый, которого приглашаем на работу по развитию новых проектов. Если ему интересна задача, то он ей займется за любой разумный гонорар. Сам изучит предметную область, реализует прототип, идентифицирует и раздаст задачи сотрудникам. Код, написанный им, можно распечатывать и вешать в рамочку на стену.Но как только все заработало и стало продаваться, он начинает терять интерес к проекту и передает бразды правления другим.
На этом, обычно, наше сотрудничество заканчивается до следующей интересной темы. К сожалению, не знаю чем он занимается в свободное время, но вроде пилит что-то свое.
Интересно, что фундаментальное математическое образование у него слабое, что не мешает ему сформулировать задачу для профессионалов в этой области.
На этом, обычно, наше сотрудничество заканчивается до следующей интересной темы. К сожалению, не знаю чем он занимается в свободное время, но вроде пилит что-то свое.
Интересно, что фундаментальное математическое образование у него слабое, что не мешает ему сформулировать задачу для профессионалов в этой области.
Не добавили в статье самый распространенный/популярный у людей из других отраслей тип — тыжпрограммист
В дополнение — пару замечаний о коллективах разработчиков (О себе — 25 лет разработки, типичный линейщик, красный диплом, не отличник)
— линейные программисты — основа коллектива, его связующая ткань. Основная болезнь — постепенное одеревенинение, а затем и каменение. Самостоятельно болезнь не лечится.
— рок звезды — в малом количестве являются украшением коллектива. Не создают внутренних конфликтов. Линейные программисты снисходительно относятся к причудам характера рок звезд. Отсутствует конфликт между ними и линейщиками. Самое главное — не дают линейщикам деревенеть, заставляя последних к внутреннему движению — т.е. являются лечением основной болезни линейщиков.
— пассажиры — в малом количестве играют важную роль в обеспечении взаимодействия основного коллектива (линейщики плюс рок звезды) с начальниками и прочее.
— дельцы — разрушают любой коллектив, так как по своей природной натуре не являются коллективными работниками. Привлечение дельцов оправдано только в случае «горящих» ситуаций. Создают внутренний конфликт с линейщиками, которые понимают что все равно задание упадет с дельцов на них по истечение какого-то времени. С дельцами эффективна торговля знаниями по принципу «ты мне — я тебе». Использование дельцов должно быть в отрыве от коллектива.
— линейные программисты — основа коллектива, его связующая ткань. Основная болезнь — постепенное одеревенинение, а затем и каменение. Самостоятельно болезнь не лечится.
— рок звезды — в малом количестве являются украшением коллектива. Не создают внутренних конфликтов. Линейные программисты снисходительно относятся к причудам характера рок звезд. Отсутствует конфликт между ними и линейщиками. Самое главное — не дают линейщикам деревенеть, заставляя последних к внутреннему движению — т.е. являются лечением основной болезни линейщиков.
— пассажиры — в малом количестве играют важную роль в обеспечении взаимодействия основного коллектива (линейщики плюс рок звезды) с начальниками и прочее.
— дельцы — разрушают любой коллектив, так как по своей природной натуре не являются коллективными работниками. Привлечение дельцов оправдано только в случае «горящих» ситуаций. Создают внутренний конфликт с линейщиками, которые понимают что все равно задание упадет с дельцов на них по истечение какого-то времени. С дельцами эффективна торговля знаниями по принципу «ты мне — я тебе». Использование дельцов должно быть в отрыве от коллектива.
Про дельцов не совсем верно. Делец — это руководитель, а не исполнитель. В качестве CTO / тим-лида вполне может хорошо работать. Дайте ему зарплату и высокую премиальную часть за достижение показателей и он может ориентировать команду на достижение результатов. Главное, чтобы «делец» хотя-бы немного оставался «человечным» и не шел к успеху по трупам коллег.
Делец — будет работать ВСЕГДА только на себя. Ему интересен только свой рост (знаний и денежный). Тим-лид подразумевает ответственность за коллектив. На этой должности как указывали другие хороши совместный тип пассажир+линейщик(перевес пассажира). Раньше были еще очень немногочисленный класс архитекторы задач(не путать со scrum master). Которые направляли ownerов и взаимодействовали с линейщиками. Это тоже совместный тип линейщик+пассажир(перевес линейщик).
Думаю, мы с вами просто по разному определяем «дельца». Ваш «делец» — крайний случай индивидуализма. Это, например, внешний консультант. Ему ваша компания и команда, действительно, по барабану. Мой «делец» — это ваш + немножко ориентации на людей. Таких дельцов еще меньше, чем индивидуалистов, но они все-таки есть. Если чуть-чуть изменить ваш комментарий:
Делец — будет работать СКОРЕЕ ВСЕГО только на себя.то я согласен.
если посмотреть на мой пройденный опыт — то Ваша оценка верна
Хотя не обязательно, что это будет внешний консультант. Работодатель часто нанимает таких людей — пытаясь за короткий срок работы с ними выжать из него знания по принципу «ты нам знания, мы тебе деньги и знания»
Хотя не обязательно, что это будет внешний консультант. Работодатель часто нанимает таких людей — пытаясь за короткий срок работы с ними выжать из него знания по принципу «ты нам знания, мы тебе деньги и знания»
Единственная проблема работы с дельцами — то, что они хранят свои знания. Потому что это их деньги. Линейщики миряться с этим как с неизбежным злом. Но реально вытащить знания с дельцов — это отдельная наука. Легче заинтересовать рок звезду и потом понять их решения.
Я делец (исходя из этой статьи/классификации). Уже 4 года к ряду одна и та же фирма/позиция. И да, в львиной доле это накачка в первую очередь себя. Пока что не деньгами, но очень большим багажом знаний. А собеседования и вакансии, что предлагают мне/что прохожу — это уже примерно 200к/мес. Для Сибири очень вкусно. Но мой ориентир — глобальный рынок.
Внутри фирмы у меня «выделенный проект»(вроде как и «тестирование», но просто крайне сильно тюнингованное) — вижу это симбиозом, ибо нет многих ограничений, я же выдаю эксклюзивный «товар» (спец ПО) + благодаря максимально возможной свободе могу качать навыки без остановки все эти годы.
С фирмой стабильные отношения — исключительно положительное мое мнение как о конторе, так и об отделе, с которым работаю. Учитывая гибкий график — я и дальше собираюсь работать с этими людьми (т.е. вот так «взять и бросить» в планы мои не входит явно). Это отличный резервный аэродром. Что я использую ради решения проблем, носящих «стабильный характер» (читать как минимальная плашка закрытия фин-потребностей). Для качественных финансовых рывков — другие фирмы параллельно.
Внутри фирмы у меня «выделенный проект»(вроде как и «тестирование», но просто крайне сильно тюнингованное) — вижу это симбиозом, ибо нет многих ограничений, я же выдаю эксклюзивный «товар» (спец ПО) + благодаря максимально возможной свободе могу качать навыки без остановки все эти годы.
С фирмой стабильные отношения — исключительно положительное мое мнение как о конторе, так и об отделе, с которым работаю. Учитывая гибкий график — я и дальше собираюсь работать с этими людьми (т.е. вот так «взять и бросить» в планы мои не входит явно). Это отличный резервный аэродром. Что я использую ради решения проблем, носящих «стабильный характер» (читать как минимальная плашка закрытия фин-потребностей). Для качественных финансовых рывков — другие фирмы параллельно.
Молодец!!! Все познается в сравнении. Когда у вас появится сразу несколько предложений развития одновременно внимательно всмотритесь в себя и в людей. Основная болезнь дельцов — «жадность» (может быть к Знаниям или Деньгам или к чему нибудь другому). И в этом они всегда всегда впереди. И это может заслонить у них все. Но слабы они во ВЛАСТИ — это уже прерогатива другого типажа.
Когда у вас появится сразу несколько предложений развития одновременно внимательно всмотритесь в себя и в людей
Так уже бывало. Причем пару раз. Оба за время работы в текущей фирме.
Первый раз когда произошло — впервые же пошел работать сразу на две фирмы. В основной об этом я заявил спустя месяц-полтора работы на вторую. В начале были сильно подозрительны и недовольны. Спросили «когда увольняешься?». Я ответил «в планах такого нет — я просто могу себе позволить доп.нагрузку, почему бы и нет?». С тех пор я систематически каждый год работаю где-то еще. Таким образом с одной стороны я имею почти железобетонную уверенность в том, что на хлеб с маслом будет «всегда». А на «ламборгини» надо «попотеть». Но при этом я свободен — могу без проблем как раз уже из доп.фирм уйти (однако завершив задачу полностью), могу менять сферы внутри IT. Ведь это всегда разные проекты и разные стеки технологий! Красота же!
А вот второй случай (вилка) был совсем недавно — предложили место уже в очень-очень большой и богатой фирме на западе. И тут я был в раздумьях очень конкретных. Увы, «там» моей «воле» придет условный конец. А я видимо еще не особо нагулялся. К тому же есть предпосылки и к тому, чтобы уже иметь свое дело (да, как и описано было в топике) — мысли настойчиво свербят в голову уже много времени. Отчасти это и есть причина того, зачем в первую очередь впитываю губкой знания и опыт — скоро (в масштабах годов) будет весьма полезным при выборе клиентов.
P.S. А слабость у меня к другому — отменное жилье (что-нибудь из top-high-tech), BMW, бабы (куклы барби, с силиконовыми шариками). Деньги — только инструмент для меня.
Делец — это руководитель, а не исполнитель.
Во вне привязке к профессии программиста — да.
Но с точки зрения типажей — это обязательно квалифицированный программист.
Он совсем не обязан быть руководителем.
Фриленсеры, к примеру.
Я не о тех, что крохи подбирают и перебиваются с хлеба на воду, а о квалифицированных и успешных
Вы правы. Точнее сказать у дельца больше шансов стать руководителем. Он лучше понимает значения слов «ограничения», «ответственность», «результат» и приемлет риск.
Если делец умеет сходиться с людьми и увлекать их за собой, то он открывает компанию. Если он четко понимает, что брать ответственность не только за себя, но и за других — не его, то остается успешным фрилансеров (self employeed). Нельзя сказать, что одно лучше другого: люди разные, каждому — свое.
Если делец умеет сходиться с людьми и увлекать их за собой, то он открывает компанию. Если он четко понимает, что брать ответственность не только за себя, но и за других — не его, то остается успешным фрилансеров (self employeed). Нельзя сказать, что одно лучше другого: люди разные, каждому — свое.
дельцы — разрушают любой коллектив, так как по своей природной натуре не являются коллективными работниками. Привлечение дельцов оправдано только в случае «горящих» ситуаций. Создают внутренний конфликт с линейщиками, которые понимают что все равно задание упадет с дельцов на них по истечение какого-то времени. С дельцами эффективна торговля знаниями по принципу «ты мне — я тебе». Использование дельцов должно быть в отрыве от коллектива.
Конфликтовали лично с этим типом отсюда такое отношение?
Делец в понимании автора статьи — это еще и крепкий технический специалист, а не просто бизнесмен.
Делец в моем понимании выдает вполне качественный результат, так как думет и о своем будущем, закладывает себе фундамент под будущее взаимодействие с этой фирмой, заботся о репутации, она еще принесет ему денег — и даже если результат работы дельца упадет потом на поддержку линейщиков — это не будет обязательно страшным говнокодом.
Нет не конфликтовал — и Вы совершенно правы, что Дельцы выдают очень качественный продукт. Если было бы не так — то они бы не зарабатывали столько. Их очень легко отличить от других тем, что я указывал — они БЕРЕГУТ свои ЗНАНИЯ и просто так УДОЧКОЙ с Вами не поделятся, а вот РЫБЫ вам «продадут» сколько угодно. Вот это вызывает внутреннее напряжение у линейщиков, работающими с Дельцами и только у них. В термине Делец нет ничего обидного или плохого. Главное их достоинство — они СОБИРАТЕЛИ и ХРАНИТЕЛИ знаний. Но как и любой метал, который разрушается от внутреннего напряжения — так и Дельцы изнутри разрушают коллективы. Линейщики обособляются, нарастают конфликты уже между ними — и все коллектива нет.
они БЕРЕГУТ свои ЗНАНИЯ и просто так УДОЧКОЙ с Вами не поделятся, а вот РЫБЫ вам «продадут» сколько угодно.
Знания технического характера, не сказал бы — тут больше зависит есть ли у дельца склонность к учительству, к передаче знаний новым поколениям или нет.
Мне нравится учить молодежь.
Знания как добывать деньги…
Ну скажем, я, работая на фриленсе уже много лет — только и делал, что уговаривал своих друзей бежать из контор, рассказывал о ньюансах.
Знаниями такого свойства делиться дельцу безполезно с другим типажом программистов — на то он и другой типаж.
Я учился в классе (в советское время) — в котором собрали одних отличников, ну и хорошистов для дополнения. Это страшное дело я вам честно признаюсь. Ни чьим детям этого не пожелаю.
Есть мнение, что слишком смешали теплое с мягким (личностные и профессиональные качества). Не уверен, что существует явная корреляция любви к фруктам в офисе с психотипом человека, там может быть много факторов :)
Само собой, но послушайте. Когда вы нанимаете человека — вы нанимаете не набор навыков и не машину, а живого человека со своими особенностями, в т.ч. не относяшимся к профессии напрямую. Я просто счел нужным предупредить какие основные типажи встречаются и чего от них ожидать (не только в плане работы)
Тут не фрукты как таковые, а «соцпакет» в целом. Кто-то считает его бесплатным бонусом, а кто-то в уме подсчитывает сколько эти «бонусы» стоят на рынке, сколько личного времени он будет тратить на их получение и сравнивает оценки.
интересно, спасибо
Когда-то я был Rock star, а теперь просто стар.
P.S. Шутка. Рокстаровцы так просто не сдаются!
P.S. Шутка. Рокстаровцы так просто не сдаются!
UFO just landed and posted this here
подробнее читайте про 4 касты людей, они в жизни везде, даже в наше время.
Я думаю, забыли один «чистый» тип («дельца» я считаю комбинацией, причем «дельцы», сдается мне, еще и бывают разные)
«Педант» или «Поборник чистоты».
Встречается редко, в основном в корпоративной среде. Не пропустит ни один пулл реквест с отклонениями от корпоративных стандартов, пусть даже это будут лишние пробелы в конце строки. После ревью «педанта» джуниор может получить десятки или сотни развернутых комментариев и следующий реквест прислать только на следующий день.
Обожает статические анализаторы, тесты, гайдлайны, всегда первым делом настраивает CI и автоматизирует выкладку. К сожалению из-за внимания к мелочам страдает недостатком производительности.
Не давайте ему задачи, требующие «хуяк-хуяк и в продакшн», он вас разочарует. Лучше всего объедините его в команду с Rock Star для решения mission critical — задач. «Педант» без труда отыщет все мелкие проблемы, которые Rock Star с высоты своего полета не разглядит. Кроме, этого он забракует все эзотерические творческие решения, чем заметно облегчит поддержку в будущем.
Только не забудьте выделить им кабинет со звукоизоляцией. В особенно сложных случаях, подключайте в команду «пассажира», чтобы тот следил, чтобы эти двое не поубивали друг друга.
В свободное от критики рок звезд время может на 100% быть загружен код-ревью младших специалистов. Он быстро приучит их к дисциплине. А вот в команде с линейными программистами он будет выглядеть вяло. Команда будет справедливо отмечать, что производительность «педанта» может быть в разы ниже средней по больнице. Код-стайл и скобки — вещь конечно важная, но не важнее достижения целей проекта.
«Педант» или «Поборник чистоты».
Встречается редко, в основном в корпоративной среде. Не пропустит ни один пулл реквест с отклонениями от корпоративных стандартов, пусть даже это будут лишние пробелы в конце строки. После ревью «педанта» джуниор может получить десятки или сотни развернутых комментариев и следующий реквест прислать только на следующий день.
Обожает статические анализаторы, тесты, гайдлайны, всегда первым делом настраивает CI и автоматизирует выкладку. К сожалению из-за внимания к мелочам страдает недостатком производительности.
Не давайте ему задачи, требующие «хуяк-хуяк и в продакшн», он вас разочарует. Лучше всего объедините его в команду с Rock Star для решения mission critical — задач. «Педант» без труда отыщет все мелкие проблемы, которые Rock Star с высоты своего полета не разглядит. Кроме, этого он забракует все эзотерические творческие решения, чем заметно облегчит поддержку в будущем.
Только не забудьте выделить им кабинет со звукоизоляцией. В особенно сложных случаях, подключайте в команду «пассажира», чтобы тот следил, чтобы эти двое не поубивали друг друга.
В свободное от критики рок звезд время может на 100% быть загружен код-ревью младших специалистов. Он быстро приучит их к дисциплине. А вот в команде с линейными программистами он будет выглядеть вяло. Команда будет справедливо отмечать, что производительность «педанта» может быть в разы ниже средней по больнице. Код-стайл и скобки — вещь конечно важная, но не важнее достижения целей проекта.
Я просто оставлю это здесь. Эффект Барнума
Интересная статья, прочитал на одном дыхании. Спасибо, автор!)
Интересно, а могут ли внешние факторы быть причиной смены типажа?
К примеру, работал человек в аутсорсе, клепал скучные задачи линейно. А потом перешёл в компанию, развивающую свой продукт, и стал rock star.
К примеру, работал человек в аутсорсе, клепал скучные задачи линейно. А потом перешёл в компанию, развивающую свой продукт, и стал rock star.
Думаю вряд ли, переход из линейного в дельцы или пассажира возможен, а вот в rock start нереально, так как там нужны качества которые врожденные и были изначально.
А если он изначально был rock start, но его взяли на скучные задачи? Естественно он повел себя как линейный. В такой классификации очень большое влияние оказывает где работает человек. Если в конторе делают только скучные задачи и эта контора единственная куда его взяли…
> А если он изначально был rock start, но его взяли на скучные задачи? Естественно он повел себя как линейный.
Нет. Рокстар бы приложил все возможные усилия, чтобы эти скучные задачи стали ему интересными. Фактически, эксперементировал бы за деньги работодателя, а не тупо писал код.
Нет. Рокстар бы приложил все возможные усилия, чтобы эти скучные задачи стали ему интересными. Фактически, эксперементировал бы за деньги работодателя, а не тупо писал код.
Сомневаюсь, если rock star взяли как линейного, через некоторое время он просто уйдет из-за рутины. Тут именно врожденные качества. Если их нет то не быть rock star увы и ах. Зато можно стать дельцом что я считаю довольно таки не плохо)
А как отличить кто он у начинающего программиста? У него же на лбу ничего не написано. А чтобы взяли как rock start нужен опыт и знания. Откуда их взять? Конечно же поработав вначале линейщиком.
> А как отличить кто он у начинающего программиста? У него же на лбу ничего не написано.
Очень просто. Если на простые вопросы смотрит на вас как на идиота — это рокстар.
> А чтобы взяли как rock start нужен опыт и знания.
Отличительная способность рокстара — это любознательность и желание исследовать. Без опыта рокстар не сможет писать поддерживаемый код — это факт. А вот отсутствие знаний здесь не помеха — рокстару, наоборот, будет интересно возиться в новой области.
> Откуда их взять? Конечно же поработав вначале линейщиком.
Ну хз, вот я, как типичный рокстар, ни разу не работал линейщиком. Более того, ни разу не работал фуллтайм и ни разу не работал в полноценной команде. И да, в команде работать очень тяжело — смотрю на других программистов как на говно.
Очень просто. Если на простые вопросы смотрит на вас как на идиота — это рокстар.
> А чтобы взяли как rock start нужен опыт и знания.
Отличительная способность рокстара — это любознательность и желание исследовать. Без опыта рокстар не сможет писать поддерживаемый код — это факт. А вот отсутствие знаний здесь не помеха — рокстару, наоборот, будет интересно возиться в новой области.
> Откуда их взять? Конечно же поработав вначале линейщиком.
Ну хз, вот я, как типичный рокстар, ни разу не работал линейщиком. Более того, ни разу не работал фуллтайм и ни разу не работал в полноценной команде. И да, в команде работать очень тяжело — смотрю на других программистов как на говно.
Вы разве не препод?
Нет. Терпеть не люблю преподавать.
А откуда так много информации об том как программируют неопытные
habrahabr.ru/post/319606
habrahabr.ru/post/319606
Потому что под преподаванием я понимаю подготовку материалов, чтение лекций, проведение семинаров. Это всё скучно и неинтересно.
Но т.к. я всё-таки работаю в университете, то падаваны мне нужны. И эта штука с заданиями, факически, и есть попытка определить, имеет ли смысл плодотворно работать со студентом или он не стоит потраченного времени.
Но т.к. я всё-таки работаю в университете, то падаваны мне нужны. И эта штука с заданиями, факически, и есть попытка определить, имеет ли смысл плодотворно работать со студентом или он не стоит потраченного времени.
Хм, оказывается помесь дельца и пассажира. Обидно(
Интересно, но есть у меня один знакомый, судя по этой статье — 100% пассажир, но я его хорошо знаю, тот ещё делец!
Что я хочу сказать, люди не только могут быть чуть-чуть того, чуть-чуть этого, они зачастую бывают совершенно не тем, чем кажутся на первый, на второй и даже на третий взгляд.
Что я хочу сказать, люди не только могут быть чуть-чуть того, чуть-чуть этого, они зачастую бывают совершенно не тем, чем кажутся на первый, на второй и даже на третий взгляд.
Очень доступно и понятно, спасибо!
Осознал себя махровейшим «гребцом»…
Осознал себя махровейшим «гребцом»…
Возьму на себя смелость представить свой классификатор программистов:
- мясники
- хирурги
- ювелиры
- художники
- маляры (ни в коем случае не обижаю представителей сей прекрасной профессии)
- искусствоведы
и другие...
Спасибо за статью, очень понравилось. Последний раз были такие яркие впечатления от прочтения Адизиса. Узнаёшь каждого персоонажа и понимаешь что всё так и есть, люди они все конечно уникальны, но с классификациями оно как-то легче живётся )
Это было познавательно. Спасибо за статью.
Что же, отлично описаны варианты встречавшиеся мне в жизни, да и себя нашел)
Можно даже сделать квадрат, где грани будут спектром между крайностями.
Можно даже сделать квадрат, где грани будут спектром между крайностями.
А почему про люки нельзя спрашивать никого? Хороший же вопрос на тест аналитических способностей (старенький, правда).
Не линейный программист, а кодировщик
Не делец, а разработчик
Не рок-звезда, а программист-исследователь
Пассажир — это типаж не программиста, а менеджера
А так все верно
Не делец, а разработчик
Не рок-звезда, а программист-исследователь
Пассажир — это типаж не программиста, а менеджера
А так все верно
А чем кодировщик от разработчика отличается?
Кодировщик кодирует части системы, обычно по точной спецификации, и может даже не понимать существо задачи. Идеал для аутсорсинга. Разработчик понимает задачу, создает алгоритм и раздает задания кодировщикам, если такие у него есть.
Разве делец не так же делает по спецификации?
Как вообще можно писать код не понимая существа задачи?
Как вообще можно писать код не понимая существа задачи?
Разработчик работает по техзаданию, которое обычно пишет сам со слов клиента и с ним согласовывает
Кодировщику не обязательно понимать задачу в целом, достаточно той части, которая ему поручена
Кодировщику не обязательно понимать задачу в целом, достаточно той части, которая ему поручена
Как вообще можно писать код не понимая существа задачи?
Грубый пример такой задачи "вот есть формула, пускай компьютер её считает. Ещё: "при кредите счёта 361 5% должно автоматически кредитовать счёт 378". И это примеры постановок от заказчика. Постановки задач от других программистов могут выглядеть вообще типа "твоя функция должна возвращать сумму вот этих двух столбцов этой таблицы при условии, что существует связанная запись по этим полям вот в этой таблице."
Присоединюсь:
Большинство программистов и не стремиться понимать существо задачи, если эта задача не чисто ИТ-шная.
Именно по этому многие программисты и не любят 1С — там все базовые вещи, понятные ИТ-шнику, типа логирования или отображения окон или работы с БД — решены на уровне платформы.
И программист не занимается этими далекими от прикладной области вещами. А занимается именно решением прикладных задач.
Вот тут то и возникает у программиста батхерт: «блииииин, дебет-кредит, это такая бухгалтерская муть».
Нам целые системы API проще вручную посоздавать вместо того чтобы решать конкретные прикладные задачи, далекие от ИТ-сферы.
Большинство программистов и не стремиться понимать существо задачи, если эта задача не чисто ИТ-шная.
Именно по этому многие программисты и не любят 1С — там все базовые вещи, понятные ИТ-шнику, типа логирования или отображения окон или работы с БД — решены на уровне платформы.
И программист не занимается этими далекими от прикладной области вещами. А занимается именно решением прикладных задач.
Вот тут то и возникает у программиста батхерт: «блииииин, дебет-кредит, это такая бухгалтерская муть».
Нам целые системы API проще вручную посоздавать вместо того чтобы решать конкретные прикладные задачи, далекие от ИТ-сферы.
Нет, 1С не любят по другой причине. Потому что когда прикладная задача на готовые базовые вещи "не налезает" — остается либо увольняться, либо писать костыли.
Инструментом надо пользоваться по назначению.
А не пытаться натянуть единственный инструмент на все возможные задачи.
Можно про «прикладная задача не налезает на базовые вещи» поподробнее? Пример. А то непонятно что вы именно имеете ввиду.
А не пытаться натянуть единственный инструмент на все возможные задачи.
Можно про «прикладная задача не налезает на базовые вещи» поподробнее? Пример. А то непонятно что вы именно имеете ввиду.
Точно не знаю, но где-то тут в комментариях мне рассказывали что стандартный клиент HTTP в 1C не умеет декодировать сжатые ответы. И для того чтобы такое обойти, некоторые одинэсники пишут вот таких монстров: https://infostart.ru/public/238584/
- По стандарту веб-сервер не должен посылать сжатый ответ, если клиент не выразил явным образом свое желание работать с сжатыми ответами.
- Описано расширение платформы 1С штатными средствами. Эта технология существует уже лет 20. Используется в тех редких случаях, когда необходим какой-то доп. функционал и одновременно требуется жесткая интеграция модуля с платформой 1С. Например, для подключения какого-либо специального оборудования.
- Я бы для обхода это косяка сервера (а не косяка клиента 1С) просто сделал бы http-прокси, а не стал бы делать внешнюю компоненту. но с начала — поигрался бы заголовками. А вдруг в каком то сочетании косячный веб-сервер начнет работать адекватно.
- Вы привели в пример специфическую задачу, не имеющую никакого отношения к прикладной области для работы в которой и создана платформа 1С. Собственно, вы и подтвердили мою гипотезу, что я высказал выше. Программистов, в массе своей, напрягает решение непосредственно прикладной задачи, если она далека от ИТ. Им бы попрограммировать понятные базовые вещи — http, к примеру.
То есть такой способ расширения считается нормальным?
Ну, это и объясняет почему 1С не любят.
То есть такой способ расширения считается нормальным?
Требовать/ожидать от веб-сервера работать по стандартам?
Это везде является нормальным.
Описанная проблема нестандартного веб-сервера не имеет отношения к прикладным задачам для решения которых и создана платформа 1С.
Только что проверил. Мне удалось получить с веб-сервера сжатые данные. Там просто нужно самому заголовок «Accept-Encoding: желаемый метод сжатия» в http-клиенте 1С выставить.
Сдается мне, что этим ребятам из вашей ссылки интереснее решать не прикладную проблему в 1С, а чисто понабивать скиллы в .NET. Иначе зачем тратить так много времени? Допускаю, что они недостаточно компетентны в 1С. Но при этом компетентны в .NET. Что и предопределило способ решения задачи.
Не могли бы вы в таком случае объяснить мне вот этот комментарий?
PS человек по ссылке — точно 1С-ник, а не C#-пер. Видно по русскому языку в идентификаторах.
PS человек по ссылке — точно 1С-ник, а не C#-пер. Видно по русскому языку в идентификаторах.
Не показатель.
Я тоже, когда начинал в 1С, всё писал на английском. Язык позвволяет. Вы можете писать «если тогда», а можете писать «if then».
Потому перестал. Потому что идентификаторы прикладной области слишком нетривиальные, чтобы писать их на неродном языке.
При том на языке Go, к примеру, у меня английские идентификаторы используются.
Контекст вашего разговора по ссылке непонятен.
Задайте прямой полный вопрос здесь.
Инструментом надо пользоваться по назначению.
А не пытаться натянуть единственный инструмент на все возможные задачи.
Увы, в случае именно с 1С наиболее характерно, что других инструментов особо и нет — или ограничение заказчика, или незнание других инструментов на уровне достаточном для соблюдения сроков/бюджета. На других платформах тоже встречается, на наиболее яркие случаи мне встречались именно в экосистеме 1С.
или незнание других инструментов
Ну дык знать то инструменты — задача разработчика.
А не заказчика.
И задача разработчика — показать имеющиеся альтернативы заказчику.
Предлагать инструменты достаточные для реализации задачи заказчика — задача разработчика. Выбор того разработчика, который предложит наиболее эффективные инструменты — задача заказчика. В задачу разработчика не входит предложение заказчику всех теоретически доступных инструментов для решения его задачи. Грубо — это задача аналитиков и менеджеров. Разработчик лишь сообщает заказчику (напрямую или через аналитиков): "с помощью таких-то инструментов, мы решим задачу в рамках таких-то технико-экономических рамок, с помощью других — в рамках таких-то, за решение задачи с помощью таких-то инструментов, которые по идее могут подойти, мы даже не возьмёмся, если знаете ещё какие-то — назовите, а мы оценим".
в случае именно с 1С наиболее характерно, что других инструментов особо
О чем тогда говорить?
Любое ПО может и должно быть лучше — хоть 1С, хоть Android. А толку об этом мечтать если нет альтернатив (ну и ты сам эту альтернативу не пилишь).
Я о том, что специалисты (или фирмы, специализирующиеся) по 1С, часто предлагают решения исключительно на базе 1С. Даже хранимку на SQL с которым 1С работает не предложат.
Ну как минимум — это очень и очень не круто в дальнейшей поддержке.
Имхо как раз хранимка — не то, ради чего стоит заморачиваться.
У меня вот есть СУБД на 1С интегрированная с отдельным веб-сервисом. Целый отдельный веб-сервис написать я еще понимаю смысл есть.
А хранимка — она забудется, потеряется, затрется при очередном обновлении 1С. То есть за ней нужно следить.
Имхо как раз хранимка — не то, ради чего стоит заморачиваться.
У меня вот есть СУБД на 1С интегрированная с отдельным веб-сервисом. Целый отдельный веб-сервис написать я еще понимаю смысл есть.
А хранимка — она забудется, потеряется, затрется при очередном обновлении 1С. То есть за ней нужно следить.
А это разве не запрещено лицензионной политикой 1С ?
1С не любят из-за того что это один огромный костыль. Если бы видели, что он посылает на SQL(не важно какой) сервер — вы просто матом изошли. Есть единственная толковая книга по 1С — называется «Профессиональная робота в 1с» вроде и там в некоторых местах мелким шрифтом пишут, что не надо делать на 1с — хотя до этого целые главы посвящены, что это и надо делать :) И работа с 1С возможно, если только выкинуть все из коробки и писать заново всю конфигурацию. Публикации ( infostart.ru/public/78413 и др )
Ровно такая же ситуация с запросами в развитых CMS. Ровно такая же проблема будет с любой универсальной системой.
Вы протипопоставляете универсальное решения для работы с нетривиальными задачами — и узкоспециализированную систему.
Узкоспециализированная система всегда будет быстрее работать.
Но при этом научить узкоспециализированную систему делать что то дополнительное — будет оходится очень дорого.
Однако в случае т.н. «прямых запросов из 1С», ссылку на которые вы тут привели, позволю себе усомниться в целесообразности. В версии 1С V77 еще была иногда необходимость в прямом доступе к SQL, то в версии 1C V8 (которая появилась около 15!!! лет назад) — очень мощный язык запросов.
По вашей ссылке же я наблюдаю то, о чем я уже написал выше — вместо решения прикладных задач люди предпочитают тратить свое время на базовые ИТ-задачи.
Язык запросов в 1С очень гибок. Структура БД в 1С легко корректируется под задачу. И оптимизировать выполнение запроса можно вполне средствами 1С. Мне лично доводилось на ранних этапах написания запроса в 1С для какой-нибудь аналитики получать и по часу и по 2 часа выполнение запроса, которое после надлежащих оптимизаций превращалось в 30 секунд.
1С тут ничем не отличаются. Те кто пишут на SQL какую нибудь сложную аналитику в других системах — могут вам рассказать такие же истории.
Вы протипопоставляете универсальное решения для работы с нетривиальными задачами — и узкоспециализированную систему.
Узкоспециализированная система всегда будет быстрее работать.
Но при этом научить узкоспециализированную систему делать что то дополнительное — будет оходится очень дорого.
Однако в случае т.н. «прямых запросов из 1С», ссылку на которые вы тут привели, позволю себе усомниться в целесообразности. В версии 1С V77 еще была иногда необходимость в прямом доступе к SQL, то в версии 1C V8 (которая появилась около 15!!! лет назад) — очень мощный язык запросов.
По вашей ссылке же я наблюдаю то, о чем я уже написал выше — вместо решения прикладных задач люди предпочитают тратить свое время на базовые ИТ-задачи.
Язык запросов в 1С очень гибок. Структура БД в 1С легко корректируется под задачу. И оптимизировать выполнение запроса можно вполне средствами 1С. Мне лично доводилось на ранних этапах написания запроса в 1С для какой-нибудь аналитики получать и по часу и по 2 часа выполнение запроса, которое после надлежащих оптимизаций превращалось в 30 секунд.
1С тут ничем не отличаются. Те кто пишут на SQL какую нибудь сложную аналитику в других системах — могут вам рассказать такие же истории.
Очень часто проектировщики систем допускают одну, но решающую ошибку — они не учитывают накладные расходы. Как в школе когда дается физика — школьникам не дают понятия силы трения — так и здесь в большинстве случаев проектанты не понимают что 10 объектов, это не одно и тоже что 1000, а уж тем более не 100000 объектов. И когда такие горе разработчики попадают в ловушку расширения системы — начинаются охи и ахи. Как же так вы нам обещали!!! Сразу говорю что курсы 1С учат людей строить запросы НЕПРАВИЛЬНО. Потому что то что посылается на сервер — это вообще не то что подразумевается пользователем. И приведенная публикация (моя) — это итог упрашиваний писателей конфигурации, когда на крошечные запросы система вешает систему на полчаса. При этом честно признаюсь — люди пишущие большие конфигурации об этом прекрасно знают. Также они знают, что запрос 1С это не запрос SQL — и в большинстве своем он преобразуется в запрос SQL не оптимально или неправильно. При этом вы наверно не знаете, что движок БД 1С используется без изменения со времен DBF файлов.
При этом вы наверно не знаете, что движок БД 1С используется без изменения со времен DBF файлов.
Я знаю это про версию 1C V77.
Там действительно SQL-версия 1С была реализована поверх движка DBF, что прилично подтормаживало.
Но эта версия была разработата еще в прошлом веке.
А с современной V8 — сильно сомнительно чтобы это было так.
По крайней мере скорость работы грамотно написанных запросов — чрезвычайно высока. Несопоставимо с V77
Выложенная надстройка работает (ла) под 1.8 — просто Вы никогда не сидели в трассировщике запросов сервера. И вы например ничего не знаете о выбираемом по умолчанию 1С уровне изолированности транзакций и прочих плюшках, а также способе хранения реальных данных и их выборе из БД 1С
Сидел давно в трассировщике — на 1C V77, в начале века.
В 1C V8 подумывал про трассировщик — так как в начале освоения этой версии полагал, что язык запросов так же убог как и в версии прошлого века. К счастию, вовремя разобрался с возможностями новой версии. И умею писать так чтобы работало быстро без захода в трассировщик теперь.
Понимаете в чем дело — бизнесу важно чтобы решались их задачи. За это они и платят. Гы, я «делец» по типажу из статьи наверное…
Что там внутри — начинает волновать только, когда все это тормозит или выдает результат, который не должно выдавать.
У меня — не тормозит. Не знаю почему. Наверно потому что я занимаюсь 1С профессионально уже 15 лет. Наверное потому, что и до 1С и параллельно с 1С я работал и с другими СУБД — Oracle, Tarantool, Cache.
В 1C V8 подумывал про трассировщик — так как в начале освоения этой версии полагал, что язык запросов так же убог как и в версии прошлого века. К счастию, вовремя разобрался с возможностями новой версии. И умею писать так чтобы работало быстро без захода в трассировщик теперь.
Понимаете в чем дело — бизнесу важно чтобы решались их задачи. За это они и платят. Гы, я «делец» по типажу из статьи наверное…
Что там внутри — начинает волновать только, когда все это тормозит или выдает результат, который не должно выдавать.
У меня — не тормозит. Не знаю почему. Наверно потому что я занимаюсь 1С профессионально уже 15 лет. Наверное потому, что и до 1С и параллельно с 1С я работал и с другими СУБД — Oracle, Tarantool, Cache.
Поэтому люди, которые изначально учились правильному SQL просто выпадают в осадок от результатов того, что им возвращает 1C
Поэтому люди, которые изначально учились правильному SQL просто выпадают в осадок от результатов того, что им возвращает 1C
Наверное потому что они не понимают, что «правильный SQL» — это всего лишь база, основа для более сложных прикладных построений?
А 1С манипулирует с несколько иными структурами.
Скажем, запрос по регистрам работает не с одной таблицей, как это ожидал бы человек, знающий «правильный SQL», а с двумя таблицами сразу — таблицей итогов и таблицей движений. Которые на прикладном уровне видны как единое целое.
Еще раз повторю — эту надстройку писал я — и я сопостовлял все объекты 1С видимые пользователю с реальными таблицами БД. И то безобразие, которое творилось с реальной БД — повергло бы в шок любого специалиста по реляционным БД. Просто я помогал реальным людям-конфигураторам 1С ускорять в ДЕСЯТКИ раз их скрипты — зная всю подноготную 1С
ОК. Я верю что вы круче инженеров 1С.
Так как любые узкоспециализированные запросы будут эффективнее универсальных.
Не пользовался вашей разработкой на V8
Умею писать быстро на 1С V8 без прямых запросов.
На V77 пользовался подобной вещью. Сейчас это не нужно уже.
Однако, допускаю, что многим ваша разработка нужна и полезна.
Так как любые узкоспециализированные запросы будут эффективнее универсальных.
Не пользовался вашей разработкой на V8
Умею писать быстро на 1С V8 без прямых запросов.
На V77 пользовался подобной вещью. Сейчас это не нужно уже.
Однако, допускаю, что многим ваша разработка нужна и полезна.
Вы просто не видели и никогда не использовали крутые инструменты — и это не ваша беда. Например в свое время лучшим инструментом для 4G разработки SQL был PowerBuilder. Это просто небо и земля по сравнению с 1С — и мне удосужилось видеть разработки — копии по функциональности с 1С — но которые работают в десятки раз быстрее. Потому что и были правильно спроектированы и сам инструмент позволял в разы больше чем 1С. И писали его люди, которые не один год окучивали огород 1С
1C — это попытка натянуть объектную(сущностную) модель данных на реляционное хранилище данных. И попытка полностью провальная. Но качество любого продукта никогда не коррелируется с его продажами. Это две разные вещи. Как например процессоры Intel и процессоры Vax машин. Как операционная система Windows и OS/2 или VMS
Тем, что разработчик продумывает архитектуру, а кодировщик — нет
Это как отличие техника от инженера.
Техник следует инструкциям (по крайней мере должен следовать, инициатива техника крайне нежелательна).
Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.
На Западе в этом очень четкое деление.
У нас — страна левшей, потому не столь очевидно.
Однако, отсуствие культуры техников в нашей стране есть не гуд для производительности труда.
Техник следует инструкциям (по крайней мере должен следовать, инициатива техника крайне нежелательна).
Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.
На Западе в этом очень четкое деление.
У нас — страна левшей, потому не столь очевидно.
Однако, отсуствие культуры техников в нашей стране есть не гуд для производительности труда.
Инженер может при столкновении с проблемой придумать новые пути решения. И это для него не геройство, а будни.
Задача «чистого» инженера — решить поставленную задачу, комбинируя известные и хорошо опробованные технологии. Как у архитектора — построить дом с заданными параметрами, используя материалы с известными характеристиками. Сложность в том чтобы правильно согласовать все между собой, выполнив все требования.
А изучение чего-то принципиально нового — скорее задача для научного сотрудника. Конечно, инженеры часто занимаются и НИОКР — не сказал бы что это плохо. Но в некоторых отраслях «инициатива» (стремление использовать что-то новое, нестандартное, свое) инженера не то что нежелательна, а даже наказуема.
Но в некоторых отраслях «инициатива» (стремление использовать что-то новое, нестандартное, свое) инженера не то что нежелательна, а даже наказуема.
В ИТ это не так.
В ИТ как раз задача engeneer исследовать те или иные проблемы, в том числе.
Я как то работал в канадской компании, нам там старший разработчик так и говорил, когда у команды были затруднение — «вы же ребята инженеры, как вам не стыдно найти решение, тем более что исследования оплачиваются за счет фирмы»
Задача "чистого" инженера — предоставить оптимальное по технико-экономическим параметрам техническое решение бизнес-задачи. Будет в решении много НИОКР или будет лишь композиция уже известных решений — это его область отвественности. "Инициатива" тут скорее будет в предложениях бизнесу решить бизнес-задачу не техническими, а, например, административными методами. Или наоборот.
Почему "как"? По российскому классификатору есть техник-программист — выпускник техникума в общем случае, — и инженер-программист — выпускник вуза. По программам подготовки можно точно сказать, что первый "заточен" на решение технических задач ("должен следовать инструкции" — перегиб палки, в целом хорошему технику и архитектуру довольно сложной системы доверить можно), а второй — на решение бизнес-задач путем постановки и решения технических.
Возможно, именно поэтому многих так раздражают проповедники Agile, Роберт Мартин и пр.
Они предлагают всем строго следовать добродетелям дельца (возможно, даже с некоторым уклоном в линейного программиста)
Они предлагают всем строго следовать добродетелям дельца (возможно, даже с некоторым уклоном в линейного программиста)
Идея делить людей на несколько категорий изначально бессмысленна, зачастую в человеке смешано много разных черт и нет какого-то определённого типа
Интересная классификация. Мне кажется разделение здесь основано на мотивации:
Линейный — остаться в зоне комфорта минимальными усилиями, интроверт.
РокСтар — удовлетворить собственное любопытство в сфере, профильной деятельности компании.
Делец — максимальная выгода минимальными усилиями.
Пассажир — остаться в зоне комфорта минимальными усилиями, экстраверт.
Поясню про «зону комфорта». В отношении работы, оставаться в зоне комфорта — значит выполнять возложенные на тебя обязательства и получать за это материальные и моральные/репутационные плюшки.
Линейный выполняет обязательства (выполняет работу в срок, учит новые технологии), не требуя взамен ничего сверх положенного и стараясь не перетруждаться.
Пассажир идет на диалог, стремясь во-первых получить больше нематериальных плюшек (ему общение в радость), а во-вторых уменьшить обязательства (уболтать того, кто эти обязательства определяет либо переложить часть работы на других).
Линейный — остаться в зоне комфорта минимальными усилиями, интроверт.
РокСтар — удовлетворить собственное любопытство в сфере, профильной деятельности компании.
Делец — максимальная выгода минимальными усилиями.
Пассажир — остаться в зоне комфорта минимальными усилиями, экстраверт.
Поясню про «зону комфорта». В отношении работы, оставаться в зоне комфорта — значит выполнять возложенные на тебя обязательства и получать за это материальные и моральные/репутационные плюшки.
Линейный выполняет обязательства (выполняет работу в срок, учит новые технологии), не требуя взамен ничего сверх положенного и стараясь не перетруждаться.
Пассажир идет на диалог, стремясь во-первых получить больше нематериальных плюшек (ему общение в радость), а во-вторых уменьшить обязательства (уболтать того, кто эти обязательства определяет либо переложить часть работы на других).
Биг спс автору. Являюсь по факту пассажиром в АйТи (не соответствует классификации автора, а как признак полного непрофа, спец из другой отрасли — info b2b). Моя классификация много проще (повторюсь, чайник в IT, но разбор двойников телефонов пришлось самому написать): кодер(=линейный), топ кодер с наличием хорошей соображалки (=рокстар), понторез-разводчик (обычно много разных красивых дипломов и курсов, кол-во реального кода близко к нулю, близок к дельцу с понтами и без кода), тестер ПО, джуниор + начинающий кодер(чайник) по необходимости вынужденный кодить. Так же заметил особенность, что с 95-99% из отрасли IT (программирование) бывает сложно коммуницировать и пускать на коммуникацию с клиентами (люди в себе и в коде), может это только у меня так, а в целом по статистике не показательно. И по моей статистике в любой отрасли (не только в программинге) реальных профи (супер разлива) в районе 1-3%.
Интересно, спасибо. Замечу, что классификация ограничена наёмными работниками. Что не всегда так.
Так, где голосование кто есть кто?
Еще маленькое замечание. Наверное для умного руководителя не столько важна данная градация, сколько динамика движения коллектива и главное НАПРАВЛЕНИЕ(ВЕКТОР) движения коллектива. Наверно многие согласятся (а может и нет), что выбранный типаж может двигаться только к своим соседским типажам (хотя двигаться в сторону Порождающего типажа намного сложнее. Например Рок звезды — порождающий типаж к Линейщикам, поэтому с возрастом Рок звездам легче перейти в линейщики. И наоборот двигаться Линейщикам в сторону рок звезд едва ли возможно :) Дальние переходы возможны, но это как сказать — ломать карму :)
Я правильно понимаю, что классификация производилась без привлечения статистики и унифицированного опросника? Как проводили оценку мотивации — по валидной методике или личным мнением?
Вы перечислили кучу способов составления таких классификаций исключая, собсно, общение и работу непосредственно бок о бок с испытуемыми людьми. Мне кажется здесь что-то не так...
Наблюдение в психологии — хороший метод сбора первичной информации. Для вашей классификации можно было фиксировать поведенческие акты. Накопив достаточное количество — провести кластерный анализ (статистика!), если выявлены четкие однородные группы, то можно их описать. Параллельно можно собирать сведения о «бэкграунде» и мотивации. Вполне достойное исследования уровня дипломной работы.
Идея-то отличная. Если она работает, то сужает перечень рассматриваемых качеств кандидатов. Это снижает риски неудачного подбора из-за неподходящего сценария взаимодействия сотрудника и работодателя. Повышает результативность и общую удовлетворенность.
Есть отличные пример подобной работы — модель командных ролей Белбина.
Идея-то отличная. Если она работает, то сужает перечень рассматриваемых качеств кандидатов. Это снижает риски неудачного подбора из-за неподходящего сценария взаимодействия сотрудника и работодателя. Повышает результативность и общую удовлетворенность.
Есть отличные пример подобной работы — модель командных ролей Белбина.
Понравилась статья. Для руководителей скорее подходит, для решения кадровых вопросов. Для программиста она полезна, разве что, осознанием своего типажа и соответственно своих возможностей и соответствующей компенсации. Можно типажи еще описать на основании реальных стремлений: к комфорту, к открытиям, к деньгам, к общению. Но так это, не думаю, что будет полным перечнем. Например, вот куда поставить тех, кто разрабатывает только опен сорс, т.е. какие-то альтруисты.
Интересное чтиво, спасибо. Но чем-то напоминает типы личности Майер-Бриггс, надеюсь никто не будет это использовать на работе)
Веселая классификация!
Я работаю в науке — у нас переизбыток чистых Рок-Стар — три штуки в лаборатории. )))
Есть смесь дельца с пассажиром — собирается увольняться.
Ну и наиболее адекватные — смесь линейщика с рок-стар.
«типы личности Майер-Бриггс,» — сюда же соционику. Как правило оно связано — т.е. вполне можно найти соответствие, но… скажем «пассажир» — это более социальное явление как мне кажется. Наш лабораторный «пассажир» по идее мог бы очень хорошо работать в науке — но… его мотивы где-то в другом месте.
Я работаю в науке — у нас переизбыток чистых Рок-Стар — три штуки в лаборатории. )))
Есть смесь дельца с пассажиром — собирается увольняться.
Ну и наиболее адекватные — смесь линейщика с рок-стар.
«типы личности Майер-Бриггс,» — сюда же соционику. Как правило оно связано — т.е. вполне можно найти соответствие, но… скажем «пассажир» — это более социальное явление как мне кажется. Наш лабораторный «пассажир» по идее мог бы очень хорошо работать в науке — но… его мотивы где-то в другом месте.
Интересно. Как сейчас дела у тех, кто между линейным и рок-старом?
Чего спрашивать не стоит: алгоритмические вопросы, математикаА почему? Казалось бы, делец с его мотивацией заработать все деньги мира в первую очередь хорошенько разберётся в том, что часто спрашивают на собеседованиях (то есть, как раз эти темы). А если он их хорошо знает — с чего бы ему не радоваться возможности показать себя с хорошей стороны?
Нет. Он в голове держит интересные _решенные_ задачи, а не набор отполированных инструментов на все случаи жизни. Практика практика и только практика.
Если какой то алгоритм лежит в стандартной библиотке — его незачем знать.
Если какой то алгоритм лежит в стандартной библиотке — его незачем знать.
Ну как это незачем, если это каждый первый спрашивает на собеседовании
Пройдут у дельца собеседование далеко не все такое спрашивающие :) Уж делец точно относится к собеседованию не как к экзамену, а как к деловым переговорам о возможном сотрудничестве. Если интервьюверы займут сходу позицию "экзаменатора", то делец вполне может встать и уйти посреди такой "беседы", чтобы не тратить зря время.
+1.
VolCh Alexander63DEmon_CDXLIV Давайте я немного подробнее опишу ход моих рассуждений. Буду очень благодарен, если вы укажете, где я рассуждаю неверно или не по-дельцовски.
Я отношу себя к дельцам, поскольку единственной мотивацией для меня являются деньги. Для меня фраза «мне достаточно денег» — дикость. Я не понимаю, как можно ходить по собеседованиям реже, чем раз в год, и считаю неправильным принимать единственный оффер — компании должны торговаться между собой. При сравнении офферов я перевожу в деньги все, что переводится (ДМС, скажем, или обеды), оцениваю все будущие бенефиты и дисконтирую к сегодняшнему дню. Насколько я могу судить, это довольно близко к описанию типа «делец» из поста.
Я воспринимаю процесс найма (от отсылки резюме до первого рабочего дня) как состоящий из двух этапов. Первый этап — взаимный экзамен: компания убеждается, что соискатель подходит им (обычно в смысле soft skills и hard skills), а соискатель — что компания подходит ему (в моем случае — в смысле низких рисков отказа от исполнения обязательств и в смысле достаточных возможностей для развития). И вот если этот экзамен обеими сторонами успешно пройден, дальше начинаются переговоры.
Моя задача на первом этапе — составить о себе как можно лучшее впечатление и достоверно оценить компанию. А на втором этапе большое количество заинтересованных во мне компаний серьёзно усиливают мою позицию на переговорах. Так что если у меня есть выбор из двух вариантов:
Я выбираю тот вариант, который принесёт мне больше денег, т.е. первый.
PS: По моему опыту (100+ собеседований в десятках компаний) есть лишь два вида компаний, которые не спрашивают про алгоритмы: это стартапы (в реалиях РФ нередко пытающиеся предложить работу за долю, т.е. бесплатно) и шаражки на три с половиной человека, предлагающие три копейки. В обоих видах этих компаний я не заинтересован. Мой опыт собеседований достаточно специфичен — скажем, я не был на достаточном количестве собеседований уровня team lead и выше, чтобы делать выводы, там ситуация может отличаться.
PPS: Допускаю, что я могу быть «неправильным» дельцом, и некоторые из моих черт характера или привычных методов рассуждения могут быть артефактами rock star, которым я был десять лет назад
Я отношу себя к дельцам, поскольку единственной мотивацией для меня являются деньги. Для меня фраза «мне достаточно денег» — дикость. Я не понимаю, как можно ходить по собеседованиям реже, чем раз в год, и считаю неправильным принимать единственный оффер — компании должны торговаться между собой. При сравнении офферов я перевожу в деньги все, что переводится (ДМС, скажем, или обеды), оцениваю все будущие бенефиты и дисконтирую к сегодняшнему дню. Насколько я могу судить, это довольно близко к описанию типа «делец» из поста.
Я воспринимаю процесс найма (от отсылки резюме до первого рабочего дня) как состоящий из двух этапов. Первый этап — взаимный экзамен: компания убеждается, что соискатель подходит им (обычно в смысле soft skills и hard skills), а соискатель — что компания подходит ему (в моем случае — в смысле низких рисков отказа от исполнения обязательств и в смысле достаточных возможностей для развития). И вот если этот экзамен обеими сторонами успешно пройден, дальше начинаются переговоры.
Моя задача на первом этапе — составить о себе как можно лучшее впечатление и достоверно оценить компанию. А на втором этапе большое количество заинтересованных во мне компаний серьёзно усиливают мою позицию на переговорах. Так что если у меня есть выбор из двух вариантов:
- Потратить немного времени и заботать алгоритмы
- Отказаться от общения с 90% работодателей
Я выбираю тот вариант, который принесёт мне больше денег, т.е. первый.
PS: По моему опыту (100+ собеседований в десятках компаний) есть лишь два вида компаний, которые не спрашивают про алгоритмы: это стартапы (в реалиях РФ нередко пытающиеся предложить работу за долю, т.е. бесплатно) и шаражки на три с половиной человека, предлагающие три копейки. В обоих видах этих компаний я не заинтересован. Мой опыт собеседований достаточно специфичен — скажем, я не был на достаточном количестве собеседований уровня team lead и выше, чтобы делать выводы, там ситуация может отличаться.
PPS: Допускаю, что я могу быть «неправильным» дельцом, и некоторые из моих черт характера или привычных методов рассуждения могут быть артефактами rock star, которым я был десять лет назад
Задайте себе вопрос — если есть проблемы с заказчиком вы рискнете увести проект /команду лично под себя если это выгодно? Если ответ — «конечно да, что за глупый вопрос?!» Вы делец, и это один из основных рисков работы с дельцами.
Ну и видимо у Вас область специфичная, дельцы обычно или тим лиды или на каких то больших проектах сидят кем то типа ведущих, у них странно алгоритмы спрашивать.
Ну и видимо у Вас область специфичная, дельцы обычно или тим лиды или на каких то больших проектах сидят кем то типа ведущих, у них странно алгоритмы спрашивать.
Если это выгодно в долгосрочной перспективе, учитывая репутационные издержки — конечно да, что за глупый вопрос?! Но пока что такого ни разу не случалось.
Мне до team lead пока что навыков недостаёт, но это дело наживное. «Делец» же, насколько я понял суть поста — это скорее про мотивацию
Мне до team lead пока что навыков недостаёт, но это дело наживное. «Делец» же, насколько я понял суть поста — это скорее про мотивацию
Не только мотивация — но и какие задачи хорошо решает и какие риски при работе с ним.
Грубо говоря за одни и те же деньги линейный что то пилит в углу, рок-стар творит что то свое, делец — решает проблемы/строит бизнес, пассажир — руководит людьми и общается.
Грубо говоря за одни и те же деньги линейный что то пилит в углу, рок-стар творит что то свое, делец — решает проблемы/строит бизнес, пассажир — руководит людьми и общается.
Как прекрасно в вашем сообщении выплескиваются эмоции. :))
То же самое можно сформулировать примерно так:
“За одни и те же деньги линейный честно работает, рок-стар — творит, делец говнокодит, лишь бы работало, пассажир — руководит“
Или так:
“За одни и те же деньги линейный пилит, рок-стар создает продукт, делец доводит до ума, пассажир выстраивает процесс.
И каждый раз не меняя сути мы будем очень по-разному оценивать вклад людей в результат.
То же самое можно сформулировать примерно так:
“За одни и те же деньги линейный честно работает, рок-стар — творит, делец говнокодит, лишь бы работало, пассажир — руководит“
Или так:
“За одни и те же деньги линейный пилит, рок-стар создает продукт, делец доводит до ума, пассажир выстраивает процесс.
И каждый раз не меняя сути мы будем очень по-разному оценивать вклад людей в результат.
Так что если у меня есть выбор из двух вариантов:
Потратить немного времени и заботать алгоритмы
Отказаться от общения с 90% работодателей
Я выбираю тот вариант, который принесёт мне больше денег, т.е. первый.
А если в этих 90% работодателей крутится 10% денег, то кого тогда послать? Деньги и rocket science (которая, к тому же, за «немного времени» эффективно не осваивается) — это перепендикулярные понятия. К тому же в реальном мире 90% работодателей вся эта херь алгоритмически озабоченная на фиг не нужна. Им нужно чтобы работало вчера, а то и позавчера И не колышет как и что там будет под капотом.
Согласен, что умение решать алгоритмические задачи в ежедневной работе нужно очень редко, однако оно нужно почти на каждом собеседовании, поэтому обладание этим навыком, хоть и не повышает мое качество работы, позволяет мне быстрее-выше-сильнее проходить собеседования, тем самым принося мне реальные деньги.
Насчёт 90% и 10% — по моему опыту, в РФ компании, не требующие алгоритмических навыков на собеседовании — это либо стартапы за долю (т.е. бесплатно), либо шарашки на три с половиной человека за три копейки. Так что да, rocket science не нужна в работе (ну, чаще всего), но пока она нужна на собеседовании, я хочу её знать.
Насчёт 90% и 10% — по моему опыту, в РФ компании, не требующие алгоритмических навыков на собеседовании — это либо стартапы за долю (т.е. бесплатно), либо шарашки на три с половиной человека за три копейки. Так что да, rocket science не нужна в работе (ну, чаще всего), но пока она нужна на собеседовании, я хочу её знать.
которая, к тому же, за «немного времени» эффективно не осваиваетсяПри сносном владении матаппаратом Кормен изучается за месяц в нужном для прохождения собеседований обьёме. Не сложнее изучения какого-нибудь Django или jQuery.
Важнее тут, скорее, то, что непосредственно сами эти знания в деньги превратить нельзя — ну так делец, не способный выкроить месяц на то, чтобы изучить что-то, что ему будет приносить прибыль годами — плохой делец.
А если в этих 90% работодателей крутится 10% денег, то кого тогда послать?Если в этих 90% работодателей крутиться 10% денег, то общаться нужно, очевидно, с теми 10%, в которых крутятся 90% денег.
Компании, способный «послать» кандидата за то, что он кроме «пузырька» ничего не знает обычно имеют больше денег на оплату, чем компании, выживающие «от заказа до заказа» и потому не имеющие возможности «перебирать» кандидатов.
При сносном владении матаппаратом Кормен изучается за месяц в нужном для прохождения собеседований обьёме. Не сложнее изучения какого-нибудь Django или jQuery.
На уровне в носу поковырять — да, за месяц можно. На уровне изобразить что-то удобоваримое и не вызывающее рвотных позывов — уже от полугода, причем в плотном погружении в проекты где весь их спектр реально нужен и каждый день востребован. Ну а на уровне чтобы to get things done — это годы.
Важнее тут, скорее, то, что непосредственно сами эти знания в деньги превратить нельзя — ну так делец, не способный выкроить месяц на то, чтобы изучить что-то, что ему будет приносить прибыль годами — плохой делец.
Дельцу годами прибыль приносят soft skills, а не заумная хрень. Которую, к тому же, часто легко можно скинать фанатикам-студентам.
В скольких компаниях вы не отвечали или отвечали расплывчато на подобные вопросы, но офер получили? По личному опыту достаточно отвечать где-то на половину вопросов по разным темам, чтобы получить офер.
Именно оффер — никогда. Однажды я сильно не выспался и вообще ничего путного по задачам не сказал, но меня все равно позвали дальше — прервал процесс найма, потому что ну нельзя же так.
Во втором из двух случаев, когда я не решил задачу, был отказ.
Неужели разница между «решил половину задач с трудом» и «с ходу полно ответил на все вопросы» не влияет на оффер? В этом случае да, согласен, сильно высокий алгоритмический навык не нужен, но все же нужно быть уверенным, что сможешь ответить на половину вопросов
Во втором из двух случаев, когда я не решил задачу, был отказ.
Неужели разница между «решил половину задач с трудом» и «с ходу полно ответил на все вопросы» не влияет на оффер? В этом случае да, согласен, сильно высокий алгоритмический навык не нужен, но все же нужно быть уверенным, что сможешь ответить на половину вопросов
Вы прям считаете что дельцу позарез надо. Там еще вопрос — кто кого собеседует ))
Ну это не только для дельцов верно. Линейные или звезда точно также ходит на собеседование, чтобы о компании узнать. И прособеседовть будущих руководителей.
Ну а отношение к сложным вопросам разное. Звезда просто получает удовольствие от их решения, линейный мучается, но решает, а делец пытается отмазаться.
Ну а отношение к сложным вопросам разное. Звезда просто получает удовольствие от их решения, линейный мучается, но решает, а делец пытается отмазаться.
Решение сложных задач == репутация, а это и хлеб и масло для дельца.
Как раз сложные вопросы — интересны, за простое — не платят.
Ну при условии что есть идеи как их решать с выгодой для себя ))
Как раз сложные вопросы — интересны, за простое — не платят.
Ну при условии что есть идеи как их решать с выгодой для себя ))
Мы же вроде про собеседования говорим?
Правильно. Уровень собеседований дельца — решенные задачи, а не база.
Если спрашивают за алгоритмы — это не интересно по деньгам, ну или это скорее к рок-стару (исследователю) который алгоритмы и пилит и любит, а не конкретные проблемы решает.
Для решения частных проблем надо знать общие черты и границы применимости, под капот как правило смысла нет лезть, слишком дорого, там уже столько людей копалось — оно или подходит для конкретной задачи или не подходит.
Статья очень хорошо описывает мотивацию разных типов, она ведь реально разная у всех.
Если спрашивают за алгоритмы — это не интересно по деньгам, ну или это скорее к рок-стару (исследователю) который алгоритмы и пилит и любит, а не конкретные проблемы решает.
Для решения частных проблем надо знать общие черты и границы применимости, под капот как правило смысла нет лезть, слишком дорого, там уже столько людей копалось — оно или подходит для конкретной задачи или не подходит.
Статья очень хорошо описывает мотивацию разных типов, она ведь реально разная у всех.
Я фразу “Уровень собеседований дельца — решенные задачи, а не база“ не понял. Что это значит? Что дельцы на собеседования по алгоритмам не ходят?
Или ходят, но отказываются сложные вопросы на собеседованиях решать?
Или ходят, но отказываются сложные вопросы на собеседованиях решать?
Лично я думаю большинство не ходят.
Те кто под капотом ковыряются как мне кажется или рок-стары или линейные.
Ну или крайне редкий зверь специализирующийся на конкретном инструменте, но на мой взгляд излишняя специализация не
окупается.
Дельцы — те кто решают проблемы и заточены под это, поверьте доскональное знание алгоритмов для этого — не самое важное ))
Но это мое личное мнение.
Те кто под капотом ковыряются как мне кажется или рок-стары или линейные.
Ну или крайне редкий зверь специализирующийся на конкретном инструменте, но на мой взгляд излишняя специализация не
окупается.
Дельцы — те кто решают проблемы и заточены под это, поверьте доскональное знание алгоритмов для этого — не самое важное ))
Но это мое личное мнение.
Как раз сложные вопросы — интересны, за простое — не платят.
Платят. В нужном месте и в нужное время. И тогда перекрашенная на форме кнопка вполне себе может вылиться в пару десятков килобаксов кешем на карман за 4 дня работы.
В подкасте Радио-Т, Умпутун прямо сказал, что еще на середине такого вопроса встанет и уйдет, и с этими людьми больше дела иметь не будет.
Наверное, я не из них. Не беспокоить прошу, а алгоритмы гуглю. :)
*смиренно принял судьбу линейного
Вы так говорите как будто это что то плохое! Я им завидую.
Сидят, пашут, всем довольны…
Сидят, пашут, всем довольны…
Сидят, пашут… А потом бац, контора ликвидируется, и неликвид на улице. Зачастую уже в возрасте и без привлекательного списка достижений.
Есть такой риск.
А многие просто уходят на пенсию и вполне довольны там где сейчас ))
А многие просто уходят на пенсию и вполне довольны там где сейчас ))
Какой неликвид. Линейные программисты — самый ликвид!!! Их ВСЕГДА дефицит.
Это рок-стары в 90% контор не нужны. На дельцов в 90% контор нету денег. А работать кому-то надо.
Это рок-стары в 90% контор не нужны. На дельцов в 90% контор нету денег. А работать кому-то надо.
Вы это 50+ линейщику который кроме турбопаскаля ничего не знает и в общем то знать не хочет скажите. Особенно не в столицах ;)
Но про неликвид не я сказал, я как раз сказал что шансы быть неликвидом не высокие.
В общем то и статья о том что линещики — суть и соль. С этим тоже никто не спорит.
Но про неликвид не я сказал, я как раз сказал что шансы быть неликвидом не высокие.
В общем то и статья о том что линещики — суть и соль. С этим тоже никто не спорит.
Что не так с вопросом про Content-Length? Понимание почему и для чего он нужен очень важно, это не детали реализации x+y или y+x, это важная (в т. ч. архитектурная) часть протокола от которой многое зависит.
Очень годная статья!
UFO just landed and posted this here
Писать код на собеседованиях НЕ надо.Это мечта всех «пассажиров». Но у нас «в памятке для интервьюера» написано чётко и недвусмысленно: в отчёте об интервью код, написанный кандидатом должен быть обязательно.
А для того, чтобы этот код можно было приложить — он должен быть написан, согласитесь?
И вы его напишете все равно.Не напишут. В том-то и дело. 80% кандидатов (не путать с 80% работающих в индустрии — я уже говорил почему) пишут код по принципу если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла. Самый просто способ их отсеять — это попросить написать код. Простой. То, что любой вменяемый читатель Хабра сможет написать за 5 минут. И посмотреть на него. 90% отсеиваются сразу — 80% потому что не могут написать без помощи IDE вообще ничего, а ещё половина — потому что напишут нечто, что не будет напоминать решение требуемой задачи даже отдалённо. Дальше — уже легче.
Справедливости ради, тесты — это тоже код.
Совершенно верно, но написать код с тестами — всё-таки сложнее, чем код без тестов, а если вы не можете решить более простую задачу, то зачем вас мучить более сложной?
Если кандидат сам, по своей инициативе, начнёт с написания тестов — я буду только за. При условии что он код исходно-то задачи в конце-концов напишет. А то «пассажиры» стремятся тестами и ограничиться, а код — совсе не писать…
Если кандидат сам, по своей инициативе, начнёт с написания тестов — я буду только за. При условии что он код исходно-то задачи в конце-концов напишет. А то «пассажиры» стремятся тестами и ограничиться, а код — совсе не писать…
UFO just landed and posted this here
вы меня в пассажиры решили записать?)) По каким критериям?Исходя из ваших «размахиваний руками» и словесного поноса без полезного выхлопа.
Лично я себя считаю рок-звездой)) Я писал код. Раньше.Вы не поверите — но я встречал немало таких «звёзд, которые писали код раньше». Жалкое зрелище, скажу я вам. Особенно их попытки найти себе «негров», которые оный код за них будут писать в то время как они будут «мудрые мысли» излагать.
Может быть где-то их умения и можно применить с пользой.
Потому что это становится главным трендом и мейнстримом отрасли.Лет примерно 20 назад большинство программистов были программистоами на Visual Basic'е и Delphi (последнее, впрочем, реже на западе и чаще в России). Было ли это мейнстримом и нужно ли было бросать C++ и только нарождавшуюся тогда Java ради Visual Basic'а?
Назовите, на выбор задачу, которую не напишет, пусть, 80% здешней биоты, прямо с ходу.Найти расстояние d между двумя вершинами в DOM-дереве (ну раз вы так хотите мейнстрим) за O(d) (а не за O(чего-то-там ещё) без дополнительной памяти.
И обьясните как вы будете проверять тестами то, что время работы таки O(d) и что дополнительная память таки не используется.
Найти расстояние d между двумя вершинами в DOM-дереве (ну раз вы так хотите мейнстрим) за O(d) (а не за O(чего-то-там ещё) без дополнительной памяти.
И обьясните как вы будете проверять тестами то, что время работы таки O(d) и что дополнительная память таки не используется.
Проверять тестами на собесе, что дополнительная память не используется и проверять сложность тестами — это как-то сильно странно.
Не очень понимаю, как можно не использовать дополнительную память для этой задачи. Даже указатель на текущую вершину нельзя использовать? Это же память. Даже счетчик шагов? Как мы тогда узнаем расстояние, если не посчитаем шаги? Может там подвох какой-то есть? И как можно за O(d) посчитать, если d не конфигурационный параметр? Может за O(h), где h — высота дерева?
Видимо d — depth, это то же самое, что и h — height.
Не очень понимаю, как можно не использовать дополнительную память для этой задачиВидимо, имелось в виду O(1) дополнительной памяти, как минимальное количество.
как можно за O(d) посчитать, если d не конфигурационный параметрНапример, если в дереве у каждой вершины хранится глубина и указатель на родителя, можно использовать следующий алгоритм:
1. В ответ заносим 0.
2. Пока глубина первой вершины больше глубины второй, переходим к её родителю, увеличивая ответ на 1.
3. Пока глубина второй вершины больше глубины первой, переходим к её родителю, увеличивая ответ на 1.
4. Пока вершины не совпадают, переходим к родителям в обеих, увеличивая ответ на 2.Очевидно, что это работает за O(d).
При использовании O(d) дополнительной памяти (хеш-таблица) можно сделать то же самое, требуя от дерева только указателей на родителей, без глубин.
Честно говоря, не знаю, какая информация хранится в вершинах DOM, но нужно плясать от этого.
Например, если в дереве у каждой вершины хранится глубина и указатель на родителя,
Да, но это уже O(h) дополнительной памяти. И чтобы найти глубину для двух заданных вершин и их родителей, надо пройтись еще O(h) раз.
Если же глубина не хранится, то алгоритм за O(d) тоже существует, просто константа перед O(d) будет больше. Нам достаточно знания не абсолютных значений глубин, а разницы между глубинами.
1. Положим D = 1.
2. Считаем родителей на D уровней выше для каждой из вершин.
3. Смотрим, находится ли родитель на D уровней выше для первой вершины среди всех родителей уровней [0, D] для второй вершины. Если да — нашли общего предка, то решение очевидно: отсюда мы имеем разницу глубин между вершинами и можем применить алгоритм из комментария alexeykuzmin0.
4. Аналогично для второй вершины и списка родителей первой.
5. Если общий предок не найден, тогда положим D = D * 2 и переходим к шагу 2.
Решение будет найдено для D ~ d (лень точные константы считать). Ну а сумма 1 + 2 + 4 + 8 +… + D = 2D — 1 ~ D ~ d, т.е. получается O(d).
Примечание: нужно ещё обрабатывать частные случаи, когда вершина имеет глубину меньше D.
1. Положим D = 1.
2. Считаем родителей на D уровней выше для каждой из вершин.
3. Смотрим, находится ли родитель на D уровней выше для первой вершины среди всех родителей уровней [0, D] для второй вершины. Если да — нашли общего предка, то решение очевидно: отсюда мы имеем разницу глубин между вершинами и можем применить алгоритм из комментария alexeykuzmin0.
4. Аналогично для второй вершины и списка родителей первой.
5. Если общий предок не найден, тогда положим D = D * 2 и переходим к шагу 2.
Решение будет найдено для D ~ d (лень точные константы считать). Ну а сумма 1 + 2 + 4 + 8 +… + D = 2D — 1 ~ D ~ d, т.е. получается O(d).
Примечание: нужно ещё обрабатывать частные случаи, когда вершина имеет глубину меньше D.
А каким образом вы делаете п.3 с константной памятью? Собственно, это тот самый алгоритм, который я имел в виду, написав про хеш-таблицу.
PS: удваивать D в п.5 не обязательно, можно каждый раз проверять лишь одного нового предка
PS: удваивать D в п.5 не обязательно, можно каждый раз проверять лишь одного нового предка
> А каким образом вы делаете п.3 с константной памятью?
А нам и не нужно хранить список предков.
> PS: удваивать D в п.5 не обязательно, можно каждый раз проверять лишь одного нового предка
Я очень понял, как в этом случае реализовать алгоритм.
А нам и не нужно хранить список предков.
> PS: удваивать D в п.5 не обязательно, можно каждый раз проверять лишь одного нового предка
Я очень понял, как в этом случае реализовать алгоритм.
Вот, набросал код для понимания (тестами не покрывал, может не работать):
Ползём слева на 1 вверх, потом справа на 2 вверх, потом слева на 4, справа на 8 и т.д.
C# код
class Node
{
public Node Parent;
static Node GetCommonParent(Node lhs, Node rhs)
{
int diff = GetDepthDifference(lhs, rhs);
if (diff > 0)
{
for (int i = 0; i < diff; i++)
lhs = lhs.Parent;
}
else if (diff < 0)
{
for (int i = 0; i < -diff; i++)
rhs = rhs.Parent;
}
while (lhs != rhs)
{
lhs = lhs.Parent;
rhs = rhs.Parent;
}
return lhs;
}
static int GetDepthDifference(Node lhs, Node rhs)
{
int left = 0, right = 0, d = 1;
while (true)
{
if (lhs.Parent == null)
{
while (rhs.Parent != null)
{
rhs = rhs.Parent;
right++;
}
return lhs == rhs ? left - right : throw new Exception("Different roots");
}
if (rhs.Parent == null)
{
while (lhs.Parent != null)
{
lhs = lhs.Parent;
left++;
}
return lhs == rhs ? left - right : throw new Exception("Different roots");
}
if (left < right)
{
for (int i = 0; i < d; i++)
{
if (lhs == rhs)
return left - right;
if (lhs.Parent == null)
break;
lhs = lhs.Parent;
left++;
}
}
else
{
for (int i = 0; i < d; i++)
{
if (lhs == rhs)
return left - right;
if (rhs.Parent == null)
break;
rhs = rhs.Parent;
right++;
}
}
d *= 2;
}
}
}Ползём слева на 1 вверх, потом справа на 2 вверх, потом слева на 4, справа на 8 и т.д.
Ну слава богу, хоть кто-то сделал. Я-то по наивности изначально думал, что это — простенькая, «разминочная», задачка. После проведения десятка интервью и общения с коллегами пришло понимание, что хороший кандидат (и хороший специалист) сам не всегда её решает. Но пара-тройка подсказок решают всегда — если человек не может даже понять как это работает, то это уже «никуда не годится».
Ну вообще, давать подобную задачу вне контекта реальной задачи — дурной тон. Почему критична сложность: O(d) вместо O(h)? Ведь O(h) реализовать проще — меньше вероятность ошибки. К тому же O(d) может работать дольше из-за более высокой константы.
А весь контекст в исходной задаче был. DOM-дерево == интерактив. То есть важно не отработать максимально быстро в среднем, а сделать так, чтобы «не тупило».
В исходном варианте ещё было ограничение, что если узлы слишком далеко — то можно дальше уже не искать, нам были интересны только узлы на расстоянии до 7 (или 8? не помню) шагов друг от друга. А за счёт «табличной вёрстки» дерево могло иметь шлубину не в одну сотню «шагов»… Но эти подробности уже делают задачу слишком сложной для собеседования.
В исходном варианте ещё было ограничение, что если узлы слишком далеко — то можно дальше уже не искать, нам были интересны только узлы на расстоянии до 7 (или 8? не помню) шагов друг от друга. А за счёт «табличной вёрстки» дерево могло иметь шлубину не в одну сотню «шагов»… Но эти подробности уже делают задачу слишком сложной для собеседования.
Проверять тестами на собесе, что дополнительная память не используется и проверять сложность тестами — это как-то сильно странно.Я тоже так считаю, но основной посыл который мы тут все обсуждаем:
Вы удивитесь, наверное, сейчас, но писать код НЕ надо. Он или написан, или его пишут все. И вы его напишете все равно. Надо писать ОЖИДАЕМЫЙ результат от ваших действий. Ибо: 1. это несет стабильность и читаемость. 2. Любой заменит вас, ЛЮБОЙ, если он прочитает ваши тесты. Аминь.Вот мне и хотелось увидеть как будут написаны тесты, что «любой мог заменить вас» прочитав их.
Не очень понимаю, как можно не использовать дополнительную память для этой задачи.«Без использования дополнительной памяти» == «используя O(1) памяти», конечно.
P.S. Задачка, кстати, практическая: исходно нужно было не найти расстояние, а понять — находятся ли элементы близко друг от друга в DOM-дереве или нет. Под IE6. Где, как мы знаем, JavaScript был «несколько» медленнее современного. Раз этак примерно в 1000. И работа с динамической памятью там была… ну, в общем… была, да. Так что разница межде десятком и парой сотен манипуляций вполне себе ощущалась. С тех пор, конечно, JavaScript сильно быстрее стал, но и сайты усложнились, да.
Вот мне и хотелось увидеть как будут написаны тесты, что «любой мог заменить вас» прочитав их.
Всё, уловил мысль, спасибо.
Я-то по наивности изначально думал, что это — простенькая, «разминочная», задачка. После проведения десятка интервью и общения с коллегами пришло понимание, что хороший кандидат (и хороший специалист) сам не всегда её решает. Но пара-тройка подсказок решают всегда — если человек не может даже понять как это работает, то это уже «никуда не годится».
Я бы не решил, но понял после того, как мне «разжевали» бы. Сразу стал бы опасаться за свою дальнейшую судьбу на этом гипотетическом интервью и если бы узнал, что это вы преподносите как «starter», то что же тогда основное блюдо? Задача о расстановке 8 ферзей? Mamma mia.
Сразу стал бы опасаться за свою дальнейшую судьбу на этом гипотетическом интервью и если бы узнал, что это вы преподносите как «starter», то что же тогда основное блюдо?Ну я ж никому из кандидатов не говорил, что я считал эту задачу «разминочной» и, как потом выяснилось — она таки примерно на всё интервью тянет (с разговорами «вокруг» неё, разумеется, не просто написать код и закончить).
Ну я ж никому из кандидатов не говорил, что я считал эту задачу «разминочной» и, как потом выяснилось — она таки примерно на всё интервью тянет (с разговорами «вокруг» неё, разумеется, не просто написать код и закончить).
Думаю, что даже человеку со средними способностями под силу решить эту и подобные задачки (они же не упираются в специфические знания), если как следует натренироваться перед этим именно на таких задачках. А «поговорить около» можно развив в себе концепцию картостроения :)
UFO just landed and posted this here
UFO just landed and posted this here
IDE сама по себе не говорит ничего о собеседуемом.IDE — нет. Неумение же написать три строчки без IDE говорит о многом.
Когда вы будете обсуждать наброски дизайна с командой — вы это будете делать у доски с маркерами или в IDE? Если первое, то, пожалуй, мне с вами не по пути.
UFO just landed and posted this here
Очень хорошо, что вы об этом сообщили заранее — дальнейшее можно же просто не обсуждать.
P.S. Похоже вы всё-таки не уловили «последние веяния отрасли» хотя и старательно изображаете карго-культ. Всё это «написание тестов до кода» и прочее своей истиной целью ставят снижение времени на разработку, а не, скажем, «повышение глубины раздумий». Если вы перешли на «новые технологиё», но этого не поняли — то неудивительно почему у вас возникает ощущение «иначе я буду не у дел в ближайшие даже не 5 лет, а уже вот, сейчас». Оно у вас возникает не потому, что вы плохо владаете этим технологиями, а потому что не понимаете — чего от вас, собственно, нужно. Поверьте: люди, способные выдать результат приемлемого качества и в приемлемые сроки — работу находят легко и остаться «не удел» в ближайшие 5 лет им не грозит от слова «совсем». Независимо от уровня экстремальности их подходов. А вот те, кто этого делать не умеет… увы.
P.S. Похоже вы всё-таки не уловили «последние веяния отрасли» хотя и старательно изображаете карго-культ. Всё это «написание тестов до кода» и прочее своей истиной целью ставят снижение времени на разработку, а не, скажем, «повышение глубины раздумий». Если вы перешли на «новые технологиё», но этого не поняли — то неудивительно почему у вас возникает ощущение «иначе я буду не у дел в ближайшие даже не 5 лет, а уже вот, сейчас». Оно у вас возникает не потому, что вы плохо владаете этим технологиями, а потому что не понимаете — чего от вас, собственно, нужно. Поверьте: люди, способные выдать результат приемлемого качества и в приемлемые сроки — работу находят легко и остаться «не удел» в ближайшие 5 лет им не грозит от слова «совсем». Независимо от уровня экстремальности их подходов. А вот те, кто этого делать не умеет… увы.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
По какому праву собеседующий кастрирует меня, лишая меня инструментов и вообще, полету моей мысли??По праву человека, решающего — предложить вам работу или нет.
Я его смотрел в спокойной обстановке и просто смеялся в голос над этим «верным» решением. И потом давал свое. Но все, поезд ушел. Я же не написал «на бумажке».Именно так. И в реальной работе будет то же. Если вы не сможете на «мозговом штурме» обосновать вашу точку зрения, то будет реализовано чьё-то другое решение. И то, что вы над ним будете «смеяться в голос» через месяц, дома, под подушкой — будет уже абсолютно неважно если в релиз уже уйдёт другое решение.
UFO just landed and posted this here
Вообще-то, да. Смысл существования любой компании в зарабатывании денег
Что кто-то что-там быстрее написал на бумажке и поэтому его решение единственно верное и непогрешимое, или что, «а, ладно, потом поправим», дедлайн успели и бабла куча, мы первые и герои?Да, примерно так.
Толк всего этого, смысл в чем, в майнинге бабла?Нет, конечно. Но без «майнинга бабла» всё остальное не имеет смысла.
Хороший пример — это Android vs Windows Phone. Google — очень спешил и потому Android — вышел кривой, как турецкая сабля, глючный и жрущий кучу ресурсов. В 2008м.
Microsoft же «знал», что ему, как «властелину мира»^H^H^H^H «лидеру IT индустрии» простят всё. И потому не спеша, с чуством, с толком, с расстановкой примерно так разика с пятого сделал правильную, красивую архитектуру «универсальных» приложений (я не издеваюсь — архитектура там действительно весьма хороша) — но к 2015му году.
Результат? Windows Phone сдох вместе со своей архитектурой и ни для чего больше она тоже не используется. Она о-по-зда-ла. Дорога ложка к обеду.
Вот и всё. Никому не нужна ваша «чистота, правильность и единственность» если вы неспособны её предоставить в нужные сроки.
MS кстати наступила на те же грабли, что и IBM, когда было полностью провалена борьба OS/2 с Windows.
Если бы только IBM с OS/2! На эти грабли в 80е-90е наступили все, кому не лень, как я уже писал.
Но, блин, зацените разницу в подходах: Android изначально выпускался под кнопочные телефоны и «трекбалл» (некоторые прототипы в принципе не имели touchscreen'а), на радикальную переделку дизайна времени было мало — и потому вышел вначале только под HTC Dream с кучей аппаратных кнопок. Но он — вышел в срок (ну… почти: подумаешь — на год позже iPhone). И программы написанные для того самого, первого, Android'а — могут работать и на последнем. А Windows Phone — выходила много раз и каждый раз — с «новым подходом» к написанию приложений, несовместимым со старыми устройствами.
Как такое вообще могло в готову придти кому-то в компании, которая захватила буквально всю индустрию с помощью своей религии совместимости, на которую буквально молились!
Не иначе набрали кучу людей, подобных echo — за что и поплатились…
Но, блин, зацените разницу в подходах: Android изначально выпускался под кнопочные телефоны и «трекбалл» (некоторые прототипы в принципе не имели touchscreen'а), на радикальную переделку дизайна времени было мало — и потому вышел вначале только под HTC Dream с кучей аппаратных кнопок. Но он — вышел в срок (ну… почти: подумаешь — на год позже iPhone). И программы написанные для того самого, первого, Android'а — могут работать и на последнем. А Windows Phone — выходила много раз и каждый раз — с «новым подходом» к написанию приложений, несовместимым со старыми устройствами.
Как такое вообще могло в готову придти кому-то в компании, которая захватила буквально всю индустрию с помощью своей религии совместимости, на которую буквально молились!
Не иначе набрали кучу людей, подобных echo — за что и поплатились…
У MS изначально был подход — каждая новая версия не совместима с предыдущей. Сколько раз ее проклинали например за подход к доступу к данным (DAO/ADO/и пр). Начинал писать под Android с версии 2.1 — единственное работающее правило в ней — нет ничего гарантированного. Конечно с одной стороны плохо — с другой стороны учит писать совместимо, но «вероятностно».
У MS изначально был подход — каждая новая версия не совместима с предыдущей. Сколько раз ее проклинали например за подход к доступу к данным (DAO/ADO/и пр).Тут всё-таки немного другое. Вы всегда могли притащить с собой «новую» технологию на «устаревшую» версию Windows. А приложения для Windows Phone запустить на Windows CE — нельзя, приложения для Windows 8 запустить на Windows 7 — нельзя и новые, «универсальные» для Windows 10 — ни на одной предущей версии Windows не запускаются!
Это, вообще, как? Это чего нужно выкурить, чтобы такое сотворить?
слава богу, что ушел с Windows, когда там прекратили поддержку MDI окон и весь старый интерфейс умер.
Что, реально прекратили? Убрали тот API?
Пытались убрать. Но до конца довести процесс самубийства не успели. Баллмера турнули, а Сатья всё развернул на 180 градусов. Впрочем я на 99% уверен, что решение о развороте было принято до того, как Сатья стал во главе Microsoft, а не после. А Балмера турнули — потому что кто-то же должен был ответить за «просранные полимеры»?
UFO just landed and posted this here
вы меня втянули опять в бессмысленные вопросы и старые ответы на них.Почему же бессмысленные?
Так вот — зарабатывание бабла это в том, чтобы не релизить постоянно, и постоянно править косяки, а в том, чтобы постоянно во всей системе существуют модульные тесты по каждой функции и по каждому чиху. И когда ваш «невероятно бесценный» сотрудник опять сбежит, система устойчива, потому что пришедшая ему на смену команда/прогер по тестам поймет, в чем суть и напишет, что надо, а не будет сидеть полгода гадать на бабушкином валенке и логах, че в системе и вообще зачем она. Хотя, конечно, и это не спасение и не last hope, но хоть что-то от ваших juniors и прочих гениев.А теперь, пожалуйста, примеры — в студию. Какие компании, которые последовали вашим «чудесным» советам стали от этого сильнее? Только крупных, пожалуйста (понятно что чем больше компания тем больше она страдает «от ваших juniors и прочих гениев»).
Потому что примеров компаний, которые «всё делали неправильно», а потом решили «исправиться» и потеряли кучу денег я знаю много. Это и Microsoft и Intel и много кто ещё. А вот компаний которые бы прониклись этой религией и стали вдруг «известны и богаты» — я не знаю вообще. Но, может быть, я их просто не замечаю.
Всё очень просто: люди способные сотворить «модульные тесты по каждой функции и по каждому чиху» и без того обладают достаточно дисциплиной, чтобы не порождать совсем уж ужасной чуши. А люди, на это неспособные — и не будут этого делать, хоть ты им кол на голове теши.
Тесты — штука хорошая, вот только надо понимать, что это ни разу не серебрянная пули и молиться на них — бессмысленно.
UFO just landed and posted this here
Вы точно уверены, что архитектура там действительно хороша?
Хороша была точно архитектура Windows CE и построенных на ее базе Windows CE / Mobile 5.0-6.0 и Windows Embedded Handheld 6.5.
А вот UWP как раз и делалась в лютой спешке, когда все поезда ушли — со всеми вытекающими.
Если бы ее пилили с 2008 по 2015-й, то было бы ок, и тут был бы шанс отвоевать третье, но приличное в процентах, место.
Вы пользовались UWP / разрабатывали под нее?
Вы пользовались UWP / разрабатывали под нее?Немного игрался. Как «сферический конь в вакууме» она неплоха.
Беда в том, что она плохо связана с тем что было до неё. Использовать старые наработки очень тяжко — ну так этим и Android с iOSом грешат…
> Беда в том, что она плохо связана с тем что было до неё. Использовать старые наработки очень тяжко
Почему беда-то? Вы хотели бы видеть совместимость с неудачным legacy и ещё один слой абстракций?
Почему беда-то? Вы хотели бы видеть совместимость с неудачным legacy и ещё один слой абстракций?
Вы хотели бы видеть совместимость с неудачным legacyВопрос не в том чего я хотел. Вопрос в том, что нужно было сделать.
и ещё один слой абстракций?А это уж как удастся сделать.
Вообще Windows Phone/WART/UWP/Как они там назвали её сегодня — это такая забавная трагикомедия…
Трагизм всей истории в том, что там просто чудовищное нагромождение совершенно идиотских стратегических ошибок.
А комизм — в том, для того, чтобы увидеть «как надо» нужно посмотреть, что делала в подобной ситуации компания… Microsoft. В те времена, когда она не была «многомиллиардным монстром» и не могла даже помыслить о том, чтобы своих собственных разработчиков «переламывать через колено».
Она ведь тоже через это проходила! Все почему-то считают, что Microsoft получила монополию на рынке операционок «на блюдечке с голубой каёмочкой». Из рук IBM.
Нифига подобного! IBM PC продавалась с одной из трёх операционок: PC DOS, CP/M-86, и UCSD p-System.
При этом имевшаяся у Microsoft операционка, как и в 2007, категорически не годилась под новое железо (только в 1981м нужно было перейти от кассет к дискетам, f d 2007 — от стилуса к пальцам) — и потому, как известно, подходящую операционную систему Microsoft купил (вместе с разработчиками). Но она была тоже заточена под идиотский API! Пришлось переписывать. Вышедшая через 2 года MS-DOS 2.0 имеет совершенно другой API, при этом «совершенно ясно», что старый API в новых условиях «абсолютно не годится», так как там просто в принципе некуда вставить поддержку работы с подкаталогами. Ничего — костыли решают. Потом API переделывают ещё раз, ещё раз и ещё раз. Но ужас летящий на крыльях ночи по прежднему с нами — только ближе к XXI веку, с распространением FAT32 и NTFS он, наконец-то, перестаёт поддерживаться.
А теперь, внимание, вопрос: кто заставил Microsoft напрочь забыть уроки прошлого и почему Microsoft в XXI совершил все ошибки, которые привели к гибели конкурентов Microsoft'а (Digital Research, IBM, далее везде) в веке XX? Уж не «глубокие мыслители» a-la echo_mont? Размазавшие сопли по столу и убедившие идиота Баллмера, что «не стоит резать кошке хвост по частям»?
Стоит, стоит. Если забыли как это делал Microsoft 30 лет назад — посмотрите на Google: он, с его Android'ом, всё делает точно так же…
Если бы ее пилили с 2008 по 2015-й, то было бы ок, и тут был бы шанс отвоевать третье, но приличное в процентах, место.Шанс был бы, если бы они дали возможность как-то перенести приложения с Windows CE (12%) и Symbian'a (30%) на свою новую платформу. А так… Три раза переделывать всё и заставлять разработчиков начинать с нуля? Они, эта, белены объелись?
Напомню, что когда в 1993м появилась новая операционная с новыми 32битными Win32 приложениями, то сразу же появился и способ запустить их на миллионах Windows 3.x систем. Что помешало то же самое сделать тут? Спешили очень? Блин, в 2003м Энди с парой друзей начали Андроид разрабатывать, в 2005м продал компанию Google и в 2008м телефоны уже вышли — это я понимаю, «спешили». А тут? Семь (хорошо если не десять) лет на разработку??? Ничего себе «спешка»…
Довелось работать с коллегой, который на 100% попадает в типаж «рок-звезда». Но при этом он был чертовски харизматичен и обладал дополнительно всеми качествами «пассажира». В общем, гремучая смесь. Брали его на проект в качестве обычного PHP-разработчика. Но писать скучный бэкенд на PHP ему, конечно, было не по кайфу. В итоге продавил менеджмент на разрешение реализовать API на… лиспе!
Полгода он писал свой DSL-язык на Lisp, так, чтобы тот был еще формально верефицируемым. Короче, развлекался по полной. Пока его с треском не уволили, а сам проект закрыли.
В общем, очень поучительная история к чему приводит нахождение человека не на своем месте.
Полгода он писал свой DSL-язык на Lisp, так, чтобы тот был еще формально верефицируемым. Короче, развлекался по полной. Пока его с треском не уволили, а сам проект закрыли.
В общем, очень поучительная история к чему приводит нахождение человека не на своем месте.
я бы добавил пятый типаж: ТЕРПЕЦ
некий делец, которого всё реально зае*ало: весь пи**ец который повсюду происходит
некий делец, которого всё реально зае*ало: весь пи**ец который повсюду происходит
что делает HTTP-заголовок Content-Length
Заголовок ничего не делает. Он не может производить никаких действий.
Мы его просто получаем и при необходимости обрабатываем.
Автор, подучи матчасть
Вот наверное такое же чувство должны испытывать люди после хорошего психиатра: я по прежнему болен, но теперь хотя бы знаю, как это называется.
Значит вот это всё, потому что я rock star.
Спасибо за статью. Очень интересно 👍
Четыре типажа программистов