Админы vs Программисты

Balancer> Ну а как МП программиста влияет на IT-проблемы в сторонних организациях?

в сторонних - т.е. когда программист ( а скорее администратор) - пожарный по внешним вызовам - конечно тут будет похоже на работу пожарных.

Но при чем тут программирование?

Balancer> Но это опять уровень не самого программиста. На уровне программиста авралы могут быть столь же внешней причиной, что пожары у пожарного.

у админа могут. У программиста - не понимаю.

Balancer> Например, у нас в конторе сейчас два квалифицированных админа и штук 5 программистов. Но я единственный, кто и то, и другое, умеет делать хорошо Конечно, админы ещё старой закалки, и скрипты слепить умеют, и найти/поменять строчку в исходнике. Но вот писать софт они уже не умеют. Ну а программисты даже не знают, что такое ssh

вот это нормальная ситуация. каждому свое.

Balancer> Ну, ты описываешь идеальный мир. В котором МП не берётся за авральные проекты, программисты живут размеренной жизнью, заодно и ошибок никогда не допускают, способных привести к авралам

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

а то напоминает анекдот про переговоры
- вы можете это сделать?
-да, это стоит два миллиона
- но у нас есть только 10 тысяч
- за 10 тыс мы этого не сделаем
- как? а нам вас рекомендовали, как хороших специалистов.

16-й> Нормального МП никто и спрашивать не станет, его поставят перед фактом.

ну это опять проблемы менеджемента - только не МП, а руководства компании.

16-й> После чего он может а) уволиться,

да, бежать надо от такого руководства.

16-й> б) поставить руководство перед фактом, как именно все будет происходить, в том числе в части сверхнормативной мотивации исполнителей. а) не так уж часто происходит, гораздо чаще б). Далее у руководства с точным прогнозом будет свой гемморой - выкрутиться перед заказчиком, а у МП и вверенного ему контингента будет аврал.

разумное руководство привлечет квалифицированного МП еще на этапе переговоров.
Если оно этого не хочет - не хочет понимать реальные сроки и реальные потребности в ресурсах - то отсюда надо бежать.

maitredesir>> На интеграцию должна отдельная команда собираться, имхо. И твой должен тебя от дебилов защищать.
yacc> Откуда ты такое взял?
yacc> Это нигде в должностных инструкциях не прописано.

это должно быть прошито в мозгу у МП, если он не калиф на час.
если он идиот - то действительно - зачем?

16-й> Более того, авральность вообще может быть заложена в исходные условия найма. Точнее она туда как правило заложена, только с иксовой на..кой.

ну так это опять же проблема поганого менеджемента.

maitredesir>>> На интеграцию должна отдельная команда собираться, имхо. И твой должен тебя от дебилов защищать.
yacc>> Откуда ты такое взял?
yacc>> Это нигде в должностных инструкциях не прописано.
Iva> это должно быть прошито в мозгу у МП

Слово "должен" должно быть формализовано. Иначе это требование к "идеальному мужчине" у теток.
и "имхо" как бы намекает - что это хотение а не формальность.

Iva> ну так это опять же проблема поганого менеджемента.
Авралы встречаются везде потому что все ситуации предусмотреть невозможно.
Второй вопрос, что если они систематические - то это косяк управления. Начиная от контактов с заказчиком - чтобы узнать его желания в т.ч. с некоторым запасом, до методики работы и подбора кадров на те или иные должности

yacc> Слово "должен" должно быть формализовано. Иначе это требование к "идеальному мужчине" у теток.
yacc> и "имхо" как бы намекает - что это хотение а не формальность.

это личная необходимость для хорошего менеджера. И его личный выбор - быть хорошим менеджером или не быть.

внешняя среда ( начальство) всегда будет давить, что бы этого у менеджера не было. Но это его самозащита и вопрос выживания. За прогиб в этой части - неразумное сокращение сроков и потребных ресурсов - он будет в ответе, а не начальство, которое ему такие решения навязало.

никто ему помогать в деле не отвечать за косяки чужого дядьки помогать не будет. И формализовать этого не будет. Это его личный интерес и личная забота.

yacc>> и "имхо" как бы намекает - что это хотение а не формальность.
Iva> это личная необходимость для хорошего менеджера. И его личный выбор - быть хорошим менеджером или не быть.
"Хороших менеджеров" статистически - ну 10-15%.
Но даже со средним менеджером и с формализацией - проект пойдет нормально.
В разработке ПО, в отличии от скажем кадрового агенства или рекламной фирмы - формализовать вполне себе можно.

yacc> Но даже со средним менеджером и с формализацией - проект пойдет нормально.

для хорошей формализации очень много надо поработать. И качественно.

yacc> В разработке ПО, в отличии от скажем кадрового агенства или рекламной фирмы - формализовать вполне себе можно.

согласен.
но, как правило, не умеют или лень.

Mishka> Напрямую. Любой итеративный метод — приближённый. Количество итераций бывает огромным. Поэтому нормально учат, как об этом думать и, как обрабатывать.

Двадцатый раз повторяю. Они не понимают, то такое двоичное представление данных. При чем тут приближенные методы и количество итераций? Я тебе о теплом, ты мне о мягком.

Mishka> Бесконечные дроби есть и в десятичной. Их тоже надо представлять. И представлять в двоичном виде тоже. Значит думаешь о разрядностях, о скорости накопления ошибки, о мантисе с характеристикой.

Ну бывают (хотя вопрос не о них). Ну думаешь. Как решает то? Так то, если думаешь, то вообще все проблемы решаются.

tarasv> Те, у кого маскимум г**нокодинг в них до выпуска обычно не доживают. Но есть и другие универы, для выпускников которых хоть както обойдти дерево уже проблема.

Вот. Именно такая проблема.

tarasv> Вычмат на раз приучает помнить о точностью вычислений. Естественно если его не преподают в виде курса по пользованию Mathlab.

Точность это прекрасно, но им до точности как до Китая пешком. Вычмат для них - это как первокласнику интегралы.

tarasv> Это не инженерные, а финансовые рассчеты, если уж на них тонут, то на инженерных даже "ква" сказать не успеют.

В финансовых да, экономика и все прочее.
Но есть еще задачи управления технологическим процессом. Их тоже приходится решать, а там надо учитывать, что даже если бункер, засыпая в электросталеплавилку примеси для получения нужного химсостава, имеет минимальный объем/массу выдачи, то всегда есть мужик с лопатой, который подбежит и докинет (и это не шутка). Так что считать с фиксированной точностью не всегда получается.

maitredesir> Двадцатый раз повторяю. Они не понимают, то такое двоичное представление данных. При чем тут приближенные методы и количество итераций? Я тебе о теплом, ты мне о мягком.

Тебе, видимо, методов вычислений нормально не читали? Иначе бы проблем с пониманием не было бы. Двоичное представления очень маленькая часть одной проблемы. И ничем не отличается от десятичного... Представь 1/3 в десятичной...


maitredesir> Ну бывают (хотя вопрос не о них). Ну думаешь. Как решает то? Так то, если думаешь, то вообще все проблемы решаются.
Есть стандартные методы. В далёком 1982-1984 нормально учили. В том числе и новые методы вычислений разрабатывать. Соотвественно, требования к методам, которые надо удовлетворять — сходимость там с доказательством существования решения, оценка точности и прочее. Поэтому вопрос о двоичном представлении ничем не отличается от представления в десятичном. А про десятичное все знают, только подумать не особо желают... И представление той же 1/3, как десятичную 0.(3) проходят ещё в школе. Раньше, так ещё атестата за 8 класс не имел, а уже такие вещи чел выучивал.

кщееш> Встретилось

Прикольно. Прочитал и вижу 100% эффект Барнума Как обычно, эффект рассеивается, если разобрать потезисно и применить как к другим группам людей, так и к другим известным программистам

кщееш>> Встретилось
Balancer> Прикольно. Прочитал и вижу 100% эффект Барнума Как обычно, эффект рассеивается, если разобрать потезисно и применить как к другим группам людей, так и к другим известным программистам

Вот не нуди!

" Прикольно " было достаточно жеж.

кщееш> Вот не нуди!

В каждом из нас есть маленький ED

Iva> разумное руководство привлечет квалифицированного МП еще на этапе переговоров.

Iva, ты может какой-то особый, свой смысл вкладываешь в "разумность" руководства? Какой-то социалистический или гуманитарно-социальный? Ты разъясни, а то мы может о разном говорим.

Руководство ай-ти лавочки ставится владельцем лавочки, быть может коллективным. И разумность руководства оценивается этим самым владельцем. В основном через финансовые показатели. Наемное руководство успешно кующее бабло с точки зрения владельца бизнеса оно охренеть как разумно. Поэтому привлекать на этапе переговоров оно может хоть уборщицу до кучи, но цель при этом ставит строго одну - заработать денег и не обосраться (что в виде штрафов укладывается туда же - заработать денег). Да, разумеется, авральность проекта разумное руководство будет учитывать как риск. Но не как риск перенапрячь батраков-программистов, а как риск влететь на договорные санкции. Именно для этого нужны МП и разные уборщицы на этапе переговоров. Если оценка величины этого риска укладывается в политику ай-ти лавочки, то проекту быть, и авралам быть, при очевидной разумности руководства.

Iva> Если оно этого не хочет - не хочет понимать реальные сроки и реальные потребности в ресурсах - то отсюда надо бежать.

Ну, это твое личное дело: бежать или за солидную заплату рожать.
Тезис про ненормальность авралов в работе программеров - идиотский в принципе. Потенциальная авральность составляет определенную долю рынка ай-ти разработок. А раз есть спрос, значит будет и предложение.

16-й> Iva, ты может какой-то особый, свой смысл вкладываешь в "разумность" руководства? Какой-то социалистический или гуманитарно-социальный? Ты разъясни, а то мы может о разном говорим.

разумное руководство, которое не хочет обосраться с проектом. Как по срокам, так и по затратам.

16-й> Но не как риск перенапрячь батраков-программистов, а как риск влететь на договорные санкции. Именно для этого нужны МП и разные уборщицы на этапе переговоров.

там еще есть даже чисто технические риски.
Грубо говоря одна строчка в ТЗ (или ее другая формулировка) может повлечь увеличение стоимости проекта в разы.

16-й> Если оценка величины этого риска укладывается в политику ай-ти лавочки, то проекту быть, и авралам быть, при очевидной разумности руководства.

да.

16-й>> Если оценка величины этого риска укладывается в политику ай-ти лавочки, то проекту быть, и авралам быть, при очевидной разумности руководства.
Iva> да.

Воистину! Для кого-то это бизнес модель.


Что программисты, что администраторы, что DevOps всего лишь винтики в технологической цепи.