Помню, Стив Макконнелл писал, что максимальное комфортное количество аргументов функции равно 7. Ну, плюс-минус 2. Если их будет больше, то работать с функцией станет совсем сложно.
Вообще мнения колеблются от 3 до 7 аргументов. Но мысль одна: много аргументов - плохо.
Тем не менее 👇
Вообще мнения колеблются от 3 до 7 аргументов. Но мысль одна: много аргументов - плохо.
Тем не менее 👇
Какое максимальное количество аргументов функции допустимо в C++?
Anonymous Quiz
0%
15
4%
127
22%
255
74%
Неизвестно. Зависит от реализации
2 минуты осталось или 2 минуты прошло?
Рубрика "Путаница в интерфейсах". Часть 10.
На картинке - виджет фокусировки в Windows. Это стандартное приложение, которое отключает все уведомления на заданное время, помогая сфокусироваться на работе.
Сейчас циферблат виджета показывает 2 минуты. Как вы понимаете эти 2 минуты? Как "2 минуты осталось" или как "2 минуты прошло"?
Я был абсолютно уверен, что 2 минуты прошло и еще 8 осталось.
Но не было бы этой рубрики. На самом деле все наоборот)
С какой-то стати обратный отсчет времени на циферблате начинается с положения 3-х часов. Не с 12-ти, как я подумал изначально.
Я понятия не имею, почему так сделано.
Создается ощущение, что внутри это просто обратный отсчет по тригонометрической окружности от 2π до 0. Кто-то поленился сделать сдвиг на π/2 и поднять начало отсчета наверх? Или тут есть неведомый мне смысл?
Если кто-то знает, напишите)
—
А вы запутались или я один такой?
👍 - Запутался
😁 - Один такой
Рубрика "Путаница в интерфейсах". Часть 10.
На картинке - виджет фокусировки в Windows. Это стандартное приложение, которое отключает все уведомления на заданное время, помогая сфокусироваться на работе.
Сейчас циферблат виджета показывает 2 минуты. Как вы понимаете эти 2 минуты? Как "2 минуты осталось" или как "2 минуты прошло"?
Я был абсолютно уверен, что 2 минуты прошло и еще 8 осталось.
Но не было бы этой рубрики. На самом деле все наоборот)
С какой-то стати обратный отсчет времени на циферблате начинается с положения 3-х часов. Не с 12-ти, как я подумал изначально.
Я понятия не имею, почему так сделано.
Создается ощущение, что внутри это просто обратный отсчет по тригонометрической окружности от 2π до 0. Кто-то поленился сделать сдвиг на π/2 и поднять начало отсчета наверх? Или тут есть неведомый мне смысл?
Если кто-то знает, напишите)
—
А вы запутались или я один такой?
👍 - Запутался
😁 - Один такой
👍9😁2
#include <iostream>
int main() {
const char a = '7';
const char b = '0';
const int c = a - b;
std::cout << c;
return 0;
}
Выше дан код C++. Какой вывод будет у программы?
Anonymous Quiz
43%
7
13%
0
22%
Неизвестно. Неопределенное поведение
22%
Никакой. Ошибка компиляции
Doc As Code: диаграммы PlantUML в Doxygen
ИИ заставляет по-другому смотреть на разработку. Привычные подходы оказываются так себе.
В этом плане ведение документации зацепило знатно. Документация оказалась нужна как никогда) Причем не детальная, а, наоборот, - высокоуровневая. Детали ИИ и сам неплохо соображает по коду. Но вот концепт, архитектуру, идею ему выделить сложно.
И все бы хорошо, документации у нас есть немножко) Но вот схемы и диаграммы... Они в картинках. В целом ИИ умеет в картинки, но делает это плохо и не точно.
Как раз в этот момент я вспомнил про текстовые нотации диаграмм, про PlantUML в частности. Точнее я их и не забывал, но пользовался редко. А тут оказалось, что ИИ отлично понимает, генерирует и редактирует такие диаграммы.
Получив какой-то опыт на нескольких задачах, я доработал свои соображения по принципу Doc As Code для C++ проектов. Если раньше там использовался только Doxygen и Markdown, то теперь добавляется PlantUML. Код, документация и диаграммы полностью состоят из текста и в полном объеме обрабатываются ИИ.
👉 Смотрите в новой статье, что получилось, и пишите, что думаете по этому поводу. Ощущаете необходимость в хорошей документации или с ИИ можно работать и без нее?
—
Читать еще:
- Прошлая статья по Doc As Code для C++
- Зачем нужны UML диаграммы?
ИИ заставляет по-другому смотреть на разработку. Привычные подходы оказываются так себе.
В этом плане ведение документации зацепило знатно. Документация оказалась нужна как никогда) Причем не детальная, а, наоборот, - высокоуровневая. Детали ИИ и сам неплохо соображает по коду. Но вот концепт, архитектуру, идею ему выделить сложно.
И все бы хорошо, документации у нас есть немножко) Но вот схемы и диаграммы... Они в картинках. В целом ИИ умеет в картинки, но делает это плохо и не точно.
Как раз в этот момент я вспомнил про текстовые нотации диаграмм, про PlantUML в частности. Точнее я их и не забывал, но пользовался редко. А тут оказалось, что ИИ отлично понимает, генерирует и редактирует такие диаграммы.
Получив какой-то опыт на нескольких задачах, я доработал свои соображения по принципу Doc As Code для C++ проектов. Если раньше там использовался только Doxygen и Markdown, то теперь добавляется PlantUML. Код, документация и диаграммы полностью состоят из текста и в полном объеме обрабатываются ИИ.
👉 Смотрите в новой статье, что получилось, и пишите, что думаете по этому поводу. Ощущаете необходимость в хорошей документации или с ИИ можно работать и без нее?
—
Читать еще:
- Прошлая статья по Doc As Code для C++
- Зачем нужны UML диаграммы?
👍5
Снова и снова сводит олдскулы на курсе по обратной разработке)
ASM, DOS, BIOS, MBR...
Когда-то давно все это было на слуху. Примерно тогда, когда "переустановить винду" было чем-то само собой разумеющимся. Постоянно что-то слетало, что-то не работало... Приходилось ковыряться.
А сейчас все как-то надежнее что ли стало. Пару лет назад я менял ноутбук просто потому, что он устарел) Но за все время его использования я ни разу не менял ОС. Может, просто повезло. Может, лень возиться. Не знаю...
Но к чему это я. А вы помните, что такое MBR? 😁👇
ASM, DOS, BIOS, MBR...
Когда-то давно все это было на слуху. Примерно тогда, когда "переустановить винду" было чем-то само собой разумеющимся. Постоянно что-то слетало, что-то не работало... Приходилось ковыряться.
А сейчас все как-то надежнее что ли стало. Пару лет назад я менял ноутбук просто потому, что он устарел) Но за все время его использования я ни разу не менял ОС. Может, просто повезло. Может, лень возиться. Не знаю...
Но к чему это я. А вы помните, что такое MBR? 😁👇
🥰2
Мементо
Недавно посмотрел "Мементо" Нолана.
Честное слово, главный герой - ходячая нейросеть. Он помнит все, что было до болезни, но не может вспомнить события нескольких минут назад. Как у нейросети: предобученная база и ограниченный оперативный контекст)
Чтобы хоть как-то удержать ниточку событий, герой носится со своими фотокарточками и заметками, как Клод с
Фильм смотрится сложно. Мне проще переваривать что-то линейное типа "Колобка": сбежал из дома, пообщался с местными, пал жертвой афериста. Все просто.
А тут... Не просто.
Но вывод есть: хорошо, что нейросеть - это машина без ручек и ножек 😅
—
В следующем материале поговорим как раз про ведение заметок и почему ИИ здесь выступает триггером.
Недавно посмотрел "Мементо" Нолана.
Честное слово, главный герой - ходячая нейросеть. Он помнит все, что было до болезни, но не может вспомнить события нескольких минут назад. Как у нейросети: предобученная база и ограниченный оперативный контекст)
Чтобы хоть как-то удержать ниточку событий, герой носится со своими фотокарточками и заметками, как Клод с
Claude.md. Получается у него или нет - судить зрителю. Я свое мнение придержу. Фильм смотрится сложно. Мне проще переваривать что-то линейное типа "Колобка": сбежал из дома, пообщался с местными, пал жертвой афериста. Все просто.
А тут... Не просто.
Но вывод есть: хорошо, что нейросеть - это машина без ручек и ножек 😅
—
В следующем материале поговорим как раз про ведение заметок и почему ИИ здесь выступает триггером.
👍3😁2
Кто там голосовал, что не сохраняет ссылки и не ведет базу знаний, а?
Вот, пожалуйста:
Поясню.
Когнитивная разгрузка возникает, когда мы полностью полагаемся на ИИ. Знание, которое ИИ использовал для решения задачи, для нас теряется. Долгосрочно тут ничего хорошего. Если, конечно, мы не выделим это знание и не зафиксируем его.
Так рождается база знаний. Это могут быть не только личные заметки, но и любые другие виды документации, вроде корпоративных вики. База знаний - это то место, где мы делимся знанием как с самим собой в будущем, так и со всеми остальными, кто имеет к ней доступ.
Ведение базы знаний помогает частично решить проблемы с:
- Запоминанием. Изложение материала своими словами способствует усвоению. Да-да, простое "копировать-вставить" не сработает. Хотя это лучше, чем ничего.
- Удержанием знаний. Хорошо, когда есть, куда заглянуть. Поиск по ключевым словам лучше работает с заметками, чем с головой. Особенно если в голове ничего и не было.
- Подготовкой новых специалистов. Хоть это и не очевидно, но... Если у всех будут проблемы с удержанием знаний, то кто будет обучать следующее поколение инженеров? Чат-боты? Похоже, что да. Но на что это будет похоже, я не знаю.
На самом деле, все это работало и до распространения ИИ. Просто было не так актуально. Тот же поисковик далеко не всегда давал ответ на вопрос - надо было покопаться, почитать, разобраться. Хочешь - не хочешь, а запомнишь.
Теперь все по-другому. Знание не просто доступно, знание - не нужно. На любой вопрос есть ответ. Остается его просто принять. Поэтому 👇
Делайте заметки, конспектируйте, систематизируйте. Со временем это войдёт в привычку. Со временем база знаний начнёт работать на вас. А когнитивная разгрузка из-за использования ИИ потеряет свое разрушающее действие.
—
Выше я упомянул, что эффект от когнитивной разгрузки будет заметен в долгосрочной перспективе. В следующий раз поговорим о том, почему важно и нужно смотреть в долгосрок.
Вот, пожалуйста:
Использование инструментов ИИ неизбежно... особенно если вы молодой человек, стремящийся получить преимущество на все более сложном рынке труда. Но когнитивная разгрузка опасна в любом возрасте. Накопление базы знаний может спасти ваш мозг и навыки от атрофии.
Поясню.
Когнитивная разгрузка возникает, когда мы полностью полагаемся на ИИ. Знание, которое ИИ использовал для решения задачи, для нас теряется. Долгосрочно тут ничего хорошего. Если, конечно, мы не выделим это знание и не зафиксируем его.
Так рождается база знаний. Это могут быть не только личные заметки, но и любые другие виды документации, вроде корпоративных вики. База знаний - это то место, где мы делимся знанием как с самим собой в будущем, так и со всеми остальными, кто имеет к ней доступ.
Ведение базы знаний помогает частично решить проблемы с:
- Запоминанием. Изложение материала своими словами способствует усвоению. Да-да, простое "копировать-вставить" не сработает. Хотя это лучше, чем ничего.
- Удержанием знаний. Хорошо, когда есть, куда заглянуть. Поиск по ключевым словам лучше работает с заметками, чем с головой. Особенно если в голове ничего и не было.
- Подготовкой новых специалистов. Хоть это и не очевидно, но... Если у всех будут проблемы с удержанием знаний, то кто будет обучать следующее поколение инженеров? Чат-боты? Похоже, что да. Но на что это будет похоже, я не знаю.
На самом деле, все это работало и до распространения ИИ. Просто было не так актуально. Тот же поисковик далеко не всегда давал ответ на вопрос - надо было покопаться, почитать, разобраться. Хочешь - не хочешь, а запомнишь.
Теперь все по-другому. Знание не просто доступно, знание - не нужно. На любой вопрос есть ответ. Остается его просто принять. Поэтому 👇
Делайте заметки, конспектируйте, систематизируйте. Со временем это войдёт в привычку. Со временем база знаний начнёт работать на вас. А когнитивная разгрузка из-за использования ИИ потеряет свое разрушающее действие.
—
Выше я упомянул, что эффект от когнитивной разгрузки будет заметен в долгосрочной перспективе. В следующий раз поговорим о том, почему важно и нужно смотреть в долгосрок.
👍5🙏2❤1
Последнее время я набрал столько обязательств, что физически не успеваю выгребать. Часть проектов поставил на паузу, от части вообще отказался.
Понимаете ли, мне давно не 23, и просто сказать "выгорел" я не могу. Выгорает тот, кто не знает, что делать. А я знаю: выкидываем все необязательное и давим на обязательное, чтобы поскорее вернуть обратно необязательное 😁
Блог - уже тоже обязательство и на паузу не встанет. Да, пока "хардовых" материалов и викторин будет поменьше (их сложно писать), а "софтовых" и общенаправленных - побольше. Здесь есть, что сказать, и когда, если не сейчас.
Понимаете ли, мне давно не 23, и просто сказать "выгорел" я не могу. Выгорает тот, кто не знает, что делать. А я знаю: выкидываем все необязательное и давим на обязательное, чтобы поскорее вернуть обратно необязательное 😁
Блог - уже тоже обязательство и на паузу не встанет. Да, пока "хардовых" материалов и викторин будет поменьше (их сложно писать), а "софтовых" и общенаправленных - побольше. Здесь есть, что сказать, и когда, если не сейчас.
🔥8👏1🙏1
Работать долго
Чтобы повысить свои шансы добиться хоть чего-нибудь, надо работать долго.
Что это значит?
Ну, например, готовы ли вы держать пари на $1 000 000, поставив на решку в подбрасывании монеты? Нет? А если я скажу, что у вас есть не одна, а 100 попыток ее подбросить? Заманчиво? Мы понимаем, что с таким количеством попыток резко возрастает вероятность выигрыша.
В любом другом деле все то же самое. Чем больше мы пробуем, тем выше наши шансы на успех. Только мы не можем их измерить.
В книге "Одураченные случайностью" Талеб пишет:
Там же приводится пример с ученым, день за днем разделывающим мышей в своей лаборатории. Ничего стоящего и прорывного у него не выходит. Некоторые, в том числе и собственная жена, считают ученого неудачником. НО: с каждым днем вероятностно он оказывается все ближе и ближе к конечному результату.
При этом мало просто долго работать. Наша работа должна быть долгосрочно устойчивой и качественной.
Талеб пишет:
Так и в нашей работе. Неплохо бы быть готовым воспользоваться "вкусными" возможностями в любой момент.
Q: Как быть готовым?
A: Работать долго, устойчиво и качественно.
Q: Как работать качественно?
A: Постоянно учиться.
Q: Как постоянно учиться?
A: Сомневаться в собственной исключительности, искать и признавать свои некомпетенции.
Вот такой просто рецепт.
Инвестируйте в себя и работайте долго.
#КнижнаяПолка
📍 Нассим Николас Талеб - "Одураченные случайностью" (2001)
—
Позже расскажу об одном из неочевидных моментов в профессии программиста - предсказуемости.
Чтобы повысить свои шансы добиться хоть чего-нибудь, надо работать долго.
Что это значит?
Ну, например, готовы ли вы держать пари на $1 000 000, поставив на решку в подбрасывании монеты? Нет? А если я скажу, что у вас есть не одна, а 100 попыток ее подбросить? Заманчиво? Мы понимаем, что с таким количеством попыток резко возрастает вероятность выигрыша.
В любом другом деле все то же самое. Чем больше мы пробуем, тем выше наши шансы на успех. Только мы не можем их измерить.
В книге "Одураченные случайностью" Талеб пишет:
Конечно, в игре с ясно и недвусмысленно определенными правилами шансы можно вычислить, а риски измерить. Но не в реальном мире. Ведь мать-природа не подарила нам четкие правила. Эта игра не колода карт (мы даже не знаем, сколько в ней мастей).
Там же приводится пример с ученым, день за днем разделывающим мышей в своей лаборатории. Ничего стоящего и прорывного у него не выходит. Некоторые, в том числе и собственная жена, считают ученого неудачником. НО: с каждым днем вероятностно он оказывается все ближе и ближе к конечному результату.
При этом мало просто долго работать. Наша работа должна быть долгосрочно устойчивой и качественной.
Талеб пишет:
То же касается издателей: они могут выпускать одну книгу за другой, и к их бизнес-модели не будет никаких вопросов, если однажды раз в десять лет они не взорвутся серией супербестселлеров масштаба Гарри Поттера - конечно, при условии, что они делают работу качественно, а у их книг есть вероятность стать бестселлерами.
Так и в нашей работе. Неплохо бы быть готовым воспользоваться "вкусными" возможностями в любой момент.
Q: Как быть готовым?
A: Работать долго, устойчиво и качественно.
Q: Как работать качественно?
A: Постоянно учиться.
Q: Как постоянно учиться?
A: Сомневаться в собственной исключительности, искать и признавать свои некомпетенции.
Вот такой просто рецепт.
Инвестируйте в себя и работайте долго.
#КнижнаяПолка
📍 Нассим Николас Талеб - "Одураченные случайностью" (2001)
—
Позже расскажу об одном из неочевидных моментов в профессии программиста - предсказуемости.
🙏5👍3
К середине дня заметил, что заряда на телефоне осталось на 30 с чем-то процентов. При том, что телефон я практически не трогал.
Сначала подумал, что аккум приказал долго жить. Но по факту весь заряд вытянул фоновый WhatsApp 🤯, про существование которого я уже успел забыть.
Мораль: не спешите ругать стареющий аккумулятор - возможно его просто кто-то активно жрет.
Сначала подумал, что аккум приказал долго жить. Но по факту весь заряд вытянул фоновый WhatsApp 🤯, про существование которого я уже успел забыть.
Мораль: не спешите ругать стареющий аккумулятор - возможно его просто кто-то активно жрет.
🤯5
Предсказуемость
Нам нравится, когда все предсказуемо. Это снижает стресс.
Представьте оживленную улицу большого города. Человек, не знающий правил, не может двигаться безопасно. Ни пешком, ни на транспорте. Однако новичок после автошколы - может. Почему? Потому что для него почти все вокруг предсказуемо. Но стресс все равно остается, так как есть много негласных правил. Когнитивная нагрузка все равно колоссальная. Но со временем негласные правила тоже усвоятся и вчерашнему новичку понравится водить. Потому что все вокруг станет более предсказуемым.
Или представьте своих друзей. Отчасти они вам нравятся из-за своей предсказуемости. В новом кругу лиц нам скорее не комфортно. Мы не знаем, чего ждать от других. Но если, например, это новый круг по интересам, то стресса будет меньше, так как эти люди уже более-менее предсказуемы.
В разработке то же самое: нам нравится работать там, где больше предсказуемости. Иначе - стресс.
Вопрос не только в предсказуемости руководства, команды, задач, процессов и вас, как специалиста. Хотя это крайне важно и первым приходит на ум. Но есть менее очевидная вещь: предсказуемость проекта и его кодовой базы.
Я под этим понимаю примерно следующее:
- Код выглядит так, как указано в стайл-гайде.
- Функция или класс делает именно то, что написано в документации.
- Имена сущностей раскрывают их назначение.
- Структура проекта единообразна от компонента к компоненту.
- Сообщения коммитов поясняют изменения, а не просто существуют.
- Код использует общеизвестные практики и шаблоны.
- Частное зависит от общего, а не наоборот.
Придумывать пункты можно долго, но посыл будет сохраняться: с предсказуемым кодом работать легче. Что ожидаешь, то и получаешь. Снижается когнитивная нагрузка, сокращается время разработки, случается меньше ошибок, уменьшается стресс. И это не только про разработчиков. ИИ тоже будут меньше "стрессовать") Плюсов много, минусов - нет.
Мне нравится предсказуемость. Челленджи, конечно, никто не отменял. Но не каждый же день челленджить, м?
А что для вас является самым непредсказуемым и стрессовым в работе? Баги? Коллеги? Новые задачи? Или, может быть, релизы?
—
Кстати, я накопал подход, который делает предсказуемой... работу с багами. Обязательно расскажу.
Нам нравится, когда все предсказуемо. Это снижает стресс.
Представьте оживленную улицу большого города. Человек, не знающий правил, не может двигаться безопасно. Ни пешком, ни на транспорте. Однако новичок после автошколы - может. Почему? Потому что для него почти все вокруг предсказуемо. Но стресс все равно остается, так как есть много негласных правил. Когнитивная нагрузка все равно колоссальная. Но со временем негласные правила тоже усвоятся и вчерашнему новичку понравится водить. Потому что все вокруг станет более предсказуемым.
Или представьте своих друзей. Отчасти они вам нравятся из-за своей предсказуемости. В новом кругу лиц нам скорее не комфортно. Мы не знаем, чего ждать от других. Но если, например, это новый круг по интересам, то стресса будет меньше, так как эти люди уже более-менее предсказуемы.
В разработке то же самое: нам нравится работать там, где больше предсказуемости. Иначе - стресс.
Вопрос не только в предсказуемости руководства, команды, задач, процессов и вас, как специалиста. Хотя это крайне важно и первым приходит на ум. Но есть менее очевидная вещь: предсказуемость проекта и его кодовой базы.
Я под этим понимаю примерно следующее:
- Код выглядит так, как указано в стайл-гайде.
- Функция или класс делает именно то, что написано в документации.
- Имена сущностей раскрывают их назначение.
- Структура проекта единообразна от компонента к компоненту.
- Сообщения коммитов поясняют изменения, а не просто существуют.
- Код использует общеизвестные практики и шаблоны.
- Частное зависит от общего, а не наоборот.
Придумывать пункты можно долго, но посыл будет сохраняться: с предсказуемым кодом работать легче. Что ожидаешь, то и получаешь. Снижается когнитивная нагрузка, сокращается время разработки, случается меньше ошибок, уменьшается стресс. И это не только про разработчиков. ИИ тоже будут меньше "стрессовать") Плюсов много, минусов - нет.
Мне нравится предсказуемость. Челленджи, конечно, никто не отменял. Но не каждый же день челленджить, м?
А что для вас является самым непредсказуемым и стрессовым в работе? Баги? Коллеги? Новые задачи? Или, может быть, релизы?
—
Кстати, я накопал подход, который делает предсказуемой... работу с багами. Обязательно расскажу.
👍7🤯3
Тэкс, этот пушистый мистер залез, накодил, запустил сборку, получил кучу ошибок, развернулся и потребовал ласки.
Ну чем не так себе программист? 😄
Ну чем не так себе программист? 😄
❤10🥰4
Fixit Week
Ранее я писал, что работу над багами можно сделать предсказуемой. Для этого кто-то придумал Fixit Week.
Сразу скажу, что я этот подход никогда не использовал и не участвовал в чем-то подобном. Да и не факт, что поучаствую. Но об этом позже.
Идея Fixit Week - это массовая починка багов в течение недели. Разработка фич приостанавливается на неделю и вся команда бросается на баги, которые бесят и пользователей, и разработчиков.
Движ происходит раз в квартал, что в принципе не часто. Список багов готовится и выверяется заранее: баг не должен занимать более 2-х дней работы. Тяжелые и неисследованные баги отфильтровываются, чтобы не сбивать ритм команды. За каждый исправленный баг начисляются баллы, а в конце по накопленным баллам вручаются призы.
Автор утверждает, что народ кайфует от процесса. Короткие задачи и награды дают чувство удовлетворенности, а количество багов в трекере уменьшается на глазах. В принципе, я охотно верю. Мне тоже нравится фиксить всякие мелочи. Как быстрый дофамин.
Я хотел бы провернуть что-то подобное, но скорее всего не смогу продвинуть такую идею в команде. Причин несколько:
1. Fixit Week не вписывается в привычный производственный процесс. А менять процессы всегда сложно. Особенно когда они заточены на производство фич.
2. Fixit Week требует подготовки. Баги надо выбрать и систематизировать. Это большая работа. Ради нее кому-то придется надолго бросить свои дела.
3. Разные баги - разные контексты. Перепрыгивая с бага на баг, разработчик будет переключать контекст не только в голове, но и в среде разработки. Не каждому это понравится и точно отнимет время.
По собственному опыту - причины существенные. Хотя блокирующими их не назовешь. С хорошей аргументацией и системным подходом все можно настроить: и процессы, и контексты.
Было бы интересно узнать, есть ли в вашей команде какие-нибудь спринты или итерации, выделенные чисто на починку багов всей командой? Пишите, если у кого-то есть что-то похожее.
Ранее я писал, что работу над багами можно сделать предсказуемой. Для этого кто-то придумал Fixit Week.
Сразу скажу, что я этот подход никогда не использовал и не участвовал в чем-то подобном. Да и не факт, что поучаствую. Но об этом позже.
Идея Fixit Week - это массовая починка багов в течение недели. Разработка фич приостанавливается на неделю и вся команда бросается на баги, которые бесят и пользователей, и разработчиков.
Движ происходит раз в квартал, что в принципе не часто. Список багов готовится и выверяется заранее: баг не должен занимать более 2-х дней работы. Тяжелые и неисследованные баги отфильтровываются, чтобы не сбивать ритм команды. За каждый исправленный баг начисляются баллы, а в конце по накопленным баллам вручаются призы.
Автор утверждает, что народ кайфует от процесса. Короткие задачи и награды дают чувство удовлетворенности, а количество багов в трекере уменьшается на глазах. В принципе, я охотно верю. Мне тоже нравится фиксить всякие мелочи. Как быстрый дофамин.
Я хотел бы провернуть что-то подобное, но скорее всего не смогу продвинуть такую идею в команде. Причин несколько:
1. Fixit Week не вписывается в привычный производственный процесс. А менять процессы всегда сложно. Особенно когда они заточены на производство фич.
2. Fixit Week требует подготовки. Баги надо выбрать и систематизировать. Это большая работа. Ради нее кому-то придется надолго бросить свои дела.
3. Разные баги - разные контексты. Перепрыгивая с бага на баг, разработчик будет переключать контекст не только в голове, но и в среде разработки. Не каждому это понравится и точно отнимет время.
По собственному опыту - причины существенные. Хотя блокирующими их не назовешь. С хорошей аргументацией и системным подходом все можно настроить: и процессы, и контексты.
Было бы интересно узнать, есть ли в вашей команде какие-нибудь спринты или итерации, выделенные чисто на починку багов всей командой? Пишите, если у кого-то есть что-то похожее.
👍3🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
"Мы встроили отключение подписки в отключение подписки, чтобы вы могли отключить подписку, пока отключаете подписку"
"Но перед этим вы 15 минут проведёте в приложении, чтобы понять, что подписку нельзя отключить в приложении и перейдёте на сайт"
"А уже на сайте мы встроили отключение подписки в отключение подписки, чтобы вы..."
Пятерочка умеет развлекать. 6 раз нажал кнопку, 6 раз, Карл! 🤯
"Но перед этим вы 15 минут проведёте в приложении, чтобы понять, что подписку нельзя отключить в приложении и перейдёте на сайт"
"А уже на сайте мы встроили отключение подписки в отключение подписки, чтобы вы..."
Пятерочка умеет развлекать. 6 раз нажал кнопку, 6 раз, Карл! 🤯
😁5🤯3
Замечали, что в мессенджерах и чат-ботах всегда надо думать, по какой клавише перейти на новую строку в сообщении?
Клац, и вместо перехода на новую строку, недописанное сообщение улетает адресату!
Всю жизнь... Всю жизнь я набираю тексты в текстовых редакторах, в среде разработки, в почтовых клиентах и т.п. Везде новая строка - это Enter. Везде так было, везде так есть.
Но какого-то лешего в чатах, где я тоже набираю текст, новая строка - это догадайся, что.
В каждом мессенджере, в каждом ИИ-чате это сделано по-своему. И практически нигде клавишу нельзя настроить.
Почему так? Видимо, потому что.
Заслуживает быть 11-ой частью рубрики "Путаница в интерфейсах".
—
Ну боль же, да?
💯 - Боль
😁 - Не-а, мне норм
Enter ?Shift + Enter ?Ctrl + Enter ?Неведома зверушка + Enter ?Клац, и вместо перехода на новую строку, недописанное сообщение улетает адресату!
Всю жизнь... Всю жизнь я набираю тексты в текстовых редакторах, в среде разработки, в почтовых клиентах и т.п. Везде новая строка - это Enter. Везде так было, везде так есть.
Но какого-то лешего в чатах, где я тоже набираю текст, новая строка - это догадайся, что.
В каждом мессенджере, в каждом ИИ-чате это сделано по-своему. И практически нигде клавишу нельзя настроить.
Почему так? Видимо, потому что.
Заслуживает быть 11-ой частью рубрики "Путаница в интерфейсах".
—
Ну боль же, да?
💯 - Боль
😁 - Не-а, мне норм
💯12😁3