Система электронных платежей
145,43
рейтинг
8 декабря 2015 в 10:29

Разработка → Что делать, если программировать становится скучно перевод

imageСлучалось ли c вами, долго работая в одной компании над одним и тем же проектом, начинаешь задумываться о смене обстановки, используемых технологий и самого проекта. Раньше я был уверен, что из этой ситуации один выход — найти новую работу. Эта статья, перевод которой мы публикуем, поменяла мое мнение. В ней описывается подход, благодаря которому можно сделать работу программиста нескучной и помогающей ему расти и развиваться. Мы, сервис для организации приема платежей PayOnline, предлагаем вам ознакомиться с этой методикой и поделиться ею со своим работодателем, в случае, если вы испытываете подобные, описанные автором проблемы. Ниже идет, непосредственно, перевод.

В мою бытность разработчиком я никогда не задерживался на одной и той же работе более двух лет. В моем случае каждая новая работа была для меня хорошим ходом с точки зрения карьерного роста. И даже несмотря на то, что высокая “текучка” — обычное дело в нашей профессиональной сфере, я не могу сказать, что мои предыдущие работодатели спокойно относились к моему уходу. Некоторые из них упорно пытались сделать так чтобы я остался, но работа становилась для меня настолько скучной, что оставаться я уже не мог. Сразу поясню: мне посчастливилось жить в таких местах, где работы для программистов было больше чем самих программистов. Я понимаю, что вариант со сменой работы доступен не всем.

Сейчас, будучи одним из основателей и техническим директором Enki, я отвечаю за инженерную культуру, и поэтому в мои обязанности входит контроль за тем, чтобы наши разработчики никогда не теряли интерес к своей работе, как это происходило со мной раньше. Мы вместе с нашей командой изобрели стратегию борьбы с этой проблемой. Эту стратегию мы применяем ежедневно, и поскольку за все это время она хорошо себя показала, я хочу поделиться ей здесь.

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

Меняемся быстро, узнаем что-то новое


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

Я не мог поменять команду или проект, потому что это было бы слишком неразумно с точки зрения целей моей компании. Я был нужен ей на том же самом месте. Заменить меня было нельзя, ведь я слишком хорошо разбирался в данных и технологии. В то же время изменять технологию “под себя” из-за одного только желания научиться чем-то новому я не мог. Я рассказал работодателю, в каком безвыходном положении я нахожусь и как я устал, но он не принял никаких мер, поэтому мне пора была двигаться дальше.

Как же уберечь себя от таких ситуаций?

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

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

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

Как поддержка кода делает работу скучной


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

И да, и нет. Проблема кроется в вашем образе мышления.

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

Как же можно упростить эту ситуацию?


Иногда застревание в режиме сопровождения кода происходит в результате применения плохих технических решений вкупе с недостатком смелости. Крупная монолитная база исходного кода со сложными зависимостями требует дополнительной работы с точки зрения сопровождения. В противовес ей, хорошо спроектированная инфраструктура, построенная на основе микрослужб, оказывается более гибкой. Неисправную микрослужбу можно легко заменить. Ее можно переписать с нуля, используя другой язык или технологию. Таким образом, вместо того чтобы латать унаследованный код, у вас появляется возможность изучить что-то новое. А если ваша архитектура все еще не позволяет использовать микрослужбы, вы можете улучшать ее поэтапно, одновременно поднимая свой уровень знаний в DevOps.

Стратегия применения микрослужб – только один из подходов к решению проблемы “скучного” сопровождения кода. Некоторые компании даже создают умные инструменты для того, чтобы сделать процесс сопровождения более эффективным и увлекательным. В качестве яркого примера можно привести Facebook и его подход к оптимизации огромной базы PHP исходников. Разработчики компании создали собственные компилятор и язык Hack, использующий статическую типизацию и работающий поверх PHP. Это помогло им упростить процесс сопровождения и оптимизировать рабочий процесс. Подозреваю, что всех проблем с унаследованным кодом эта мера не решила, но благодаря ей жить разработчикам наверняка стало веселее.

Как регулярная “копипаста” делает работу скучной


Есть кодинг, а есть кодинг.

Если посмотреть на мою более раннюю деятельность, то становится понятно, что я создал много никому не нужного кода. К примеру, однажды я писал скрипты на Groovy и Python для интеграции данных. Структура была сложной, содержала десятки непостоянных схем, которые не позволяли добиться сколько-нибудь значимой автоматизации. Поэтому мне пришлось писать много кода. Мои коллеги, работавшие над этой задачей вместе со мной, тогда полагали, что я получил много новой и полезной информации в процессе работы.

Но на самом деле это не так, и я объясню почему.

Все дело в том, что 50% моего кода были прямой копипастой со Stack Overflow, остальные 40% — копипастой других скриптов, авторами которых были либо коллеги, либо я сам. Процесс оказался очень однообразным и творчества или обучения новому в нем было немного.

Как относиться к этой проблеме наша команда?

Будучи одной командой, мы внимательно анализируем типы кода, который каждый из нас пишет. Мы делаем это вместе во время совместных разборов кода и ретроспектив, и если кто-то потратил неделю, работая над совершенно бесполезным кодом, мы пытаемся понять, почему так получилось.



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

Внутренние инструменты обычно делают работу скучной


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

Почему?

Потому что вы не сможете обсудить проприетарные инструменты с друзьями. Не сможете похвастаться, что знаете их. О них не напишут в блогах, а кроме того, ими нельзя воспользоваться на хакатонах или для работы над своим секретным сторонним проектом.

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

Я на собственном опыте убедился в этом на предыдущем месте работы, где мне пришлось использовать разработанный внутри компании предметно ориентированный язык для широкомасштабной интеграции данных. То, что мне на самом деле пришлось изучать, можно, пусть и с небольшим преувеличением, назвать очередным SQL-ным жаргоном. С гораздо большим желанием я предпочел бы изучать и использовать какую-нибудь низкоуровневую открытую технологию вроде Spark, потому что в этом случае я был бы в 10 раз более вовлечен, и даже если бы мой код при этом был в 2 раза избыточнее, это все равно сделало бы меня в 5 раз продуктивнее.

Какой же должна быть культура в компании чтобы предотвратить такие ситуации?

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

Время от времени случаются ошибки. К примеру, мы какое-то время использовали библиотеку agenda.js для планирования заданий по серверной части, потому что считали ее современной и интересной. Однако в нашем случае оказалось, что она все усложняет, поэтому было принято решение вернуться к старой, но более надежной технологии — старому доброму cron. И тем не менее мы не жалеем об этом эксперименте, потому что для нас это был ценный опыт.

Как monkey-coding делает вас скучным


Другая распространенная причина потери интереса к работе — плохое управление людьми. Я имею в виду структуру управления “сверху вниз”, которая применяется в среде разработчиков и нередко приводит к диктатуре вышестоящих.

Иногда руководители, сами того не понимая, используют именно такой подход, делая это из благих побуждений. Особенно часто это происходит, когда дела в проекте идут не очень хорошо, или во время приближения дедлайна. Это естественная реакция человека, находящегося под давлением, — стараться прервать обсуждения, свести до минимума “мозговые штурмы”, вместо этого выдавая подчиненным прямые указания о том, что надо сделать, без каких-либо споров или объяснений. Конечно же, все это делается ради экономии времени и получения необходимого результат.

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

Тем не менее у такого подхода есть свои скрытые издержки. Знание того, какой именно код надо писать, еще до начала самой работы превращает программирование из интеллектуального и творческого процесса в чисто механический. Иными словами, “девелопер” превращается в “манки кодера”.

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

Как предотвратить возникновение такой ситуации?

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

Повседневность всегда становится скучной


И последний, но не менее важный момент. Нет лучше способа убить интерес и увлечение, чем поместить себя в замкнутое пространство и заняться какой-нибудь рутинной деятельностью.

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

Как мы с этим боремся?

Ключевой компонент профилактики — многообразие. Мы нанимаем людей с разными опытом и происхождением. Наша текущая команда состоит из 6 человек, среди которых есть представители Британии, Франции, России и Греции. Видеть одних и тех же людей каждый день определенно гораздо интереснее, если каждый из них может привнести что-то новое в общую культуру.

Мы также стараемся разнообразить повседневную активность и выйти за рамки обычной рабочей схемы.

К примеру, мы вместе ходим на публичные митапы и хакатоны. У нас есть сторонние проекты и, кроме того, мы вносим вклад в развитие наших любимых «опенсорсных» инструментов. Время от времени мы даже помогаем остальной части команды по непрофильной для нас работе, такой как наем персонала, маркетинг, распространение продукции. Конечно, нельзя сказать, что мы во всем этом разбираемся, но мы делаем это просто для разнообразия.

Кроме того, мы выбираемся куда-нибудь всей командой (в Secret Cinema, например), а также проводим еженедельный “энкитон”(Enki + hackaton) без какой-либо заранее оговоренной программы. Иногда во время таких встреч мы что-нибудь вместе разбираем, или “штурмуем” новую идею. Иногда мы просто играем в Лигу Легенд или идем в паб. Все прелесть в том, что мы до самого последнего момента не знаем, что будем делать, пока вместе не решим.

Немного хаоса — последний ингредиент в нашем рецепте против скуки. И как и любой другой рецепт, его можно совершенствовать бесконечно. Если что-то не так просто меняем ингредиенты, или их пропорции и пробуем снова.

Как видите, рецепт «нескучного кодинга» открыт и прост. Будь вы руководителем своей команды или рядовым сотрудником, вы в силах сделать вашу работу эффективнее и интереснее. Развивайтесь, стремитесь к новым целям, не зацикливайтесь на одной задаче, особенно, если работа над ней не приносит должного результата. Время от времени переключайте внимание на другие проекты. Анализируйте свою работу, лучше коллективно, так вы быстрее найдете «проблемные места». Не бойтесь высказать новые идеи, проявляйте творческий подход, иначе программирование превратиться в механический процесс, а это просто-напросто скучно. Ну и конечно сложно быть сплоченной командой, не имея других точек соприкосновения, кроме того, что вы работаете в одной компании. Меняйте обстановку, выбирайтесь с коллегами на отдых, вместе осваивайте новые горизонты, и вам вряд ли захочется уйти.

Материал к публикации подготовлен компанией PayOnline, международной системой для приема электронных платежей. Если вам нужно организовать прием платежей на сайте, смело обращайтесь. Также подписывайтесь на наш корпоративный блог, впереди еще много интересных постов.
Автор: @cigulev Bruno Marnette
PayOnline
рейтинг 145,43
Система электронных платежей

Комментарии (56)

  • +2
    Как вы оцениваете затраты на всё вышеперечисленное, в % от общих затрат на разработку?
    • 0
      Точную оценку дать затруднительно. Я думаю, если использовать большинство советов из данной статьи, то это должна быть уже состоявшаяся компания со свободными ресурсами и достаточным количеством энтузиастов, которым нравится развиваться, как директору компании Enki, деятельность, которой описана в статье. Также безусловно во всем нужен баланс, важно не переборщить и выслушать мнение каждого, кому-то может нравиться развиваться в узком направлении и каждый день делать то, что уже хорошо получается.

  • +7
    Я бы сказал, что прежде всего работу скучной делает отсутствие цели. Когда по полгода толчешь в ступе одну и ту же воду без видимого результата.

    Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.

    Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.
    • +3
      Я тут согласен скорее с автором статьи, чем с вами. Программисты занимаются программированием, потому что им нравится программировать, а не потому, что они хотят достигать каких-то навязанных сверху целей. Важен сам процесс, результат особого значения не имеет. Если результат сильно интересует программиста, то он скорее всего не на своём месте.
      • +13
        Программисты, программирующие ради программирования, — это скорее новички/середнячки. Сеньоры программируют с какой-то целью, технической или бизнес. Обязанность менеджмента — совмещать эту цель с реальными потребностями организации.
        • –3
          Бизнес ставит сеньорам цели, это да. Но если у человека приоритет достичь этой цели, а не попрограммировать — ему дорога в менеджмент какой-нить. Технические цели — да, но это из разряда интереса к програмиированию.
        • –2
          Сеньоры программируют с целью получить бабки. А уже как достигается эта цель, с помощью каких меньших и промежуточных целей — дело десятое. ;)

          Добавлю, что все советы из статьи хороши для маленьких фирм — большие бюрократические конторы очень сильно плесневеют и костенеют с бизнесе, там ничего просто так не заменишь, не используешь, не посоветуешь.
          • 0
            За всех сеньоров не говорите. Как минимум, для некоторых бабки не цель, а средство. Не платили бы бабок, достаточных для комфортной жизни, всё равно бы программировали, пускай и в меньшем объёме, зарабатывая на комфортную жизнь работой продавца или, прости господи, проджект-менеджера :)
        • 0
          Что в вашем понимании есть «техническая цель»?
      • 0
        Не хотел бы я работать вместе с такими программистами, которым не важен результат, бррр… Это не программисты, а погромисты какие-то.
        • 0
          А вы кто по профессии?
          • +7
            Как программист, поддерживаю Scf и dendron. Не вижу смысла программировать ради программирования. Мне не приносит удовольствия писать код, который непонятно кому и зачем нужен. Программирование по своей сути — инструмент для достижения некоторых целей. А иначе это все равно что забивать гвозди потому что нравится дырявить доски, а не чтобы построить дом.
            • +6
              Аналогия с гвоздями не вполне точна, так как у программиста гораздо больше простора для роста, чем у забивателя гвоздей, но всё равно хороша.

              Подумайте о вопросе вот с такой стороны. Человек, который забивает гвозди потому, что ему нравится дырявить доски будет забивать гвозди в любой ситуации, даже если эти гвозди через дорогу вытаскивают и сдают на металлолом. Он будет делать это с наслаждением и будет получать за это достойную зарплату. Ему не грозит профессиональное выгорание на почве бессмысленности деятельности, он постоянно растёт профессионально, потому что думает только о том, как это клёво — забивать гвозди. Он даже может начать интересоваться зачем и кому забитые гвозди нужны — это позволит ему забивать гвозди таким способом, что за то же самое количество гвоздей он получит вдвое больше денег. Но это всё так — приятное дополнение к волшебному процессу забивания гвоздей, не более.

              Кстати, очень интересно, если вас действительно волнует кому и для чего код нужен, почему вы не занимаетесь менеджментом — там возможности работы с этими элементами процесса куда шире.
              • 0
                Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»? Я сомневаюсь, что они используют какие-нибудь «хипстерские» noSQL решения ради того, чтобы развиваться. Я думаю, что решения должны приниматься с учётом цели конечного продукта. Не все программируют формочки для веб-сайтов.
                • 0
                  Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»?

                  Кстати, в догонку к комментарию ниже — действительно, в таких сферах много времени уходит на специализацию, да и роста там не так много. И через 2 года менять место работы не получится. Советы статьи далеко не везде применимы.
                • +1
                  Ну использовать хипстерские решения это только один вариант роста. Другой вариант это учиться писать программы с использованием ограниченного инструментария. Тоже неплохо.

                  Про мед учреждения не знаю, а про военных могу сказать. Тем, кто там работает, программирование глубоко до фени — это неприятный, но необходимый элемент, например, запуска спутника. Спутник сделать и запустить им интересно, а код писать — ну что ж, не такое ещё делали. Это, правда, что касается именно спутников, с разработкой какого-нибудь прикладного ПО для военки я не знаком.
              • 0
                Вы как раз описали заинтересованного магией новичка, который вырос и стал использовать программирование как инструмент. Да, я точно так же пришел в программирование, но нельзя же десять лет забивать гвозди бесцельно.

                Ответ на второй вопрос — когда я пишу собственный проект, я занимаюсь вообще всем, включая администрирование, дизайн, рекламу и работу с пользователями. Возможностей завались :) Но это все на уровне хобби.
                • 0
                  То есть вы самореализуетесь в своём хобби? Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?
                  • +1
                    Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?

                    Да. Но есть вероятность, что любимое дело перестанет быть таким любимым
                  • 0
                    Спасибо, но на работе я занимаюсь любым делом сколько душе угодно часов :)
                    • 0
                      Так выходит ваше любимое занятие всё-таки программировать? В ваши непосредственные обязанности ведь не входит администрирование, дизайн, реклама и работа с пользователями?
                      • 0
                        Программирую я достаточно хорошо, чтобы продавать это умение за деньги. Остальным я занимаюсь в своих проектах, и нельзя сказать, что это не является моей обязанностью (если я не нахожу другого человека для выполнения их). Но я уже потерял нить, к чему вы клоните :)
                        • 0
                          Ну вы сказали, что на работе занимаетесь любимым делом сколько душе угодно часов. Так как вы программист, то это любимое дело очевидно — программировать. Что в общем подтверждает мой тезис — программисты больше всего любят программировать, а после этого уже все остальное.
                          • 0
                            Никто не спорил, что программисты любят программировать :) Сомнение вызвало ваше заявление, что программистам не важно достижение каких-либо целей путем программирования. Это не так. Мне важно знать, зачем я пишу код на работе, кому это надо и кому и как от этого станет лучше.
              • 0
                И все же кодить просто чтобы кодить — плохой мотиватор. Даже если пишется своя супер-пупер библиотечка, то только для того, чтобы потом её дать другим посмотреть. И если все вокруг скажут "угу, очередной велосипед" и пойдут заниматься своими делами — то с вероятностью близкой к 1 этот проект будет убран в дальний ящик. Другое дело, если люди скажут "уау, давно такую хотел", начнуть лайкать репост в гитхабе, форкать, присылать реквесты… Тут уже программист окрылятся, он утраивает усилия по поддержанию этой библиотечки, и пони с радугой во все поля...

                Если у общества нет цветовой дифференциации штанов, то у него нет цели. Любая программа пишется с целью хотя бы получить одобрение от общества. Писать просто для себя реально можно только на этапе обучения. И то даже там этот фактор тоже может ускорить это самое обучение в разы, если "смотри, я написал прогу, которая подсчитывает символы в файле" тебе говорят "ух ты!!! Давай еще!".
        • 0
          Не результат не важен, нет.
          Одно дело знать, что блок, который ты разрабатываешь — часть фичи XYZ, которая позволит пользователю делать вот это и вот это. Это — результат, это — здорово.
          Другое дело — маркетинговая муть, которая инженеру не нужна.
      • +2
        Не совсем так. Программистам нравится проверять какие-то свои идеи, пробовать новые технологии или решать задачу самым оптимальным способом. Писать очередной стопятнадцатый по счету обработчик формы никому не интересно.
      • 0
        Позвольте не согласиться.
        Точнее так — программистам безусловно нравится программировать, иначе мы не кодим больше, но результат — одна из причин почему мы кодим. Ведь так приятно, когда 1/2/5/100500 человек получают какую-то автоматизацию/упрощение/улучшение своей работы. Разве нет?
        • +1
          Результат необязательно связан с непосредственным, прямым улучшением работы пользователей.
          Допустим, вы «пилите» внутренние блоки, черные ящики, которые только косвенно влияют на работу пользователей. И даже не всегда можно подсчитать что-то типа «стало загружаться на 1.53% быстрее». Но результат-то все равно есть — внутренний результат.
  • –2
    Из всей статьи уловил только один более-менее объективный совет — чаще менять участок работ. Всё остальное — какая-то пустая болтовня в духе «чтобы было весело надо веселиться».

    Да и совет по поводу частой смены участка работ мне не нравится. Т.е. я даже верю, что это привносит определенную свежую струю, но это неминуемо должно означать, что спецов в этой конторе нет, только универсалы.
    • +3
      По моему очень ценное замечание о том, чем плохо использовать на работе закрытые технологие специфичные для конторы.
  • +3
    Вот, что забавно. Когда читаешь подобные статьи, они по большей части ориентированы на один определенный тип программистких контор — универсалов. Т.е. таких контор, которые работают с, условно, сотней клиентов, и каждому клиенту делают какой-то «проект». У одного это может быть информационная система для складского учета, у другого — подсчет какой-то статистики, у третьего — электронный документооборот и т.д. Отсюда и советы о смене участка работ или новых технологиях.
    Мне, например, доводится работать в фирме, которая… как бы сформулировать… монопродуктная фирма. Т.е. у нас есть определенный программный пакет, который поставляется разным клиентам. Под каждого другими отделами производится настройка, написание специфичного кода. Моя же команда работает над ядром системы, которое работает с БД, интерпретирует скриптовый язык, отрабатывает логику прорисовки экрана на клиентской стороне и т.п. Набор используемых технологий тоже ограничен. Ты не можешь использовать какой-то хитрый «модный» язык просто потому что это а)не нужно — нет применения б)некому, кроме тебя будет это поддерживать, когда завтра ты пойдешь в отпуск позагорать. Ты не можешь использовать какие-то другие технологии в области работы с БД, потому что там все единообразно — нечего менять. Нечего менять в протоколах связи и т.п. В итоге каждый день ты занимаешься примерно одним и тем же — процентов на 50 поддержка, процентов на 50 — новое, но в рамках той же парадигмы.
    Думаю, таких фирм-не«универсалов» полно, и там такие советы не работают.
    • 0
      Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода. А насчёт «хитрых» технологий — каждая технологиях хороша в том или ином месте, нужно убедить других участников команды в том, что с данной технологией эффективность т увлечённость команды в программном продукте возрастёт. На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям б) интерес к работе. А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.
      • 0
        Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода

        А мою работу тогда кто будет делать? В обеих командах — комплект. Каждый чем-то своим занять, «въезд» в специализацию не за день и не за месяц проходит. У всех в команде примерно год уходил на вход в область — слишком много нюансов.

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

        Если возрастет. Но это десктопное/системное программирование, там не покатит, например, сменить язык. Другие библиотеки? Да, регулярно находим что-то новое, но 80% остается того же.

        На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям

        Не всегда возможно — нет требований по продукту (не считая перемещения на новые платформы — веб, но этим занимаются другие люди).

        А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.

        В каком смысле «собраниями»? Привлечение нескольких — да, ливерсификация — так и делаем — на время болезни или отпуска один или двое могут подменить, но не больше — своей работы навалом, да и все же специализация у каждого своя.
        Вот и получается в итоге, что команда — хорошая, продукт хороший, технологиии нравятся, но однообразно и как специалист застаиваешься.
    • 0
      Я автоматикой занимаюсь. И таки получается, что мы (и большинство коллег) — такие универсалы. Сегодня я запускаю говнокачку (да, их тоже иногда надо автоматизировать), завтра — пищевое производство, у меня там техпроцесс (вот чёрт, я ж рабочие башмаки после вчерашней говнокачки не помыл), послезавтра у меня небольшая электростанция, параллельно с этим — система управления освещением и вентиляцией на другом заводике
      • 0
        Ага. А представьте, что вы каждый день занимаетесь автоматизацией хлебозаводов. С небольшими вариациями. Годами подряд. Каждому надо что-то чуть свое, пожтому без работы вы не сидите, о нет. Но тем не менее, почти одно и то же.
        • 0
          Занимался автоматизацией газотурбинных электростанций и газоперекачек несколько лет. Коллеги (к настоящему моменту) уже больше 10 лет этим занимаются. Нет двух одинаковых объектов и двух одинаковых косяков. А наладка и командировки — это всегда праздник разнообразия :)

          Есть люди, которым каждые 2-3 года надо менять направление деятельности, чтоб скука не заела. Но это перебор. А скука и выгорание случаются у всех.
          • 0
            Это не совсем то. Я о тех, кто работает с сердцевиной системы, тех, для кого нет объектов. Тех, кто делает кубики, из которых потом складываются структуры «объектов». Между ними и объектами те самые implementation engineer'ы — вот у них и вправду может быть «нет двух одинаковых объектов».
            А то, что все косяки разные — очень тонко подмечено ;)
            • 0
              тогда «хлебозавод» — это недостаточно высокий уровень абстракции. Даже если речь не о автоматике, а о процессе и технологах.
              Нет двух одинаковых объектов.
              Я, собственно, и есть implementation engineer в вашей терминологии (хотя, на мой взгляд, более уместно application engineer). Так я и кубики свои делаю, которые из проекта в проект кочуют. Когда с доработками, когда без.
              Вот кто полностью абстрагирован от объектов — это разработчики железа: сименс, шнайдер и иже с ними.

              PS А вы с какой стороны к «хлебозаводу» относитесь?
              • 0
                Да это просто абстрактный пример, не очень удачный, чтобы описать мою личную усталость от рутины. Вот представьте, что я разработчик ПО для контроллеров Siemens, например. Или интерпретатора какого-нибудь языка для opc, который универсален и на всех объектах будет одинаков. Или DCOM сервера для того же OPC. И реальных объектов в жизни не видел. Все — черные ящики, вход-выход, функция. К тому же, если захочется когда-нибудь сменить род деятельности, то, что я в течение 10 лет разрабатывал такие внутренние черные ящики, не так красочно смотрится в резюме. Да, есть опыт работы с языком, и все. Основные фреймворки — и те внутренние, закрытые.
                • 0
                  Да это просто абстрактный пример, не очень удачный, чтобы описать мою личную усталость от рутины.

                  И правда, не очень удачный.
                  Вот представьте, что я разработчик ПО для контроллеров Siemens, например.

                  И реальных объектов в жизни не видел.

                  Попытался представить. Не смог. Или под ПО имелось в виду их firmware?
                  Дело в том, что я таки разрабатываю под сименс. Естественно, прикладные задачи. Я плохо представляю себе, как делать прикладную задачу, имея представление об объекте на уровне «чёрного ящика».
                  Основные фреймворки — и те внутренние, закрытые.

                  Последние N лет я пишу на IEC_61131-3 и немного на си. Что такое фреймворк?
                  • 0
                    Или под ПО имелось в виду их firmware?

                    Например.

                    Дело в том, что я таки разрабатываю под сименс. Естественно, прикладные задачи. Я плохо представляю себе, как делать прикладную задачу, имея представление об объекте на уровне «чёрного ящика».

                    Прикладные — разумеется.

                    Последние N лет я пишу на IEC_61131-3 и немного на си. Что такое фреймворк?

                    Пусть будет не фреймворк, просто ряд специализированных библиотек.

                    Ну вот, теперь вы хотите поменять род деятельности, и ваше знание подобных узких стандартов оказывается ненужным. Благо, хоть Си — универсальный, а не какой-то свой, внутренний язык (а у нас в нашем продукте есть и свои внутренние языки).
                    • +1
                      Ну вот, теперь вы хотите поменять род деятельности, и ваше знание подобных узких стандартов оказывается ненужным.

                      Во-1, это не единственное, что мне необходимо по работе.
                      Во-2, и это более общий момент: желание поменять род деятельности приводит к тому, что многое из накопленного опыта оказывается ненужным, и многого не хватает. И неважно, в данном случае — узкий стандарт или широкий.
                      • 0
                        1) мы не вас обсуждаем лично, а условный пример
                        2) это смотря, насколько сильно род деятельности меняется. Если был программист, а становишься полотером — то да, многое из накопленного становится ненужным. Если переходишь из одной софт компании в другую — совсем другое дело. И здесь действительно проблема, если весь твой опыт — очень узкий, пусть и солидный. Потому что при условном соревновании с другими, даже более молодыми, важнее практическое знание общеупотребимых технологий и библиотек, а не узкоспециализированных, неизвестных за рамками предыдущей фирмы. В итоге два условных человека, начавшие карьеру рядом, окажутся в совершенно разных ситуациях — один, будучи «в тренде», легко попадет в десяток компаний и (как указывалось в статье, которую я и критиковал) сможет менять род деятельности. Другой, имея тот же опыт в годах, будет в худшей ситуации, потому что его опыт — узкоспециализированный. И да, мы можем сто раз обсуждать то, что второму «никто не мешает самостоятельно учить блаблабла», но это означает лишь одно — первый будет делать это по роду деятельности, а второй — дополнительно, в свободное время. В итоге чисто в часах жизни второй теряет, а по уходу из этой фирмы (где он пишет условный firmware) этот опыт, касающийся чисто внутренних продуктов, становится ненужным.

                        Но это все — стороннее. Изначально разговор шел о мотивации и монопродукте, здесь мы ушли в сторону.
                        • 0
                          один, будучи «в тренде», легко попадет в десяток компаний и (как указывалось в статье, которую я и критиковал) сможет менять род деятельности.

                          Неверно. Другой род деятельности — другой опыт нужен. Я уже писал об этом, мало одного владения инструментом (скажем, тем же С++). Надо ещё предметную область понимать. Это тоже очень ограничивает лёгкость смены рода деятельности.
                          А если ты продолжаешь делать на 90% то же самое — то что ты, вообще, поменял?
                          • 0
                            Неверно. Другой род деятельности — другой опыт нужен

                            Отнюдь. Вы не поняли мысли — ввод в новую область, разумеется, потребуется. Но технологии будут примерно те же. И это «примерно» позволяет легче сменить род деятельности, нежели при программировании того же firmware на внутренних средствах в течение ряда лет.

                            Я уже писал об этом, мало одного владения инструментом (скажем, тем же С++).

                            Одних плюсов мало, как инструмента. Как знание С или firmware средств разработки поможет, например, на собеседовании, где потребуется зная какие-нибудь стандартные библиотеки типа libevents или boost'а написать за час-два простой веб-сервер? Занимаясь firmware на внутренних инструментах ты только с ними и остаешься. Даже аппаратную платформу сменить непросто. Рынок труда для «универсальных» технологий намного шире — это основная мысль, которую я пытаюсь донести.

                            А если ты продолжаешь делать на 90% то же самое — то что ты, вообще, поменял?

                            Если ты писал прикладное ПО и продолжаешь писать прикладное, но совсем в иной области — это не «на 90% то же самое». Что меняется? Да хотя бы команда, структура ПО может быть совсем иной. Может быть и пакет технологий другим. Но одно дело, когда из списка требований ты знаешь 1-2 элемента, и другое дело — когда 8 из 10.
                            Например, ты разрабатываешь информационную систему на том же С++, с использованием ряда стандартных библиотек, работая с базой данных Oracle. Относительно легко можно заняться разработкой других ИФС с другой топологией или совсем иных прикладных програм, используя тот же С++, но в связке с MSSQL (условной). И таких «иных, но похожих по средствам» проектов (вакансий) — море. Сравним это теперь с человеком, который 10 лет разрабатывает что-то на встроенном языке какой-то нестандартной системы. Даже для перехода к другой нестандартной системе-аналогу придется заново изучать все. Именно это я критикую в статье — есть фирмы/сферы-универсалы, где сменить место работы/проект можно легко. А есть фирмы с монопродуктами, где ты не переключишься, если тебе надоела рутина. Куда переключится разработчик того же firmware, если у компании нет новых альтернативных продуктов на данный момент? Никуда.
  • 0
    А почему клавиатурой полноценной не пользуетесь? Производительность ведь снижется?
  • 0
    Кстати, а почему две картинки из оригинального поста не попали в перевод?
  • 0
    А что если с коллегами написать свой какой-то проект, в течении довольно долгого времени?
    • 0
      В рабочее время? Кто за это будет платить?
      • 0
        После работы или немного перед работой, в выходные или чуть во время работы, вместо кофе.
        Или обсуждать хотя во время перерыва на работе свои проект.
        • +1
          В статье речь о том, что бизнесу делать для того, чтобы сотрудникам не приходилось вытворять такие трюки.
          Ибо в конце концов это ведёт к смене работы.
          • 0
            Необязательно. Может к смене работы на бизнес.
  • 0
    Это проблема встречается не только в разработке ПО или технической сфере: она характерна для любой офисной работы. Каждый день вы находитесь в одном и том же помещении, с теми же людьми, выполняя те же рабочие обязанности, и все это — в обстановке, которая почти не меняется…

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

    Когда рабочее место в порядке вещей (а не в исключительных случаях) состоит из 2 кабельных барабанов, из коих большой — стол, а маленький — стул, сверху режут болгаркой, а сбоку — сварка, кондиционера в помещении нет (а иногда — и помещения, как такового). Иногда изо рта идёт пар, руки примерзают к мышке, а ноги — к бетонному полу. Иногда удобства представляют собой туалет типа «сортир» при температуре -49 за бортом… Короче, я не могу пожаловаться на однообразие условий, хоть и больше 10 лет занимаюсь одним и тем же :)
    Немного хаоса — последний ингредиент в нашем рецепте против скуки. И как и любой другой рецепт, его можно совершенствовать бесконечно.

    Хаос можно совершенствовать бесконечно, это точно :)
  • +1
    Лично за собой замечал (ибо регулярный тайм-менеджмент) следующие временные показатели.
    При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
    Сравнивал временные затраты по задачам аналогичной сложности.

    Соответственно, не стоит думать, что отсутствие интереса не несет прямой финансовый ущерб — ущерб самый что ни на есть прямой, даже не косвенный. И любой нормальный разработчик будет это нивелировать либо за счет личного времени, либо за счет клиента, повышая временные оценки задач.

    И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
    • +1
      И если руководство считает, что разработчик должен «делать то, что нужно», а отсутствие интереса — это «личные проблемы», то это просто неадекватный менеджмент, со всеми вытекающими. Самомотивация для достижения нужного уровня концентрации также отнимает время, и от этого никуда не деться.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка