Я конечно не профессиональный психолог, но у меня уже сложился некоторый опыт, который, как мне кажется, позволяет мне выделить некоторые человеческие качества, которые могут оказаться полезными для разработчика и его жизни.
Статья в целом больше для разрабов-новичков, и для опытных старожилов всё описанное будет наверное очевидно, но возможно кое-что полезное смогут перенять и они в том числе. Пишите отзывы и высказывайте свои точки зрения на эту тему, это тоже интересно будет почитать.
Исходя из моего мнения, это следующие четыре личностных качества: усердие, умение оптимизировать процессы, гибкость мышления и альтруизм.
Давайте поговорим немного о каждом из этих качеств.
Усердие
Мне кажется, это прямо больная тема нашего СНГ'шного мира. Мы разучились усердно добиваться конкретного финального результата. Это в целом как-то не по-мужски даже. Типичная проблема большинства людей: делать всё ленно и с минимальной отдачей, на 70-80% от требуемого результата, ждать "пинка" от руководства, а пока этого пинка никто не сделал — спокойно плевать в потолок. Решения, которые принимаются "на авось", без нормального анализа и аналитики.
Хуже от такого стиля жизни в первую очередь самому человеку, а во вторую — всему нашему обществу. Это касается не только программистов, это скорее вообще о всех сферах деятельности.
Я люблю говорить самому себе некоторые поговорки, которые мотивируют меня быть более усердным и ответственным, давайте я поделюсь с вами своими самыми любимыми:
- Без труда не выловишь и рыбку из пруда
- Терпение и труд — всё перетрут
- Если долго мучиться — что-нибудь получится
- Не зря говорят "Грызть гранит науки"
Я желаю всем стать более ответственными и усердными и полюбить эти личностные качества, только вместе с которыми можно создавать действительно качественные сервисы и приложения, имеющие минимальное количество ошибок и багов.
Умение оптимизировать процессы
Быть усердным чуваком — это клёво, но иногда возникает другая проблема, которая заключается в том, что такой человек начинает гнаться за невнятными цифрами и показателями вместо погони за эффективностью и скоростью получения конечного результата.
Скажем, есть люди, которые считают, что если меньше спать и больше времени проводить в работе за компьютером — то это станет показателем их превосходства, ведь это указывает на высокий уровень усердия. Но это акцентирование внимания не на тех метриках. Не так важно, сколько времени ты сидишь за компом или сколько времени ты бодрствуешь, как важно, сколько полезных дел ты успеваешь делать за определённую единицу времени.
От работы надо отдыхать, и поспать тоже полезно полноценно, ведь сон вообще является важной составляющей жизненного цикла нашего мозга, в течении которого он "сохраняет" в более глубоких слоях усвоенную в течении дня информацию в том числе.
Также хорошо отвлекаться от своей работы, чтобы она в как можно меньшей степени напоминала рутину. Я лично стараюсь работать небольшими яркими сессиями. Конечно, не всегда это получается в силу тех или иных причин, но когда получается — работа превращается в этакое драйвовое путешествие и тактичную работу над текущими багами и фичами.
Все эти тонкости жизни я хотел бы собрать в этом личностном качестве, а на последок я хочу написать от себя несколько простых советов, которые могут помочь вам начать мыслить с точки зрения оптимизации всех процессов:
- Всё что можно упростить — упростите (не забивайте мозг лишними абстакциями)
- Используйте готовые инструменты, созданные другими людьми (не изобретайте велосипеды)
- Экономьте на ресурсах и людских силах: они не бесконечные (не занимайтесь ненужными делами)
- Не забывайте про принцип DRY (Don't repeat yourself)
- Не забывайте про принцип KISS (Keep it short and simple)
Если ваше усердие объединится со стремлением оптимизировать все ваши дела — возможно, вы сможете делать всё в несколько раз быстрее, чем остальные люди, а разве это не прекрасно?
Гибкость мышления
Хорошо когда мы стремимся оптимизировать все наши процессы и дела, но ещё лучше, когда мы стремимся мыслить гибко и не боимся экспериментов и нарушения устоявшихся догматов, если видим в них зерно нерациональности.
Я сам для себя называю это качество качеством "джеки-чана". Все мы знаем, как ловко он умудрялся использовать окружающие предметы для того чтобы решать свои "проблемы", хотя предметы эти изначально вовсе и не предназначались для этого. Скажем, его фильмы наглядно демонстрируют, что рядом стоящий стул может быть очень удобно разбит о голову подошедшей слишком близко недоброжелательно настроенной персоны.
Гибкое мышление позволяет находить решения там, где люди с закостенелым и излишне "догматическим" стилем мышления приходят в уныние и бессилие. И здесь я хотел бы снова привести несколько простых советов, которые, я надеюсь, помогут вам развить в себе это качество:
- Попробуйте творчески и нестандартно решать типичные задачи
- Не зацикливайтесь на одном варианте решения проблемы
- Не бойтесь изобретать собственные решения, но при этом не забывайте анализировать мир на то, что уже было сделано другими людьми (чтобы не изобретать велосипед)
- Не бойтесь экспериментировать: попытка — не пытка
- Будьте как Джеки-Чан: используйте окружающую реальность для максимальной выгоды, не обращая внимания на то, для чего изначально предназначались те или иные предметы
Альтруизм
Это качество, которое, наверное, как вишенка на торте в личности человека. Айтишников в целом трудно упрякнуть в отсутствии альтруизма, ибо они как медики, типичные "тыжпрограммисты", зачастую бесплатно помогающие родственникам и знакомым в решении айтишных проблем.
Но всё же мне бы хотелось напомнить всем, что совместная разработка открытых проектов — это очень интересное дело, которое в том числе может развить и ваши личностные навыки. И также люди, которые успевают помогать ещё и с открытыми проектами и помогают исправлять в них баги, как я заметил, являются в целом более ценными и приятными в работе сотрудниками, которых совсем не хочется отпускать из организации.
Качество альтруиста делает из человека Человека, наверное. Оно убирает из его личности эту желчь и ненависть и добавляет ему качества сострадания, терпения и поддержки других людей.
А что если все люди начнут друг друга поддерживать в их делах? Неужели мир станет хуже от этого? Я так не думаю.
Заключение
Мы рассмотрели четыре личностных качества, которые, на мой взгляд, важны для любого разработчика: усердие, умение оптимизировать процессы, гибкость мышления и альтруизм. Как мне кажется, наличие или отсутствие этих качеств сильно сказываются на эффективности человека как современного разработчика.
И я надеюсь, что это небольшое эссе сделает людей лучше и принесёт им пользу, и я сам стараюсь следовать тому, что я написал. Спасибо за внимание и приятной разработки!
Комментарии (40)
devsolution
14.05.2018 08:53+2Автор, спасибо за статью. Она позволила пересмотреть мое текущее видение.
PMVyatkin
14.05.2018 09:00+1В идеальном мире так и есть.
В реальном мире — увы, все совсем не так. Например, случай с одного из прошлых проектов — рукотдела (РО), разработчик (Р) и техдиректор (ТД) совещаются — обсуждают новую фичу, которую можно поставить клиентам.
РО утверждает что фичу можно сделать за 2 недели, разработчик говорит что это выглядит малореальным, ТД говорит — принимайте решение, либо делаем, либо нет. РО берет под свою ответственность фичу, и они уходят.
Ценой просиженных вечеров и 4 проведенных на работе выходных — фича готова, РО — герой, который приходи с «я же говорил это реально», разработчик выкладывает резюме на НН и через 3 недели уходит в другой интегратор, усердствовать там.
Стоило ли тут проявлять усердие или надо было сразу жестко отказаться для разрабочика?saggid Автор
14.05.2018 09:06Вот кстати да, думал, добавлять или нет ещё одно качество в список, видимо надо было все-таки добавить.
Внимательность тоже важно развивать.
В статье уже написан ответ на ваш вопрос.
PMVyatkin
14.05.2018 13:22+4Хм, здесь речь не про то, что надо думать прежде чем делать.
А про то, что в современном мире важную роль играют политические игры с руководством — кто кого лучше менеджерит, кто как представляет результаты своей работы, кто ценный для компании кадр (потому что работает кое-как, но с редким стеком), а кого хоть завтра гони на мороз за одну лишь мысль о прибавке, т.к. с такими знаниями как у него людей хоть отбавляй.
Могу в целом сказать одно — надо быть на своем месте. Если вы суперкрутой ИТ-спец, не идите работать в больницу — вас там не оценят. В больнице главные врачи, и будь вы круче всех в своем городе — вы так и останетесь ненужным и незамеченным. Ищите то место, где ваши навыки востребованы.
Примеров на моем веку была масса — плохие разрабы не сумев создать нормальный код, переходили в евангелисты и очень неплохо поднимались на этой должности, очень плохой ПМ (не умел работать с высокопоставленными лицами заказчиков) перешел в саппорт и стал ИТ директором в крупной компании, плохой внедренец в одном месте стал отличным и выскооплачиваемым тестером в другом месте, миддл на Delphi ушел на джуниора на Java и через 2 года стал получать в 2,5 раза больше своих бывших коллег, работая в соседнем офисе, плохой учитель инглиша (без опыта в ИТ вообще) за 2 года стал начальником отдела аналитики в западной компании благодаря тому, что офигенно разруливал вопросы из-за отличного знания языка…
Если вы хотите достичь успеха — просто подумайте что вы можете делать хотя бы нормально, и найдите того, кто готов ценить это (и платить за это деньги).saggid Автор
14.05.2018 16:52Ну с этим вашим сообщением я вовсе и не спорю) Однако. Во всех этих вариациях развития событий способности усердно делать своё дело, оптимизировать процессы и гибко мыслить будут только увеличивать КПД человека)
yudinetz
14.05.2018 10:59Достаточно одного раза жестко настоять на своем, и тогда вас либо уволят, либо будут считаться с вашим мнением.
А чтобы не бояться увольнения, нужно постоянно ходить по собеседованиям и держать руку на пульсе.
MetaDone
14.05.2018 13:56Подобный случай отлично описан в книге Роберта Мартина — Идеальный программист. Там достаточно много уделено внимания как раз таким случаям как жестко отказать или когда следует браться за реализацию фишки. В приведенном вами примере разработчику следовало четко сказать что за 2 недели — не сделать, а за 3-4 — да, реализуемо. И никаких «если постараться то за 2 успеем»
PMVyatkin
14.05.2018 14:15Ну разраб так и сказал. На что руководитель ответил — «Я точно знаю как сделать это за 2 недели, и я уверен в этом на 100%. Это мое решение, как руководителя, ты исполнитель, делай что говорят и не лезь в менеджмент».
Дело в том, что цели участников процесса должны пострадать. В моем примере выше — цели менеджера краткосрочные, показать как он круто меняет процессы и повышает производительность команды (в краткосрочном периоде).
У разработчика же цели долгосрочные — работать в компании, где нет диких овертаймов. Поэтому он, видя что началась такая кухня, задачи то сделает, только и компанию надумает сменить.MetaDone
14.05.2018 14:32В этом и косяк — должна быть цель сделать крутой продукт. Разработчику надо было держаться до конца и говорить что если срок 2 недели то фишка не будет полностью готова и получится недоделанная и кривая. Или в процессе сказать руководителю отдела что как бы он ни хотел чуда не случится и нужно отодвигать сроки или обрезать функционал. В общем куча вариантов как обойти то что руководитель отдела захотел повыеживаться несмотря на предупреждения
PMVyatkin
14.05.2018 14:43+1Цель сделать крутой продукт всегда есть. Не всегда есть цели по срокам, бюджету, понимание того что надо сделать, система мотивации и т.д. и т.п.
В этом случае — разработчик почти ничего сделать не может. У него нет управленческих функций, на принятие решения — он не влияет (его голос совещательный и может быть проигнорирован).
Это проблема системы менеджмента, где исполнители и менеджмент находятся по разные стороны продукта вообще. Вспомните пример, когда на заводе инженер придумавший как сэкономить заводу кучу денег получал 100 рублей, его начальник — 1000 рублей, а директор завода — Ленинскую премию?
В скрам-команде — участники команды вместе решают сколько могут взять, такого минуса там нет — именно поэтому скрам-фреймворк и популярен — он почти гарантирует то, что люди сделают под чем подпишутся.
А в конкретной системе менеджмента «я начальник — ты дурак, ты начальник — я дурак» быть ответственным и исполнительным — часто не выгодно для исполнителя.MetaDone
14.05.2018 14:53+1В таком случае надо перескочить через голову с намеком что прямой руководитель не хочет прислушиваться к голосу разума и фишка будет зафейлена за 2 недели без вариантов вообще. Если же никто так и не прислушается то или со спокойной совестью делать без переработок что возможно и потом говорить «я же говорил» либо сваливать из такого места. Быть слишком исполнительным в таком случае себе вреднее, потом все сроки так и будут ставиться с учетом того что чувак в экстренном случае пропустит свои выходные и будет перерабатывать потому что ему сказали что надо
PMVyatkin
14.05.2018 18:14Увы, с переработками обычно по другому — менеджер подходит и просит «Переработай сейчас, потом сочтемся» или наиболее распространено «Мне вообще все равно сколько вы сидите, хоть не ходите на работу вообще, лишь бы были сделаны все фичи». Вроде как и не причина уходить, т.к. не перерабатывать предлагают, и вроде не постоянно, но на самом деле это первый тревожный звоночек говнеца, попахивающего неоплачиваемыми переработками.
Я это очень близко к сердцу воспринимаю, т.к. знаю лично десятки менеджеров, заставляющих, уговаривающих и вынуждающих людей к диким переработкам (овер 20-30 часов в неделю вне основного рабочего дня) и не отдавших им ничего в замен.
Krypt
14.05.2018 15:30+1На месте программиста я бы просил либо оплату сверхурочных, либо оплачиваемые отгулы. Именно для того, чтобы руководитель понимал, что такие вещи не даются бесплатно.
PMVyatkin
15.05.2018 08:51Согласен. Но, беда в том, что нечестные руководители обычно говорят — давай еще спринток, и там об отгулах поговорим и далее с этой темы соскакивает, или же дает отглул с очередным условием — «да, отгул конечно тебе положен, ты прав, но сначала заставь работать без проблем интеграцию и иди конечно»
Ну и по ТК работа в выходные дни оплачивается по двойному тарифу, отгулы же по одинарному.
zenkz
14.05.2018 20:05+1Ну в данном случае разработчик уходит от руководителя-карьериста (РО) и правильно делает. С усердием это ни как не связано. Любые оценки должны быть обоснованы и к ним должно быть добавлено 25-30% на риски и баги. А если руководитель готов брать «под свою ответственность» чужую работу, то пусть идёт работать в госслужбу — там таких любят…
В нормальной команде эта ситуация выглядит так: Разработчик предоставляет оценку на фичу и эта оценка обсуждается (аргументировано). Если фича не влазит по времени или бюджету, то либо она убирается, либо режется часть функционала. (Вот тут вступает в игру РО, чтобы оградить своего разработчика от овертаймов, но в то же время реализовать пожелания). Т.е. РО и разработчик должны играть на одной стороне поля…PMVyatkin
15.05.2018 08:52Не могу не согласится, в нормальных компаниях так и есть. Но в множестве других практикуется принцип — «мне пофигу сколько вы тратите на работу, лишь бы она была сделана», где якобы люди (не на руководящих позициях, и это важно!) уходят от работы по часам к результату (считай, свой бизнес открывают с ответственностью).
zenkz
15.05.2018 17:42Я тоже сторонник работы на результат, а не лишьбы 8 часов в день отсидеть, но тут вопрос в том, что принцип: «мне пофигу сколько вы тратите на работу, лишь бы она была сделана», не означает отсутствия планирования и оценок. Это отично работает когда и руководители и подчинённые адекватные, но, к сожалению, это часто трансформируется в забивание на работу со стороны подчинённых или установлением заведомо неисполнимых сроков со стороны руководителя.
PMVyatkin
16.05.2018 13:05Я думаю что любой адекватный человек — сторонник работы на результат. Но есть нюансы — результат не всегда очевиден в среднесрочной и долгосрочной перспективе, платят тебе все таки не за результат (зарплата — это продажа часов, а не прибыль с результата).
И тут в ход идет умение нормального менеджера договариваться и контролировать. Вкратце — сотрудник спокойно работает 8 часов (и задача менеджера — контролировать что он работает это время а не валяет дурака).
Если же у сотрудника возникает необходимость поработать больше 8 часов — это согласовывается (!), и переработки фиксируются. Если же человек остался на часок поковырять код в удовольствие, или же потому что сам так считает нужным (например для развития себя) — это тоже нормально.
Далее, периодически, переработки считаются и обмениваются на деньги/отгулы.
И это нормально. А ненормально — договариваться с людьми при выдаче оффера на 8 часов, а затем используя менеджерские приемы заставлять их работать больше (значительно больше) бесплатно, лишая сотрудников времени на развитие и дальнейшего карьерного и финансового роста.
firedragon
14.05.2018 20:50Самуил Маркович, Вы сильный, Вы справитесь! — Яша, я — умный, я даже не возьмусь!
greabock
14.05.2018 10:16+4Ну нормальные же технические статьи писали. А тут вот это…
saggid Автор
14.05.2018 10:24+1Одно другому не мешает, технические никуда деваться не собираются, и вчера кстати я запостил сразу две статьи, эту и "техническую") Я считаю что важно объяснить и эти моменты, в особенности новичкам. Как там ваш ларавел-коллектив кстати поживает?) Сто лет не видел вас, не общался.
greabock
14.05.2018 11:47Довольно разрозненно. «Старички-активисты» получили, что хотели, прокачались, и теперь каждый занят своим делом, в основном. Новички в большинстве своем слабоваты и/или не очень активны. SerafimArts сейчас пилит graphql-фреймворк на php — получается неплохо.
vmm86
14.05.2018 10:27+3Я люблю говорить самому себе некоторые поговорки, которые мотивируют меня быть более усердным и ответственнымwing_pin
14.05.2018 11:11+4Сударь, вы стали жертвой ошибки выжившего. Во многих случаях усердие приводит к отрицательному результату. Вместо того, чтобы в определенный момент отбросить неудачное решение и попробовать новое, человек продолжает усердно трудиться над мертвым решением. Альтруизм в свою очередь приведет разве что к успеху твоего руководителя. Так что все очень спорно.
saggid Автор
14.05.2018 11:18+1Опять про усердие… В статье всё расписано на эту тему, почитайте внимательно пожалуйста. Текста-то всего ничего.
lxsmkv
14.05.2018 15:50Я бы добавил «умение видеть работу», целеустремленность, упорство.
Именно упорство нужно чтобы превозмогать трудности. Так же и трудности в постижении нового. Когда ты не бросаешь после десяти попыток, а делаешь еще пять.
Целеустремленность нужна, чтобы видеть конечную цель. Не отдельный участок работы, а конечный результат всей твоей деятельности. Чтобы отличать когда твоя работа двигает проект вперед, а когда ты съехал не в том направлении или топчешься на месте.
А усердие, оно само по себе ведь такое… Можно сильно «потеть», без промедления хвататься за любую задачу, но при этом в итоге совершать бесполезную работу.
potan
14.05.2018 16:21«Хуже ленивого дурака только дурак усердный.»
Очень тоскливо поддерживать код, написаные по принципу «терпение и труд все перетрут». Конечно, проевив должное усердие, с помощью «грузиков и противовесиков» можно заставить работать любую систему. Но всем будет лучше, если так делать не будут. Уердие хоошо только если идет в паре с профессионализмом, иначе вреда будет гораздо больше, чем пользы.
2PAE
15.05.2018 08:01Если вы пытаетесь играть на поле психологии, то уточните термины. Нет такой сущности как «усердие». Есть сущность «мотивация».
К примеру, люди дышат всю жизнь. При этом, обычно не прилагают к этому никаких усилий. Так как люди охуенно замотивированны на это! Не будешь дышать, сдохнешь. Обратите внимание на своё дыхание, какое оно у вас в этот момент. Спокойное, мерное, глубокое, поверхностное, прерывистое, затруднённое, быстрое, медленное? Думаю пол минуты назад вы и не задумывались об этом. Если задумывались, то у вас проблемы со здоровьем и надо что-то делать.
Конечно при беге на 100 метров человек дышит активно и прилагаю массу дополнительных усилий. Когда человек стреляет из винтовки, то наоборот задерживает дыхание и опять прикладывает дополнительные усилия.
Но и тот и тот случай, скорее исключение из правил, чем ежедневная деятельность большинства людей.
Если вам приходится постоянно прилагать дополнительные усилия для выполнения ежедневной деятельности, значит у вас низкая мотивация к данной деятельности. Поэтому не надо придумывать «усердие», а надо работать с мотивацией.
Отчего у вас низкая мотивация и нужны дополнительные усилия? Это отдельный вопрос.
В среднем по больнице, мотивация низкая, так как зачастую вложенные усилия не ведут к заметным изменениям.
Многие руководители хотят что-бы работники работали лучше и больше, но не желают вознаграждать людей за труд.
А так как закон сохранения энергии ещё никому не удалось нарушить, мне по крайней мере об этом не известно, из ничего — ничего и получается.saggid Автор
15.05.2018 08:27Ну как тут сказать. Психология психологией, я согласен что в целом вещь важная, но про мотивацию тоже есть забавный троллинг от какого-то мужика.
Мне вот тоже как-то не надо ни книги читать, ни курсы по мотивации проходить, чтобы быть замотивированным в том, чтобы быть усердным. Мне просто на каком-то этапе жизни надо было понять, что без усердия многое пропустишь и мало сделаешь. Вот и всё. Теперь я стараюсь быть усердным, а не валяться на диване целый день и плевать в потолок. Наверное, можно сказать, что это и есть моя мотивация. И в какой-то степени я сейчас этой статьей постарался замотивировать остальных.
Короче, не надо так к словам придираться, и не думаю что если я там слово "мотивация" нигде не упомянул, то я никого ни в чём сегодня не замотивировал)
2PAE
15.05.2018 12:02Использование точной терминологии, повышает эффективность коммуникации. В свою очередь использование не однозначных терминов, ведёт к «размыванию» эффективности.
Исходя из словарей, слово усердие это положительный термин. Исходя из отношения комментаторов, скорее отрицательный.
А так как смысл коммуникации заключается в той реакции которую она вызывает, то Ваш безусловно положительный порыв вызвал скорее отторжение, чем принятие.
Так же, усердие это результат, мотивация причина. Если есть проблема, то решать надо причину, а не бороться с результатом.
Простой пример из возможно знакомой вам области. SQL сервер. База данных. Тормозит. Что делать?
Борьба с результатом, это повышение частоты процессора -ров, увеличение объёма ОЗУ, перенос системы на SSD. И не факт что проблема будет решена.
Борьба с причиной, это оптимизация SQL запросов к базе данным. Есть вероятность что проблема будет решена без изменения текущей конфигурации сервера.
Ну и так далее.
В общем пока отсутствие усердия «прямо больная тема нашего СНГ'шного мира» будет решаться через борьбу с результатом, всё будет как и было.
Хотя… Теперь с новым президентом и новым премьер министром, всё изменится! Ух заживём!!!saggid Автор
15.05.2018 12:05Я ваш посыл понял ещё в вашем первом сообщении, спасибо за разъяснения. Своё мнение о "мотивации" я тоже разъяснил, надеюсь что и вы меня поняли. Спасибо.
saggid Автор
15.05.2018 12:36Я бы наверное так сказал: мотивация — это отдельная большая тема, и она как раз не является неким "личностным качеством" человека. Скажем, вы можете легко увидеть разницу между ленивым и усердным персонами, если посадите их работать над одним проектом. Можно будет увидеть, что в одних и тех же условиях один делает больше, а другой делает меньше. Вот и вся метрика, как-бы. Я писал об этом.
А мотивация — это дело полезное в целом, да. В том смысле, что хорошо если руководитель стремится замотивировать своих сотрудников премиями и справедливой оценкой их труда. Но это тема отдельная и в рамки этой статьи не входит) Надеюсь вы поняли меня.
Tepex
Как тут не вспомнить 3 добродетели программиста по мнению Ларри Уолла: «Laziness, Impatience and Hubris».
lightman
Hubris — высокомерие (кому лень гуглить)
TrigovorTosh
Помоему, в оригинальном переводе (не помню чьём), «Hubris» — это «Гордыня».
selfoss
Что, конечно, радикально все меняет