понедельник, 2 мая 2011 г.

Языки, разработчики и менеджеры

У нас в твиттере (опять) разгорелась дискуссия. Ну как, дискуссия-то особо не клеится, мыслей много, а сообщения слишком короткие – все-таки твиттер SmileМожет, в комментариях будет попроще.

В общем, Слава Панкратов был на конференции, и там рассказывали как кто-то использовал Nemerle для автоматизации тестов на отдельно взятом проекте. Отношение Славы к этому строго негативное. Оно и понятно, язык экзотический, кто будет потом это поддерживать?

К дискуссии присоединился Владимир Кочетков (магия твиттера, собираются три абсолютно незнакомых человека и обсуждают вопрос). Владимир считает, что проблема преувеличена, все-таки .NET, к C# достаточно близок, а особенности Nemerle освоить не так-то и сложно. Да и речь идет о небольшой туле, риск не так и велик.

Что же, многие менеджеры сталкивались с такой проблемой. Приходит разработчик светлая голова к менеджеру и предлагает написать вот эту полезность да и еще на чем-то непонятном. Что делать? Дать добро, а потом расхлебывать?  Объяснить, что все это игрушки, а нам нужно проект делать (с риском, что больше человек и не будет приходить с идеями, раз его здесь не ценят)?

Лично я вижу массу положительных моментов в том, чтобы дать ребятам возможность оттопыриться на каком-то некритичном куске проекта. Вот мои соображения, и скажите, где я не прав! Smile

Во-первых, ребята, которые увлекаются неординарными языками, функциональным программированием, – это обычно талантливые, высококлассные специалисты. У меня в группе есть такие парни – Витя, Паша, например. И если ребята чего-то хотят, то я отношусь к этому серьезно, где мне еще найти таких?

Во-вторых, мне кажется неслучайным, что они и на Java/C# здорово пишут. Я уже писал про это, хорошему разработчику нельзя останавливаться на месте, а освоение новых языков здорово прокачивает мозги.  Мне кажется, что интерес к другим платформам в том числе помогает повышать квалификацию программиста и в обычных мейнстрим языках.

В-третьих, если эти умные ребята предлагают какую-то технологию, то у них часто есть вполне осознанные технологические доводы. Например, Nemerle очень неплох для DSL, поэтому этот язык, вероятно, неплохо подходит для формирования удобного DSL для фреймворка по тестированию. Может, люди дело предлагают?

В-четвертых, когда эти классные ребята с горящими глазами рассказывают другим классным ребятам (работающим в другой компании) о своем опыте в Nemerle… Я нахожу это полезным Smile Это именно та адресная реклама, которая нам нужна на рынке программистов.

Ну и по поводу поддержки… Если вдруг тот, кто это все написал, уйдет куда-то (хотя с чего бы это?), а программисты в целом получают удовольствие от работы со всякими там маргинальными технологиями, то, может, другие разработчики наоборот будут рваться поддерживать этот кусочек, просто чтобы получить немного фана? Может, когда на собеседовании я вдруг скажу “а тут у нас еще на nemerle есть штукенция”, то у человека загорятся глаза и он все-таки пойдет к нам, а не к конкурентам?

В общем, мне кажется, что люди важнее. Программисты без менеджера вполне могут сделать проект, а вот менеджер без программистов – это вряд ли.

8 комментариев:

  1. >> Объяснить, что все это игрушки, а нам нужно проект делать (с риском, что больше человек и не будет приходить с идеями, раз его здесь не ценят)?
    Ты утрируешь, Андрей. Я тогда тоже буду, так что теперь любую идею принимать, чтобы все разработчики были счастливы?

    ОтветитьУдалить
  2. Ты тоже утрируешь :)

    А когда-нибудь сталкивалась с саботажем? Когда разработчик в итоге решает сам что-то делать по чуть-чуть ни с кем не советуясь? Потому что знает, что все равно запилят. Уж лучше он ко мне придет и мы обсудим.

    Самое интересное, что я когда-то, когда еще писал код, именно таким саботажем и занимался - писал по чуть-чуть юнит-тесты или рефакторинг делал втихую.

    Это сейчас все говорят "да, тесты это правильно, надо писать", а раньше кислые лица делали.

    ОтветитьУдалить
  3. Конечно, утрирую. Я ж так и написала "Ты утрируешь, Андрей. Я тогда тоже буду". С саботажем со стороны разработчиков не помню, чтобы сталкивалась. Может что-то по мелочи и было. Сама да, кое-что саботировала, как менеджер.
    Я не за ТО, что нужно все запрещать. Должен быть баланс, как и везде. Но аргументация твоя мне не нравится. Есть бизнес, у него есть цели, команда обеспечивает его цели. Команда ОЧЕНЬ важна, ее мотивация ОЧЕНЬ важна. Но не надо же бросаться в крайности. Все, что делается в проекте должно нести выгоду заказчику. Если это не несет выгоду, делать этого не стоит. И существует очень много вещей, которые и выгоду несут заказчику, и для команда являются приятной "фенечкой".

    ОтветитьУдалить
  4. > "Ты утрируешь, Андрей. Я тогда тоже буду"

    А, сорри :) Ночью что-то недопонял.

    В принципе, я конкретную ситуацию описывал - умные ребята предлагают нестандартные средства для некритичного куска проекта. Не так уж я и утрирую.

    > Все, что делается в проекте должно нести выгоду заказчику.

    Ну, автоматизация тестирования однозначно принесет выгоду заказчику. Какая разница заказчику, на чем это написано? Nemerle с технической точки зрения может и удобнее, чем C#.

    Вообще, у нас какая-то грусть - Java да C#, как будто других языков нет.

    Вон Erlang для многих экзотика (очередной функциональный язык), правильно? А вообще, годный язык. CouchDB, например, на Erlang-e написан. Да что там, вообще, чуть ли не отраслевой стандарт для телекоммуникаций.

    Вопрос просто в том, чего мы хотим достичь. Если хотим клепать однотипные проекты для веба, то зачем нам что-то еще.

    После того, как мы поработали с серьезными многопоточными ETL мне очень нравится то, что ребята предлагают в F#, пускай бы разработчики посмотрели и поучились - концепции оттуда можно и на обычных языках реализовывать.

    ОтветитьУдалить
  5. Ладно. Я собственно тебя поняла. Я скорее не оппонирую тебе. Мне наверное понятнее и важнее, чем тебе иметь мотивированную команду, и не потерять высококлассных профессионалов.
    Но важно, что грань очень тонкая между тем, чтобы пробывать что-то новое ради интереса, и с помощью чего-то нового приносить value для проекта.
    Очень важна, чтобы команда это научилась понимать. Подружить нужно бизнесс и девелопмент. Это я не к тому говорю, что ты не подружил, ты может и подружил. Это я говорю к тому, что часто нет между ними теплых чувств. :)

    ОтветитьУдалить
  6. > Но важно, что грань очень тонкая между тем, чтобы пробывать что-то новое ради интереса, и с помощью чего-то нового приносить value для проекта.


    Мы наоборот уговаривали заказчика использовать мейнстримовый .net, а они все же захотели ab initio. теперь ищут разработчиков, жалуются, что дорого :)

    ОтветитьУдалить
  7. > Так или иначе, но я не согласен с той категоричностью, с которой от Вячеслава прозвучало пожелание о вбитом в голову разработчика гвозде.

    Это точно, меня такая категоричность сильно удивила. Я за свою недолгую карьеру впервую очередь понял, что ни в чем нельзя быть на 100% уверенным. И чем дальше уходишь в сторону менеджмента, тем больше приходится учиться доверять специалистам.

    ОтветитьУдалить
  8. Думаю, что истина все же где-то посередине. Озвученной информации явно недостаточно для того, чтобы делать однозначный вывод о том, что же там происходит у них в проекте. Вячеслав принял за данность крайний вариант, что некий разработчик втихаря переписал часть инфраструктурного кода, относящегося к процессу тестирования, на Nemerle и высказался о необходимости жестко пресекать подобные вещи. Но кто сказал, что втихаря? Быть может, ему действительно выделили не особо критичный участок, как раз для экспериментов? Или то, что он пишет быть может обратно совместимо с используемым фреймворком, почему бы и нет? Или там всего немерла-то - пара переписанных на нем батников, тоже ведь возможно?

    Так или иначе, но я не согласен с той категоричностью, с которой от Вячеслава прозвучало пожелание о вбитом в голову разработчика гвозде. Опыт, имеющийся у меня, говорит о том, что если подобные инициативы поощрять гвоздями в голову, то рано или поздно, этими же гвоздями сотрудники прочно закрепят тебя на кресте. Даже в наихудшем для проекта случае, когда инициатива проявляется втихаря, последнее что нужно делать - это как-либо наказывать сотрудника. Во-первых, потому что более инициатив от него не будет и я считаю это минусом, а не плюсом. Во-вторых, потому что подобные активности, как правило, говорят о стремлении сотрудника что-то улучшить, оптимизировать, чем-то помочь проекту помимо исполнения своих прямых обязанностей. Это достойно поощрения, на мой взгляд и гораздо более грамотной стратегией менеджера или тим-лида, в данном случае, мне представляется взятие под крыло подобных активистов и поощрение их деятельности. При грамотном контроле, вреда проекту от этого не будет, зато польза несомненна: во-первых, есть неслабый шанс, что их идеи действительно помогут что-то улучшить. Во-вторых, сотрудник добровольно занимающийся подобной исследовательской деятельностью будет весьма замотивирован (до поры до времени - да, но это уже тема отдельного разговора). В-третьих, совершенно согласен с тем, что сам факт наличия в компании ресёч-направлений - очевидный плюс для соискателей при выборе работодателя. В-четвертых - сотрудник-активист по результатам своих исследований вполне может подготовить доклад на следующий addconf на тему: "как мы внедряли X для Y в компании Z". Да много еще чего можно из этого извлечь и сохранить при этом стремление сотрудника делать что-то большее, чем того требуют должностные инструкции.

    Что же касается непосредственно этого языка, то в нем проделана значительная работа по мимикрии под шарп именно для того, чтобы облегчить разработчикам переход на новый язык. На самом деле, большинство шарповских конструкций в нем реализовано макрами и выгрузив эту либу разработчик внезапно осознает, что от шарпа в этом языке почти ничего нет :) Но даже, если писать на нем "как на шарпе", то это даст некоторый выигрыш хотя бы в объеме кода (т.к. вывод типов у Nemerle чуток посильнее будет, он поддерживает indentation-синтаксис а-ля Python, некоторые конструкции получаются гораздо компактнее аналогичных шарповских).

    ОтветитьУдалить