Издеpжки профессий

[hell_boy]

Нет здесь слесарей-инженеров КИПиА/АСУТП. Пишите свои

[keysansa]

Сотрудники техподдержки уже не гуглят. Они работают по сценарию. Хорошо если попадется человек, который раньше в "поле" работал, потом каким-то Макаром на телефон тех поддержки сел. Тогда он решит ваш вопрос сразу.
ЗЫ. Про поваров понравилось )

[VADR]

Сотрудники техподдержки уже не гуглят. Они работают по сценарию.

Довольно много лет назад (году так в 1997-98-м) был свидетелем звонка в техподдержку одной большой софтверной фирмы (которая сейчас стала ещё больше :) ). Один ВУЗ, спонсируемый небедными компаниями того времени, имел полный комплект лицензионного ПО этой фирмы (что редкость для того времени). И вот с этим ПО возникают проблемы. Не помню сути проблем, что-то со связью между серверами в домене, но местные сисадмины решили позвонить в техподдержку (опять же... деньги уплачены, пуркуа бы собственно и па?). Набросали на бумажке коротенький конспект: что и как произошло, что делали, что получилось. Звонят в ТП, включают громкую связь, выкладывают всю эту инфу сотруднику, тот умно угукает после каждого предложения... после чего начинает работать: "Так... во-первых, убедитесь, что ваш компьютер включен!".

[hell_boy]

"Так... во-первых, убедитесь, что ваш компьютер включен!".

Мне пару раз ночью звонили тетки-операторы с удаленного объекта. Компьютер был включен, а монитор - нет. Как показало расследование: у них пересменка была с 23:00 до 00:00, менялись заочно, один оператор уходил, а через 15 минут приходил сменщик. Ушедший оператор после ужина немного спал сидя перед монитором, а что бы в глаза не светило, монитор выключал. Перед сменой просыпался и бежал на автобус, забыв включить монитор. Пришедший сменщик, если он был мужского пола, догадывался монитор включить, если женского - нет.
Правда, добром это не закончилось. Один из операторов очень любил поспать так, что 3 раза подряд влетал в аварию. Его уволили в конце-концов, а он пошел в прокуратуру с жалобой на незаконное увольнение. Его не просто восстановили, но и сделали начальником этого объекта. После чего там было еще 2 пожара.

[VADR]

Мне пару раз ночью звонили тетки-операторы с удаленного объекта. Компьютер был включен, а монитор - нет.

Ну, раз уж мы плавно перетекли в воспоминания курьёзных ситуаций... Как-то тоже довольно давно, году в 2001-м, наверное, мне позвонили девушки-операторши с одного из объектов. С их слов - "в середине экрана появились глазки с ручками, и ничего с ними сделать нельзя!". Я бегу на работу, лихорадочно пытаясь вспомнить, какой элемент интерфейса может выглядеть подобным образом, и ничего не вспоминаю. В итоге, как показало расследование (очень краткое, секунд на 10), девушки, будучи весьма аккуратными, решили протереть пыль с монитора. И случайно задели клавишу настройки яркости/контрастности. В центре экрана действительно появилась комбинация из 4 кружков, обозначающих яркость/контрастность больше/меньше. При некоторой доле фантазии это можно было принять за какого-нибудь Чебурашку или ещё кого подобного. Монитор был довольно крутой для своего времени - какой-то EIZO, 21 дюйм, электронно-лучевой, естественно... но вот убирать это меню по таймауту разработчики к тому времени ещё не придумали. Вот и получились "глазки с ручками" :)

[hell_boy]

А еще были траблы с звуковой сигнализацией. Колонки выносные выключали или убавляли громкость. Встроенные в монитор - хорошо отключаются из меню монитора. Для вывода звука пришлось задействовать пищалку системного блока. У рабочих станций HP можно пищалку использовать для вывода звука, т.е. - пищалка является стандартным звуковым устройством Windows. Но АРМ был не на базе техники HP, и операционная система была SUN Solaris. Пришлось писать драйвер перенаправления звука с звуковой платы на пищалку под SUN Solaris. Операторы выкрутились оригинально - заложили системники телогрейками. Начальник цеха, обнаружив это, поступил неоригинально - депремировал всю смену до конца года. Дело было в феврале.

[VADR]

Операторы выкрутились оригинально - заложили системники телогрейками.

Какие-то непродвинутые операторы. Наши выкрутились проще - в гнёзда для подключения колонок спички вставили :)

[Jackson]

Сотрудники техподдержки уже не гуглят. Они работают по сценарию.

Я - техподдержка. Не знаю, про кого Вы говорите. В бытовухе и ПО - может быть, без этого никак. А в тематике форума - вряд ли. Гуглю: в голове, в документации, затем везде (в такой последовательности). И никак иначе. И да, практически всегда ответ на вопрос есть в документации, которая выложена в интернете. Иногда я думаю, что поддержка - это плагин голосового чтения документации (это сейчас и телефоны умеют).

[hell_boy]

практически всегда ответ на вопрос есть в документации, которая выложена в интернете

Не забывайте, что на работу вышло поколение, которое все изучает по ютубу. Если в ютубе нет, то и нигде нет. У меня программист работает, который ни одной книжки по С++ и Джаве не прочитал. Все учил по ютубу. Кстати, кодить у него получается быстро, но с большим количеством ошибок, как у компании Билла Гейтса. Алгоритмов он не знает, в ютубе этого нет практически. Так что ему нужен еще специалист по алгоритмам и тестировшик ПО.

[keysansa]

В бытовухе и ПО - может быть, без этого никак.

Техподдержка Siemens (модуль Fluing Saw) пример не бытовухи. 40 мин на телефоне, доступ по тимвьюверу в течении часа - результат - используйте старую версию (в которой нет новых функций, ради чего покупалось), или оплачивайте выезд специалиста.

Отправлено спустя 3 минуты 44 секунды:

Кстати, кодить у него получается быстро, но с большим количеством ошибок

Это последствие надежды на компилятор. Так реально проще кодить - компилятор выдаст все ошибки (правда, при таком подходе компилятор лучше поменять на Паскаль - чище код выйдет).

[MuadDib]

Кстати, кодить у него получается быстро, но с большим количеством ошибок

Это последствие надежды на компилятор. Так реально проще кодить - компилятор выдаст все ошибки (правда, при таком подходе компилятор лучше поменять на Паскаль - чище код выйдет).

Увы, при таком подходе надо менять не компилятор, а программиста. Компилятор никогда не выдаст "все ошибки". Он находит только синтаксические ошибки. И Паскаль в этом лишь немногим строже Си/Си++. Собственными глазами видел, как криворукий кодер правит строчку, на которую ругается компилятор, как попало. Лишь бы компиляция прошла, а будет ли это работать вообще - пофиг. Пусть тестировщики развлекаются. И это не "поколение youtube", не джун какой-то, а матерый, мать его, специалист с парой десятков лет опыта нативной разработки. Что уж тут говорить про варнинги компилятора, про средства статического анализа кода - такие персонажи их будут тупо игнорить. Компилируется же, фигли.

А ведь есть еще огромный пласт логических ошибок. Когда и синтаксис в порядке, и статическому анализу ругаться не на что, а программа не будет работать как требуется, потому что программисту было лень продумывать какие-то ситуации, лень заморачиваться синхронизацией потоков, да мало ли что еще. "Дома в холодильнике водка стынет или "танчики" ждут, а я сижу тут и фигней маюсь. Пусть другие за меня поработают"

[Универсал]

Ответы на вопросы, возможно, и есть в документации, но, блин, понять их после перевода с немецкого на итальянский, потом на английский, после чего, благополучно, на русский совершенно невозможно. А если в промежуток втесался ещё и китайский - дело швах. Мне попадались инструкции, в которых я не мог понять ни одного предложения. Не спасали даже попытки читать английский вариант. Иногда спасают только комиксы - иллюстрации в картинках и скриншоты меню настроек.
И вообще. Если вы приобретаете дорогое, очень интеллектуальное, очень крутого бренда современное оборудование и надеетесь после профессионального монтажа и пусконаладки на долгую и беспроблемную эксплуатацию - вы наивный человек. В любом оборудовании обязательно через пару-тройку лет начнут высыхать электролитические конденсатоы, поначалу создающие массу совершенно хаотических сбоев, ошибок и аварий, в конце-концов приводящих к полному отказу. И чем круче бренд, тем глубже будет ваш шок, когда вы узнаете цену замены какого-либо паршивого элемента, на вид абсолютной дешевки.
Где мне только не приходилось перепаивать эти паршивые копеечные конденсаторы!
Например, крайне досадно, когда вышел из строя какой-нибудь модуль ввода-вывода, и совершенно неизвестны его сетевые настройки и конфигурация входов или выходов. Начинается гадание на кофейной гуще, типа сборки кубика Рубика с завязанными глазами. Хотя проблема нередко решается за 15 минут перепайкой конденсатора, вместе с ожиданием нагрева паяльника и сборкой-разборкой модуля.
Я давно уже постоянно ношу в инструментальной сумке кроме паяльника с принадлежностями простенький ESR пробничек, самодельный.
А в последние годы этой тенденцией страдают уже и плёночные конденсаторы, используемые как фазосдвигающие для электродвигателей, а также как балластные в устройствах с бестрансформаторными блоками питания. Казалось бы, там-то чему сохнуть! А их ёмкость с годами падает в разы.

[Jackson]

Так что ему нужен еще специалист по алгоритмам и тестировшик ПО.

Я думаю, фирме нужен другой программист, а этому нужен урок о том, что книжки читать все-таки надо. Вообще это жесть.

Кстати, кодить у него получается быстро, но с большим количеством ошибок, как у компании Билла Гейтса

Из резюме соискателя на должность секретаря:
Владение машинописью - печатаю до 500 знаков в минуту (и такая ерунда порой получается!)

Не забывайте, что на работу вышло поколение, которое все изучает по ютубу.

Да, это жесть. Счастье что в моей работе на ютубе ничего нет - людям некуда деваться, читают хотя бы сопроводительную документацию.

Техподдержка Siemens (модуль Fluing Saw) пример не бытовухи. 40 мин на телефоне, доступ по тимвьюверу в течении часа - результат - используйте старую версию (в которой нет новых функций, ради чего покупалось), или оплачивайте выезд специалиста.

Речь была о другом немного. Но вообще - в ПО это нередкий случай.

Увы, при таком подходе надо менять не компилятор, а программиста.

Согласен.

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

Ну почему же? Интеллектуальному оборудованию - интеллектуальное сопровождение. Либо свои спецы должны быть обученные не на 5-копеечной зарплате, либо фирменный сервис тоже не за 5 копеек. Так что если надежда подкреплена этим всем - проблем и правда будет немного. А электролиты за 3 года высыхают только если оборудование неправильно применено, либо неправильно эксплуатируется.

А в последние годы этой тенденцией страдают уже и плёночные конденсаторы, используемые как фазосдвигающие для электродвигателей, а также как балластные в устройствах с бестрансформаторными блоками питания. Казалось бы, там-то чему сохнуть! А их ёмкость с годами падает в разы.

Комплектующие стали менее качественными, это факт. Однако комплектуха промышленного качества никуда не делась, просто она стала дороже, и отличить одно от другого стало сложнее. Тем не менее, всегда была дешёвая электроника и дорогая. Я не замечаю чтобы приличная электроника стала дохнуть как-то чаще или по-другому. Вопрос только в том, что считать приличной электроникой. Приличный бренд и приличная цена это не определяют.

[Jackson]

Вот ровно потому, что публика стала всё изучать по ютубу, а не умом доходить, эта публика и не может разобраться что где лучше применить, как отличить хорошее от плохого. Ровно поэтому. И производители, естественно, на это реагируют и продают всё больше за красивые названия. Однако подкованный человек с легкостью находит именно то что ему нужно, когда ему никто не мешает, такой человек обычно на опальном счету у именитых брендов и дилеров - он им продажи портит. Зато у него всё работает, только об этом мало кто знает - те же бренды и дилеры не в восторге от распространения такой информации.

[keysansa]

Увы, при таком подходе надо менять не компилятор, а программиста. Компилятор никогда не выдаст "все ошибки". Он находит только синтаксические ошибки. И Паскаль в этом лишь немногим строже Си/Си++. Собственными глазами видел, как криворукий кодер правит строчку, на которую ругается компилятор, как попало. Лишь бы компиляция прошла, а будет ли это работать вообще - пофиг. Пусть тестировщики развлекаются.

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

Отправлено спустя 11 минут 40 секунд:

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

Вспоминается преподаватель по электротехнике в училище.
Он постоянно повторял (это 92-93 года), что бывает блочный ремонт, а бывает вдумчивый. В первом случае меняем блоки друг за другом пока не заработает, во втором ищем конкретную неисправность.
В итоге, по моему опыту - истина где то рядом. Точнее посередине. Вдумчиво меняем блок на машине, что бы минимизировать простой, а потом вдумчиво ремонтируем блок в свободное время.

Отправлено спустя 3 минуты 35 секунд:

Речь была о другом немного. Но вообще - в ПО это нередкий случай.

Может я что-то пропустил в обсуждении.
Однако совет использовать старую версию модуля был от разработчика модуля, а не службы поддержки. И вы тоже не поддержка. Вы разработчик, который выполняет функции поддержки.

Отправлено спустя 9 минут 6 секунд:

А ведь есть еще огромный пласт логических ошибок. Когда и синтаксис в порядке, и статическому анализу ругаться не на что, а программа не будет работать как требуется, потому что программисту было лень продумывать какие-то ситуации, лень заморачиваться синхронизацией потоков, да мало ли что еще. "Дома в холодильнике водка стынет или "танчики" ждут, а я сижу тут и фигней маюсь. Пусть другие за меня поработают"

Начальник должен смотреть код подчиненных, а не только решать организационные вопросы. Последняя фраза для тимлидов тоже подходит.

[hell_boy]

Вспоминается преподаватель по электротехнике в училище.
Он постоянно повторял (это 92-93 года), что бывает блочный ремонт, а бывает вдумчивый. В первом случае меняем блоки друг за другом пока не заработает, во втором ищем конкретную неисправность.
В итоге, по моему опыту - истина где то рядом. Точнее посередине. Вдумчиво меняем блок на машине, что бы минимизировать простой, а потом вдумчиво ремонтируем блок в свободное время.

Есть еще ремонт методом половинного деления. Тоже в ПТУ обучали. Это когда сразу меняешь половину блоков на заведомо исправные, если не заработало, то неисправность - во второй половине. Найденую неисправной половину, делишь еще раз пополам, и т.д. пока не найдешь неисправный блок. Метод работает, когда блоков в ЗИПе на целое устройство, а сам ремонтник в этом устройстве совершенно не разбирается. Так военные ремонтировали свои ЭВМ во времена СССР

Отправлено спустя 14 минут 16 секунд:

Начальник должен смотреть код подчиненных

Начальство тоже сейчас из поколения ютуба и с экономическим образованием. Я недавно пообщался с заказчиком, который вместо ТЗ прислал ссылку на канал финской компании с комментарием: "Хочу, как у них". "Алгоритмы" он заменяет понятием "бизнес-логика", "мнемосхема" - "мэшап", "элемент на мнемосхеме" - "виджет", "интерфейс" - "коннектор" и т.д.

[Универсал]

На все эти блочные ремонты просто умора смотреть со стороны, когда неисправны два блока. Животики надорвёшь, особенно когда неисправность меняется при замене одного из неисправных блоков.
Ну, а ремонт чего-либо военными...
На эту тему столько анекдотов...

[Valerich]

Я недавно пообщался с заказчиком, который вместо ТЗ прислал ссылку на канал финской компании с комментарием: "Хочу, как у них"

У нас большинство проектов так: "а у нас на старой работе было так (и прилагается несколько фоток с телефона)" или "вот скриншоты с мониторов на соседнем заводе" или "вот увидел статью в журнале, надо сделать также".
Ну что делать? Собираешь по крупицам информацию и делаешь. После нескольких изменений в железе и версий программы всё даже работает

[winb]

Я недавно пообщался с заказчиком, который вместо ТЗ прислал ссылку на канал финской компании с комментарием: "Хочу, как у них"

У нас большинство проектов так: "а у нас на старой работе было так (и прилагается несколько фоток с телефона)" или "вот скриншоты с мониторов на соседнем заводе" или "вот увидел статью в журнале, надо сделать также".
Ну что делать? Собираешь по крупицам информацию и делаешь. После нескольких изменений в железе и версий программы всё даже работает

Самое интересное, что после решения пары таких задач у менеджеров закрепляется уверенность, что так задания и должно быть. Не нужно их расслаблять - не делают ТЗ, делайте его для себя сами и пусть подписывают. Если человек адекватный, то после нескольких решений не по "хочу как у них", а по согласованному им техзаданию, ТЗ начинает читаться внимательно, требования становятся реальными и конкретными. А если не адекватный... Тут придется жечь нервы или как-то приспосабливаться, но это чревато профессиональной деградацией...

[Jackson]

Ну а менять программиста просто потому, что он делает кучу синтаксических ошибок - глупо

До тех пор, пока эти синтаксические ошибки не приведут к аппаратным ошибкам в оборудовании или финансовым ошибкам в отчётности. Я бы не ждал этого. Иметь эту бомбу замедленного действия и никак с ней не разбираться - значит получить потом большой бадабум в самый неподходящий момент. Основной постулат Мерфи, с.ка такая, работает.

Есть еще ремонт методом половинного деления. Тоже в ПТУ обучали. Это когда сразу меняешь половину блоков на заведомо исправные, если не заработало, то неисправность - во второй половине.

Это когда лень разбираться. Обычно всё же удаётся действовать методом исключения в процессе мозгового штурма - экономит время и средства.

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

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

[Serex]

Есть отраслевые специфики.
Прошлая работа - формацевтика - до безобразия зарегулированная государством. Буквально правила есть на то как чихнуть и как почесаться. Естественно от таких правил "башня" уезжает.
А потом другая работа - никаких правил. Что-то там начальник по ТБ заикается, но больше о том, как пятую точку директора прикрыть, потому как это единственный действующий аргумент. А так стадо директоров и каждый что-то свое генерит, без согласования с другими директорами, а у подчиненных глаза на лоб от всего этого, пытаются хотелки директоров между собой увязать. А потом как собственник скажет - "увеличить план на 20%", тут и директора приплыли, сидят с округленными глазами. И в этом всем начинаешь думать о фармацевтика, как о неком благоволении!

А профессиональное выгорание тоже присутствует, это когда занимаешься то организацией склада электронных запчастей, то монтажом кабеля по лоткам. И вроде чего жаловаться то? Платят по окладу!

[MuadDib]

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

Кто вам сказал, что надо увольнять за синтаксические ошибки? Любой программист, всерьез претендующий как минимум на позицию джуна, в состоянии справиться с исправлением синтаксических ошибок. Вопрос в том, сколько ошибок остается сидеть в программе после успешной компиляции. Если их много, и количество не уменьшается после серьезных разговоров, то да, надо увольнять или переводить на должность, где этот программист не может сильно нагадить.
Юнит-тесты хорошо помогают в тестировании отдельного модуля, и то, если они пишутся на совесть. Если их ляпает тот же самый неумеха что пишет основной код, толку от них очень мало. Формальные критерии типа coverage иногда способны выявить халтуру в написании тестов, но далеко не всегда. А в тестировании распределенной системы или взаимодействия со сторонним оборудованием/ПО создать правильные тесты очень сложно. Это фактически отдельная работа по моделированию, где могут быть свои ошибки или пробелы.

Начальник должен смотреть код подчиненных, а не только решать организационные вопросы. Последняя фраза для тимлидов тоже подходит.

Смотреть должен, работать за подчиненных - нет. Самая сложная и ответственная часть работы программиста - обеспечить корректность кода, продумать все возможные особые ситуации, надежно обработать ошибки. Когда эту работу за подчиненного начинает делать начальник, подчиненный очень быстро начинает борзеть и перестает заботиться о качестве кода вообще. Зачем париться - за тебя же все продумают, ошибки укажут. Особенно одаренные находят халтурку и ваяют ее, пока лид разгребает за ними говнокод. Проверено на практике, увы.
И да, последняя фраза подходит вообще для всех. И любого работника, живущего по такой концепции, надо гнать ссаными тряпками, будь он программер или CEO.

[Valerich]

Не нужно их расслаблять - не делают ТЗ, делайте его для себя сами и пусть подписывают.

Так и происходит) Только подпись - штука ненадежная - "обстоятельства изменились, надо переделать", оборудование делаем сами для себя, так что заказчик и начальник - одно лицо)

[keysansa]

Есть еще ремонт методом половинного деления. Тоже в ПТУ обучали. Это когда сразу меняешь половину блоков на заведомо исправные, если не заработало, то неисправность - во второй половине.

Прикольно )
Не знал, что он так называется, когда перед каждым Новым годом чинил гирлянду (она у нас старая была и одна) )
Он более продвинут, чем просто блочный, статистика присутствует )

Отправлено спустя 7 минут 11 секунд:

На все эти блочные ремонты просто умора смотреть со стороны, когда неисправны два блока.

Метод половинного деления решает эту проблемму )
Вот, правильно сказано:

Обычно всё же удаётся действовать методом исключения в процессе мозгового штурма - экономит время и средства.

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

Ну и сейчас - иногда только блочный ремонт и возможен.

Отправлено спустя 25 минут 46 секунд:

До тех пор, пока эти синтаксические ошибки не приведут к аппаратным ошибкам

Вот именно по этому, и рекомендовал человека посадить на Pascal (мой пример с подчиненным удачно этим закончился, правда ввиду особенностей работы и времени - это ST, а не Pascal). Это языки строгой типизации, в них сложнее пройти синтаксический анализ из-за синтаксической ошибки. Лучше всего, конечно LD, на мой взгляд. Но у него свои проблемы.
С финансами имел дело, но там основной тип данных - c плавающей точкой - поэтому компилятор не способен повлиять на ошибки.

Отправлено спустя 8 минут 26 секунд:

Естественно от таких правил "башня" уезжает.

В 2006 году летал в Египет. В самолете познакомился от скуки (моя подружка в последний момент соскочила с поездки потому что я начальнику сказал, что нужен отпуск "прям щас", он спросил - "с кем?", я ответил правду, а она узнав про это, сказала - "на меня тут все нехорошо смотреть будут") с парой молодоженов из Мурманска. Отлично провели время, но между делом, поинтересовавшись, кто где из них работает, услышал вот такое (вкратце):
Они оба работали на заводе по производству взрывчатых веществ. И на самом производстве принимают только женщин, потому, что только женщины могут работать строго по технологии, не отступая от нее. Мужчины же начинают "оптимизировать" процесс, а на этом производстве такое недопустимо.

[Универсал]

Есть еще ремонт методом половинного деления.

В науке пользуются выражением "поиск льва в пустыне".
Не работает, когда львов несколько.