Этот пост скорее ирония, размышления на тему чрезмерной самоуверенности и погоне изобретателей за популярностью и славой. Не стоит относиться к нему серьёзно.
Крушение глубоководного обитаемого аппарата «Титан» с пятью миллионерами на борту 18 июня 2023 года породило не только волну мемов (раз, два, триЧитать полностью »
Но теперь, спустя три года, можно с уверенностью сказать: американский технологический гигант не достиг дна с уходом Apple, а только продолжает исследовать глубины собственного падения. Ведь из статуса гегемона, компании, которая определяет вектор технологического развития человечества, Intel превратилась в компанию-производителя, которая с трудом отбивается от конкурентов, теряет рынки и направления, а в сферах, что стали центральными — вовсе имеет роль догоняющего. Но в какой момент что-то пошло не так? И что сгубило гордого американского гиганта, который насаждал свою волю и видение будущего на протяжении двух десятилетий?
Перформанс — это результативность команды. Начиная с этого места понятийный аппарат разваливается. Чтобы измерять результативность, нужно знать какую-то метрику. Метрика «строчки кода» определённо не подходит, а метрика «готовые фичи» измеряет продуктолога или команду, а не индивидуального разработчика. И вот этим «чем-то» ещё нужно управлять. Логика в том, чтобы разработчик разрабатывал нужное и с понятной скоростью, чтобы на него можно было полагаться в задачах.
Управлять можно, например:
Например, хорошие метрики, следующие из этого — это доступность сервиса, максимальное время ответа сервиса, размер техдолга (хотя его тоже сложно измерить), процент покрытия автотестами и так далее.
Но вы не управляете даже этим! Этим всем управляет сам разработчик. Вы же управляете тем, как он понимает текущую ситуацию с компанией, продуктом, командой и своим развитием.
Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать полностью »
Казалось бы истина в заголовке, но я слишком часто встречал менеджеров(Project Manager/Product Owner) которые хотели схитрить и обойти это правило. Они приходят к команде разработки и говорят каждый на свой лад.
Ребят, надо быстро напилить фичу, сделайте ее как-нибудь, презентуем, посмотрим понравится ли клиенту и тогда уже переделаем нормально
Лёха, я знаю про то, что у нас нестабильно работает старый код и надо его переделать, но сейчас надо клиенту фичи показать, выбить деньги и тогда уже согласуем переделку неработающего функционала
Всем привет! Меня зовут Олеся, я СВЧ инженер-разработчик. Проектирую фазовращатели, делители, модули, усилительные блоки и т.п. Веду Инстаграм *запрещён в России и вконтакте; ник везде leka_engineer. Также веду телеграм канал с полезными ссылками. Я пишу это, так как статьи с Хабра иногда воруют.
Начиная новый проект, хорошо вспомнить полезные принципы программирования, которые помогут правильно расставить приоритеты и избежать многих ошибок. Рекомендациями от автора с опытом программирования в 20 лет делимся к старту курса по Читать полностью »
Представьте себе, что вы работаете над довольно сложной программой. Например, с мудрёными математическими расчётами. Вы её компилируете, запускаете в первый раз, она выдаёт ожидаемый результат и работает без ошибок. Скорее всего, в такой ситуации опытный программист сильно удивится и начнет перепроверять свой код: так не бывает, чтобы сложная программа сразу скомпилировалась, заработала, да ещё и не содержала багов.
Всё гораздо серьёзнее. Вот пример для проверки:
#include <iostream>
int main()
{
std::cout << "-3/3u*3 = " << int(-3/3u*3) << "n";
}Посмотреть результат можно тут.
Или попробуйте поиграться с этим примером здесь или здесь.
Вообще-то мне не удалось найти хоть какой-то компилятор С++, который бы выдавал результат отличный от -4. Даже старый GCC-4.1.2, clang-3.0.0 или Borland C 1992 года. Также заметил, что результат одинаковый и для константы, вычисляемой в момент компиляции и для времени выполнения.