Ага и никого не удивляет тот факт, что согласно источника, приведенного в статье — видео якобы было опубликовано в Snapchat:
student is now facing two Felony charges for a threat he allegedly sent via Snapchat
Для тех кто не в курсе, если не сделать скрина, то сообщение в Snapchat т.с. «самоуничтожается». Таким образом, на момент суда у судьи, скорее всего, кроме заявления стукача против парня никаких других доказательств не было.
Можно гораздо проще. Они скрыто друг от друга берут игровые фишки от любой игры в эквиваленте своей зарплаты и так, чтобы никто другой не видел (например зажав жменю фишек в руке) кладут их в непрозрачный мешок, встряхивают его для надежности, пересчитывают содержимое мешка и делят на 3.
«Тупо кодить» в современных условиях просто нельзя — как аналитик должен понимать «что там по капотом», так и разработчик — «а для чего собственно этот алгоритм предназначен в конечном счёте».
«Тупо кодить» нельзя в любых условиях. Для того, чтобы все понимали кто, что и для чего делает — вполне достаточно общения в предназначенное для этого время, конечно при условии, что все участники процесса — профессионалы своего дела.
В нормальных компаниях… в порядке вещей работа аналитика, разработчика и тестировщика в связке… Когда разработчик плотно общается со всеми участниками цепи ...
В моем понимании слова «плотное общение» означают частое, регулярное и скорее всего достаточно длительное. И если я вас правильно понял — ответьте пожалуйста, по какому тарифу в этих «нормальных компаниях» оплачивают разработчику и остальным «участникам цепи» рабочее время, потраченное на такое вот «плотное общение»?
Ну если все в вашей компании являются одновременно еще и совладельцами «вашего продукта» (что предполагает получение каждым своей части прибыли), то тогда — да, все правильно. Если ли же дело обстоит по другому, то все эти лозунги — просто разводилово исполнителей на дополнительную и естественно неоплачиваемую работу, которую им надо выполнить помимо основной.
В моей компании все выполняют хорошо именно свою работу и получают именно за это хорошую зарплату. Как показала практика, это возможно только при тщательном планировании работ, их правильном распределении между исполнителями и четком определении зоны ответственности каждого исполнителя, что (возвращаясь к теме) исключает какое-либо дополнительное «общение» в рабочее время.
Ну автор как бы не про программирование мультиварки пишет и даже не про Basic в калькуляторе, а про программирование на Python, а это уже предполагает некий базовый уровень.
Т.е. по другой аналогии этот ваш старшеклассник хочет в свободное время покататься на шоссейном мотоцикле минуя стадии велосипеда, мопеда и т.п.
То о чем я написал — это не пожелание разработчика, это должна быть позиция компании. Лично у меня большее недопонимание вызвало бы смещение приоритета от тасков в Jira в сторону различного не запланированного «общения».
Хотя если в упомянутых вами компания/стартапах разработчику платят не за выполнение задач, а за «общение», то почему нет — пусть «общается».
Если кто-то хочет научиться программировать, он не должен для этого предварительно изучать администрирование системы.
Если кто-то просто хочет научиться программировать, он не должен для этого изучать устройство операционных систем.
Мне вот интересно согласился бы автор этих строк, чтобы его лечил врач, который просто «научился лечить», не зная при этом даже азов анатомии, химии, биологии и прочих базовых для врача дисциплин?
Если кому-то что-то еще нужно объяснять после совместного обсуждения и принятия решения, то у этого кого-то либо проблемы с коммуникацией на собрании, либо недостаток компетенции. В любом случае такие запросы на объяснения должны проходить через ПМа.
Под блокировкой я понимаю либо то, что кому-то нужен еще пока не сделанный твой код, либо то, что необходимый для другого разработчика уже сделанный твой код не работает должным образом и он не может продолжать разработку своей части кода.
Если общаться в специально отведенное время (регулярные митинги, запланированные обсуждения, встречи и т.п.), то можно и нужно общаться хоть с кем: заказчики, аналитики, архитекторы, тестировщики и т.д. — в рабоче время только с руководителем и непосредственными коллегами.
Этой проблемы вообще не должно быть.
Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тетировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.
Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
В моей компании все выполняют хорошо именно свою работу и получают именно за это хорошую зарплату. Как показала практика, это возможно только при тщательном планировании работ, их правильном распределении между исполнителями и четком определении зоны ответственности каждого исполнителя, что (возвращаясь к теме) исключает какое-либо дополнительное «общение» в рабочее время.
Т.е. по другой аналогии этот ваш старшеклассник хочет в свободное время покататься на шоссейном мотоцикле минуя стадии велосипеда, мопеда и т.п.
Хотя если в упомянутых вами компания/стартапах разработчику платят не за выполнение задач, а за «общение», то почему нет — пусть «общается».
на самом деле он НЕ понимает
Под блокировкой я понимаю либо то, что кому-то нужен еще пока не сделанный твой код, либо то, что необходимый для другого разработчика уже сделанный твой код не работает должным образом и он не может продолжать разработку своей части кода.
Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тетировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.
Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!