На обсуждение публики выносится вопрос — как же организовать систему, которая будет гарантированно переживать «хабраэффект» раз в год, практически бездействуя остальное время.
это не задача руководителя проекта, он просто не имеет инструментов её решить
Вот это ложь творческое преувеличение. Смена приоритетов далеко не всегда эндогенна. Да, работа в норме должна быть self-rewarding, но это не означает, что reward измеряется в прожитых и потраченных человеко-часах. Бывает, что меняется качественный, содержательный характер работы. Бывает, что сотрудник не чувствует себя в достаточной степени code owner (потому что вынужден следовать чужим архитектурным решениям, принятым годы назад) и боится выйти с радикальным предложением, как сделать «правильней и проще» — а в legacy-коде тонет (и правильно делает, «лучше задохнуться, чем вдыхать этот дым»). В таком случае помогает просто подойти и спросить — что, по его мнению, выглядит ненатурально, избыточно, что он поменял бы или убрал бы, если бы мог (правила те же, что и при проведении мозгового штурма — гарантировать, что ни одно предложение не будет высмеяно, сочтено признаком недостаточной компетентности или как-то еще использовано против автора).
Бывает, что сотрудника тупо поджимают финансы, и он с охотой пошел бы на внутреннее совместительство (а его не дают). Бывает, что сотрудник в панике от профессионализма команды (новой, расширенной, «укрепленной»). Бывает, что сотрудник автоматизировал в своей ежедневной деятельности все, что возможно, и его впору переводить в R&D или в разработку средств разработки. Бывает, что сотрудник вместо работы вынужден красить забор в белый цвет или мавзолей в зеленый (я с этим поступал просто: за меня корпоративные тренинги проходили тимлид и скрам-мастер), или отчитываться и ставить себе сроки в часах и минутах.
Лопата угля, вовремя подброшенная в топку самооценки, решает проблему «выгорания» где-то в половине случаев.
Не так. Изучивший, помимо профессионального минимума, слабые места своей собственной встроенной вычислительной машинки.
Ну, примерно, как хороший педагог-предметник — это не только предметник, но и педагог.
Если человек не ищет коротких путей, это не сеньор и не юниор. Это вообще не инженер. Если у него есть диплом, он выдан по ошибке.
Но чтобы двигаться дальше, диплом придется перерасти.
Наш «князь Вадим» любил рассказывать про то, как по результатам профилирования qsort в плотном цикле заменили на сортировку пузырьком — потому что элементов в списке в каждом случае было amortized O(1) («один, два, много»). (Не вспомню, к сожалению, в каком проекте.)
По моему глубокому убеждению, сеньора от юниора отличает вовсе не понимание побочные эффектов написанного им кода.
Практически у каждого такого эффекта есть свой «золотой ключик»: накладные расходы циклов — SIMD, накладные расходы блокировок — lock-free, накладные расходы нормализации — NoSQL, накладные расходы ожидания в I/O — селекторы и continuations, накладные расходы конвейера и кеша процессора — «профилируй, бабка...» — и так далее. Выучил, внедрил, поехал.
А вот «серебряной пули» нет.
И сеньора от юниора отличает понимание побочных эффектов своей собственной деятельности по написанию кода.
Умение, так сказать, наступать песне на горло и душить прекрасные порывы.
Домашняя еда дорога (а ресторанная — особенно дорога) по сравнению с «Роллтоном».
Возможны жизненные ситуации, когда хватает только на «Роллтон».
Но питание одним «Роллтоном» — плохая долгосрочная стратегия. И не только потому, что он субъективно надоедает.
Перфекционизм и эротичность кода — необходимые условия терпимого NPV расходов на его поддержку.
Зависит от того, что Вы называете словом «исходит».
Например, короткий sleep или timed wait в цикле будет отрабатывать в N раз чаще или реже. Если тело (или условие) цикла имеет побочные эффекты, эти побочные эффекты тоже будут отрабатывать в N раз чаще или реже. Например, если Вы делаете пошаговую анимацию с фиксированным шагом, ее скорость изменится. Если Вы используете интерполяцию по времени, скорость анимации в среднем (amortized) не изменится, но она станет более или менее плавной. Наконец, если логика Вашей программы полагается на определенную частоту таймера, скорее всего, в ней есть и другие проблемы (hardcoded constants, смешение спецификации с реализацией, смешение бизнес-логики со вводом-выводом и еще что-нибудь столь же пионерское).
В предположении, что решены все денежные проблемы: культурология, литературоведение, этнография, сравнительная мифология. Музыкальная критика. Воспитание детей (своих и чужих).
В предположении, что денежные проблемы не решены: шай-яй-яй-тан его знает. Дизайн, верстка.
Если есть время доучиться и закрыть «белые пятна» — звукозапись, видеомонтаж, фотография.
Репетитор по английскому языку, школьной математике, началам химии и физики.
В крайнем случае (полный коллапс инфосферы или очевидная невозможность заработать с ее помощью) — пойду поваром, тоже хлеб (pun unintended).
И вообще этот шаг воспринимается как удар под дых от гугла. Люди привыкли к эклипсу, черт возьми, а они фактически вынуждаю их переходить на новую ide (потому что поддержка эклипса, как мне кажется, сойдет на нет)
Для инди-разработчиков — отчасти справедливо (ну, по крайней мере, валидный повод обидеться).
Для команд все несколько иначе. По моим наблюдениям — там, где за стандарт принята IDEA, достаточно чистый код пишут и пользователи Eclipse: планка задана, и она обеспечивается взаимодействием людей, а не взаимодействием стандартов. Там, где за стандарт принят «дефолтный» Eclipse, проблемы архитектуры и особенно стиля (я не про расположение скобок) не то, что не решаются, а попросту не ставятся: «А зачем это вообще, работает же?» — а немногочисленные белые вороны с «IDEA» либо вытягивают проект из болота хаков, как Архимед триеру за канат, либо попросту замыкаются и занимаются чем-нибудь более интересным и вознаграждающим.
Выборка моя, впрочем, небольшая, охотно поверю, что есть проекты, где архитектура продиктована заказчиком или фреймворком, или разработчики такие хардкорные сверхпрофессионалы, что их почерк и Vim не испортит. Но мне все-таки по душе идея (pun unintented), что человек не должен делать то, что может сделать автомат (в нашем случае — синтаксический и семантический анализ проекта в целом): это оскорбительно и для человека, и для автомата.
При всем неуважении — ВВП дал содержательный ответ (об использовании и разработке автоматизированных вооружений) на вопрос о человекоподобных роботах. Хотя и не настолько развернутый, конечно.
Будущее просто наступает, ему все возрастыдиктаторы общества покорны.
Облака и виртуализацию отменили?
Вот это
ложьтворческое преувеличение. Смена приоритетов далеко не всегда эндогенна. Да, работа в норме должна быть self-rewarding, но это не означает, что reward измеряется в прожитых и потраченных человеко-часах. Бывает, что меняется качественный, содержательный характер работы. Бывает, что сотрудник не чувствует себя в достаточной степени code owner (потому что вынужден следовать чужим архитектурным решениям, принятым годы назад) и боится выйти с радикальным предложением, как сделать «правильней и проще» — а в legacy-коде тонет (и правильно делает, «лучше задохнуться, чем вдыхать этот дым»). В таком случае помогает просто подойти и спросить — что, по его мнению, выглядит ненатурально, избыточно, что он поменял бы или убрал бы, если бы мог (правила те же, что и при проведении мозгового штурма — гарантировать, что ни одно предложение не будет высмеяно, сочтено признаком недостаточной компетентности или как-то еще использовано против автора).Бывает, что сотрудника тупо поджимают финансы, и он с охотой пошел бы на внутреннее совместительство (а его не дают). Бывает, что сотрудник в панике от профессионализма команды (новой, расширенной, «укрепленной»). Бывает, что сотрудник автоматизировал в своей ежедневной деятельности все, что возможно, и его впору переводить в R&D или в разработку средств разработки. Бывает, что сотрудник вместо работы вынужден красить забор в белый цвет или мавзолей в зеленый (я с этим поступал просто: за меня корпоративные тренинги проходили тимлид и скрам-мастер), или отчитываться и ставить себе сроки в часах и минутах.
Лопата угля, вовремя подброшенная в топку самооценки, решает проблему «выгорания» где-то в половине случаев.
Ну, примерно, как хороший педагог-предметник — это не только предметник, но и педагог.
Но чтобы двигаться дальше, диплом придется перерасти.
Наш «князь Вадим» любил рассказывать про то, как по результатам профилирования qsort в плотном цикле заменили на сортировку пузырьком — потому что элементов в списке в каждом случае было amortized O(1) («один, два, много»). (Не вспомню, к сожалению, в каком проекте.)
Практически у каждого такого эффекта есть свой «золотой ключик»: накладные расходы циклов — SIMD, накладные расходы блокировок — lock-free, накладные расходы нормализации — NoSQL, накладные расходы ожидания в I/O — селекторы и continuations, накладные расходы конвейера и кеша процессора — «профилируй, бабка...» — и так далее. Выучил, внедрил, поехал.
А вот «серебряной пули» нет.
И сеньора от юниора отличает понимание побочных эффектов своей собственной деятельности по написанию кода.
Умение, так сказать, наступать песне на горло и душить прекрасные порывы.
Домашняя еда дорога (а ресторанная — особенно дорога) по сравнению с «Роллтоном».
Возможны жизненные ситуации, когда хватает только на «Роллтон».
Но питание одним «Роллтоном» — плохая долгосрочная стратегия. И не только потому, что он субъективно надоедает.
Перфекционизм и эротичность кода — необходимые условия терпимого NPV расходов на его поддержку.
Например, короткий sleep или timed wait в цикле будет отрабатывать в N раз чаще или реже. Если тело (или условие) цикла имеет побочные эффекты, эти побочные эффекты тоже будут отрабатывать в N раз чаще или реже. Например, если Вы делаете пошаговую анимацию с фиксированным шагом, ее скорость изменится. Если Вы используете интерполяцию по времени, скорость анимации в среднем (amortized) не изменится, но она станет более или менее плавной. Наконец, если логика Вашей программы полагается на определенную частоту таймера, скорее всего, в ней есть и другие проблемы (hardcoded constants, смешение спецификации с реализацией, смешение бизнес-логики со вводом-выводом и еще что-нибудь столь же пионерское).
Для внеклассного чтения: staff.um.edu.mt/jskl1/turbo.html#Error
В предположении, что денежные проблемы не решены: шай-яй-яй-тан его знает. Дизайн, верстка.
Если есть время доучиться и закрыть «белые пятна» — звукозапись, видеомонтаж, фотография.
Репетитор по английскому языку, школьной математике, началам химии и физики.
В крайнем случае (полный коллапс инфосферы или очевидная невозможность заработать с ее помощью) — пойду поваром, тоже хлеб (pun unintended).
Для инди-разработчиков — отчасти справедливо (ну, по крайней мере, валидный повод обидеться).
Для команд все несколько иначе. По моим наблюдениям — там, где за стандарт принята IDEA, достаточно чистый код пишут и пользователи Eclipse: планка задана, и она обеспечивается взаимодействием людей, а не взаимодействием стандартов. Там, где за стандарт принят «дефолтный» Eclipse, проблемы архитектуры и особенно стиля (я не про расположение скобок) не то, что не решаются, а попросту не ставятся: «А зачем это вообще, работает же?» — а немногочисленные белые вороны с «IDEA» либо вытягивают проект из болота хаков, как Архимед триеру за канат, либо попросту замыкаются и занимаются чем-нибудь более интересным и вознаграждающим.
Выборка моя, впрочем, небольшая, охотно поверю, что есть проекты, где архитектура продиктована заказчиком или фреймворком, или разработчики такие хардкорные сверхпрофессионалы, что их почерк и Vim не испортит. Но мне все-таки по душе идея (pun unintented), что человек не должен делать то, что может сделать автомат (в нашем случае — синтаксический и семантический анализ проекта в целом): это оскорбительно и для человека, и для автомата.
Будущее просто наступает, ему все
возрастыдиктаторыобщества покорны.