В голову пришел пример: врач в государственной поликлинике и врач в частной клинике. Но страшно же господа-товарищи очень страшно! Давно копошится в голове мысль - а что же нужно, чтобы люди работали по совести. Хотя и совесть у всех разная. Недавно разговаривала со своей соседкой, работающей нянечкой детского сада, говорю ей : "зачем вы пошли на такую работу, это же дети, отвественность". А она мне: "я ни за что не отвечаю, отвечает воспитатель". А потом дети падают на мокром полу, получают травмы, или вообще уходят за пределы дет. садов.
Читабельный по мне - это стремление к простоте, чтоб тебя и студент и гуру понимали, и старпер и суперстар на острие, а если начинаются навороты с алгоритмами или переподвывертом новых технологий - то бывает и очень красиво, и элегантно, и "браво" хочется крикнуть, но у половины команды ужас в глазах :-D.
Омоложение и стремление за другими языками - конечно да, но можно делать лаконично и по значимой ценности. Но часто происходит засахаривание там, где нужно и там, где нет. Понятно, что можно сказать была бы возможность, а применение найдется. С другой стороны, очень многие возможности можно реализовать как отдельные пакеты и тогда команда сама будет себя ограничивать или не ограничивать (тут смысл 1) в стремлении к единообразию кода до его написания и без массивных кодинг стандартов, а не только средствами анализаторов, линта, код ревью, когда код уже написан; и 2) уменьшении желания новобранцев "самородков" делать/писать так, потому что модно, а не потому что нужно - необоснованное применение или внесение нового подхода без согласия команды; когда возможность есть и ставить ничего не надо - то часто даже мысли не возникает о причиняемых последствиях) . Ну вот например, все что связано с кодогенерацией - почему бы отдельным пакетом не сделать, ведь они почти в каждой версии что-то для нее добавляют.
Может в Go и правы, что борятся с избыточностью в языке. C# за последние годы пооброс странными вещами, по мне только замусоривающими язык. Лучше бы часть из них сделали отдельными пакетами, хочешь использовать устанавливай и используй, а не хочешь и не надо.
С таким количеством изменений и новых конструкций, которые возникли в последние 5 лет, пора уже каждой команде писать Coding standard о том, какие конструкции они используют, а какие категорически нет :-D. Я ещё не оправилась от дефолтных методов в интерфейсах, а они уже конструктор в имя класса запихнули :D.
Я бы добавила, что есть и другой вид выгорания, когда оно не сказывается на результате работы, но сказывается на настрое человека. Например, опять же из-за гиперответственности человек хорошо справляется, помогает команде, в том числе работает сверхурочно, чтобы помочь команде или заказчику, но в команде есть люди, которые откровенно халтурят. И тут человек начинает сравнивать - почему Вася работает сильно проще и меньше, а зарплату получает примерно такую же... Или ещё один пример - слишком много на себя взял, работу тянешь, а личную жизнь уже нет. Тут можно сказать, что сроки неверно установили, и это правда, но часто человек гонится за тем, чтобы вырасти, ему навязывают новые обязанности, в которых приходится разбираться в свободное время. Вспомним хотя бы дядюшку Боба с его 20 часами в неделю для саморазвития вне рабочего времени. Как результат - выгорание но другое, когда сил и времени не остаётся на жизнь. На самой работе оно скажется гораздо позже, когда человек просто уволится и пойдет сажать огород.
Вы абсолютно правы про настроенные процессы. Но это статья все же из песочницы, для мальчиков и девочек, которым ещё до процессов ой как далеко. Но я в корне не согласна, что им не надо думать про ответственность за свою работу и валить все на менеджера. Опять же разные уровни ответственности. Да с выстроенными процессами плохой код просто не пройдет ревью, но это опять же не повод писать как придется в надежде, что прокатит. Каждый винтик в механизме важен.
Конечно, написана статья слишком высокопарно что ли... Но зато дискуссия-то пошла в комментах прямо радует :)
Так ответственность не только у мальков и девочек должна быть, но у менеджеров и бизнеса. Тут уровни ответственности просто разные: у одних - все тесты написать, которые им утвердили, а не спать полдня, а потом копипастом не глядя хреначить, а у других - квалифицированный персонал нанять, а не с соседями по двору договариваться.
Очень зависит от ситуации, скорей всего уведомлю вышестоящих руководителей, пусть они решают, что делать.
Вот, вы в большинстве случаев ответственный человек, который всё-таки отнесет проблему на уровень выше. За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому - халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
А мне от этого хорошо или плохо?
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой - в игры играть вместо того, чтобы работать :)
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально.
И что же, если вы видите в коде ошибку, которая принесет кучу проблем в будущем, но с большой вероятностью уже не вам, вы будете делать вид, что ее нет, лишь бы вас не трогали? Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает? Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит. Поэтому последние годы и лепится г..но на скорую руку практически везде.
Да ладно ругать автора, тема-то важная на самом деле. Может какой-нибудь такой же умненький или не ещё очень мальчик, увидев именно эту статью, поймет, что несёт ответственность за свою работу, а не просто пришел денег получать.
Но статью надо доработать! Что очень не понравилось:
1)Были уже в нашем мире и случаи гибели людей, и падения космических аппаратов и т.д. Зачем что-то представлять, если настоящие примеры можно привести.
2) Упор на тестирование как на важнейший атрибут. Но оно не освобождает от ответственности никого. Например, бизнес аналитиков, которые могут создать неверные требования, ведь разработчики и тестировщики часто действуют по принципу "у меня в ТЗ так написано, значит пусть так и будет"
В голову пришел пример: врач в государственной поликлинике и врач в частной клинике. Но страшно же господа-товарищи очень страшно! Давно копошится в голове мысль - а что же нужно, чтобы люди работали по совести. Хотя и совесть у всех разная. Недавно разговаривала со своей соседкой, работающей нянечкой детского сада, говорю ей : "зачем вы пошли на такую работу, это же дети, отвественность". А она мне: "я ни за что не отвечаю, отвечает воспитатель". А потом дети падают на мокром полу, получают травмы, или вообще уходят за пределы дет. садов.
Читабельный по мне - это стремление к простоте, чтоб тебя и студент и гуру понимали, и старпер и суперстар на острие, а если начинаются навороты с алгоритмами или переподвывертом новых технологий - то бывает и очень красиво, и элегантно, и "браво" хочется крикнуть, но у половины команды ужас в глазах :-D.
Омоложение и стремление за другими языками - конечно да, но можно делать лаконично и по значимой ценности. Но часто происходит засахаривание там, где нужно и там, где нет. Понятно, что можно сказать была бы возможность, а применение найдется. С другой стороны, очень многие возможности можно реализовать как отдельные пакеты и тогда команда сама будет себя ограничивать или не ограничивать (тут смысл 1) в стремлении к единообразию кода до его написания и без массивных кодинг стандартов, а не только средствами анализаторов, линта, код ревью, когда код уже написан; и 2) уменьшении желания новобранцев "самородков" делать/писать так, потому что модно, а не потому что нужно - необоснованное применение или внесение нового подхода без согласия команды; когда возможность есть и ставить ничего не надо - то часто даже мысли не возникает о причиняемых последствиях) . Ну вот например, все что связано с кодогенерацией - почему бы отдельным пакетом не сделать, ведь они почти в каждой версии что-то для нее добавляют.
Может в Go и правы, что борятся с избыточностью в языке. C# за последние годы пооброс странными вещами, по мне только замусоривающими язык. Лучше бы часть из них сделали отдельными пакетами, хочешь использовать устанавливай и используй, а не хочешь и не надо.
С таким количеством изменений и новых конструкций, которые возникли в последние 5 лет, пора уже каждой команде писать Coding standard о том, какие конструкции они используют, а какие категорически нет :-D. Я ещё не оправилась от дефолтных методов в интерфейсах, а они уже конструктор в имя класса запихнули :D.
Я бы добавила, что есть и другой вид выгорания, когда оно не сказывается на результате работы, но сказывается на настрое человека. Например, опять же из-за гиперответственности человек хорошо справляется, помогает команде, в том числе работает сверхурочно, чтобы помочь команде или заказчику, но в команде есть люди, которые откровенно халтурят. И тут человек начинает сравнивать - почему Вася работает сильно проще и меньше, а зарплату получает примерно такую же... Или ещё один пример - слишком много на себя взял, работу тянешь, а личную жизнь уже нет. Тут можно сказать, что сроки неверно установили, и это правда, но часто человек гонится за тем, чтобы вырасти, ему навязывают новые обязанности, в которых приходится разбираться в свободное время. Вспомним хотя бы дядюшку Боба с его 20 часами в неделю для саморазвития вне рабочего времени. Как результат - выгорание но другое, когда сил и времени не остаётся на жизнь. На самой работе оно скажется гораздо позже, когда человек просто уволится и пойдет сажать огород.
Вы абсолютно правы про настроенные процессы. Но это статья все же из песочницы, для мальчиков и девочек, которым ещё до процессов ой как далеко. Но я в корне не согласна, что им не надо думать про ответственность за свою работу и валить все на менеджера. Опять же разные уровни ответственности. Да с выстроенными процессами плохой код просто не пройдет ревью, но это опять же не повод писать как придется в надежде, что прокатит. Каждый винтик в механизме важен.
Конечно, написана статья слишком высокопарно что ли... Но зато дискуссия-то пошла в комментах прямо радует :)
Так ответственность не только у мальков и девочек должна быть, но у менеджеров и бизнеса. Тут уровни ответственности просто разные: у одних - все тесты написать, которые им утвердили, а не спать полдня, а потом копипастом не глядя хреначить, а у других - квалифицированный персонал нанять, а не с соседями по двору договариваться.
Вот, вы в большинстве случаев ответственный человек, который всё-таки отнесет проблему на уровень выше. За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому - халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой - в игры играть вместо того, чтобы работать :)
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально.
И что же, если вы видите в коде ошибку, которая принесет кучу проблем в будущем, но с большой вероятностью уже не вам, вы будете делать вид, что ее нет, лишь бы вас не трогали? Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает? Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит. Поэтому последние годы и лепится г..но на скорую руку практически везде.
Да ладно ругать автора, тема-то важная на самом деле. Может какой-нибудь такой же умненький или не ещё очень мальчик, увидев именно эту статью, поймет, что несёт ответственность за свою работу, а не просто пришел денег получать.
Но статью надо доработать! Что очень не понравилось:
1)Были уже в нашем мире и случаи гибели людей, и падения космических аппаратов и т.д. Зачем что-то представлять, если настоящие примеры можно привести.
2) Упор на тестирование как на важнейший атрибут. Но оно не освобождает от ответственности никого. Например, бизнес аналитиков, которые могут создать неверные требования, ведь разработчики и тестировщики часто действуют по принципу "у меня в ТЗ так написано, значит пусть так и будет"