Не может так быть, чтобы тех. культура в компании деградировала, а разработчики - нет. Культура не в вакууме существует. Заданный руководством стиль приводит к падению квалификации в первую очередь у разработчиков, а общая культура компании становится следствием. Гугл это уже кладбище не только проектов, но и талантов.
Манипуляцией занимаются все и всегда, вопрос в масштабах. Это не признак токсичности. Да и токсичность не ограничивается отношениями между коллегами или руководством. В самом рабочем процессе столько есть подводных камней "токсичности", что с лихвой перекрывает "атмосферу" и "сплетни". Начало вроде и неплохое, но вышло однобоко. P.S. да, этот комментарий может быть оценён как манипулятивный и токсичный, все мы люди, все разные.
Это вы только вершину айсберга поскребли, а техдолг может и с другой стороны расти, не только со стороны неопытности руководителей или исполнителей.
Ошибки управления проектом
Слабое владение или отсутствие владения тех. деталями со стороны руководителей приводит к неверной оценке трудозатрат, что выливается в "сжатые сроки"
Те же "сжатые сроки" получаются, когда руководители пытаются откусить кусок больше, чем могут проглотить. Списывать только на неопытность? Этим и люди с большим стажем страдают в первую очередь из-за оторванности от коллектива.
Неумение переложить требования бизнеса на язык заказчика - классика, всегда и везде. Это экономия на сотрудниках (аналитиках), которая приводит к тех. долгу. С одной стороны сиюминутные затраты меньше, с другой стороны отложенные затраты больше.
Попытки воспитать "универсальных солдат" в компании приводят к размыванию ответственности, и в итоге даёт ситуацию, когда вроде бы все всё умеют, но никто ни за что не отвечает.
Тех. культура, опыт и т.п.
Недостаток - конечно приводит к тех. долгу. Пока люди учатся, пока они набьют шишки в поле с граблями - долг неизбежно растёт. Контролировать можно только установлением стандартов в компании, или, хотя бы, в отделе.
Никакие тесты не спасут от техдолга. Более того, избыток тестов сам по себе начинает создавать техдолг, т.к. зачастую тесты представляют собой код более низкого качества, чем то, что они проверяют. Этим страдают абсолютно все, даже бигтехи на Западе. Только стандарты и только кросс ревью, но это замедляет процесс разработки, и если руководство не согласно на увеличение сроков... ну вы сами понимаете.
Архитектура - основной источник техдолга. Не код, а именно архитектура. Код может быть идеален, вылизан, покрыт тестами в хвост и в гриву, но если архитектура система убогая, то никакой код не спасёт. Неизбежно будут нагорожены костыли со всеми вытекающими.
Переусложенние (overengineering) - ещё один массовый источник техдолга. Многие любят велосипеды изобретать, и на определённом этапе это даже хорошо, для научения, но плохо для перспективы. Этим даже многие т.н. сеньоры грешат.
Это тоже далеко не исчерпывающий список.
Самый действенный способ уменьшить техдолг — не допускать его.
Совсем не допускать не получится, только если вы не вселенский гений, который ещё до начала работы над проектом видит все итоги реализации, внедрения, и поддержки. Техдолг неизбежен, именно поэтому существует отладка, тестирование, рефакторинг и т.п. Работа над проектом включает в себя работу с техдолгом. Это только hello world можно написать с ходу без "долгов", а что-то посложнее - не выйдет. Не допускать здесь это видеть, контролировать, не давать расти, и даже уменьшать. Техдолг это двигатель качества пока у вас нет 20+ лет разнообразнейшего опыта.
А бизнесу надо просто показывать план. Вот сейчас так, вы хотите это, значит займёт столько-то, потому что изначально не предусматривалось и т.п. Тут нечего добавить.
Бороться надо с причинами, а не с последствиями. Выгорание - следствие.
нужно наполнять свою жизнь интересными, увлекательными вещами, разделять работу и отдых и уметь между ними переключаться, а также заботиться о себе.
Когда у вас работа 8-9 часов + пару часов на транспорт + неизмеряемое время на "подумать о работе", то эта работа становится основным времяпрепровождением в жизни. Хорошо, если это интересная работа, но так случается от силы у пары процентов людей (а то и меньше). В такой ситуации "переключаться" и "разделять работу и отдых", а также "наполнять свою жизнь интересными, увлекательными вещами" это дополнительное большое усилие, которое после опустошительной работы многие сделать не могут. Так что если причина в работе, то проще сменить её сразу, не ждать, пока в списке симптомов выгорания будет отмечена хотя бы половина.
Во-первых, проблема не в написании кода, а в поддержке написанного - в расширении, изменении и т.д. Во-вторых, ни одна контора, выпускающая очередную "нейросеть-убийцу программистов", не даст 100% гарантии на корректность выдаваемого машиной кода.
В итоге всё сведётся к тому, что для примитивных (в т.ч. учебных) задач будут использовать сетки, а для серьёзных разработок - людей, чью работку сетки будут местами ускорять, что уже есть.
Ну а мистер Хуанг просто хочет продавать больше железа, потому и выдаёт на гора такие перлы.
Неплохая статья, очень даже неплохая.
По логам — мы используем github.com/uber-go/zap с небольшой оберткой, которая позволяет нам создавать нужные аппендеры на лету. Форматирование zap тоже поддерживает, но если хочется свой формат лог записей, то нужно написать немного кода. Универсализма как в log4j я пока не видел.
Посмотрите на людей на улицах, они же просто зомби. Единицы обращают внимание на происходящее вокруг, остальные же смотрят только на себя.
А теперь представьте, что таких «прокачали». Кому станет лучше? Им самим — тоже не факт. Окружающим — да они такие же ничегонезамечатели. Человечеству — навряд ли.
Прежде, чем задумываться о «прокачке», стоит начать с развития себя до уровня человека, а иначе большинство лишь двуногие прямоходящие.
Ищите позиции исследователя (research engineer), и у вас будет определённая свобода. Говорю по собственному опыту.
А так все верно, и про творчество, и про безликость.
У go есть определенная область применения, в которой он великолепен. Те же, кто пытаются натянуть сову на глобус представить go в качестве универсального языка, либо не понимают его, либо лукавят. Гвозди и микроскопом можно забивать, только результат печален будет.
Все это к тому, что у вас изначально предвзятое мнение в сторону go, это видно из статьи. Язык это лишь инструмент, и не стоит поливать его, не зная его ниши. Эдак можно про любой язык наворотить.
Что по-поводу пары Java/C#? Go ей ни разу не конкурент, по крайней мере пока он молод (речь про версию Go 1.11).
Вполне себе конкурент, и наверное поэтому гугл переводит свои внутренние сервисы с явы/питона на го, получая прирост производительности.
Может стоит поизучать области применения языка, ознакомиться с успехами и провалами, прежде чем городить подобную отсебятину?
Не может так быть, чтобы тех. культура в компании деградировала, а разработчики - нет. Культура не в вакууме существует. Заданный руководством стиль приводит к падению квалификации в первую очередь у разработчиков, а общая культура компании становится следствием. Гугл это уже кладбище не только проектов, но и талантов.
Манипуляцией занимаются все и всегда, вопрос в масштабах. Это не признак токсичности. Да и токсичность не ограничивается отношениями между коллегами или руководством. В самом рабочем процессе столько есть подводных камней "токсичности", что с лихвой перекрывает "атмосферу" и "сплетни". Начало вроде и неплохое, но вышло однобоко.
P.S.
да, этот комментарий может быть оценён как манипулятивный и токсичный, все мы люди, все разные.
Это вы только вершину айсберга поскребли, а техдолг может и с другой стороны расти, не только со стороны неопытности руководителей или исполнителей.
Ошибки управления проектом
Слабое владение или отсутствие владения тех. деталями со стороны руководителей приводит к неверной оценке трудозатрат, что выливается в "сжатые сроки"
Те же "сжатые сроки" получаются, когда руководители пытаются откусить кусок больше, чем могут проглотить. Списывать только на неопытность? Этим и люди с большим стажем страдают в первую очередь из-за оторванности от коллектива.
Неумение переложить требования бизнеса на язык заказчика - классика, всегда и везде. Это экономия на сотрудниках (аналитиках), которая приводит к тех. долгу. С одной стороны сиюминутные затраты меньше, с другой стороны отложенные затраты больше.
Попытки воспитать "универсальных солдат" в компании приводят к размыванию ответственности, и в итоге даёт ситуацию, когда вроде бы все всё умеют, но никто ни за что не отвечает.
Тех. культура, опыт и т.п.
Недостаток - конечно приводит к тех. долгу. Пока люди учатся, пока они набьют шишки в поле с граблями - долг неизбежно растёт. Контролировать можно только установлением стандартов в компании, или, хотя бы, в отделе.
Никакие тесты не спасут от техдолга. Более того, избыток тестов сам по себе начинает создавать техдолг, т.к. зачастую тесты представляют собой код более низкого качества, чем то, что они проверяют. Этим страдают абсолютно все, даже бигтехи на Западе. Только стандарты и только кросс ревью, но это замедляет процесс разработки, и если руководство не согласно на увеличение сроков... ну вы сами понимаете.
Архитектура - основной источник техдолга. Не код, а именно архитектура. Код может быть идеален, вылизан, покрыт тестами в хвост и в гриву, но если архитектура система убогая, то никакой код не спасёт. Неизбежно будут нагорожены костыли со всеми вытекающими.
Переусложенние (overengineering) - ещё один массовый источник техдолга. Многие любят велосипеды изобретать, и на определённом этапе это даже хорошо, для научения, но плохо для перспективы. Этим даже многие т.н. сеньоры грешат.
Это тоже далеко не исчерпывающий список.
Совсем не допускать не получится, только если вы не вселенский гений, который ещё до начала работы над проектом видит все итоги реализации, внедрения, и поддержки. Техдолг неизбежен, именно поэтому существует отладка, тестирование, рефакторинг и т.п. Работа над проектом включает в себя работу с техдолгом. Это только hello world можно написать с ходу без "долгов", а что-то посложнее - не выйдет. Не допускать здесь это видеть, контролировать, не давать расти, и даже уменьшать. Техдолг это двигатель качества пока у вас нет 20+ лет разнообразнейшего опыта.
А бизнесу надо просто показывать план. Вот сейчас так, вы хотите это, значит займёт столько-то, потому что изначально не предусматривалось и т.п. Тут нечего добавить.
Бороться надо с причинами, а не с последствиями. Выгорание - следствие.
нужно наполнять свою жизнь интересными, увлекательными вещами, разделять работу и отдых и уметь между ними переключаться, а также заботиться о себе.Когда у вас работа 8-9 часов + пару часов на транспорт + неизмеряемое время на "подумать о работе", то эта работа становится основным времяпрепровождением в жизни. Хорошо, если это интересная работа, но так случается от силы у пары процентов людей (а то и меньше). В такой ситуации "переключаться" и "разделять работу и отдых", а также "наполнять свою жизнь интересными, увлекательными вещами" это дополнительное большое усилие, которое после опустошительной работы многие сделать не могут.
Так что если причина в работе, то проще сменить её сразу, не ждать, пока в списке симптомов выгорания будет отмечена хотя бы половина.
Последние 20% - самые сложные. Интересно было бы глянуть на хотя бы запланированное сравнение функционала с другими движками.
Казалось бы, что может пойти не так :)
Во-первых, проблема не в написании кода, а в поддержке написанного - в расширении, изменении и т.д. Во-вторых, ни одна контора, выпускающая очередную "нейросеть-убийцу программистов", не даст 100% гарантии на корректность выдаваемого машиной кода.
В итоге всё сведётся к тому, что для примитивных (в т.ч. учебных) задач будут использовать сетки, а для серьёзных разработок - людей, чью работку сетки будут местами ускорять, что уже есть.
Ну а мистер Хуанг просто хочет продавать больше железа, потому и выдаёт на гора такие перлы.
По логам — мы используем github.com/uber-go/zap с небольшой оберткой, которая позволяет нам создавать нужные аппендеры на лету. Форматирование zap тоже поддерживает, но если хочется свой формат лог записей, то нужно написать немного кода. Универсализма как в log4j я пока не видел.
А теперь представьте, что таких «прокачали». Кому станет лучше? Им самим — тоже не факт. Окружающим — да они такие же ничегонезамечатели. Человечеству — навряд ли.
Прежде, чем задумываться о «прокачке», стоит начать с развития себя до уровня человека, а иначе большинство лишь двуногие прямоходящие.
А так все верно, и про творчество, и про безликость.
Если б я увидел это в разделе «для кого эта статья», не сказал бы ни слова :)
P.S.
я читаю статьи целиком
натянуть сову на глобуспредставить go в качестве универсального языка, либо не понимают его, либо лукавят. Гвозди и микроскопом можно забивать, только результат печален будет.Все это к тому, что у вас изначально предвзятое мнение в сторону go, это видно из статьи. Язык это лишь инструмент, и не стоит поливать его, не зная его ниши. Эдак можно про любой язык наворотить.
Вполне себе конкурент, и наверное поэтому гугл переводит свои внутренние сервисы с явы/питона на го, получая прирост производительности.
Может стоит поизучать области применения языка, ознакомиться с успехами и провалами, прежде чем городить подобную отсебятину?