Ад HR, или "метаклассы ищут на работу убер-метаклассов"

[metaclass]

http://ru-java.livejournal.com/1137245.html
Жесть по ссылке напоминает нашу контору, за одним исключением - там все еще верят, что можно найти идеального сотрудника, который будет работать за пятерых, впишется в команду, будет одновременно уметь в БД, код, общение с юзерами, проектирование софта, командование коллегами и прочие сказки. Современная организация процессов разработки ПО отрицает существование таких людей. Как написал там artureg: "Там скорее всего вредные ревнивые пиздоболы. Команды которые нельзя маштабировать надо разгонять."

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

Comments

[serbod.livejournal.com]

Сам сейчас в таком положении. Нужна свежая кровь, потому что некоторые ветераны хоть и обладают серьезными техническимим навыками, но при этом не обладают достаточным common sense. Могут матерно послать девок из колл-центра учить английский или безапеляционно заявить, что "вот это работать не будет" или "это никогда не случится". Разумеется, при проверке оно работает, и обязательно случается. Ну, и как правило, такие люди испытывают агрессивное неприятие к документированию своей работы. Примерно как вампиры к чесноку.

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

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

[anonim-legion.livejournal.com]

>послать девок из колл-центра учить английский

А тут-то что не так?

[serbod.livejournal.com]

Совсем не так. Ошибка ORA-012345 - some shit happened. Девочка сообщает разработчику, а он вместо того, чтобы оторвать жопу от стула и пройти в соседний кабинет и посмотреть на ошибку вживую, начинает садо-мазо секс по телефону. Хорошо, что девочка не дура, пошла сразу к начальству.

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

[metaclass.livejournal.com]

Из каких соображений он делает текстовый ключ, он не объяснял?

[serbod.livejournal.com]

Чтобы имена не дублировались. Но во-первых это не критично, во-вторых контроль уникальности имен (и не только) уже встроен в фреймворк.

[fraks-nsk.livejournal.com]

А что он будет делать когда понадобится сделать такую же запись в справочнике, но другую? И не надо говорить что так не бывает.

[anonim-legion.livejournal.com]

Вообще, странная история. По описанию, персонаж - дурак. Но ведь он работал, и что-то делал, не один год.

История подается через испорченный телефон.

[serbod.livejournal.com]

Не дурак, просто сложный человек.

[fi_mihej.livejournal.com]

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

[os80.livejournal.com]

И почему Вы запрещаете ему делать Unique Key?

[serbod.livejournal.com]

Вы что-то путаете. В моей спецификации был классический автоинкремент в качестве ключа записи. Прочитайте комменты выше еще раз.

[os80.livejournal.com]

Не путаю. Хотя выбираю один вариант из нескольких возможных.
Ну хочется человеку уникальный ключ по имени. Ну хочется Вам уникальный ключ по ID. Ну и что мешает их сделать одновременно?
А какой из них будет primary - в большинстве случаев должно быть монопенисуально.

[berezovsky.livejournal.com]

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

[eperniyteatr.livejournal.com]

А как его использовать во внешнеми ключе? Это я про "удалить, потом создать"

[serbod.livejournal.com]

Никак.