О срачах про собеседования - О работе

___>Например система стала работать медленно. Медленнее с каждым релизом.

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

___>Или стала кушать много ресурсов.
___>Или вдруг стало происходить что-то очень неочевидное.

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

___>И ничего необычного от разработчика тут не требуется конечно.
___>Но может оказаться, что далеко не всем трудолюбивым эти задачи можно поручить.

Этак можно дойти и до банальности: не каждому трудолюбивому плотнику можно поручить писать программы.

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

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

___>Но общая тенденция уменьшения трудолюбия с опытом(а часто даже и просто с возрастом) не просто заметна а очень сильно заметна даже на этом форуме.

Про один психологический аспект я уже упомянул, теперь коротко о втором. Начну с афоризма (приписывают его Стасу Янковскому): "Лень простого русского человека — это не грех, а совершенно необходимое средство нейтрализации кипучей активности руководящих им дураков".
К сожалению, в программировании это тоже ярко выражено: опытный специалист может формально подчиняться руководству и выполнять все поручения. При этом он прекрасно осознает, что требуют делать ерунду, и что как только эта ерунда будет сделана — придется переделывать. У работника есть два выхода. Первый — очевиден: можно попытаться объяснить, что ерунду делать не надо. Когда я был молод и горяч, так и поступал, в результате был один негатив.
Поэтому дальше я стал действовать по второму варианту: отмечал, что данное решение неоптимально, и затем его реализовывал, разумеется, не торопясь, чтобы дать руководству время на осознание ошибок, прикрытие пятой точки и изобретение отмазки, почему было принято такое решение. В итоге все оставались довольны: руководству не скипидарили задний проход, и нам, как работникам, не только перепадала благодарность начальства, но и можно было "прокачать скиллы", решая какие-то совсем другие проблемы.
Отмечу, что данный процесс имеет место быть на любом уровне иерархии. Отмечу, что в итоге всё сводится к вопросу адекватности начальства.

On 03.04.2013 2:25, SkyDance wrote:

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

> Этак можно дойти и до банальности: не каждому трудолюбивому плотнику
> можно поручить писать программы.
Ну так да, не заметил чем заканчиваются все такие срачи: "а вот у нас
"таджик-дворник" не справился писать".

> Что создает у вас иллюзию "как-то мало они работают, ленивые, поди".
Ну это естественно. Воспользуюсь аналогией. Закрыть пулеметную амбразуру
грудью — это подкиг. а если его все совершают, уже нет. Следующим
подвигом должно быть "закрыть пушечную амбразуру грудью".

> Про один психологический аспект я уже упомянул, теперь коротко о втором.
> Начну с афоризма (приписывают его Стасу Янковскому): "Лень простого
> русского человека — это не грех, а совершенно необходимое средство
> нейтрализации кипучей активности руководящих им дураков".
+100

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Vzhyk, Вы писали:

___>>Ну может я один это замечаю, но у опытных спецов с трудолюбием очень часто не очень хорошо дела обстоят.
V>Копать отсюда и до обеда — это еще духов можно запахать, а вот дедушек попробуй.

___>>А уж на трудовые подвиги их вообще не вдохновить никак

V>И награждать посмертно.

___>>Но общая тенденция уменьшения трудолюбия с опытом(а часто даже и просто с возрастом) не просто заметна а очень сильно заметна даже на этом форуме.
V>Логичная тенденция. Это молодой готов на вас пахать за строчку в резюме, а дедушке это нафиг не надо. Плати за трудолюбие — будет тебе трудолюбие.

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

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

А еще вспоминая прелести армейской жизни так смешно читать тут про рабство, "инженегров", "ярмо овертаймов", "галеры" и прочие ужасы на работе

On 03.04.2013 14:26, robin_of_the_wood wrote:

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

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

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

> Ну и самое главное то, что зарплаты опытных сотрудников на всех моих
> работах всегда были больше, чем зарплаты начинающих. Иногда значительно
> больше.
Как-то уже давно знавал я двух челов на ибе в Минске, за одинаковую
работы одному платили в 3 раза больше (просто тот, кому платили меньше,
не знал, что зарплаты программистов на несколько лет уже выросли).

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, SkyDance, Вы писали:

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

Да. Но опыт профилирования может сильно повлиять на результат.

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

И тут опыт решения подобных проблем может очень сильно сказаться. А его(этот опыт) не нагуглишь.

SD>Этак можно дойти и до банальности: не каждому трудолюбивому плотнику можно поручить писать программы.
Можно. Но мы не будем

SD>Это несколько другая психологическая ловушка, в которую вы попали. Опытные разработчики и так совершают "трудовые подвиги" по сравнению с неопытынми. Вы, собственно, и сами это заявили парой сообщений назад, упомянув, что по-возможности именно опытных стараются оставить в своей команде.
SD>Ловушка заключается в том, что вы привыкли к тем подвигам, которые совершают опытные разработчики, и уже не воспринимаете это как подвиги. Что создает у вас иллюзию "как-то мало они работают, ленивые, поди".

У меня нет иллюзий. Я очень хороо осведомлен о том, кто, что, как, и сколько делает. Это входит в мои обязанности.

SD>Про один психологический аспект я уже упомянул, теперь коротко о втором. Начну с афоризма (приписывают его Стасу Янковскому): "Лень простого русского человека — это не грех, а совершенно необходимое средство нейтрализации кипучей активности руководящих им дураков".
SD>К сожалению, в программировании это тоже ярко выражено: опытный специалист может формально подчиняться руководству и выполнять все поручения. При этом он прекрасно осознает, что требуют делать ерунду, и что как только эта ерунда будет сделана — придется переделывать. У работника есть два выхода. Первый — очевиден: можно попытаться объяснить, что ерунду делать не надо. Когда я был молод и горяч, так и поступал, в результате был один негатив.
SD>Поэтому дальше я стал действовать по второму варианту: отмечал, что данное решение неоптимально, и затем его реализовывал, разумеется, не торопясь, чтобы дать руководству время на осознание ошибок, прикрытие пятой точки и изобретение отмазки, почему было принято такое решение. В итоге все оставались довольны: руководству не скипидарили задний проход, и нам, как работникам, не только перепадала благодарность начальства, но и можно было "прокачать скиллы", решая какие-то совсем другие проблемы.
SD>Отмечу, что данный процесс имеет место быть на любом уровне иерархии. Отмечу, что в итоге всё сводится к вопросу адекватности начальства.

Правильно. И вывод вроде логичный.
Но дело то то не в теории, а в том, что моя личная практика приводит к противоположному выводу.
Вот если бы вывод был тот же, тогда бы логично было рассуждать про мои заблуждения и попадания в ловушки.
А так моя точка зрения полностью обьясняет то, что я наблюдаю вокруг.

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

Здравствуйте, Vzhyk, Вы писали:

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

>> Во вторых потом кандидату с ярко выраженными признаками "дедушки" очень
>> непросто устроиться на новую работу.
V>Седая борода и дряхлый вид.
Отнюдь.
Слово специально взято в кавычки чтобы показать, что речь идет совсем не о возрастных особенностях внешнего вида.
Но мне кажется что все все прекрасно поняли.

V>Как-то уже давно знавал я двух челов на ибе в Минске, за одинаковую
V>работы одному платили в 3 раза больше (просто тот, кому платили меньше,
V>не знал, что зарплаты программистов на несколько лет уже выросли).

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

On 03.04.2013 17:08, robin_of_the_wood wrote:

> Но к проблеме "дедушек" это слабо относится.
А она есть эта проблема? Просто я не могу понять, зачем вам дедушки,
если вполне трудолюбивых духов хватает, как здесь, например:
http://rsdn.ru/forum/message/5122783.aspx
"1. Программист риски учитывать не умеет по определению.
2. Если он считает, что умеет это делать, читай п. 1."

З.Ы. Последнее время все больше и больше народа здесь пишут об
организации работы на конторе в стиле "дать духу лом и сказать пометать
плац отсюда и до обеда".

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Vzhyk, Вы писали:

>> Но к проблеме "дедушек" это слабо относится.
V>А она есть эта проблема? Просто я не могу понять, зачем вам дедушки,
V>если вполне трудолюбивых духов хватает, как здесь, например:
V>http://rsdn.ru/forum/message/5122783.aspx
V>"1. Программист риски учитывать не умеет по определению.
V>2. Если он считает, что умеет это делать, читай п. 1."
Проблема есть. Чаще правда у самих "дедушек" с завышенной самооценкой.
Зачем они нужны в моем случае я описывал, другие описывали свои ситуации и я с интересом читал.
В общем ничего необычного. Одним нужны. Другим не нужны. Там где нужны не любые подойдут.

V>З.Ы. Последнее время все больше и больше народа здесь пишут об
V>организации работы на конторе в стиле "дать духу лом и сказать пометать
V>плац отсюда и до обеда".

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

___>Да. Но опыт профилирования может сильно повлиять на результат.

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

___>И тут опыт решения подобных проблем может очень сильно сказаться. А его(этот опыт) не нагуглишь.

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

___>У меня нет иллюзий. Я очень хороо осведомлен о том, кто, что, как, и сколько делает. Это входит в мои обязанности.

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

___>Но дело то то не в теории, а в том, что моя личная практика приводит к противоположному выводу.

Рад, что у вас так всё хорошо сложилось.

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

On 04.04.2013 1:43, SkyDance wrote:

> К тому же, вопреки уверениям Vzhyk, профилировать
> интересно только первые несколько раз, потом эта работа превращается в
> ту же самую занудную кропотливую тягомотину.
С таким подходом, после нескольких раз любая работа превращается в ту же
самую занудную кропотливую тягомотину.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, SkyDance, Вы писали:

___>>У меня нет иллюзий. Я очень хороо осведомлен о том, кто, что, как, и сколько делает. Это входит в мои обязанности.

SD>Могу лишь позавидовать строгости и высокому уровню вашей квалификации. Передайте мои поздравления тем людям, кто реализовал столь хороший процесс разработки в вашей фирме. Это действительно сложная задача, решить которую далеко не всем под силу.

Я это писал не про одну конкретную фирму.
Не понял при чем тут строгость и квалификация.
Согласен что следить за состоянием дел на проекте проще при определенной организации процесса.
Но это не становится невозможным при любой организации (ну совсем уж крайние случаи работы без систем контроля версий я не рассматриваю)

___>>Но дело то то не в теории, а в том, что моя личная практика приводит к противоположному выводу.

SD>Рад, что у вас так всё хорошо сложилось.

SD>Если вас не затруднит, я бы хотел получить несколько ответов по вашей ситуации. Не обязательно делать это публично, наверное, лучше через email (или личные сообщения этого сайта).

Да мне собственно скрывать нечего. Тем более что все вполне общеизвестно.
Более того моя ситуация — это не последний мой проект. Это все мои проекты в разных фирмах и иногда у разных заказчиков.
И общего было очень мало.

SD>В частности, хотелось бы знать, как у вас реализован процесс разработки, особенно интересует та часть, что позволяет вам быть хорошо осведомлённым о том, кто, что, как и сколько делает.

Везде было очень сильно по разному. Но минимальный уровень порядка правда был везде.
1. Система контроля версий
2. Багтрэкер
3. Набор простых правил типа "Любое изменение кода привязано к задаче", "Смена статуса задачи подтвержена комитом или ссылкой на документ итд"

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

SD>А также понять, что и как изменилось после замены слабой команды на сильную — насколько выросли расходные статьи бюджета,
Ну я про замену команды говорил как о частном случае. Несколько раз такое встречалось. Причем обстоятельства были разные.
По бюджету очень редко имел точную информацию, но по моим впечатлениям потери на сроках были всегда значительнее чем затраты на новых сотрудников.
Хотя тут могу и ошибаться.

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

SD>что стало с существующими практиками,
Иногда менялись. Иногда нет. Больше зависило от фирмы и/или заказчика.
Часто периодически корректировались в лучшую сторону вне зависимости от кадровых перестановок. Иногда очень медленно но обьяснялось условиями.
Но во всех проектах всегда придерживались определенных правил и общего подхода.

SD>как исправляли тестирование,
Ну его всегда расширяли и улучшали. Иногда вводили. Виды тестирования сильно зависили от фирмы и от проекта но общая тенденция была одинаковая.
Правило "Код, который не тестировался, не работает" очень редко давало сбой

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

SD>как чинили профилирование.
Ну его не то чтобы чинили. Скорее применяли для обнаружения узких мест.
Кроме профилирования еше почти во всех проектах довольно успешно внедряли различные средства мониторинга.
Особенно для бэкграундных процессов, очередей, динамически создаваемых процессов и сущностей итд.

	От:	SkyDance
	Дата:	02.04.13 23:25
	Оценка:

	От:	Vzhyk
	Дата:	03.04.13 07:02
	Оценка:

	От:	robin_of_the_wood
	Дата:	03.04.13 11:26
	Оценка:

	От:	Vzhyk
	Дата:	03.04.13 11:48
	Оценка:

	От:	robin_of_the_wood
	Дата:	03.04.13 11:59
	Оценка: