Comments 56
Как вы оцениваете затраты на всё вышеперечисленное, в % от общих затрат на разработку?
Точную оценку дать затруднительно. Я думаю, если использовать большинство советов из данной статьи, то это должна быть уже состоявшаяся компания со свободными ресурсами и достаточным количеством энтузиастов, которым нравится развиваться, как директору компании Enki, деятельность, которой описана в статье. Также безусловно во всем нужен баланс, важно не переборщить и выслушать мнение каждого, кому-то может нравиться развиваться в узком направлении и каждый день делать то, что уже хорошо получается.
Я бы сказал, что прежде всего работу скучной делает отсутствие цели. Когда по полгода толчешь в ступе одну и ту же воду без видимого результата.
Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.
Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.
Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.
Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.
Я тут согласен скорее с автором статьи, чем с вами. Программисты занимаются программированием, потому что им нравится программировать, а не потому, что они хотят достигать каких-то навязанных сверху целей. Важен сам процесс, результат особого значения не имеет. Если результат сильно интересует программиста, то он скорее всего не на своём месте.
Программисты, программирующие ради программирования, — это скорее новички/середнячки. Сеньоры программируют с какой-то целью, технической или бизнес. Обязанность менеджмента — совмещать эту цель с реальными потребностями организации.
Бизнес ставит сеньорам цели, это да. Но если у человека приоритет достичь этой цели, а не попрограммировать — ему дорога в менеджмент какой-нить. Технические цели — да, но это из разряда интереса к програмиированию.
Сеньоры программируют с целью получить бабки. А уже как достигается эта цель, с помощью каких меньших и промежуточных целей — дело десятое. ;)
Добавлю, что все советы из статьи хороши для маленьких фирм — большие бюрократические конторы очень сильно плесневеют и костенеют с бизнесе, там ничего просто так не заменишь, не используешь, не посоветуешь.
Добавлю, что все советы из статьи хороши для маленьких фирм — большие бюрократические конторы очень сильно плесневеют и костенеют с бизнесе, там ничего просто так не заменишь, не используешь, не посоветуешь.
Что в вашем понимании есть «техническая цель»?
Не хотел бы я работать вместе с такими программистами, которым не важен результат, бррр… Это не программисты, а погромисты какие-то.
А вы кто по профессии?
Как программист, поддерживаю Scf и dendron. Не вижу смысла программировать ради программирования. Мне не приносит удовольствия писать код, который непонятно кому и зачем нужен. Программирование по своей сути — инструмент для достижения некоторых целей. А иначе это все равно что забивать гвозди потому что нравится дырявить доски, а не чтобы построить дом.
Аналогия с гвоздями не вполне точна, так как у программиста гораздо больше простора для роста, чем у забивателя гвоздей, но всё равно хороша.
Подумайте о вопросе вот с такой стороны. Человек, который забивает гвозди потому, что ему нравится дырявить доски будет забивать гвозди в любой ситуации, даже если эти гвозди через дорогу вытаскивают и сдают на металлолом. Он будет делать это с наслаждением и будет получать за это достойную зарплату. Ему не грозит профессиональное выгорание на почве бессмысленности деятельности, он постоянно растёт профессионально, потому что думает только о том, как это клёво — забивать гвозди. Он даже может начать интересоваться зачем и кому забитые гвозди нужны — это позволит ему забивать гвозди таким способом, что за то же самое количество гвоздей он получит вдвое больше денег. Но это всё так — приятное дополнение к волшебному процессу забивания гвоздей, не более.
Кстати, очень интересно, если вас действительно волнует кому и для чего код нужен, почему вы не занимаетесь менеджментом — там возможности работы с этими элементами процесса куда шире.
Подумайте о вопросе вот с такой стороны. Человек, который забивает гвозди потому, что ему нравится дырявить доски будет забивать гвозди в любой ситуации, даже если эти гвозди через дорогу вытаскивают и сдают на металлолом. Он будет делать это с наслаждением и будет получать за это достойную зарплату. Ему не грозит профессиональное выгорание на почве бессмысленности деятельности, он постоянно растёт профессионально, потому что думает только о том, как это клёво — забивать гвозди. Он даже может начать интересоваться зачем и кому забитые гвозди нужны — это позволит ему забивать гвозди таким способом, что за то же самое количество гвоздей он получит вдвое больше денег. Но это всё так — приятное дополнение к волшебному процессу забивания гвоздей, не более.
Кстати, очень интересно, если вас действительно волнует кому и для чего код нужен, почему вы не занимаетесь менеджментом — там возможности работы с этими элементами процесса куда шире.
Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»? Я сомневаюсь, что они используют какие-нибудь «хипстерские» noSQL решения ради того, чтобы развиваться. Я думаю, что решения должны приниматься с учётом цели конечного продукта. Не все программируют формочки для веб-сайтов.
Интересно, а разработчики систем для мед учреждений / военного ПО тоже программируют для «роста»?
Кстати, в догонку к комментарию ниже — действительно, в таких сферах много времени уходит на специализацию, да и роста там не так много. И через 2 года менять место работы не получится. Советы статьи далеко не везде применимы.
Ну использовать хипстерские решения это только один вариант роста. Другой вариант это учиться писать программы с использованием ограниченного инструментария. Тоже неплохо.
Про мед учреждения не знаю, а про военных могу сказать. Тем, кто там работает, программирование глубоко до фени — это неприятный, но необходимый элемент, например, запуска спутника. Спутник сделать и запустить им интересно, а код писать — ну что ж, не такое ещё делали. Это, правда, что касается именно спутников, с разработкой какого-нибудь прикладного ПО для военки я не знаком.
Про мед учреждения не знаю, а про военных могу сказать. Тем, кто там работает, программирование глубоко до фени — это неприятный, но необходимый элемент, например, запуска спутника. Спутник сделать и запустить им интересно, а код писать — ну что ж, не такое ещё делали. Это, правда, что касается именно спутников, с разработкой какого-нибудь прикладного ПО для военки я не знаком.
Вы как раз описали заинтересованного магией новичка, который вырос и стал использовать программирование как инструмент. Да, я точно так же пришел в программирование, но нельзя же десять лет забивать гвозди бесцельно.
Ответ на второй вопрос — когда я пишу собственный проект, я занимаюсь вообще всем, включая администрирование, дизайн, рекламу и работу с пользователями. Возможностей завались :) Но это все на уровне хобби.
Ответ на второй вопрос — когда я пишу собственный проект, я занимаюсь вообще всем, включая администрирование, дизайн, рекламу и работу с пользователями. Возможностей завались :) Но это все на уровне хобби.
То есть вы самореализуетесь в своём хобби? Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?
Может найти работу, которая позволит заниматься любимым делом по 8 часов в день?
Да. Но есть вероятность, что любимое дело перестанет быть таким любимым
Спасибо, но на работе я занимаюсь любым делом сколько душе угодно часов :)
Так выходит ваше любимое занятие всё-таки программировать? В ваши непосредственные обязанности ведь не входит администрирование, дизайн, реклама и работа с пользователями?
Программирую я достаточно хорошо, чтобы продавать это умение за деньги. Остальным я занимаюсь в своих проектах, и нельзя сказать, что это не является моей обязанностью (если я не нахожу другого человека для выполнения их). Но я уже потерял нить, к чему вы клоните :)
И все же кодить просто чтобы кодить — плохой мотиватор. Даже если пишется своя супер-пупер библиотечка, то только для того, чтобы потом её дать другим посмотреть. И если все вокруг скажут "угу, очередной велосипед" и пойдут заниматься своими делами — то с вероятностью близкой к 1 этот проект будет убран в дальний ящик. Другое дело, если люди скажут "уау, давно такую хотел", начнуть лайкать репост в гитхабе, форкать, присылать реквесты… Тут уже программист окрылятся, он утраивает усилия по поддержанию этой библиотечки, и пони с радугой во все поля...
Если у общества нет цветовой дифференциации штанов, то у него нет цели. Любая программа пишется с целью хотя бы получить одобрение от общества. Писать просто для себя реально можно только на этапе обучения. И то даже там этот фактор тоже может ускорить это самое обучение в разы, если "смотри, я написал прогу, которая подсчитывает символы в файле" тебе говорят "ух ты!!! Давай еще!".
Если у общества нет цветовой дифференциации штанов, то у него нет цели. Любая программа пишется с целью хотя бы получить одобрение от общества. Писать просто для себя реально можно только на этапе обучения. И то даже там этот фактор тоже может ускорить это самое обучение в разы, если "смотри, я написал прогу, которая подсчитывает символы в файле" тебе говорят "ух ты!!! Давай еще!".
Не результат не важен, нет.
Одно дело знать, что блок, который ты разрабатываешь — часть фичи XYZ, которая позволит пользователю делать вот это и вот это. Это — результат, это — здорово.
Другое дело — маркетинговая муть, которая инженеру не нужна.
Одно дело знать, что блок, который ты разрабатываешь — часть фичи XYZ, которая позволит пользователю делать вот это и вот это. Это — результат, это — здорово.
Другое дело — маркетинговая муть, которая инженеру не нужна.
Не совсем так. Программистам нравится проверять какие-то свои идеи, пробовать новые технологии или решать задачу самым оптимальным способом. Писать очередной стопятнадцатый по счету обработчик формы никому не интересно.
Позвольте не согласиться.
Точнее так — программистам безусловно нравится программировать, иначе мы не кодим больше, но результат — одна из причин почему мы кодим. Ведь так приятно, когда 1/2/5/100500 человек получают какую-то автоматизацию/упрощение/улучшение своей работы. Разве нет?
Точнее так — программистам безусловно нравится программировать, иначе мы не кодим больше, но результат — одна из причин почему мы кодим. Ведь так приятно, когда 1/2/5/100500 человек получают какую-то автоматизацию/упрощение/улучшение своей работы. Разве нет?
Результат необязательно связан с непосредственным, прямым улучшением работы пользователей.
Допустим, вы «пилите» внутренние блоки, черные ящики, которые только косвенно влияют на работу пользователей. И даже не всегда можно подсчитать что-то типа «стало загружаться на 1.53% быстрее». Но результат-то все равно есть — внутренний результат.
Допустим, вы «пилите» внутренние блоки, черные ящики, которые только косвенно влияют на работу пользователей. И даже не всегда можно подсчитать что-то типа «стало загружаться на 1.53% быстрее». Но результат-то все равно есть — внутренний результат.
UFO just landed and posted this here
Вот, что забавно. Когда читаешь подобные статьи, они по большей части ориентированы на один определенный тип программистких контор — универсалов. Т.е. таких контор, которые работают с, условно, сотней клиентов, и каждому клиенту делают какой-то «проект». У одного это может быть информационная система для складского учета, у другого — подсчет какой-то статистики, у третьего — электронный документооборот и т.д. Отсюда и советы о смене участка работ или новых технологиях.
Мне, например, доводится работать в фирме, которая… как бы сформулировать… монопродуктная фирма. Т.е. у нас есть определенный программный пакет, который поставляется разным клиентам. Под каждого другими отделами производится настройка, написание специфичного кода. Моя же команда работает над ядром системы, которое работает с БД, интерпретирует скриптовый язык, отрабатывает логику прорисовки экрана на клиентской стороне и т.п. Набор используемых технологий тоже ограничен. Ты не можешь использовать какой-то хитрый «модный» язык просто потому что это а)не нужно — нет применения б)некому, кроме тебя будет это поддерживать, когда завтра ты пойдешь в отпуск позагорать. Ты не можешь использовать какие-то другие технологии в области работы с БД, потому что там все единообразно — нечего менять. Нечего менять в протоколах связи и т.п. В итоге каждый день ты занимаешься примерно одним и тем же — процентов на 50 поддержка, процентов на 50 — новое, но в рамках той же парадигмы.
Думаю, таких фирм-не«универсалов» полно, и там такие советы не работают.
Мне, например, доводится работать в фирме, которая… как бы сформулировать… монопродуктная фирма. Т.е. у нас есть определенный программный пакет, который поставляется разным клиентам. Под каждого другими отделами производится настройка, написание специфичного кода. Моя же команда работает над ядром системы, которое работает с БД, интерпретирует скриптовый язык, отрабатывает логику прорисовки экрана на клиентской стороне и т.п. Набор используемых технологий тоже ограничен. Ты не можешь использовать какой-то хитрый «модный» язык просто потому что это а)не нужно — нет применения б)некому, кроме тебя будет это поддерживать, когда завтра ты пойдешь в отпуск позагорать. Ты не можешь использовать какие-то другие технологии в области работы с БД, потому что там все единообразно — нечего менять. Нечего менять в протоколах связи и т.п. В итоге каждый день ты занимаешься примерно одним и тем же — процентов на 50 поддержка, процентов на 50 — новое, но в рамках той же парадигмы.
Думаю, таких фирм-не«универсалов» полно, и там такие советы не работают.
Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода. А насчёт «хитрых» технологий — каждая технологиях хороша в том или ином месте, нужно убедить других участников команды в том, что с данной технологией эффективность т увлечённость команды в программном продукте возрастёт. На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям б) интерес к работе. А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.
Вы говорите у вас несколько команд, как минимум можно пойти в другую команду, приступить к написанию специфичного кода
А мою работу тогда кто будет делать? В обеих командах — комплект. Каждый чем-то своим занять, «въезд» в специализацию не за день и не за месяц проходит. У всех в команде примерно год уходил на вход в область — слишком много нюансов.
каждая технологиях хороша в том или ином месте, нужно убедить других участников команды в том, что с данной технологией эффективность т увлечённость команды в программном продукте возрастёт
Если возрастет. Но это десктопное/системное программирование, там не покатит, например, сменить язык. Другие библиотеки? Да, регулярно находим что-то новое, но 80% остается того же.
На выходе получаем: а) новые горизонты и возможность открывать путь к «космическим» технологиям
Не всегда возможно — нет требований по продукту (не считая перемещения на новые платформы — веб, но этим занимаются другие люди).
А проблема в том что некому поддерживать решается собраниями или привлечением нескольких людей.
В каком смысле «собраниями»? Привлечение нескольких — да, ливерсификация — так и делаем — на время болезни или отпуска один или двое могут подменить, но не больше — своей работы навалом, да и все же специализация у каждого своя.
Вот и получается в итоге, что команда — хорошая, продукт хороший, технологиии нравятся, но однообразно и как специалист застаиваешься.
Я автоматикой занимаюсь. И таки получается, что мы (и большинство коллег) — такие универсалы. Сегодня я запускаю говнокачку (да, их тоже иногда надо автоматизировать), завтра — пищевое производство, у меня там техпроцесс (вот чёрт, я ж рабочие башмаки после вчерашней говнокачки не помыл), послезавтра у меня небольшая электростанция, параллельно с этим — система управления освещением и вентиляцией на другом заводике 
Ага. А представьте, что вы каждый день занимаетесь автоматизацией хлебозаводов. С небольшими вариациями. Годами подряд. Каждому надо что-то чуть свое, пожтому без работы вы не сидите, о нет. Но тем не менее, почти одно и то же.
Занимался автоматизацией газотурбинных электростанций и газоперекачек несколько лет. Коллеги (к настоящему моменту) уже больше 10 лет этим занимаются. Нет двух одинаковых объектов и двух одинаковых косяков. А наладка и командировки — это всегда праздник разнообразия :)
Есть люди, которым каждые 2-3 года надо менять направление деятельности, чтоб скука не заела. Но это перебор. А скука и выгорание случаются у всех.
Есть люди, которым каждые 2-3 года надо менять направление деятельности, чтоб скука не заела. Но это перебор. А скука и выгорание случаются у всех.
Это не совсем то. Я о тех, кто работает с сердцевиной системы, тех, для кого нет объектов. Тех, кто делает кубики, из которых потом складываются структуры «объектов». Между ними и объектами те самые implementation engineer'ы — вот у них и вправду может быть «нет двух одинаковых объектов».
А то, что все косяки разные — очень тонко подмечено ;)
А то, что все косяки разные — очень тонко подмечено ;)
тогда «хлебозавод» — это недостаточно высокий уровень абстракции. Даже если речь не о автоматике, а о процессе и технологах.
Нет двух одинаковых объектов.
Я, собственно, и есть implementation engineer в вашей терминологии (хотя, на мой взгляд, более уместно application engineer). Так я и кубики свои делаю, которые из проекта в проект кочуют. Когда с доработками, когда без.
Вот кто полностью абстрагирован от объектов — это разработчики железа: сименс, шнайдер и иже с ними.
PS А вы с какой стороны к «хлебозаводу» относитесь?
Нет двух одинаковых объектов.
Я, собственно, и есть implementation engineer в вашей терминологии (хотя, на мой взгляд, более уместно application engineer). Так я и кубики свои делаю, которые из проекта в проект кочуют. Когда с доработками, когда без.
Вот кто полностью абстрагирован от объектов — это разработчики железа: сименс, шнайдер и иже с ними.
PS А вы с какой стороны к «хлебозаводу» относитесь?
Да это просто абстрактный пример, не очень удачный, чтобы описать мою личную усталость от рутины. Вот представьте, что я разработчик ПО для контроллеров Siemens, например. Или интерпретатора какого-нибудь языка для opc, который универсален и на всех объектах будет одинаков. Или DCOM сервера для того же OPC. И реальных объектов в жизни не видел. Все — черные ящики, вход-выход, функция. К тому же, если захочется когда-нибудь сменить род деятельности, то, что я в течение 10 лет разрабатывал такие внутренние черные ящики, не так красочно смотрится в резюме. Да, есть опыт работы с языком, и все. Основные фреймворки — и те внутренние, закрытые.
Да это просто абстрактный пример, не очень удачный, чтобы описать мою личную усталость от рутины.
И правда, не очень удачный.
Вот представьте, что я разработчик ПО для контроллеров Siemens, например.
И реальных объектов в жизни не видел.
Попытался представить. Не смог. Или под ПО имелось в виду их firmware?
Дело в том, что я таки разрабатываю под сименс. Естественно, прикладные задачи. Я плохо представляю себе, как делать прикладную задачу, имея представление об объекте на уровне «чёрного ящика».
Основные фреймворки — и те внутренние, закрытые.
Последние N лет я пишу на IEC_61131-3 и немного на си. Что такое фреймворк?
Или под ПО имелось в виду их firmware?
Например.
Дело в том, что я таки разрабатываю под сименс. Естественно, прикладные задачи. Я плохо представляю себе, как делать прикладную задачу, имея представление об объекте на уровне «чёрного ящика».
Прикладные — разумеется.
Последние N лет я пишу на IEC_61131-3 и немного на си. Что такое фреймворк?
Пусть будет не фреймворк, просто ряд специализированных библиотек.
Ну вот, теперь вы хотите поменять род деятельности, и ваше знание подобных узких стандартов оказывается ненужным. Благо, хоть Си — универсальный, а не какой-то свой, внутренний язык (а у нас в нашем продукте есть и свои внутренние языки).
Ну вот, теперь вы хотите поменять род деятельности, и ваше знание подобных узких стандартов оказывается ненужным.
Во-1, это не единственное, что мне необходимо по работе.
Во-2, и это более общий момент: желание поменять род деятельности приводит к тому, что многое из накопленного опыта оказывается ненужным, и многого не хватает. И неважно, в данном случае — узкий стандарт или широкий.
1) мы не вас обсуждаем лично, а условный пример
2) это смотря, насколько сильно род деятельности меняется. Если был программист, а становишься полотером — то да, многое из накопленного становится ненужным. Если переходишь из одной софт компании в другую — совсем другое дело. И здесь действительно проблема, если весь твой опыт — очень узкий, пусть и солидный. Потому что при условном соревновании с другими, даже более молодыми, важнее практическое знание общеупотребимых технологий и библиотек, а не узкоспециализированных, неизвестных за рамками предыдущей фирмы. В итоге два условных человека, начавшие карьеру рядом, окажутся в совершенно разных ситуациях — один, будучи «в тренде», легко попадет в десяток компаний и (как указывалось в статье, которую я и критиковал) сможет менять род деятельности. Другой, имея тот же опыт в годах, будет в худшей ситуации, потому что его опыт — узкоспециализированный. И да, мы можем сто раз обсуждать то, что второму «никто не мешает самостоятельно учить блаблабла», но это означает лишь одно — первый будет делать это по роду деятельности, а второй — дополнительно, в свободное время. В итоге чисто в часах жизни второй теряет, а по уходу из этой фирмы (где он пишет условный firmware) этот опыт, касающийся чисто внутренних продуктов, становится ненужным.
Но это все — стороннее. Изначально разговор шел о мотивации и монопродукте, здесь мы ушли в сторону.
2) это смотря, насколько сильно род деятельности меняется. Если был программист, а становишься полотером — то да, многое из накопленного становится ненужным. Если переходишь из одной софт компании в другую — совсем другое дело. И здесь действительно проблема, если весь твой опыт — очень узкий, пусть и солидный. Потому что при условном соревновании с другими, даже более молодыми, важнее практическое знание общеупотребимых технологий и библиотек, а не узкоспециализированных, неизвестных за рамками предыдущей фирмы. В итоге два условных человека, начавшие карьеру рядом, окажутся в совершенно разных ситуациях — один, будучи «в тренде», легко попадет в десяток компаний и (как указывалось в статье, которую я и критиковал) сможет менять род деятельности. Другой, имея тот же опыт в годах, будет в худшей ситуации, потому что его опыт — узкоспециализированный. И да, мы можем сто раз обсуждать то, что второму «никто не мешает самостоятельно учить блаблабла», но это означает лишь одно — первый будет делать это по роду деятельности, а второй — дополнительно, в свободное время. В итоге чисто в часах жизни второй теряет, а по уходу из этой фирмы (где он пишет условный firmware) этот опыт, касающийся чисто внутренних продуктов, становится ненужным.
Но это все — стороннее. Изначально разговор шел о мотивации и монопродукте, здесь мы ушли в сторону.
один, будучи «в тренде», легко попадет в десяток компаний и (как указывалось в статье, которую я и критиковал) сможет менять род деятельности.
Неверно. Другой род деятельности — другой опыт нужен. Я уже писал об этом, мало одного владения инструментом (скажем, тем же С++). Надо ещё предметную область понимать. Это тоже очень ограничивает лёгкость смены рода деятельности.
А если ты продолжаешь делать на 90% то же самое — то что ты, вообще, поменял?
Неверно. Другой род деятельности — другой опыт нужен
Отнюдь. Вы не поняли мысли — ввод в новую область, разумеется, потребуется. Но технологии будут примерно те же. И это «примерно» позволяет легче сменить род деятельности, нежели при программировании того же firmware на внутренних средствах в течение ряда лет.
Я уже писал об этом, мало одного владения инструментом (скажем, тем же С++).
Одних плюсов мало, как инструмента. Как знание С или firmware средств разработки поможет, например, на собеседовании, где потребуется зная какие-нибудь стандартные библиотеки типа libevents или boost'а написать за час-два простой веб-сервер? Занимаясь firmware на внутренних инструментах ты только с ними и остаешься. Даже аппаратную платформу сменить непросто. Рынок труда для «универсальных» технологий намного шире — это основная мысль, которую я пытаюсь донести.
А если ты продолжаешь делать на 90% то же самое — то что ты, вообще, поменял?
Если ты писал прикладное ПО и продолжаешь писать прикладное, но совсем в иной области — это не «на 90% то же самое». Что меняется? Да хотя бы команда, структура ПО может быть совсем иной. Может быть и пакет технологий другим. Но одно дело, когда из списка требований ты знаешь 1-2 элемента, и другое дело — когда 8 из 10.
Например, ты разрабатываешь информационную систему на том же С++, с использованием ряда стандартных библиотек, работая с базой данных Oracle. Относительно легко можно заняться разработкой других ИФС с другой топологией или совсем иных прикладных програм, используя тот же С++, но в связке с MSSQL (условной). И таких «иных, но похожих по средствам» проектов (вакансий) — море. Сравним это теперь с человеком, который 10 лет разрабатывает что-то на встроенном языке какой-то нестандартной системы. Даже для перехода к другой нестандартной системе-аналогу придется заново изучать все. Именно это я критикую в статье — есть фирмы/сферы-универсалы, где сменить место работы/проект можно легко. А есть фирмы с монопродуктами, где ты не переключишься, если тебе надоела рутина. Куда переключится разработчик того же firmware, если у компании нет новых альтернативных продуктов на данный момент? Никуда.
А почему клавиатурой полноценной не пользуетесь? Производительность ведь снижется?
Кстати, а почему две картинки из оригинального поста не попали в перевод?
А что если с коллегами написать свой какой-то проект, в течении довольно долгого времени?
Это проблема встречается не только в разработке ПО или технической сфере: она характерна для любой офисной работы. Каждый день вы находитесь в одном и том же помещении, с теми же людьми, выполняя те же рабочие обязанности, и все это — в обстановке, которая почти не меняется…
Попробуйте железо программировать. В смысле, автоматику. Накатаетесь по объектам столько, что рабочий день в офисе будет восприниматься, как выходной.
люди все равно начинают принимать все хорошее как должное и раздражаться из-за того, что им не нравится.
Когда рабочее место в порядке вещей (а не в исключительных случаях) состоит из 2 кабельных барабанов, из коих большой — стол, а маленький — стул, сверху режут болгаркой, а сбоку — сварка, кондиционера в помещении нет (а иногда — и помещения, как такового). Иногда изо рта идёт пар, руки примерзают к мышке, а ноги — к бетонному полу. Иногда удобства представляют собой туалет типа «сортир» при температуре -49 за бортом… Короче, я не могу пожаловаться на однообразие условий, хоть и больше 10 лет занимаюсь одним и тем же :)
Немного хаоса — последний ингредиент в нашем рецепте против скуки. И как и любой другой рецепт, его можно совершенствовать бесконечно.
Хаос можно совершенствовать бесконечно, это точно :)
Лично за собой замечал (ибо регулярный тайм-менеджмент) следующие временные показатели.
При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
Сравнивал временные затраты по задачам аналогичной сложности.
Соответственно, не стоит думать, что отсутствие интереса не несет прямой финансовый ущерб — ущерб самый что ни на есть прямой, даже не косвенный. И любой нормальный разработчик будет это нивелировать либо за счет личного времени, либо за счет клиента, повышая временные оценки задач.
И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
Сравнивал временные затраты по задачам аналогичной сложности.
Соответственно, не стоит думать, что отсутствие интереса не несет прямой финансовый ущерб — ущерб самый что ни на есть прямой, даже не косвенный. И любой нормальный разработчик будет это нивелировать либо за счет личного времени, либо за счет клиента, повышая временные оценки задач.
И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
Sign up to leave a comment.
Что делать, если программировать становится скучно