Comments 88
UFO just landed and posted this here
Чур я — диктор!
Я — Вячеслав Петрович
Я тогда плод какой-то странной любви между Сережей и Петей.
Я что-то между Серегой и Антоном.
А меня здесь нет. Хехе. Я пишу быстро, хорошо, по теме и современно. И при этом стараюсь не переусложнять.
Так что статья не про меня. И не увы. ))
PS: и на работе пишу код рабочего проекта.
Так что статья не про меня. И не увы. ))
PS: и на работе пишу код рабочего проекта.
Заметно, как вы на работе в понедельник в 10:52 утра пишете код рабочего проекта.
Мне не нравится Ваш сарказм. Но если у Вас лично есть конкретные претензии к качеству и количеству моего кода, прошу высказать их прямо.
UFO just landed and posted this here
Рано или поздно многие хорошие программисты, независимо от задачи становятся Петями. Так как у каждого из нас появляются свои идеи, которые охота воплотить больше, чем задания данные начальством.
Ваш топик добра поборол мою лень. Хватит на час.
Вообще описанное в топике относится не только к программистом. Любой человек которому безразлична его работа будет выполнять ее хуже того, кому она не безразлична.
Безразличие это страшно и пожалуй во всех сферах, не только в программировании и наверное даже не только применимо к работе а вообще глобально.
Безразличие это страшно и пожалуй во всех сферах, не только в программировании и наверное даже не только применимо к работе а вообще глобально.
Любой человек которому безразлична его работа будет выполнять ее хуже того, кому она не безразлична.
Только при прочих равных.
А то, что более мотивированный будет делать активнее менее мотивированного, — не открытие. И тем не менее, более активно ещё не значит, что лучше.
Ответ на оба вопроса — пох. Я бы не брал на работу людей, которые говорят — важно. Видимо это джуниоры.
Представьте себе работающего программиста, который говорит, что ему крайне важно, чтобы контора получала больше бабла с помощью его кода. Кода — какого-нибудь управления предприятием. Наверное, человек неадекватный.
Мне лично совершенно не важны задачи, которые ставит перед собой контора. Деньги, которые получаю, тоже не главный мотив. Мне просто нравится сам процесс программирования. Говорить, что важен позарез результат — вранье. Сомневаюсь, что даже даст мне какой-то новый опыт. Но интересно просто так развивать проект. В том числе, за более короткий срок создать более лучший код
Представьте себе работающего программиста, который говорит, что ему крайне важно, чтобы контора получала больше бабла с помощью его кода. Кода — какого-нибудь управления предприятием. Наверное, человек неадекватный.
Мне лично совершенно не важны задачи, которые ставит перед собой контора. Деньги, которые получаю, тоже не главный мотив. Мне просто нравится сам процесс программирования. Говорить, что важен позарез результат — вранье. Сомневаюсь, что даже даст мне какой-то новый опыт. Но интересно просто так развивать проект. В том числе, за более короткий срок создать более лучший код
Представьте себе работающего программиста, который говорит, что ему крайне важно, чтобы контора получала больше бабла с помощью его кода. Кода — какого-нибудь управления предприятием. Наверное, человек неадекватный.
Наверное, я неадекватный. Мне важно, чтобы фирма зарабатывала больше денег. С помощью моего кода и прочих разработок — в том числе (правда, код последнее время — не совсем управления предприятием, а всего лишь автоматизации части производственного процесса). Потому что тогда у нас появится возможность идти дальше, к новым интересным разработкам. А кроме того, там мне какие-то акции обещали...
Ну да, ну да )))))
Бывают результаты, а бывает процесс достижения результатов. Я ни в грош не ставлю людей, которые только стремятся к результату. Но не любят процесс. Таких миллиарды и они результатов не достигают )))
Да, я болею за проект. Как одна из интересных задач для меня — это сэкономить конторе деньги посредством скорости и качества написания кода, а также соответствования требованиям. Но это просто увлекательный процесс для меня. Не более. Всяким обещаниям премий, акций и чего-то еще в будущем — я давно не верю. Просто договариваюсь о стабильной устраивающей зарплате.
Бывают результаты, а бывает процесс достижения результатов. Я ни в грош не ставлю людей, которые только стремятся к результату. Но не любят процесс. Таких миллиарды и они результатов не достигают )))
Да, я болею за проект. Как одна из интересных задач для меня — это сэкономить конторе деньги посредством скорости и качества написания кода, а также соответствования требованиям. Но это просто увлекательный процесс для меня. Не более. Всяким обещаниям премий, акций и чего-то еще в будущем — я давно не верю. Просто договариваюсь о стабильной устраивающей зарплате.
Ну так верить не надо, а заключать соглашения наверное. Что-то было про это здесь на хабре про дерьмовые стартапы.
Для одних важен результат. Для других процесс. Это, кажется, связано с психологической вертностью. И не имеет никакого отношения к успешности. Кто-то осуществляет процесс, чтобы достичь результата, а кто-то достигает результата осуществляя процесс. В этом вся разница.
А мне нравится красота. Красота во всем — в выбранном инструментарии, в постановке задач и структуре пользовательского интерфейса, в структуре модулей системы и в самом коде. Некая гармония.
В начале своей карьеры пытался работать программистом в банке. Настолько тошно стало от содержания труда, что через 3 дня бросил.
В начале своей карьеры пытался работать программистом в банке. Настолько тошно стало от содержания труда, что через 3 дня бросил.
У меня другая модель. Я изначально считаю, что мы занимаемся очень плохими делами. Никакой красоты, никакой эстетики. И оценка, что лучше или что хуже исходит из этого. Т.е. лучше то, что меньше приносит вреда.
Каждая строчка кода — это зло. Это увеличение энтропии. Хаос растет.
Вот пример. Мне недавно дали задачу — оптимизировать код. Код делает некоторые сложные вычисления и обрабатывает много данных. Работает верно, но сутки. Надо было ускорить.
Делал. Как обычно. Сначала переписал код на нормальный язык программирования. Потом нашел узкое место, которое дало ускорение на порядок. Потом код оброс классами, скрывающими некоторую логику, не относящуюся к задаче напрямую. Вроде всё хорошо. Но главный алгоритм так и остался — циклы на пару страниц. 5 отдельных шагов с циклами. Код читается скверно. Оно и понятно. Надо выделять методы. Выделил. При этом общался плотно с заказчиком и выяснил, что и как лучше назвать, что каждый шаг делает.
Теперь, вроде, код разбит на куски, каждый кусок не очень большой. Но код стал более читаемый? Отнюдь! Теперь главный цикл состоит из вызовов пяти методов. И как только мне нужно что-то понять или далее подумать как оптимизировать, мне проще открыть старый код, когда всё было в одном методе. Почему код не стал более понятным? Потому что я его не упростил, разбивая на методы. Я его усложнил. Потому что ввел новые понятия, которых до этого не существовало — имена методов.
И с одной стороны нельзя не разбивать код, потому что внимание не может следить за многими объектами одновременно, и с другой стороны разбиение не добавляет ясности, кроме случаев, когда новые введенные понятия (имена методов, например), не являются совсем новыми, а хорошо известны из жизни. Часто так бывает? Нет.
Где же гармония? Всё, что ни делалось — всё хаос. Ничего с этим не возможно поделать. Наша задача — только находить баланс в коде и минимизировать субъективно сложность.
Работать программистом в банке — наверное может и затошнить. Но и нет вообще нигде отрасли в программировании, как мне кажется, где была бы красота и романтика. Красоту ощущают новички, которые только первый раз сталкиваются с какой-то проблемой и ее решением. Тогда они испытывают нечто платоновское — удивление и радость познания.
Каждая строчка кода — это зло. Это увеличение энтропии. Хаос растет.
Вот пример. Мне недавно дали задачу — оптимизировать код. Код делает некоторые сложные вычисления и обрабатывает много данных. Работает верно, но сутки. Надо было ускорить.
Делал. Как обычно. Сначала переписал код на нормальный язык программирования. Потом нашел узкое место, которое дало ускорение на порядок. Потом код оброс классами, скрывающими некоторую логику, не относящуюся к задаче напрямую. Вроде всё хорошо. Но главный алгоритм так и остался — циклы на пару страниц. 5 отдельных шагов с циклами. Код читается скверно. Оно и понятно. Надо выделять методы. Выделил. При этом общался плотно с заказчиком и выяснил, что и как лучше назвать, что каждый шаг делает.
Теперь, вроде, код разбит на куски, каждый кусок не очень большой. Но код стал более читаемый? Отнюдь! Теперь главный цикл состоит из вызовов пяти методов. И как только мне нужно что-то понять или далее подумать как оптимизировать, мне проще открыть старый код, когда всё было в одном методе. Почему код не стал более понятным? Потому что я его не упростил, разбивая на методы. Я его усложнил. Потому что ввел новые понятия, которых до этого не существовало — имена методов.
И с одной стороны нельзя не разбивать код, потому что внимание не может следить за многими объектами одновременно, и с другой стороны разбиение не добавляет ясности, кроме случаев, когда новые введенные понятия (имена методов, например), не являются совсем новыми, а хорошо известны из жизни. Часто так бывает? Нет.
Где же гармония? Всё, что ни делалось — всё хаос. Ничего с этим не возможно поделать. Наша задача — только находить баланс в коде и минимизировать субъективно сложность.
Работать программистом в банке — наверное может и затошнить. Но и нет вообще нигде отрасли в программировании, как мне кажется, где была бы красота и романтика. Красоту ощущают новички, которые только первый раз сталкиваются с какой-то проблемой и ее решением. Тогда они испытывают нечто платоновское — удивление и радость познания.
Это все можно назвать одним словом — ответственность.
Человек, которому не по-барабану итог своей работы,… Получить хороший результат от человека, которому наплевать на этот результат, нельзя будет никогда.
— — Мысль в посте в целом верная, но… все же «по барабану» из приведенных примеров здесь только Коле.
Всем остальным (включая Машу) итог работы НЕ по барабану, просто у них СВОЯ точка зрения на то, каким он должен быть. Не зря же Славик пишет понятный код, а евгений хочет переписать код на правильные языки, а антон использует паттерны, маша вот тоже старается хоть и не догоняет, а сергей так вообще в одиночку может свернуть такие горы которые 3 других прогера в команде не свернут.
Самое любопытное, что все они хорошие программисты. Так же как хорош молоток, отвертка, дрель. Плох тот, кто молотком начинает завинчивать шурупы пихая сергея в команду, вешая на машу одиночный проект, запивая в евгения горящий проект и так далее.
— — Мысль в посте в целом верная, но… все же «по барабану» из приведенных примеров здесь только Коле.
Всем остальным (включая Машу) итог работы НЕ по барабану, просто у них СВОЯ точка зрения на то, каким он должен быть. Не зря же Славик пишет понятный код, а евгений хочет переписать код на правильные языки, а антон использует паттерны, маша вот тоже старается хоть и не догоняет, а сергей так вообще в одиночку может свернуть такие горы которые 3 других прогера в команде не свернут.
Самое любопытное, что все они хорошие программисты. Так же как хорош молоток, отвертка, дрель. Плох тот, кто молотком начинает завинчивать шурупы пихая сергея в команду, вешая на машу одиночный проект, запивая в евгения горящий проект и так далее.
Обычно об этом не задумываются.
А у Вас задача, наверное, была вручить именную кружку как на картинке: "
Вот тут и понеслось…
А у Вас задача, наверное, была вручить именную кружку как на картинке: "
<name> За вклад в проект"?Вот тут и понеслось…
кроме мании величия, предельного алкоголизма и меланхолии по осени, никаких малоприятных мелочей и нет вовсе :D
«Славик пишет исключительно простой и понятный код, избегая всего нового и навороченного. И в итоге не использует ничего из достижений программной индустрии последнего десятилетия.»
А простой и понятный код противоречит требованию использовать достижения последнего десятилетия?
А простой и понятный код противоречит требованию использовать достижения последнего десятилетия?
А это Сергей Петрович, он руководит группой разработчиков. Ему надо правильно выстроить команду и замотивировать каждого программиста. Для этого он…
Для разных задач может потребоваться различный «хороший программист».
Где-то нужен Сергей, если проект можно вести в одиночку.
Где-то нужен Коля, который будет идеально писать программу, которая будет работать там, где от программы зависят жизни людей.
Где-то без Маши не обойтись, поскольку нужен технически подкованный менеджер, который сможет убедить клиента, что САП это круто, 1С говно (или наоборот).
А где-то в крупной компании пригодится и Петя, который будет генерировать нечто интересное
и т.д.
Где-то нужен Сергей, если проект можно вести в одиночку.
Где-то нужен Коля, который будет идеально писать программу, которая будет работать там, где от программы зависят жизни людей.
Где-то без Маши не обойтись, поскольку нужен технически подкованный менеджер, который сможет убедить клиента, что САП это круто, 1С говно (или наоборот).
А где-то в крупной компании пригодится и Петя, который будет генерировать нечто интересное
и т.д.
Правильно делают, что ничего не делают, если зарплату и так начальство платит.
Выходит, начальство — не начальство.
Выходит, начальство — не начальство.
Черт. А я — Петя. Реально. Петя.
Можно было короче: «в любом деле самое важное — мотивация».
И добавить к этому «мотивация деньгами — одна из самых неэффективных, но очень часто у сотрудника нет ничего, кроме неё».
И вздохнуть печально.
Посмотришь на то как нынче т.н. «стартапы» как доткомы до краха растут аки грибы после дождя — так тут же и вспоминаешь, что слишком многое делается не чтобы пользоваться, а чтобы продавать(ся). А раз так, то о какой истинной мотивации речь может идти «в общем случае»? Остаётся лишь удивиться и порадоваться редким исключениям.
И добавить к этому «мотивация деньгами — одна из самых неэффективных, но очень часто у сотрудника нет ничего, кроме неё».
И вздохнуть печально.
Посмотришь на то как нынче т.н. «стартапы» как доткомы до краха растут аки грибы после дождя — так тут же и вспоминаешь, что слишком многое делается не чтобы пользоваться, а чтобы продавать(ся). А раз так, то о какой истинной мотивации речь может идти «в общем случае»? Остаётся лишь удивиться и порадоваться редким исключениям.
мотивация деньгами — одна из самых неэффективных
А подтверждение исследованиями есть? Насколько я могу видеть — такая мотивация одна из самых эффективных, только затратная :)
Есть завод. было 3 логиста (перевозки) они брали откаты ставя те машины которые больше заплатят, а не более подходящие и была у них зарплата 15 тыс… подняли до 30 затем 50 потом 80…
Мне кажется подними им зарплату даже до 500 тыс они бы делали то же самое. Закончилось это тем что их уволили взяли новых и стали платить 15.
Мне кажется подними им зарплату даже до 500 тыс они бы делали то же самое. Закончилось это тем что их уволили взяли новых и стали платить 15.
Э-э, а откаты не мотивация деньгами? Или откаты пренебрежимо малы с зарплатой в 80, не говоря о 500?
15 тыс… подняли до 30 затем 50 потом 80…
Вы не указали прибыль от откатов, по этому сказать сложно… У меня брат подобным грешил. Спросил его на сколько откаты превышают зарплату — примерно в 20 раз. А вы повышали в 2-5 раз. Вот они и не держались за такую зарплату.
Речь идет о простом профессионализме.
Встречал все типы людей из этой статьи.
Встречал все типы людей из этой статьи.
Здравствуйте, я — Коля, но хочу быть Петей.
«Хороший программист» — это зайка, милашка, думает только о хорошем, добром…, и ни когда не думает о плохом, ведь о плохом думают только «Плохие программисты».
Если человеку действительно важно и нужно, то, что он делает — всё остальное по-большому счету можно игнорировать.
Концепция красивая, но лично видел больше одного опровержения. Когда человеку действительно важно то, чем он занимается, он много работает, старается изучать что-то новое — но у него плохо получается. Это примерно как если человеку очень важно рисовать, он регулярно рисует — но он не умеет рисовать O_O. Безусловно, при большом желании он вытянет с любого уровня до среднего, но со сложными задачами всегда будут проблемы.
Хороший
Евгений наоборот порывается выбросить 90% существующего решения и за каких-то смешных пару лет переписать всё на Haskell/Lisp/Prolog
…
а Славик с Евгением — вернуться в реальность и начать, наконец, делать что-то нужное правильными инструментами.
А кто решает-то, что такое правильные инструменты? Если вы, конкретно, не умеете, не понимаете как с ними работать, то это проблемы не Жени и Славы.
А вот дали бы Славе с Женей написать на Haskell, это ваше спагетти 20 летней давности…
В коммерческой разработке — рынок решает. Масса факторов, связанных с бюджетом проекта, сроками, стоимостью поддержки, стоимостью специалистов, их доступностью и т.д.
Переписать все на Haskell — оправдано только тогда, когда это экономически целесообразно с учетом всего выше перечисленного хотя бы в среднесрочном периоде. А не тогда, когда это «правильно».
Переписать все на Haskell — оправдано только тогда, когда это экономически целесообразно с учетом всего выше перечисленного хотя бы в среднесрочном периоде. А не тогда, когда это «правильно».
Вы правильно отметили, что рынок решает. Если это даже экономически целесообразно переписать силами 3х умных прогов ПО, наймут 30 просторабочих потому что они доступнее и проще заменимы, при этом поддержка проекта будет расти экспоненциально. И вот это как раз неправильно как экономически так и с технической точки зрения, в долгосрочной перспективе.
Однако, есть менеджмент, который весь конструктив от Жени слушать не будет, для них это эзотерика. Я сталкиваюсь с таким постоянно, но после того как дав переписать хотя б 10% проекта и увидев результат начинают задумываться.
С аргументом, что через 2 года, переписанный проект будет похож на старый, не соглашусь. Суть последних достижений ПО, как раз в поддержке наукой, теория категорий в основе Haskell дает опр. степень прогнозируемости и анализа. А языки написанные школьниками рассчитаны на решение сиюминутных задач.
«Мы наймем еще 2х программистов и проект пойдет в 2 раза быстрее» из классиков, Брукс.
Однако, есть менеджмент, который весь конструктив от Жени слушать не будет, для них это эзотерика. Я сталкиваюсь с таким постоянно, но после того как дав переписать хотя б 10% проекта и увидев результат начинают задумываться.
С аргументом, что через 2 года, переписанный проект будет похож на старый, не соглашусь. Суть последних достижений ПО, как раз в поддержке наукой, теория категорий в основе Haskell дает опр. степень прогнозируемости и анализа. А языки написанные школьниками рассчитаны на решение сиюминутных задач.
«Мы наймем еще 2х программистов и проект пойдет в 2 раза быстрее» из классиков, Брукс.
Всё верно, хороший программист, работат над любым проектом — как над своим.
Почитал — даже вас как-то жалко стало. Может вам хороших подсунуть посоветовать?
Правда едят много ;-)
Правда едят много ;-)
Это называется «мотивация». Нормальным HR/PM и прочим хорошо известно, что мотивация заменяет собой многое (хотя бы в том смысле, что при наличии мотивации опыт, знания и навыки можно приобрести), а ещё поддержание — одна из самых важных обязанностей любого начальника.
Начинал свой путь разработчика я как Коля, а теперь я Вася.
Повысьте Васе и Коле зарплаты до рыночного уровня и выше, чтобы им стало интересно работать на вашу компанию — и они стали больше времени тратить на ваши проекты.
Прекрасно знаю обоих, Вася — замечательный код в кучей open source проектов, признанный лидер, участник и докладчик многих конференций. Коля — по ночам работает удаленно на американскую компанию, в офисе просто отсыпается и отдыхает.
Такой вот альтернативный взгляд на то, как на самом деле все происходит.
Прекрасно знаю обоих, Вася — замечательный код в кучей open source проектов, признанный лидер, участник и докладчик многих конференций. Коля — по ночам работает удаленно на американскую компанию, в офисе просто отсыпается и отдыхает.
Такой вот альтернативный взгляд на то, как на самом деле все происходит.
К сожалению, даже свой проект может стать неинтересным через какое-то время.
Господа, позвольте мне поимпровизировать! Давайте поэкспериментируем, взглянем на наших персонажей, скажем так, немного шире, попробуем узнать некоторые их черты получше:
Василий не работает на результат с точки зрения разработки, зато его качества позволяют ему быть душой компании. Василий хорошо воспитан, у него хорошие манеры, он интеллигентен, с ним интересно поболтать на разные темы, у него великолепная семья, которой могут позавидовать многие его коллеги, прекрасные дети и в жизни все предельно стабильно и позитивно. Он испытывает искреннее удовольствие, формируя вокруг себя гармоничный мир. В целом он окружен позитивом и любовью близких людей.
Петр работает усердно, но чаще не над тем, что требуется по проекту. Он усидчив, но его мысли нестабильны, он переключает контекст слишком часто, он реализует то, что ему искренне хочется воплотить в реальность, и что он считает наиболее интересным. Петр полностью поглощен необходимостью самореализации через воплощения собственных идей. Его богатый и сложный, в отличие от большинства коллег, внутренний мир полностью захватывает его воображение. Петр пробует различные идеи, он пробует все новые и новые подходы и в конечном счете это позволяет ему накопить такой пласт опыта из его собственных экспериментов, что в определенный момент времени он понимает свою абсолютную самодостаточность в успешной реализации собственных идей. Он счастлив осознавать этот факт, ему нет равных в импровизации, в творческом подходе. В конечном счете Петр понимает, что существует целый мир нереализованных возможностей, и когда ему становится скучно выполнять рутину, он уходит из компании и начинает свой успешный стартап.
Николай выполняет все очень четко, он тщательно размышляет над необходимым и достаточным, он крайне щепетильно относится к любому решению. Николай очень много думает, прогнозируя исход, прежде чем совершить действие. В уме Николай выстраивает настолько сложные модели, что практическая реализация является при таком подходе лишь побочным эффектом этого сложнейшего процесса моделирования. Иногда Николай впадает в своего рода мысленную рекурсию и проворачивает одни и те же мысли десятки раз, снова и снова взвешивая возможные погрешности. Николай предельно внимателен в исполнении, в отличие от своих коллег, его ум обладает ювелирной точностью. Он не умеет импровизировать так как это делает Петр, но он способен смоделировать ситуацию настолько глубоко, что это позволяет ему видеть на десять шагов вперед не допуская лишних ошибок и соблюдая абсолютную точность. Николай не начинает действовать, пока не убедится, что это единственно правильное и наиболее оптимальное решение.
Сергей не коммуникативный, в меру замкнут. Он истинный интроверт, его сознание инкапсулируется от внешнего мира, полностью погружая Сергея в разработку алгоритмов. Сергей в одиночку способен спроектировать сложнейшие вещи, он не нуждается в делегировании частей и синхронизации. Он мастер, он один из умнейших разработчиков среди коллег. Сергей вполне способен разработать механизм, реализация которого займет времени больше, чем какие-либо разумные пределы. С ним сложно найти общий язык, но если он говорит, то каждое его слово и фраза несут глубокий смысл, передавая такой объем информации, что остальным потребуется время, чтобы осмыслить о чем вообще идет речь.
Мария не умеет программировать, она с трудом вникает в хитросплетения логики алгоритмов, но она настолько коммуникативна и открыта для окружающих ее людей, что стала для всех источником неисчерпаемой энергии, лучшим собеседником, человеком, который никогда не скажет, что ему не интересно выслушивать чьи-то переживания, люди готовы делиться с ней своими эмоциями. Мария весьма счастлива быть настолько общительной, у нее огромное множество друзей, у нее практически не бывает моментов, когда она чувствует себя одинокой и забытой всеми, как это бывает у Николая и порой у Сергея.
Антон чрезмерно усложняет код перегружая его применением паттернов. Его подход основан на применении приобретенных им знаний о стандартных вариантах решения. Антон не любит экспериментировать, он не любитель поиска оптимальных решений. Он предпочитает применять стандартные в его понимании методы, которые позволяют решать ему любые задачи. Антон складывает механизмы из однотипных блоков, его мышление уже давно абстрагировалось от низкоуровневой реализации. Антон способен быстро и просто формировать масштабные пласты логики, не задумываясь над архитектурой, используя лишь простые паттерны. Антону неизвестны проблемы с выделением слоев абстракции, он оперирует кодом на другом уровне. Он не прилагает особых усилий, ему нравится такой подход решения всех вопросов.
Славик пишет настолько лаконично, что уровень вхождения в построенные им логические модели очень низок. Новички сходу понимают что делает его код, в отличие от оверинжиниринга кода Антона. Славик иногда действует не эффективно, он расписывает все черезчур простыми конструкциями, не использует высокоуровневые абстракции, поэтому работает в целом не очень продуктивно, но его простые решения помогают быстрее въехать в суть дела. Со Славиком общаются все junior разработчики, для них он верный друг и помощник.
Евгений знает множество средств, он прекрасно понимает задачи и перспективы проекта и может трезво оценить еще на самом раннем этапе необходимость и возможность корректировки курса развития, пока затраты еще позволяют исправить ситуацию. Евгений весьма дальновидный разработчик, его познания обширны, коллеги часто советуются с ним как со стратегом, он знает свое дело, хотя и не лишен определенной доли оптимизма, а, возможно, в некоторой степени максимализма. Евгений любит иногда пообщаться с Сергеем, они находят общий язык, рассуждая о чем-то запредельном для Славика и ненужном для Антона.
…
Несмотря на то, что все персонажи вымышлены, они весьма напоминают многих героев из реальной жизни своими чертами характера. Существующая проблема в невозможности эффективного выполнения проекта иллюзорна, она сформирована абсолютным непониманием людей друг друга, это критично по одной простой причине — все структуры имеют определенную вертикаль власти, которая не позволяет людям занять оптимальное положение в социальной структуре в рамках организации. Люди неэффективны лишь потому, что их заставляют делать то, к чему они не предрасположены. Сложно закручивать ложкой шурупы. Собирая команду, необходимо обладать определенными качествами дальновидности Евгения, интеллектом Сергея, аккуратностью Николая, коммуникативностью Марии и учтивости Василия. При всем при этом, необходимо уметь доносить до своих коллег информацию также доступно, как Славик, при этом не изобретая велосипедов, а используя для организации процесса работы своей команды уже обкатанные временем паттерны, подобно подходу, используемому Антоном. И самое главное — необходимо обладать творческим подходом Петра, уметь быстро менять контекст, чтобы эффективно реагировать на малейшие изменения в хрупком балансе социальной системы и мгновенно реагировать на это.
Мы все люди, мы все разные, и потому у всех нас огромное разнообразие интересов. Собрать команду людей, которые были бы одновременно сильно заинтересованы в реализации проекта — на мой взгляд, утопия. Куда важнее, проанализировать и выделить в задаче моменты, интересные тем людям, которые будут иметь к ней непосредственное отношение. В этом и заключается своего рода искусство, искусство адаптировать задачу под совокупность людей ее исполняющих.
Мы все умеем отдавать приказы, но крайне малое количество из нас умеет проектировать социальные структуры и взаимодействия в них.
Василий не работает на результат с точки зрения разработки, зато его качества позволяют ему быть душой компании. Василий хорошо воспитан, у него хорошие манеры, он интеллигентен, с ним интересно поболтать на разные темы, у него великолепная семья, которой могут позавидовать многие его коллеги, прекрасные дети и в жизни все предельно стабильно и позитивно. Он испытывает искреннее удовольствие, формируя вокруг себя гармоничный мир. В целом он окружен позитивом и любовью близких людей.
Петр работает усердно, но чаще не над тем, что требуется по проекту. Он усидчив, но его мысли нестабильны, он переключает контекст слишком часто, он реализует то, что ему искренне хочется воплотить в реальность, и что он считает наиболее интересным. Петр полностью поглощен необходимостью самореализации через воплощения собственных идей. Его богатый и сложный, в отличие от большинства коллег, внутренний мир полностью захватывает его воображение. Петр пробует различные идеи, он пробует все новые и новые подходы и в конечном счете это позволяет ему накопить такой пласт опыта из его собственных экспериментов, что в определенный момент времени он понимает свою абсолютную самодостаточность в успешной реализации собственных идей. Он счастлив осознавать этот факт, ему нет равных в импровизации, в творческом подходе. В конечном счете Петр понимает, что существует целый мир нереализованных возможностей, и когда ему становится скучно выполнять рутину, он уходит из компании и начинает свой успешный стартап.
Николай выполняет все очень четко, он тщательно размышляет над необходимым и достаточным, он крайне щепетильно относится к любому решению. Николай очень много думает, прогнозируя исход, прежде чем совершить действие. В уме Николай выстраивает настолько сложные модели, что практическая реализация является при таком подходе лишь побочным эффектом этого сложнейшего процесса моделирования. Иногда Николай впадает в своего рода мысленную рекурсию и проворачивает одни и те же мысли десятки раз, снова и снова взвешивая возможные погрешности. Николай предельно внимателен в исполнении, в отличие от своих коллег, его ум обладает ювелирной точностью. Он не умеет импровизировать так как это делает Петр, но он способен смоделировать ситуацию настолько глубоко, что это позволяет ему видеть на десять шагов вперед не допуская лишних ошибок и соблюдая абсолютную точность. Николай не начинает действовать, пока не убедится, что это единственно правильное и наиболее оптимальное решение.
Сергей не коммуникативный, в меру замкнут. Он истинный интроверт, его сознание инкапсулируется от внешнего мира, полностью погружая Сергея в разработку алгоритмов. Сергей в одиночку способен спроектировать сложнейшие вещи, он не нуждается в делегировании частей и синхронизации. Он мастер, он один из умнейших разработчиков среди коллег. Сергей вполне способен разработать механизм, реализация которого займет времени больше, чем какие-либо разумные пределы. С ним сложно найти общий язык, но если он говорит, то каждое его слово и фраза несут глубокий смысл, передавая такой объем информации, что остальным потребуется время, чтобы осмыслить о чем вообще идет речь.
Мария не умеет программировать, она с трудом вникает в хитросплетения логики алгоритмов, но она настолько коммуникативна и открыта для окружающих ее людей, что стала для всех источником неисчерпаемой энергии, лучшим собеседником, человеком, который никогда не скажет, что ему не интересно выслушивать чьи-то переживания, люди готовы делиться с ней своими эмоциями. Мария весьма счастлива быть настолько общительной, у нее огромное множество друзей, у нее практически не бывает моментов, когда она чувствует себя одинокой и забытой всеми, как это бывает у Николая и порой у Сергея.
Антон чрезмерно усложняет код перегружая его применением паттернов. Его подход основан на применении приобретенных им знаний о стандартных вариантах решения. Антон не любит экспериментировать, он не любитель поиска оптимальных решений. Он предпочитает применять стандартные в его понимании методы, которые позволяют решать ему любые задачи. Антон складывает механизмы из однотипных блоков, его мышление уже давно абстрагировалось от низкоуровневой реализации. Антон способен быстро и просто формировать масштабные пласты логики, не задумываясь над архитектурой, используя лишь простые паттерны. Антону неизвестны проблемы с выделением слоев абстракции, он оперирует кодом на другом уровне. Он не прилагает особых усилий, ему нравится такой подход решения всех вопросов.
Славик пишет настолько лаконично, что уровень вхождения в построенные им логические модели очень низок. Новички сходу понимают что делает его код, в отличие от оверинжиниринга кода Антона. Славик иногда действует не эффективно, он расписывает все черезчур простыми конструкциями, не использует высокоуровневые абстракции, поэтому работает в целом не очень продуктивно, но его простые решения помогают быстрее въехать в суть дела. Со Славиком общаются все junior разработчики, для них он верный друг и помощник.
Евгений знает множество средств, он прекрасно понимает задачи и перспективы проекта и может трезво оценить еще на самом раннем этапе необходимость и возможность корректировки курса развития, пока затраты еще позволяют исправить ситуацию. Евгений весьма дальновидный разработчик, его познания обширны, коллеги часто советуются с ним как со стратегом, он знает свое дело, хотя и не лишен определенной доли оптимизма, а, возможно, в некоторой степени максимализма. Евгений любит иногда пообщаться с Сергеем, они находят общий язык, рассуждая о чем-то запредельном для Славика и ненужном для Антона.
…
Несмотря на то, что все персонажи вымышлены, они весьма напоминают многих героев из реальной жизни своими чертами характера. Существующая проблема в невозможности эффективного выполнения проекта иллюзорна, она сформирована абсолютным непониманием людей друг друга, это критично по одной простой причине — все структуры имеют определенную вертикаль власти, которая не позволяет людям занять оптимальное положение в социальной структуре в рамках организации. Люди неэффективны лишь потому, что их заставляют делать то, к чему они не предрасположены. Сложно закручивать ложкой шурупы. Собирая команду, необходимо обладать определенными качествами дальновидности Евгения, интеллектом Сергея, аккуратностью Николая, коммуникативностью Марии и учтивости Василия. При всем при этом, необходимо уметь доносить до своих коллег информацию также доступно, как Славик, при этом не изобретая велосипедов, а используя для организации процесса работы своей команды уже обкатанные временем паттерны, подобно подходу, используемому Антоном. И самое главное — необходимо обладать творческим подходом Петра, уметь быстро менять контекст, чтобы эффективно реагировать на малейшие изменения в хрупком балансе социальной системы и мгновенно реагировать на это.
Мы все люди, мы все разные, и потому у всех нас огромное разнообразие интересов. Собрать команду людей, которые были бы одновременно сильно заинтересованы в реализации проекта — на мой взгляд, утопия. Куда важнее, проанализировать и выделить в задаче моменты, интересные тем людям, которые будут иметь к ней непосредственное отношение. В этом и заключается своего рода искусство, искусство адаптировать задачу под совокупность людей ее исполняющих.
Мы все умеем отдавать приказы, но крайне малое количество из нас умеет проектировать социальные структуры и взаимодействия в них.
Прям палата №6 вспомнилась… «Равнодушие — паралич души...» — а в этом случае это паралич работы/проекта.
На самом деле очень важен подход к людям, PM или руководитель должен уметь сделать так чтобы все были достаточно мотивированы, т.е. всем было важно и не повигу, а также нужно правильно распределять и ставить задачи, так чтобы каждый мог максимально задействовать свой потенциал и особенности.
Создать хорошую команду — дело не простое.
На самом деле очень важен подход к людям, PM или руководитель должен уметь сделать так чтобы все были достаточно мотивированы, т.е. всем было важно и не повигу, а также нужно правильно распределять и ставить задачи, так чтобы каждый мог максимально задействовать свой потенциал и особенности.
Создать хорошую команду — дело не простое.
У вас нет в команде Архип?!?!
Знакомьтесь — это Архип. Он очень хороший программист. Он быстро пишет код, он хорошо коммуницирует с другими разработчиками, тестерами, начальником. Он компилирует релизные версии продукта три раза в час. Есть только один недостаток — в любой его программе тестеры находят баги. Когда тестеры устают бодаться, программу отдают пользователям и тогда шквал недовольства идет от пользователей. Архипу очень сложно — ведь он одновременно правит баги и пишет новую версию программы. К тому времени как поправлены все баги в старом коде у Архипа уже готова новая версия с новыми багами.
Знакомьтесь — это Архип. Он очень хороший программист. Он быстро пишет код, он хорошо коммуницирует с другими разработчиками, тестерами, начальником. Он компилирует релизные версии продукта три раза в час. Есть только один недостаток — в любой его программе тестеры находят баги. Когда тестеры устают бодаться, программу отдают пользователям и тогда шквал недовольства идет от пользователей. Архипу очень сложно — ведь он одновременно правит баги и пишет новую версию программы. К тому времени как поправлены все баги в старом коде у Архипа уже готова новая версия с новыми багами.
Могу добавить еще:
«Сотрудник с высокой мотивацией работает эффективно, сотрудник без мотивации просто опасен.» — Хабрахабр ©
«Сотрудник с высокой мотивацией работает эффективно, сотрудник без мотивации просто опасен.» — Хабрахабр ©
Я тоже раньше задумывался над вопросами, поставленными в статье, но после просмотра www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html мне стало все ясно. Главная мысль, которую я вынес для себя «You need to work with people who BELIEVE in what YOU believe»
А я… увы… (с)
:-) Хорошая песенка вспомнилась.
:-) Хорошая песенка вспомнилась.
Узнаю себя почти во всех. Кроме, разве что, Васи и Маши…
Хороший программист, это тот, кто программирует заказчиков (начальников), а не компьютеры ;)
(кстати, хороший с точки зрения его самого или удобный начальству? ;)
А точнее он в первую очередь повлияет на формулировку задачи, если она будет не оптимальна, а только потом возьмется за задачу (уже новую). А чаще, так и вообще предложит решение не требующее программирования.
И при поступлении новых данных вовремя повлияет на заказчика (узнал реальную ситуацию с задачей и понял что заказчик не понимает что ему нужно — строит систему управления заводом от начальства, а на самом деле важные решения принимает слесарь :) ).
Хотя опять же, смотря кто заказчик (клиент или начальник). Не всегда главная цель — это выполнение задачи :))
ps. а у вас чашка сверху запаяна :)
(кстати, хороший с точки зрения его самого или удобный начальству? ;)
А точнее он в первую очередь повлияет на формулировку задачи, если она будет не оптимальна, а только потом возьмется за задачу (уже новую). А чаще, так и вообще предложит решение не требующее программирования.
И при поступлении новых данных вовремя повлияет на заказчика (узнал реальную ситуацию с задачей и понял что заказчик не понимает что ему нужно — строит систему управления заводом от начальства, а на самом деле важные решения принимает слесарь :) ).
Хотя опять же, смотря кто заказчик (клиент или начальник). Не всегда главная цель — это выполнение задачи :))
ps. а у вас чашка сверху запаяна :)
Sign up to leave a comment.
Какой хороший программист!