Оригинал: Bruno Marnette: Coding is boring, unless…
Мне не удавалось, как разработчику, задерживаться на одной работе больше двух лет.
Каждая новая работа — это отличный карьерный шаг, а высокая текучка работников присуща нашей сфере. Но мои бывшие работодатели не были особенно рады, что я уходил. Некоторые из них пытались удержать меня, но мне становилось так скучно, что у меня не оставалось выбора.
(Оговорка: мне везло, что я жил в местах, где работы для программистов было больше, чем программистов! Я понимаю, что возможность сменить работу доступна не всем).
Сейчас я соучредитель и технический директор компании Enki. Так что я несу ответственность за инженерную культуру. Часть моей работы — быть уверенным в том, что наши разработчики не сходят с ума от скуки, как это иногда случалось со мной в прошлом.
Мы с командой разработали стратегию против скуки и применили ее в нашей компании. И поскольку эта стратегия до сих пор хорошо работает, я хотел бы поделиться ей здесь.
В Enki нам повезло работать над трудной и интересной задачей. У нас есть много интересных штук для претворения их в код и множество занятных проблем, которые нужно решить. Поэтому, казалось бы, о какой скуке может идти речь? Но в начале её никогда и не бывает. Скука, как правило, нагнетается со временем, и поражает вас в самый неподходящий момент.
Вот почему мы заранее предлагаем решение, создавая культуру, которая спасет нас (постучим по дереву!) и сделает так, чтобы никогда не становилось скучно.
TLDR: Too Long; Didn’t Learn
Наиболее распространенная и очевидная причина скуки у разработчиков — проект, который длится слишком долго.
Я испытал это лично на своей первой работе. Моя команда работала над подготовкой и обслуживанием финансовых данных через удобный API. Сначала всё было интересно из-за сложности и объёма данных. Я узнал об эффективных способах анализа данных и дизайне API. Но спустя год мы по-прежнему работали над тем же набором данных, с теми же технологиями. Я становился специалистом в какой-то узкой области. Я не узнавал ничего нового.
Я не мог поменять команду или проект, потому что компании было очень важно держать меня на том месте, где я был. Я разбирался в данных и технологии слишком хорошо, чтобы меня заменили. Я не мог оправдать перед ними замену технологии всего лишь потребностью в изучении чего-то нового. Я рассказал, что мне скучно и у меня нет сил, но меня не услышали, так что пришлось двигаться дальше.
Как предотвратить подобное чувство?
В нашей команде мы стараемся не давать работать над тем же кодом, продуктом или набором данных более трех месяцев любому сотруднику. Этот период немного варьируется и, возможно, слишком мал для крупных компаний. Но мы в целом верим в частые ротации.
Чтобы реализовать подобные схемы, мы обеспечиваем комплексное окружение. Каждый из наших разработчиков может работать над любой частью основного кода (или может быстро научиться это делать).
Еще один фактор для профилактики — это постоянное обсуждение подобных проблем. У нас есть прямые, открытые дискуссии каждую неделю. Если разработчик начинает чувствовать себя слишком специализированным или ощущает избыточный комфорт, то пришло время менять место.
Поддерживать старый код — скучно
Понять, что ваш проект в режиме поддержки — официально или нет — можно, когда разработчики тратят 90% своего времени на исправление багов вместо разработки новых компонентов.
Некоторые скажут, что обслуживание неизбежно. Старый код нуждается в поддержке. Создавать программное обеспечение — это как строить дом. Старые дома нужно обслуживать и реставрировать их время от времени. Верно?
И да и нет. Типичная проблема — это сложившиеся установки.
Когда-то у меня был ментор, который к этому вопросу относился цинично. Он воспринимал как данность то, что ничего нельзя больше сделать. Так устроена разработка софта, говорил он. Жизнь отстой — привыкай.
Как справляться с такой проблемой?
Режим поддержки иногда является результатом низкокачественных технических решений в сочетании с отсутствием твёрдости убеждений.
Большая, монолитная кодовая база со сложными зависимостями требует дополнительного технического обслуживания. Хорошо спроектированная инфраструктура микро-сервисов, напротив, немного податливей. Когда микро-сервис перестает работать, его можно заменить. Можно переписать его с нуля, используя другой язык или технологию. Таким образом вы узнаете что-то новое, вместо исправления унаследованного кода. А если ваша архитектура пока этого не позволяет, то вы можете предпринять какие-то шаги, чтобы её улучшить и получить навыки DevOps в процессе.
Стратегия микро-сервисов — это только один из возможных способов подойти к проблеме "скучного" технического обслуживания. Некоторые создают продвинутые инструменты, чтобы сделать поддержку более эффективной и увлекательной. Отличный пример это то, что Facebook сделал со своей массивной базой кода на PHP. Они построили свой собственный компилятор и написали собственный типизированный язык (Hack) поверх PHP, чтобы одновременно облегчить обслуживание и улучшить опыт разработчиков. Я подозреваю, что это не "решило" проблемы легаси-кода, но, безусловно, сделало работу более интересной.
Копипастить скучно
Есть программирование, и есть программирование.
На некоторых своих бывших должностях я писал километры не слишком стоящего кода. Например, когда-то я писал скрипты на Groovy и Python для интеграции данных. Данные были сложные, с десятками противоречивых схем, которые не давали достаточно возможностей для автоматизации. Поэтому мне нужно было писать много кода, а мои коллеги считали, что я узнавал много нового.
Но это было не так. Почему?
Потому что 50% моего кода (специально преувеличиваю!) были прямым копированием из Stack Overflow. А другие 40% были копированием из других скриптов. Либо моих коллег, либо моих собственных. Работа стала однообразной. Креативности или приобретения знаний тут было мало.
Как мы пытаемся справиться с этим?
Как команда, мы обращаем внимание на тип кода, написанного другими. Мы делаем это во время код-ревью, созвонов и встреч. Если кто-то провел неделю над не слишком творческим кодом, мы стараемся понять, почему.
Иногда корень проблемы технический. Возможно, мы работаем над скриптами или настройками больше, чем требуется. В таком случае, мы добавляем больше автоматизации. В некоторых случаях мы делаем копипаст специально. Тогда мы стараемся распределить нагрузку скучной работы, чтобы разделаться с ней поскорее.
Внутренние инструменты обычно скучны
Нам, разработчикам, нравится создавать собственные внутренние инструменты для решения специфических проблем, потому что создавать новые вещи — это круто. И ещё, проектирование специальных решений ощущается "чище", чем адаптирование и повторное использование уже существующих. Но изучение проприетарного инструмента примерно в 10 раз менее интересно, чем изучение популярных технологий с открытым кодом.
Почему?
Потому что вы не можете о нем поговорить с друзьями, похвастаться им, не можете прочитать о нём на Hacker News, использовать его во время хакатонов или в закрытом стороннем проекте.
Но многие компании попадают в ловушку: они создают решения, которые не стоят появляющейся при этом скуки. Другими словами: справляясь с краткосрочной безысходностью, они создают безысходность на долгую перспективу.
Я видел это сам на предыдущей работе. Я был вынужден использовать внутренний DSL для масштабной интеграции данных. Всё, что я узнал нового — это ещё один подобный SQL жаргон (специально преувеличиваю). Лучше бы я пользовался и изучал открытую низкоуровневую технологию, вроде Spark. Я был бы в 10 раз сильнее вовлечён, и даже если бы мой код был бы в два раза более многословным, это всё ещё делало бы меня в 5 раз более продуктивным. (не совсем математически обосновано, но вы понимаете).
Какая культура и окружение может это предотвратить?
Мы стараемся по максимуму использовать открытые технологии. Если мы можем повторно использовать что-то актуальное и захватывающее, мы это делаем. Мы не избегаем самых современных технологий. Мы выбрасываем созданный нами код как только открытая технология становится достаточно зрелой, чтобы заменить его. И когда наш собственный код становится достаточно универсальным, мы публикуем его под открытой лицензией.
Иногда мы делаем ошибки. Например, некоторое время мы использовали библиотеку agenda.js чтобы планировать бэкенд задачи, потому что это казалось современным и заманчивым. Но оказалось, что это всё усложняет, поэтому мы переключились на старую, более надежную технологию (старый добрый cron!). Мы не жалеем, что экспериментировали, потому что это был ценный опыт.
Быть манки-кодером скучно
Еще один распространенная причина скуки — это непрофессиональное управление персоналом. Если говорить точнее: диктаторское управление разработчиками, по принципу "сверху вниз".
Руководители с благородными намерениями иногда используют такой стиль управления, сами не осознавая этого. Особенно, когда проект продвигается не слишком хорошо, или когда приближается дедлайн. Под давлением срабатывает естественный рефлекс: пытаться сокращать обсуждения, сводить к минимуму мозговой штурм и давать людям конкретные указания, что делать — без обсуждения и объяснения. Просто ради экономии времени и результата.
Понимающего подопечного это не обязательно расстроит; на самом деле, некоторые люди (иногда) ценят несложные задачи, которые нужно выполнить точно, как сказано. Предполагается, конечно, что об этом попросили таким способом, который видится уместным.
Но здесь есть некоторые скрытые издержки.
Точное знание, как писать код ещё до начала работы, превращает интеллектуальный и творческий процесс в механический. Другими словами, это превращает разработчиков в манки-кодеров.
Что еще более важно, вовлечённые разработчики хотят понимать, почему они делают что-то именно таким способом, а не другим. Если, конечно, это не банальная работа по обходу проблемы в граничном случае или написание временного патча. Но разработчик, который перестает заботиться о важных решениях и их обоснованности — это тот разработчик, который готов к смене работы.
Как это предотвратить?
Главное, что нужно, — это обстановка, которая поощряет открытые дискуссии. С регулярным форумом для обсуждения, разработок стратегии и планирования того, что должно быть сделано в команде. И чтобы сохранить такую атмосферу, все в команде должны быть бдительными.
Именно в тяжёлые времена (или когда близок дедлайн) подопечным нужно говорить громче, а наставникам внимательно слушать.
Рутина всегда становится скучной
Последнее, но не менее важное: рутина в замкнутой атмосфере — абсолютный убийца удовольствия.
И это касается не только разработчиков и индустрии IT. Это можно применить почти к любым сотрудникам, не работающими напрямую с клиентами. Каждый день та же комната, те же самые люди, та же атмосфера, та же должность… Даже в быстро растущем коллективе, и даже тогда, когда все эти вещи объективно "хороши", люди начинают принимать все хорошее как должное, а плохое их сильно расстраивает.
Как мы боремся с этим?
Ключевой ингредиент тут — разнообразие: нанимать людей с разным видом опыта и разного происхождения (например, наша команда состоит из 6 человек родом из Британии, Франции, России и Греции). Ежедневно встречаться с теми же людьми, безусловно, интереснее, если каждый из них может внести что-то особенное в культуру.
Кроме того, мы стараемся, чтобы чаще была возможность выйти из повседневной рутины.
Например, мы вместе ходим на общественные митапы и хакатоны. У нас есть сторонние проекты, и мы содействуем развитию наших любимых открытых инструментов. Мы даже время от времени помогаем коллегам с нетехническими вопросами (например, с наймом новых людей, маркетингом, распространением...). Не потому, что мы все в этом специалисты, а для разнообразия.
Мы также организуем сторонние вылазки для команды (например, Secret Cinema) и у нас есть еженедельный "еnkiтон" без четкой цели и плана. Во время него мы иногда пишем вместе бесполезные программы. Иногда обмозговываем новую идею. Иногда просто играем в League of Legends. Или идем в паб. Приятное тут в том, что мы не знаем, что будем делать до последней минуты, пока не решим вместе.
Капля хаоса — последний ингредиент нашего рецепта против скуки. И, как любой рецепт, его никогда нельзя довести до идеала. Измените количество, замените ингредиенты и повторите.
Оригинал: Bruno Marnette: Coding is boring, unless…
(Перевод Наталии Басс)
Комментарии (46)
habradante
09.08.2016 12:01+5Идеальные советы для фирмы, чья цель обучение сотрудников, а не выпуск продукта :) На мой взгляд срок в три месяца сильно занижен, это время чтобы нахвататься по верхам, а не изучить технологию. Мы, например, сотрудникам просто выдаем более сложные задачи, но время, через которое они их получают, сильно зависит от их обучаемости и желания.
darthandrew
09.08.2016 12:45-8Когда к нам приходят новые сотрудники — обычно это студенты. По факту, такого человека можно лишь оценить «примерно» пригоден он к работе программистом или не очень за первые два месяца. Но опыта у них почти нет, и пройдут годы, лет 5, пока они выйдут на уровень «Получил автономную задачу, сделал качественно и не налажал в коде». Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно. Прыгунов я бы не любил, и зная, что за плечами у него УЖЕ несколько фирм, где он работал всего по пару лет… да я бы его не взял, странный парень, конфликтер вероятно, или денег кучу требует. Пусть идет и сделает себе свой бизнес, свою фирму, и зарабатывает.
sefus
09.08.2016 13:20+4Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Нанять бы новичка, научить его и продолжать платить так, как будто он ничего не умеет — вот было бы честно и справедливо.
Toshiro
09.08.2016 13:22-6А в чем собственно проблема? Оплати своему разработчику ипотеку, раз уж он так сильно тебе требуется, и он лет 10 никуда от тебя не денется с минимальной зарплатой.
darthandrew
09.08.2016 13:54-2Все проще: хочешь чтобы тебя учили — будь готов отработать. Может не 10 лет, но 5 точно. Или ходи говори «я быстро учусь». А вообще программисты и так зажрались по самое не хочу, скучно им работать, ага. Конечно это черта характера. Кто-то любит «начинать все новое и новое», не всегда доводя до ума — для бизнеса это вредно. Другие наоборот — не любят начинать новое, а привыкли к привычному проекту и задачам «около него». Любой более-менее серьезный проект скорее всего очень скоро перестает быть «веселым для души», потому что есть требования, есть рутина (но за нее платят), есть отладка сложных случаев когда даже не ты писал, а разгребать тебе. Это называется «работа». Не скучно — это для себя небольшую программку для души набросать, быстро получилось, ура, можно новую начинать.
Toshiro
09.08.2016 14:36-2Я вас категорически поддерживаю, но не могу плюсануть из-за кармы)) Вообще не понимаю этой волны статей и комментариев про скуку за последние 2 недели. Откуда… нет, скорее как такие вечноскучающие персонажи попадают в ИТ? В ИТ Карл!!! Наверное единственную сферу деятельности где даже в рутинных задачах ты то и дело ощущаешь себя всесоздателем!
Одно дело — когда ты десяток лет занимался разработкой интернет-магазинов и видеть их уже не можешь. Но учитывая опыт, который ты за эти 10 лет накопил и навыки, которые получил — смело уходи куда душа лежит! И совсем другое, когда ты за какие то жалкие 3 месяца теряешь интерес к проекту. А чем ты думал, когда брался за него? Разумеется, такое случается у всех. Но это не тенденция, это случайность! А в статье это расписано чуть ли не как норма. Я абсолютно не согласен с такой интерпретацией, это лишь оправдания недостойные профессионала.
https://habrastorage.org/files/fa2/836/16e/fa283616edfa4a5d8a6ab59336965fab.jpg
RPG18
09.08.2016 14:46+1А чем ты думал, когда брался за него?
А есть выбор? На собеседовании говорят об одном, а потом дают совсем другое.Toshiro
09.08.2016 15:40+1Нет, это вы позволяете им так поступать. Кто вам запрещает задавать вопросы? Расспрашивайте работодателя, уточняйте все детали, записывайте наконец в блокнот! Неужели так трудно скачать из PlayMarket или AppStore диктофон?! Работодатель прекрасно понимает все свои риски, поэтому на собеседованиях докапывается до самых бессмысленных деталей. Так чего вы то вдруг засмущались? Докапывайтесь до него!
Что за проект? Какая точная зарплата? Белая ли зарплата? На каких условиях стоит ожидать роста зарплаты? Есть ли перспективы для роста карьерного? Стабильные ли инвестиции в проект (не обанкротится ли фирма завтра)? Сколько уже сделано и сколько предстоит сделать? Есть ли утвержденный план работ? Определены ли точные роли в команде? Кто руководит, какой у него стаж руководства, есть ли успешные завершенные проекты? А у команды? А кто в команде, сколько их, давно ли они работают в команде, чем занимались? Кому вы непосредственно будете подчиняться и какие границы у этого подчинения? Каковы корпоративные правила в этом месте? Есть ли гарантии оплаты сверхурочных? Заинтересована ли компания в вашем обучении? Оплачивает ли она курсы/сертификаты? И т.д. думаю вы уловили мысль.
В конце-концов, это вам в этом месте и над этим проектом работать (не)определенное время. Ну так выясните на берегу во что вы собираетесь ввязаться, чтобы потом не скулить на хабре, не приходя в сознание, о том как вам скучно и что все плохо!RPG18
09.08.2016 16:18А толку от диктофона? Вот и остается только менять работу.
Toshiro
09.08.2016 16:45Толку от диктофона — записать собеседование (если разрешат, бывает до собеса подписываешь соглашение о коммерческой тайне и неразглашении), чтобы самому потом в спокойной обстановке еще раз прослушать все, если не получается запомнить. Некоторые вещи не сразу принимаются во внимание, даже если они сказаны прямым текстом.
RomanArzumanyan
09.08.2016 15:07+2Рынок диктует свои законы. Когда программисты станут не нужны — они станут трудолюбивыми. А пока имеем то, что имеем.
И да, 5 лет — это очень много. А 10 лет — это путь от школьника до кандидата наук.
Rasifiel
09.08.2016 17:51Не берите новичков, берите готовых. Берешь необученных по двум причинам а) посчитали, что все равно выгодно б) толку от готового опыта для тебя мало, все равно все специфичное. Если же обсчитался при рассчете, то кто же тебе виноват.
И вот в обратную сторону так же будет по вашему предложению — компания будет обязана не увольнять в течении 5 лет за то, что работник облагодетельствовал компанию своим присутствием и своими знаниями?
asm0dey
10.08.2016 09:19Разбираться со сложными проблемами — интересно, это я как разработчик с почти девятилетним стажем говорю. Неважно откуда эти проблемы пришли — от бизнеса или от другого разработчика или от несовершенства используемого фреймворка. Скучно — заниматься рутиной, которую ты уже не раз делал. Надо отдавать такую работу не крутым разработчикам, а тем для кого это ещё не рутина.
DyadichenkoGA
10.08.2016 16:03То есть я правильно понимаю, что вы предлагаете разработчику не максимизировать свою выгоду из гуманистических побуждений? Просто заниматься обучением имеет смысл, когда нет свободных специалистов на рынке. Если обучением считать выполнение детских/рутинных задач, то это тоже стоит денег и человек по факту их отработал. А я полагаю, что при разнице предложений в 10-15%, если на работе нет никаких серьёзных проблем, человек вряд ли перейдёт в другую компанию. А если уровень специалиста вырос, то смысл ему сидеть в компании, если ему в другой предлагают на 100-200% больше? Ведь в долгосрочной перспективе он теряет не эти 100%, а значительно большие суммы денег. Я не говорю про скуку, этот вопрос другой и тут айти специалисты может быть действительно зажрались, но я в мало каких компаниях видел нормальную систему обучения. Обычно тебя бросают на задачи, и ты должен с ними разобраться. Иногда можешь спросить совета у старших коллег (хотя чаще быстрее помогают гугл и StackOverflow). Это не совсем обучение.
darthandrew
10.08.2016 16:24Про обучение: это когда человеку говоришь «Ты строки сообщений пользователям не в коде пиши, а в ресурсы помещай, для локализации поможет». Или «Ты поток создал, а про блокировки не подумал, надо вот так». Или «У тебя кнопки ОК и Отмена наоборот, в винде не так». «А табуляции порядок проверил? Что будет когда человек на форме прожмет таб?». Я уже не говорю про случаи как проектируется набор классов, что надо пихать в члены класса, что не надо, как там с наследованием и т.п. Обычно человек-вчерашний студент он вот знает вроде много, но начнет делать — там всякие вещи бывают. И только корпоративная культура его обучает, как правильно программировать. Поэтому в моей практике новый сотрудник-студент учится, но учится работая. На него тратят время, по факту, инвестируют. И нормальные люди это оценят и работают, хотя бы некоторое время. Ну конечно кто-то и уходит. Удержать нельзя, в любом случае. Кстати студентов набрать лучше, у них еще «прет энтузиазм». А купить крутого парня можно, но экономически не всегда выгодно — он ленив будет, ему что-попало не поручить, деньги давай.
DyadichenkoGA
10.08.2016 16:52+1Ну просто, на мой взгляд, должен быть адекватный рост соразмерно скиллам. Да, можно платить меньше рыночной цены, но не в 2 раза же. 5 лет срока — это очень много. Год-два возможно. Просто чтобы проектирование доверяли студентам, я такого не видел, наверное зависит от компаний. Хотя, я и сам то, по сути, выпустившийся студент, некоторое время работал на разных проектах, в разных фирмах и на фрилансе.
А всё, кроме пожалуй примера с потоками, это я бы всё-таки не назвал обучением. Обучение, это когда студент не имеет представления о паттернах, о адекватном применении наследования, о том какие существую приёмы, чтобы избежать дублирования и т. п. и ему объясняется «как надо». Просто то, что описано звучит, как код ревью вне зависимости от уровня специалиста. («У тебя кнопки ОК и Отмена наоборот, в винде не так» это вообще скорее к проектированию UI, а не к разработке)
Но в случае, когда у человека реально вырос уровень, вы, как компания, получаете хорошего специалиста, которого плюс ко всему не надо вводить в проект, который в нём уже +- разбирается и может достаточно хорошо выполнять большой класс задач, так почему ему платить на порядок ниже рыночной цены? Так как он пришёл к вам студентом и якобы он вам «обязан», хотя он так же работал? Это достаточно странное обоснование.
4410
09.08.2016 13:48+10Очень однобокий комментарий. Разработчик не виноват что индустрия так работает и самое большое повышение зарплаты происходит при смене места работы. Он ходит на работу зарабатывать деньги, и осуждать его за то, что он хочет получать больше денег за это, а не готов «за идею» работать на вас, это как-то нелепо, не находите?
Не занимайтесь благотворительностью, считайте деньги, чтобы сотрудник, которого вы взяли «на обучение», всё равно приносил вам прибыль. Вместо того чтобы потом писать обиженные комментарии. И да, это ваше «обучение» обычно сводится к работе над самой «плохой» работой — багфиксингом, написанием тестов, копанием в легаси коде. Словом, всем тем, чем остальные разработчики заниматься не хотят.darthandrew
09.08.2016 14:19Да. разработчик не виноват. Объясню еще проще: идеального решения тут нет. Был человек, поработал несколько лет, напрограммировал много чего. Уходит. Что получает команда? На «старых» сотрудников возрастает нагрузка — теперь надо поддерживать и его код тоже. Новые-молодые не помогут — их еще надо научить. Так что с точки зрения того кто ушел — он молодец, сбросил старье с себя, больше зп, жизнь с чистого листа. На тех кто остался — «ну спасибо, Вася, теперь твой громадный модуль нам досталось вести!». Вот и вся логика, ничего такого — просто стороны РАЗНЫЕ, как на войне. И понимать им друг друга не обязательно.
poxu
09.08.2016 14:22+1О как. Получается, что стороны конфликта это не бизнес и программист, а программист, который ушёл и программисты, которые остались. Внезапно.
RPG18
09.08.2016 14:50+7На тех кто остался — «ну спасибо, Вася, теперь твой громадный модуль нам досталось вести!».
Bus factor? Если да, то руководство виновато, что ничего не делало.
0serg
09.08.2016 16:04Не занимайтесь благотворительностью, считайте деньги
Подсчет денег бизнесом, как правило, приводит просто к отказу от найма студентов.
Профессионалы стоят дороже, но толку от них на единицу капиталовложений все равно больше.
В принципе нам, программистам, в каком-то смысле это выгодно, т.к. новички создают нам конкуренцию.
Но я согласен с darthandrew, с гуманистических позиций это выглядит довольно паршиво.
OYTIS
09.08.2016 14:02+1Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Вот этого я в IT-менеджменте совершенно не понимаю. Неужели нельзя заранее посчитать, сколько будет стоить на рынке человек, который получил у нас опыт, и заложить соответствующее повышение зарплаты в расходы сразу? Зачем заставлять человека «скакать»?darthandrew
09.08.2016 14:09-1Так обычно и закладывают, ес-нно. Начинающий студент может получать одну зп, потом проработал время — пересмотр, как он в деле, и прочее. Однако! Повышение зп зависит не только от человеческих достижений. Есть еще и финансовая обстановка в данном месте работы, и негласная оценка его в сравнении с другими. Т.е. он может быть «просто нормальный», может быть «умный», или какой-нибудь «ну просто обалдеть какой умный». Вариант когда человек «слабоват»… по идее таких не держат, или держат не в программировании. Так что легко сказать — «заложи повышение». А человек вам скажет «Я вот там видел… предлагают в 1,5 раза выше чем у вас». С точки зрения человека получить больше — нормально, молодец. С точки зрения владельца бизнеса — это доп.нагрузка, в сложные времена сложнее будет «пересидеть». А с точки зрения коллег, которые получают вот столько, а работали дольше и ничем его не хуже? Дать ему негласно больше других просто потому что попросил? Поэтому зп в IT строго секретная штука.
OYTIS
09.08.2016 14:24+6Но ведь действительно предлагают. Причем одна и та же компания может нового человека с опытом брать на большую зарплату, чем платит своим сотрудникам с тем же опытом. Возникает подозрение, что текучка на самом деле всем нравится.
darthandrew
09.08.2016 14:32-1Видимо есть разные проекты. В здравом уме любить текучку (или плевать на сотрудников) могут там, где человек по сути не важен. Вот как-то в стиле «Наш дворник уволился, ничего — вон на бирже еще 100 готовы работать за зп еще ниже чем мы ему платили». Может есть такие проекты, я такого не знаю, в нормальном случае программисты важны, каждый в своем роде. Конечно в идеальном мире их заставляют вести проектную документацию, все пишут комментарии, все успели повидать чужие участки работы… В реальном есть заказ на результат, никому юнит-тесты не хочется оплачивать, технический долг это называется. И да — тут вот каждый спец.важен. Хотя бывает — ушел человек, и думаешь — «попутного ветра в спину, вот же… был!»
Hello1
10.08.2016 20:26+1Прям про мою предыдущую работу. Когда попросил прибавки — сказали что денег мало и добавили 10 000 через 2 месяца. А еще через месяц наняли 4х программистов, 2 из которых не прошли испытательный, на зп +20 000 от моей.
OYTIS
11.08.2016 11:19+1Да все так делают. Это общее место, что если хочешь больше получать — нужно менять работу. Почему — загадка, возможно, работодателям тоже надоедает видеть одни и те же лица в офисе.
sefus
09.08.2016 14:27+2А вы продаёте свои товары\услуги по рыночной цене или в 1.5 раза дешевле остальных?
lookid
09.08.2016 20:20-2Программиста нанимают решать круг задач за определенную цену. У компании есть процессы по пересмотру зарплат, например, раз в год. Если сотрудник пытается нарушать процессы компании или вредит, то его либо ставят на место, либо увольняют. В вакансии всё описано, что нужно делать. Зарплата либо оговаривается на собеседовании, либо указана в вакансии. У сотрудника есть все карты на руках, прежде чем он согласится работать. Собеседовать наших кандидатов «по-американски» не имеет смысла, завалят. https://habrahabr.ru/post/200190/
Кто-то должен уйти в минус, или начать работать эффективнее.
Electronick
10.08.2016 08:57не понимаю о чем вы, всю жизнь ломал процессы компаний, навязывая свои условия, и никто меня так и не уволил.
и больше трех лет нигде также не работал, потому что и правда начинает съедать рутина, а это негативно сказывается на производительности. и кому было бы хорошо, если бы я остался?
Raptor_C
09.08.2016 15:25+1Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Ну так платить нужно так, чтобы человека не тянуло в сторону. И это относится ко всем, будь то джуниор или сеньёр и т.д. Но в любом случае человек работает не за идею, а за деньги. И это нужно понимать.
begemot_sun
09.08.2016 13:44+3На первой фотке: два программиста читают одну цитату на баш.орг с двух мониторов (не работают).
На второй фотке: куча студентов делают лабу, но точно не работают.
На третьей фотке: два студента сидят в метро и хз что делают (не работают).
Собственно все хорошо, по статье вы как мама вашему персоналу. Подтираете, ложку в ротик кладете, еще и прожевываете. Это гуд когда есть деньги, и я посмотрю на вас когда у вас будет дедлайн\другие обязательства со штрафами.
В целом желаю вам успехов. Хорошо когда хорошо платят.
jorgen
09.08.2016 15:47+1Поток наивности.
Поддерживать старый код — скучно
Пускай у вас идеальный продукт, пускай поддержка в нём не заключается в борьбе с устаревшей архитектурой. Вы никуда не убежите от поддержки массива крайних случаев, бизнес-ограничений, спец. подходов в сторонних АПИ и сервисах, корректировок ТЗ от клиентов, итд итп. Но это если продукт успешный. Если у продукта нет клиентов (например, только пока) — то вполне можно мечтать об идельной архитектуре в стиле «написал и забыл».
Внутренние инструменты обычно скучны
Здесь прям к каждой посылке противоположный вывод. С друзьями интересно обсуждать очередной сетап докера, а не самопальный скрипт с самопальным рендерером для полной переупаковки ассетов проекта? Ну-ну.
Это то, что на глаза попалось только.
wanick
09.08.2016 19:27Тут позволю себе не согласится, существуют задачи решения которых достойны обсуждения с коллегами.
mtt
09.08.2016 16:33Скучно — это не свойство объекта, а восприятие субъекта. Так что это не «программировать» скучно, а конкретный человек «скучает» от программирования. Как только осознает это, поменяет занятие. Или восприятие
KroTozeR
09.08.2016 21:44Скажу на примере своей работы:
1) Тоталитаризм в отношениях «руководство-программист». У нас такого нет, и слава Богу! С начальником всегда можно нормально пообщаться, в чём-то убедить или переубедить.
2) Общение. Да мы всем коллективом собираемся у начальника, рассказываем, «кактус-пеки» (от «как успехи?»), как закончим, начинаем мозговать и обсуждать идеи. К начальнику всегда можно зайти и рассказать о задумке, поразмыслить о её востребованности.
3) Есть простыня идей — листы бумаги, куда мы пишем идеи. Иногда поднимаем, создаём собственное ТЗ и реализуем в формате «инициативного проекта» (контора у нас — подчинённая).
В принципе, нам не бывает особо скучно. Бывает трудно, долго, сложно, но чтоб скучать? А когда скучать, если задачи разные и никогда не заканчиваются?) Каждый сам выбирает, за какую задачу возьмётся. Но все считаются с очерёдностью.
naething
09.08.2016 20:02Статья заставила улыбнуться. Снова эти хипстеры со своими «микросервисами» и инновационными методами разработки. Наверняка делают какие-нибудь бесполезные мобильные приложения и не имеют отношения к реальной индустрии ПО. Если в проекте пара миллионов строк кода, то только как следует въехать в архитектуру и структуру кода займет три месяца, и никакие «микросервисы» не помогут (наоборот, придется еще больше информации в голове держать).
KroTozeR
09.08.2016 21:30У нас как раз такой проект. Медленно рефакторимся на микросервисы. Коллективный разум решил, что они создают меньше проблем, когда нужно добавить хотелку, идущую вразрез с архитектурой ПО.
RomanArzumanyan
10.08.2016 13:24Эти хипстеры станут орлами, когда нынешние сеньоры уйдут на пенсию. Да и вообще, работают — не трогайте.
А любой крупный живой (не на искусственной вентиляции) проект рано или поздно расслаивается на набор субкомпонентов. Библиотеки, модули, классы, микросервисы — называйте как хотите.
Tiulkin
10.08.2016 20:56Вы, как соучредитель, продали бы свою квартиру, чтобы выплатить зарплату своим программистам при недостатке финансирования?
nomadmoon
Звучит как «в нашем продукте куча нетривиального кода написанного творческими узбеками, баги в котором никто не правит». На месте заказчика я бы напрягся.