Ад HR, или "метаклассы ищут на работу убер-метаклассов"
http://ru-java.livejournal.com/1137245.html
Жесть по ссылке напоминает нашу контору, за одним исключением - там все еще верят, что можно найти идеального сотрудника, который будет работать за пятерых, впишется в команду, будет одновременно уметь в БД, код, общение с юзерами, проектирование софта, командование коллегами и прочие сказки. Современная организация процессов разработки ПО отрицает существование таких людей. Как написал там
artureg: "Там скорее всего вредные ревнивые пиздоболы. Команды которые нельзя маштабировать надо разгонять."
Так вот. Желание кольчатых червей-менеджеров и их личинок линейно "масштабировать команды" - оно похвально, с точки зрения "бизнеса", но не является абсолютно правильным. Потому что один правильный работник, будучи правильно приложенным, может решить все технические проблемы конторы на пару лет вперед. А один мотивированныйпротивогазработник, ответив в 6 часов пятницы на звонок крупного клиента с мелкими проблемами, может обеспечить поток бабла от этого клиента на 5 лет вперед.
Жесть по ссылке напоминает нашу контору, за одним исключением - там все еще верят, что можно найти идеального сотрудника, который будет работать за пятерых, впишется в команду, будет одновременно уметь в БД, код, общение с юзерами, проектирование софта, командование коллегами и прочие сказки. Современная организация процессов разработки ПО отрицает существование таких людей. Как написал там
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Так вот. Желание кольчатых червей-менеджеров и их личинок линейно "масштабировать команды" - оно похвально, с точки зрения "бизнеса", но не является абсолютно правильным. Потому что один правильный работник, будучи правильно приложенным, может решить все технические проблемы конторы на пару лет вперед. А один мотивированный
no subject
У меня к тому персонажу тоже есть претензии. Например, я веду разработку бизнес-процесса, описал принцип работы, написал спецификацию, какие мне таблицы и процедуры нужны. И вместо обсуждения спецификации он тупо берет и правит ее по своему усмотрению. Выкидывает автоинкремент и делает ключом название товара. Пытаюсь объяснить, что текстовый ключ подвержен проблемам с кодировками, избыточен и неудобен. И вообще наш фреймворк заточен под цифровые ключи. Он уперся рогом. А начальство сути проблемы не понимает, ничем помочь не может. Пришлось делать справочник товаров с текстовым ключом и вносить костыль в фреймворк для переименования товара (его нужно сперва удалить, потом создать с новым именем).
no subject
no subject
no subject
no subject
История подается через испорченный телефон.
no subject
no subject
no subject
no subject
no subject
Ну хочется человеку уникальный ключ по имени. Ну хочется Вам уникальный ключ по ID. Ну и что мешает их сделать одновременно?
А какой из них будет primary - в большинстве случаев должно быть монопенисуально.
no subject
no subject
no subject