Случалось ли 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, международной системой для приема электронных платежей. Если вам нужно организовать прием платежей на сайте, смело обращайтесь. Также подписывайтесь на наш корпоративный блог, впереди еще много интересных постов.
Комментарии (42)
Scf
08.12.2015 14:59+7Я бы сказал, что прежде всего работу скучной делает отсутствие цели. Когда по полгода толчешь в ступе одну и ту же воду без видимого результата.
Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.
Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.poxu
08.12.2015 15:11+3Я тут согласен скорее с автором статьи, чем с вами. Программисты занимаются программированием, потому что им нравится программировать, а не потому, что они хотят достигать каких-то навязанных сверху целей. Важен сам процесс, результат особого значения не имеет. Если результат сильно интересует программиста, то он скорее всего не на своём месте.
Scf
08.12.2015 16:18+13Программисты, программирующие ради программирования, — это скорее новички/середнячки. Сеньоры программируют с какой-то целью, технической или бизнес. Обязанность менеджмента — совмещать эту цель с реальными потребностями организации.
poxu
08.12.2015 16:47-3Бизнес ставит сеньорам цели, это да. Но если у человека приоритет достичь этой цели, а не попрограммировать — ему дорога в менеджмент какой-нить. Технические цели — да, но это из разряда интереса к програмиированию.
dyadyaSerezha
09.12.2015 13:35-2Сеньоры программируют с целью получить бабки. А уже как достигается эта цель, с помощью каких меньших и промежуточных целей — дело десятое. ;)
Добавлю, что все советы из статьи хороши для маленьких фирм — большие бюрократические конторы очень сильно плесневеют и костенеют с бизнесе, там ничего просто так не заменишь, не используешь, не посоветуешь.VolCh
09.12.2015 15:09За всех сеньоров не говорите. Как минимум, для некоторых бабки не цель, а средство. Не платили бы бабок, достаточных для комфортной жизни, всё равно бы программировали, пускай и в меньшем объёме, зарабатывая на комфортную жизнь работой продавца или, прости господи, проджект-менеджера :)
dendron
08.12.2015 19:13Не хотел бы я работать вместе с такими программистами, которым не важен результат, бррр… Это не программисты, а погромисты какие-то.
poxu
08.12.2015 19:39А вы кто по профессии?
Aiditz
08.12.2015 23:42+7Как программист, поддерживаю Scf и dendron. Не вижу смысла программировать ради программирования. Мне не приносит удовольствия писать код, который непонятно кому и зачем нужен. Программирование по своей сути — инструмент для достижения некоторых целей. А иначе это все равно что забивать гвозди потому что нравится дырявить доски, а не чтобы построить дом.
poxu
09.12.2015 00:12+6Аналогия с гвоздями не вполне точна, так как у программиста гораздо больше простора для роста, чем у забивателя гвоздей, но всё равно хороша.
Подумайте о вопросе вот с такой стороны. Человек, который забивает гвозди потому, что ему нравится дырявить доски будет забивать гвозди в любой ситуации, даже если эти гвозди через дорогу вытаскивают и сдают на металлолом. Он будет делать это с наслаждением и будет получать за это достойную зарплату. Ему не грозит профессиональное выгорание на почве бессмысленности деятельности, он постоянно растёт профессионально, потому что думает только о том, как это клёво — забивать гвозди. Он даже может начать интересоваться зачем и кому забитые гвозди нужны — это позволит ему забивать гвозди таким способом, что за то же самое количество гвоздей он получит вдвое больше денег. Но это всё так — приятное дополнение к волшебному процессу забивания гвоздей, не более.
Кстати, очень интересно, если вас действительно волнует кому и для чего код нужен, почему вы не занимаетесь менеджментом — там возможности работы с этими элементами процесса куда шире.
ya-est
09.12.2015 02:09Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»? Я сомневаюсь, что они используют какие-нибудь «хипстерские» noSQL решения ради того, чтобы развиваться. Я думаю, что решения должны приниматься с учётом цели конечного продукта. Не все программируют формочки для веб-сайтов.
MacIn
09.12.2015 03:13Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»?
Кстати, в догонку к комментарию ниже — действительно, в таких сферах много времени уходит на специализацию, да и роста там не так много. И через 2 года менять место работы не получится. Советы статьи далеко не везде применимы.
poxu
09.12.2015 10:32+1Ну использовать хипстерские решения это только один вариант роста. Другой вариант это учиться писать программы с использованием ограниченного инструментария. Тоже неплохо.
Про мед учреждения не знаю, а про военных могу сказать. Тем, кто там работает, программирование глубоко до фени — это неприятный, но необходимый элемент, например, запуска спутника. Спутник сделать и запустить им интересно, а код писать — ну что ж, не такое ещё делали. Это, правда, что касается именно спутников, с разработкой какого-нибудь прикладного ПО для военки я не знаком.
Aiditz
09.12.2015 04:29Вы как раз описали заинтересованного магией новичка, который вырос и стал использовать программирование как инструмент. Да, я точно так же пришел в программирование, но нельзя же десять лет забивать гвозди бесцельно.
Ответ на второй вопрос — когда я пишу собственный проект, я занимаюсь вообще всем, включая администрирование, дизайн, рекламу и работу с пользователями. Возможностей завались :) Но это все на уровне хобби.poxu
09.12.2015 10:36То есть вы самореализуетесь в своём хобби? Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?
vvzvlad
09.12.2015 21:59+1Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?
Да. Но есть вероятность, что любимое дело перестанет быть таким любимым
Aiditz
11.12.2015 07:57Спасибо, но на работе я занимаюсь любым делом сколько душе угодно часов :)
poxu
11.12.2015 10:47Так выходит ваше любимое занятие всё-таки программировать? В ваши непосредственные обязанности ведь не входит администрирование, дизайн, реклама и работа с пользователями?
Aiditz
11.12.2015 20:00Программирую я достаточно хорошо, чтобы продавать это умение за деньги. Остальным я занимаюсь в своих проектах, и нельзя сказать, что это не является моей обязанностью (если я не нахожу другого человека для выполнения их). Но я уже потерял нить, к чему вы клоните :)
poxu
11.12.2015 22:31Ну вы сказали, что на работе занимаетесь любимым делом сколько душе угодно часов. Так как вы программист, то это любимое дело очевидно — программировать. Что в общем подтверждает мой тезис — программисты больше всего любят программировать, а после этого уже все остальное.
Aiditz
11.12.2015 22:40Никто не спорил, что программисты любят программировать :) Сомнение вызвало ваше заявление, что программистам не важно достижение каких-либо целей путем программирования. Это не так. Мне важно знать, зачем я пишу код на работе, кому это надо и кому и как от этого станет лучше.
MacIn
09.12.2015 01:43Не результат не важен, нет.
Одно дело знать, что блок, который ты разрабатываешь — часть фичи XYZ, которая позволит пользователю делать вот это и вот это. Это — результат, это — здорово.
Другое дело — маркетинговая муть, которая инженеру не нужна.
CrashLogger
08.12.2015 21:08+2Не совсем так. Программистам нравится проверять какие-то свои идеи, пробовать новые технологии или решать задачу самым оптимальным способом. Писать очередной стопятнадцатый по счету обработчик формы никому не интересно.
Godless
10.12.2015 09:54Позвольте не согласиться.
Точнее так — программистам безусловно нравится программировать, иначе мы не кодим больше, но результат — одна из причин почему мы кодим. Ведь так приятно, когда 1/2/5/100500 человек получают какую-то автоматизацию/упрощение/улучшение своей работы. Разве нет?MacIn
10.12.2015 17:40+1Результат необязательно связан с непосредственным, прямым улучшением работы пользователей.
Допустим, вы «пилите» внутренние блоки, черные ящики, которые только косвенно влияют на работу пользователей. И даже не всегда можно подсчитать что-то типа «стало загружаться на 1.53% быстрее». Но результат-то все равно есть — внутренний результат.
ivanych
09.12.2015 00:13-2Из всей статьи уловил только один более-менее объективный совет — чаще менять участок работ. Всё остальное — какая-то пустая болтовня в духе «чтобы было весело надо веселиться».
Да и совет по поводу частой смены участка работ мне не нравится. Т.е. я даже верю, что это привносит определенную свежую струю, но это неминуемо должно означать, что спецов в этой конторе нет, только универсалы.poxu
09.12.2015 00:36+3По моему очень ценное замечание о том, чем плохо использовать на работе закрытые технологие специфичные для конторы.
MacIn
09.12.2015 01:52+3Вот, что забавно. Когда читаешь подобные статьи, они по большей части ориентированы на один определенный тип программистких контор — универсалов. Т.е. таких контор, которые работают с, условно, сотней клиентов, и каждому клиенту делают какой-то «проект». У одного это может быть информационная система для складского учета, у другого — подсчет какой-то статистики, у третьего — электронный документооборот и т.д. Отсюда и советы о смене участка работ или новых технологиях.
Мне, например, доводится работать в фирме, которая… как бы сформулировать… монопродуктная фирма. Т.е. у нас есть определенный программный пакет, который поставляется разным клиентам. Под каждого другими отделами производится настройка, написание специфичного кода. Моя же команда работает над ядром системы, которое работает с БД, интерпретирует скриптовый язык, отрабатывает логику прорисовки экрана на клиентской стороне и т.п. Набор используемых технологий тоже ограничен. Ты не можешь использовать какой-то хитрый «модный» язык просто потому что это а)не нужно — нет применения б)некому, кроме тебя будет это поддерживать, когда завтра ты пойдешь в отпуск позагорать. Ты не можешь использовать какие-то другие технологии в области работы с БД, потому что там все единообразно — нечего менять. Нечего менять в протоколах связи и т.п. В итоге каждый день ты занимаешься примерно одним и тем же — процентов на 50 поддержка, процентов на 50 — новое, но в рамках той же парадигмы.
Думаю, таких фирм-не«универсалов» полно, и там такие советы не работают.ya-est
09.12.2015 02:19Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода. А насчёт «хитрых» технологий — каждая технологиях хороша в том или ином месте, нужно убедить других участников команды в том, что с данной технологией эффективность т увлечённость команды в программном продукте возрастёт. На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям б) интерес к работе. А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.
MacIn
09.12.2015 03:33Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода
А мою работу тогда кто будет делать? В обеих командах — комплект. Каждый чем-то своим занять, «въезд» в специализацию не за день и не за месяц проходит. У всех в команде примерно год уходил на вход в область — слишком много нюансов.
каждая технологиях хороша в том или ином месте, нужно убедить других участников команды в том, что с данной технологией эффективность т увлечённость команды в программном продукте возрастёт
Если возрастет. Но это десктопное/системное программирование, там не покатит, например, сменить язык. Другие библиотеки? Да, регулярно находим что-то новое, но 80% остается того же.
На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям
Не всегда возможно — нет требований по продукту (не считая перемещения на новые платформы — веб, но этим занимаются другие люди).
А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.
В каком смысле «собраниями»? Привлечение нескольких — да, ливерсификация — так и делаем — на время болезни или отпуска один или двое могут подменить, но не больше — своей работы навалом, да и все же специализация у каждого своя.
Вот и получается в итоге, что команда — хорошая, продукт хороший, технологиии нравятся, но однообразно и как специалист застаиваешься.
Muzzy0
17.12.2015 23:30Я автоматикой занимаюсь. И таки получается, что мы (и большинство коллег) — такие универсалы. Сегодня я запускаю говнокачку (да, их тоже иногда надо автоматизировать), завтра — пищевое производство, у меня там техпроцесс (вот чёрт, я ж рабочие башмаки после вчерашней говнокачки не помыл), послезавтра у меня небольшая электростанция, параллельно с этим — система управления освещением и вентиляцией на другом заводике
BalinTomsk
09.12.2015 21:52А почему клавиатурой полноценной не пользуетесь? Производительность ведь снижется?
dmrt
12.12.2015 02:09А что если с коллегами написать свой какой-то проект, в течении довольно долгого времени?
Muzzy0
17.12.2015 23:25Это проблема встречается не только в разработке ПО или технической сфере: она характерна для любой офисной работы. Каждый день вы находитесь в одном и том же помещении, с теми же людьми, выполняя те же рабочие обязанности, и все это — в обстановке, которая почти не меняется…
Попробуйте железо программировать. В смысле, автоматику. Накатаетесь по объектам столько, что рабочий день в офисе будет восприниматься, как выходной.
люди все равно начинают принимать все хорошее как должное и раздражаться из-за того, что им не нравится.
Когда рабочее место в порядке вещей (а не в исключительных случаях) состоит из 2 кабельных барабанов, из коих большой — стол, а маленький — стул, сверху режут болгаркой, а сбоку — сварка, кондиционера в помещении нет (а иногда — и помещения, как такового). Иногда изо рта идёт пар, руки примерзают к мышке, а ноги — к бетонному полу. Иногда удобства представляют собой туалет типа «сортир» при температуре -49 за бортом… Короче, я не могу пожаловаться на однообразие условий, хоть и больше 10 лет занимаюсь одним и тем же :)
Немного хаоса — последний ингредиент в нашем рецепте против скуки. И как и любой другой рецепт, его можно совершенствовать бесконечно.
Хаос можно совершенствовать бесконечно, это точно :)
Scf
Как вы оцениваете затраты на всё вышеперечисленное, в % от общих затрат на разработку?
cigulev
Точную оценку дать затруднительно. Я думаю, если использовать большинство советов из данной статьи, то это должна быть уже состоявшаяся компания со свободными ресурсами и достаточным количеством энтузиастов, которым нравится развиваться, как директору компании Enki, деятельность, которой описана в статье. Также безусловно во всем нужен баланс, важно не переборщить и выслушать мнение каждого, кому-то может нравиться развиваться в узком направлении и каждый день делать то, что уже хорошо получается.