Pull to refresh
41
0
Друг @kk86

Пользователь

Send message

В Amazon таких нет, представляете? Есть много команд, пилящих инфраструктуру (для пайплайнов в том числе). Но каждая сервисная команда сата содержит свои пайплайны — DevOps

1 < 2 < 3
true

паубивав бы за такие грязные хаки!


-2 < -1 < 0
false
уйма задач, разработчика особо не касающихся:

"Pipeline сломат" — это моя проблема.


"QA несогласны" — это моя проблема.


"performance просел" — это моя проблема.


"не дали времени на..." — это проблема либо моя (плохо сигнализирую "красные флаги"), но чаще — менеджмента с "датой наперед" в голове плюс с пресловутым "и так сойдет".


image

It depends. Иными словами, не все. Наша основная проблема в том, что многие утверждают "задача выполнена", когда на деле — нет. классическая такая "Developer calls it done".


image


Лично меня разбирает сарказм, когда в попытке угодить менеджменту и срокам сверху разработчики упускают слишком много дефектов.


Я борюсь за Scrum's "done-done-done". Чаще всего, это требует замедления команды. И как правило, это воспринимают это как элементарное "сделать как можно меньше и получить за это как можно больше", а не как профессионализм и борьбу за Качество.


Так яснее?

то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше

O'RLY? Смею предположить, что это, мягко говоря, не так. Особенно если в вашей компании толковые разработчики.

Это ее перефразирование, поскольку утрачен исходный смысл. Я вижу большую разницу между "планы бесполезны, но важны" и "планы ничего не стоят, но планирование это всё".
Так или иначе, моя мысль была о том, что планы ценны даже если и не соблюдаются и на 50%. Спасибо, что дали подсказку про первоисточник.

Планы бесполезны, но важны

Что бы это значило? Это шутка такая?


Да, планы как правило не выполняются. Это совсем не значит, что они бесполезны. Максимум, план может иметь ограниченную полезность для конкретного применения (равно как и любой другой инструмент).


План это модель прогресса проекта.


All models are wrong but some are useful — George E. P. Box

"Количество полезности" плана, риски (стоимость) игнориования/фиксации плана, и многое другое определяют степень его важности.

Про 95% — чистая правда, но не все это понимают. Недавно пересаживал одну команду с архаики SVN на Git. БОльшая часть команды осваивала постепенно с базовых 5 команд к чему-то поумнее, типа cherry-pick, rebase [-i], и так далее. Но были и люди, которые привыкли учить что-либо "наскоком и целиком", как по учебнику. Вот они страдали больше, потому что learning curve выглядел для них хуже...

Привязка к корп серверу и интернету вообще большое зло. Автономность с Hg/Git/… даёт большой выйгрыш при "переключении контекста".

Спасибо за комментарий по существу вместо балабольства о жигулях vs мерседесах!


Можете привести пример того, когда важно знать, в какой ветке родился commit? С Git это и правда не определить. Так что, например, после cherry-pick так сразу и не скажешь, что откуда пришло (но мне и не приходилось задаваться вопросом).

охоту моих далеких предков на мамонта… Только предки полагались на свою физическую силу, а мы вместо этого используем силу своего интеллекта.

Really?


https://www.quora.com/How-did-prehistoric-humans-kill-mammoths

Насколько можно доверять вашим замерам? Полноценный бенчмаркинг дело нелегкое, люди обычно пишут используют фреймворки, чтобы замеры были как можно более чистыми. По типу https://github.com/dotnet/BenchmarkDotNet для .NET

Как я вас понимаю!

Всем известно, что в России самые лучшие программисты.

дальше читать не стал.

sorttest.zip во времена GitHub :(

Статья переводная…
Если я правильно понимаю, то библиотека собирает из оригинальных бенчмарков другие бинарные артефакты, которые используются непосредственно в рантайме для оценки времени исполнения. А как дебажить это дело, если, брейкпойнты привязаны к оригинальному коду и ничего их волшебно не отображает на правильные места в новых бинарниках?
> Как может выглядеть параноидальное программирование? Вот типичный пример на Java

И дальше идет пример параноидального программирования. Это совсем не то же самое, что и защитное программирование.

«защитное программирование» это не есть «стелить солому везде, где только можно»

Information

Rating
Does not participate
Location
Seattle, Washington, США
Registered
Activity