Pull to refresh
10
0

Пользователь

Send message
Это ограниченное понимание роли лида, притянутое за уши опыта, через который вы прошли. Повторюсь: не стоит путать свойство функции со свойством исполнителя этой функции. Если, к примеру, вам только и встречались лиды, которые были «дискредитированы» более «сведущими», то это не значит, что все лиды такие :)

Лид не нужен совсем, нет в скраме такой роли.


Если с Скраме нет какой-то вещи, то это не значит, что она не нужна!
Если в Скраме нет роли лида, то это не значит, что никто не исполняет эту роль!
Давайте, я отвечу такой аналогией.
У меня есть велосипед — у него отвалилось колесо.
Он был покрашен — краска стала отходить.
Проехав 10 километров, он заскрепел, т.к. не был смазан, а после 20-ти километров появился люфт руля.

Вывод: все велосипеды — зло!

Так и вас: вы приводите нормальные поинты, только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов.
но на нормальных проектах, это зло, постоянно тормозящее проект и других разработчиков, просто в силу физической невозможности проффессионально все успевать


Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают, а то, признаться, я таких за 10+ лет опыта не видел, что-то новое и неоткрытое! :)
anatolix
А какое ratio между microsoft .net (подозреваю, что он у вас еще остался), .net core и go у вас? По какому принципу выбиралось «вот этот микрососервис будет go'шным, а этот — .net core'вым»? И пару примеров сервисов на .net core интересно увидеть.
SergeyEgorov
а можно больше конкретики, из чего конкретно складывается эксплуатация и где именно она дорогая?
Я видел самые разные примеры целей в разных компаниях. От «сделать такую-то техническую задачу Х» до «стать экспертом в системном администрировании». Цели первого вида ставить легко. Если есть какой-то проект, то его имплементация, та часть, которая возложена на вас, — это и есть цель. Иногда пытаются ставить вероятностную цель: пытаются угадать, на какой процент изменится поведение системы или пользователей. Заранее какой процент получится предугадать сложно, поэтому здесь риск недостижения может быть сколь угодно велик, в общем, на свой страх и риск :) Цели второго типа — они слишком общи и сложно измеримы. Тем не менее, есть компании, которые все равно требуют такие цели ставить потому, что у сотрудника должен быть вектор развития, который такими целями и управляется.
то вы узнаете только те технологии, которыми эта компания пользуется.


Ну а если вам другие технологии и не нужны?
За это время как раз и можно нормально изучить ограниченный набор технологий, но не только это. К примеру, если вы это время работали бы в продуктовой компании, то изучили бы как минимум несколько модулей на хорошем уровне, получив ценное знание о том, как они устроены. Это в разы повышает архитектурные скиллы, например.
Как лучше такую систему сделать?


Я тут недавно слышал интересную мысль: матрицы компетенций не нужны потому, что пока вы будете ее составлять она и сама и устареет (новые технологии приходят, старые — уходят), и навыки ваших специалистов тоже устареют. :)

На самом деле, ваш вопрос, пожалуй, самый сложный во всем этом процессе, связанном с формальным ростом внутри компании. Лично я не очень верю в систему баллов, ее сложно обосновать и сложно гранулировать (например, если у вас 100 баллов — вы получаете повышение, а если 98 — не получаете. ну бред же!). Но с другой стороны, сотрудники, которые проходят курсы и получают сертификаты как правило, знают в среднем больше и обладают большой мотивацией, которая и должна быть вознаграждена в итоге.
Вообще, общий подход, принятый во многих больших компаний — это постановка целей. Цели не только получают ранг, степень выполнения, но и степень влияния на команду, отдел и бизнес целиком. Например, если вы сделали очень простую систему, в которой может не быть ничего выдающегося с технической точки зрения, то она может экономить компании значительные деньги. Если же вы сделали систему, которая сложна и неповторима (в значении «сложно сделать») — это отличный пример, который показывает, что произошел рост в квалификации на качественном уровне, заслуживающий поощрения.
Но, понятно, что когда мы масштабируем эту систему оценки на всю компанию, то в ней встречаются сложные и неоднозначные кейсы, связанные с тем, что разные менеджеры по своему трактуют важность и степень достижений, с тем, наконец, что в компании существуют лимиты на повышения. Например, если есть 10 человек, которые получили отличные и одинаковые оценки на performance review, то для них нет гарантии, что они получат одинаковое вознаграждение. В целом, этот процесс имеет много изъянов и вещей, связанных со случайностью. Случайность работает в обе стороны: вам повезет и вы выполните какую-то важную цель из-за благоприятного стечения обстоятельств, либо наоборот.

Букв, действительно, немало, т.к. статья ориентирована на начинающих разработчиков, поэтому, короче не получилось. :)
По вашим комментариям 1-3: ну, я все же фокуссировался на качестве, которое называется skill (не номинальную смену должности из-за перехода). Если skill есть, то за ним как правило и подтягиваются более хорошие финансовые и карьерные условия.
Вы же как раз пишите пример логики, который я привожу в разделе «Смена работы». Чем смена работы, особенно в первые 3 года опыта может быть плоха — я привожу пример в статье. Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.

Когда вы будете менять компанию и иметь значение будет лишь то как выглядит со стороны ваша роль в этих проектах и сколько их было.


Опыт — отличная вещь, чтобы а) попасть на собеседование на интересную позицию б) при условии, что вы прошли тех. интервью, быть при прочих равных первым кандидатом на нее.
На собеседованиях (если мы говорим про позиции jun-dev-senior) вы во многом продаете ведь не опыт, а ваше знание технологий и умение решать задачи прямо на собеседовании (например, писать код на листочке).

Не тратьте время зря на бесполезные проекты


Частично согласен. Но был ли проект бесполезным, возможно, вы сразу не узнаете. Вообще, опять же, в первые 1-3 года опыта бесполезных проектов практически не бывает. Когда у вас опыта нет, они все приносят какой-то полезный опыт и формируют подход. У меня есть личный пример: на первом году работы я несколько месяцев занимался тем, что сейчас называется DevOps. Мне не очень нравилось, ну все-таки это не разработка самой системы. Но опыт, который я там получил, до сих пор формирует у меня планку качества и понимание того, как должна быть устроена, например, автоматизация развертывания и среды тестирования, и какие бенефиты это все дает: я понимаю это не на бумаге и не потому, что так написано в книгах или статьях, а потому — что я трогал это руками и видел конкретные результаты. Это ощущение стоит дорого и позволяет правильно оценивать важность задач и выхлоп от их внедрения. Не все важные задачи интересны конкретным разработчикам или менеджерам — это правда.
Во-первых, прошу прощения, но собеседование само по себе — это и есть редукционистский и, безусловно, относительный подход: вы пытаетесь за 2-4 часа оценить опыт/навыки человека, который работал, к примеру 10 лет. Тут именно вопрос в том, как именно редуцировать так, чтобы проверять наиболее релевантное. Во-вторых, я снова повторюсь, что провожу собеседования комплексно и оцениваю на нем и в том числе и «нюансы специализации и конкретного опыта». Но если человек, имеющий хотя бы какой-то опыт, который можно считать приличным, не может написать простой код без ошибок на бумаге даже с 3-ей попытки — это, снова повторюсь, говорит о том, что если он и реально что-то разрабатывает (а не просто все наврал в резюме), то его подход к разработке основан на гуглении и бездумном итеративном устранении ошибок методом тыка. Это не тот уровень разработчиков, с которыми я работал когда-либо :)

весьма далекие от реального положения вещей (см. теорию хаоса)

Ну и какое же реальное положение вещей, просветите пожалуйста? :)

банальный способ переложить ответственность на примитивную методологию


Ну а ваша то методология какая? Демонстрировать написанный код? Хорошо, а если ваш код не покрывает тех случаев, которые бы я хотел увидеть? Готовы дописать ваш код прямо на собеседовании? :) Ведь это будет сложнее, чем начать сначала на абстрактной задаче. Дальше: где гарантия того, что этот код написан самостоятельно и что он написан в приемлемые сроки? Где гарантия, что этот код вообще правильный? Итд.

«Оказывались полными мудаками» — это разве про уровень разработчика? Это про общий подход к работе и soft skills. Или что вы имеете в виду?

«бумажка вам не скажет о уровне разработчика ВООБЩЕ НИЧЕГО»


Она скажет:
1) об умении сначала думать, потом делать и делать аккуратно
2) писать не очень сложный код без ошибок
3) придумывать алгоритмы для сформулированных задач в ограниченное время
4) о знании базового синтаксиса языка без Google и SO. Например, сколько раз я уже видел кандидатов, которые путают названия контейнеров в STL и их методов, по ним сразу видно, что hands on опыта с ними они не имеют. Разработчик, который не помнит, что в вектор добавляет метод push_back — это очень интересно, конечно :)

Я вовсе не предлагаю использовать бумажку (В значении coding interview) как единственный способ проведения собеседования и не утверждаю, что это единственный способ проверять skills. Но это достаточно действенный способ, который имеет распределение успехов, по которому можно неплохо пытаться определяться уровень в том числе. Скажем, вы даете написать 3-4 алгоритма разной сложности (подразумеваю, что речь идет о позиции, что где алгоритмы являются критичным навыком), далее можно построить распределение, по которому будет видно, что большинство справляется с 1-2 задачами с разной чистотой выполнения оных и далее все идет по убыванию. Действительно редкие специалисты способны закодить все 4, не допустив или почти не допустив ошибок. Если в вашей работе почти каждый код — это алгоритм, то такая проверка уже, на самом деле, многое скажет о том, что вы можете ожидать, наняв человека. Между «писать код на бумажке» и «писать код на ноутбуке» с моей точки зрения разницы не очень много, т.к., например, лично я почти не даю на собеседованиях реально технически сложных для кодирования задач, которые без клавиатуры делаются просто напросто долго, но некоторые этим злоупотребляют.
Проблема в том, что кроме категории «самозванец» существует уровень разработчика как таковой. Его часто необходимо определить достаточно точно, на сколько это возможно, конечно. Я бы усилил ваше высказывание и сказал, что именно самозванцев (т.е. абсолютных нулей или близких к ним) часто можно и по резюме определять, остальные отсеиваются на skype интервью. Бумажка вовсе не так плоха, как про нее пишут. Например, сделать reverse строки — это достаточно просто. Если такое сложно написать на бумаге правильно, то скорее всего человек если и действительно занимается программированием, то привык заниматься им в стиле «что-то не работает, поправлю как я вот здесь, авось заработает», «ой, что-то не заработало, наверное, еще нужно поправить вот здесь и вот тут». Кому-то здесь нужны такие специалисты?
«Я таких людей не беру. Очень много кандидатов у нас отсеивалось именно по этому принципу. ». — Спасибо вам за статью. А как вы это проверяете в условиях ограниченного времени на собеседовании? На что конкретно смотрите?
Merrimac

Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно привело к тому, что все команды (фронт, бэк и интеграция) оказались настолько плотно связаны, что любое обновление интеграции требовало регрессионной проверки практически всей шины!


Два вопроса:
1) Почему регрессионная проверка почти всей шины — это проблема? Это ведь можно по разному организовать.
2) Имхо, и вы можете меня поправить, здесь проблема может быть не столько в факте повторного использования, сколько в неудачной композиции.

Поддержка гибкой разработки. Легкое подключение новых, вертикальных команд, выход на уровень «фабрики разработки», с автоматизацией рутинных задач.


Назовите, пожалуйста, топ-3 причины, по которым вы считаете, что гибкая разработка в системе SOA/ESB невозможна.
Про over 50 (и предположим до 150, хотя, имхо 150,250 — суть одно, вряд ли разница ощутима) — отличный поинт. Однако, с учетом текущих экономических реалий таким конторам приходится не сладко, если только у них не присутствуют западные клиенты. Есть ощущение, что все остальные либо медленно но верно загибаются, либо отнюдь не медленно, либо их кто-то покупает (как-то не слышно о таких кейсах в посл. время, ну разве что очередной сферический Мегафонлайн кого-нить подъел).
В отрасли занимаются Big Data в любом случае, без формального определения. И в целом успешно. Неважно, сколько петабайт хранит база. Если в эту базу новых данных не поступает — мы получаем один setting, в рамках которого живем, если же туда в день приходит по 200 ГБ — совсем другой сеттинг. Занимаемся ли мы анализом собранных данных, строим ли мы витрины данных, есть ли у нас необходимость в близкой к real time обработке — условия могут быть самые разные.
Это-то как раз не феномен, а логичное следствие :) В среднем чем меньше у человека опыт, тем интереснее ему работать.

Наверное, и такое бывает. Но есть другое объяснение, более простое: одни делают вещи быстрее, чем другие, изначально.
Но талант выражается в нестандартных решения и новых идеях, а не в количестве или качестве кода. Количество и качество кода — результат как раз прилежности и аккуратности, а эти свойства не врожденные, а приобретаемые.

В чем выражается талант — это вопрос. Красивый код писать — это тоже талант. Пишется его не так много. Люди без опыта как правило не могут этого сделать. Но некоторые все-таки могут. Причем, опять же, делают это не хуже, а лучше, чем люди с опытом в 2-3 раза больше. Это врожденная способность понимать красоту. Объяснение вида "у них больше мотивации" не выглядит убедительным. Я полагаю, что у детей из бедных кварталов немало мотивации, но почему-то не все из них становятся Роберто Карлосами. Думаю, аналогия понятна.
А вообще чем больше я общаюсь с разными людьми, тем больше убеждаюсь в том, что «таланта не существует».

Да, только тогда не понятно, как объяснить, что у людей с вдвое меньшим опытом продуктивность в 2-3 раза выше. Как объяснить то, что одни пишут красивый легко поддерживаемый код, а другие — средний. Итд.
Что-то в последнее время слишком много разговоров про "ученые и олимпиадники пишут один только кривой код". На самом деле, код разный. Бывает, что и кривой, а бывает, что очень даже неплохой. На олимпиадах тех же самых, как правило вырабатываются кое-какие навыки написания краткого кода, который делает то, что надо. При правильном оборачивании такого кода в набор методов — может получиться правильно организованная библиотека.
Архитектура — очень хорошо. Знание алгоритмов — все таки не один и тот же, хоть и связанный скилл.
Базы данных: есть особый спектр специалистов, они с базами данных не работают вообще и не про какую оптимизацию запросов everyday не слышали и не услышат. (ну, например, среди программистов C++ такие встречаются) Это, однако, не означает, что они не смогут оптимизировать запрос. Потому что решает в конечном счете понимание принципов. В комментариях к этой и изначальным статьям прослеживаются выводы типа "Успех проекта был обусловен знанием пяти команд Unix'а, а не знанием алгоритмов". Это мне напоминает особо интересные собеседования по языкам программирования, где ставятся вопросы из разряда "А какой в методе Y у класса X аргумент номер 2?" Имхо, более толковый специалист — тот, кто НЕ зная этих 5-ти команд или не зная этого метода, сможет предположить их наличие, сможет найти эти объекты и разобраться в них, применить их на практике. Это одна из причин, по которой на некотоых собеседованиях вы не увидите сложных тестов из 40 вопросов на знание языков C++ и C# или на знание стандартной библиотеки. К примеру, иногда приходится собеседовать людей (совсем зеленых на низкие позиции), которые не знают внутренних особенностей STL. Но если они способны продемонстрировать понимание, как самостоятельно реализовать ту или иную вещь в STL — это гораздо важнее.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity