Вы уже видели это безобразие ? (Developer auction )

[oshibka_residenta]

Еще заметила что проект/аппликейшен/компания имеет обычно технический персонал с очень небольшой дельтой технической экспертизы. Г

Google по результам Hiring и top-coder сделал похожие выводы про продуктивность: внутри компании инженеры примерно одинаковы, а между компании продуктивность может отличаться в 10 раз.

[mynameiszb]

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

Это надо просто представлять, сколько времени ушло у админов на то, чтобы выстроить процесс и наладить его для работы "как следует, а не как хочется".
И еще - бангалорских братьев близко к pre-production / production системам не допускали.

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

[oshibka_residenta]

И еще - бангалорских братьев близко к pre-production / production системам не допускали.

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

[mynameiszb]

Подпускать надо, но только предварительно четко разделить зоны ответственности. Никакого булшита навроде: мы одна команда, етц.

Какие могут быть зоны ответственности, когда "ради снижения затрат" саппорт девелопмента и тестеров подвинули на группу "товарищей из Бангалора"? На бумажках все красиво нарисовано, но в итоге выливается в классическую ситуацию с коматозом, в который почти каждый день влетают зависящие от баз люди.

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

[Flash-04]

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

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

[ПростоНик]

Подпускать надо, но только предварительно четко разделить зоны ответственности. Никакого булшита навроде: мы одна команда, етц.

Какие могут быть зоны ответственности, когда "ради снижения затрат" саппорт девелопмента и тестеров подвинули на группу "товарищей из Бангалора"? На бумажках все красиво нарисовано, но в итоге выливается в классическую ситуацию с коматозом, в который почти каждый день влетают зависящие от баз люди.

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

"Борис, ты не прав"
Допускать надо, чтобы "братья" задокументировано накосячили, а потом "героически" исправлять. И обязательно докладную начальству - чтобы подтвердить свою незаменимость.

[mynameiszb]

Допускать надо, чтобы "братья" задокументировано накосячили, а потом "героически" исправлять. И обязательно докладную начальству - чтобы подтвердить свою незаменимость.

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

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

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

[oshibka_residenta]

@mynameiszb А почему это должна быть ваша проблема? Ну встанет работа, ваше-то какое дело. Посоветуйте тем, кто от этого страдает обращаться за поддержкой в Бангалор. И либо они ее там получит, либо пусть Бангалор вам скажет, что они _не могут_ это сделать.
И вообще, можете всех кого не любите посылать на х в Бангалор за суппортом - будут ходить как шелковые.

[Сабина]

А на контракт так и не идешь ?

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

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

[geek7]

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

+1 мне фантастически везет на непосредственное (во всех смыслах) начальство

[geek7]

Куда как интереснее, что говорить наверх, когда база промежуточной аналитики растет по террабайту в месяц. И это - "под минимальной нагрузкой"
А диски в стойке и обслуживание в protected data centers стоит ну очень невменяемых денег для полноценного саппорта...

говорить "пора переходить на клауд" и требовать премию за экономию

[geek7]

Я дев лид и СМИ на проекте. В данный момент, в компании нет никого, кто лучше меня знает, что и как приложение должно делать, в том числе и бизнес для которого приложение создается (и это одна из причин всех проблем). В начале проекта все было хорошо, было достаточно времени, я научил всех девелоперов тому, что нам надо, тому как писать код, каким стандартам следовать и т.д. и т.п. Было много времени и мы делали все в соответствии с планами, все было вовремя, ни одно итерации из 9 не задержали ни на оин день (как я говорил выше - первую итерацию я сам всю переписал с нуля перед дедлайном, но остальные были сделаны командой). В итоге, главные менеджеры пришли ко мне и забрали всю команду (т.е. абсолютно всю), со словами, что у тебя на проекте все хорошо только потому, что у тебя лучшие девелоперы (из, примерно, 10 других команд, ни одна не сдала ни одной итерации вовремя). В итоге за 2 месяца до дедлайна, мне дали полностью новую команду, абсолютно новых людей, и одновременно с этим стали забирать у меня 70-80% времени на митинги. Я не могу ни мониторить что команда делает, не успеваю им объяснять как правильно делать, не имею времени для код ревью. У меня за спиной постоянно очередь из архитекторов, BA, меджеров моего и смежных проектов которые с нами интегрируются, плюс куча бюрократов требующих отчетов по каждому чиху 3 раза в день. Возможно, в коиманде не дураки, возможно, как их лид я не справляюсь, но я физически не вижу что я могу сделать лучше и эфективние. Не дай бог, я давая задание, где-то оговорюсь или забуду что-то упомянуть, они ж даже не перспросят - сначала все сделают, а потом придут и скажут, что какое-то говно получилось, не знаю ли я в чем дело - они просто тупо не думают своей головой.

мне лучшим решением в Вашей ситуации видится использование талантов строго по назначению.
из 37 отобрать 7 самых ответственных и послушных в заград-отряд от "архитекторов, BA, меджеров моего и смежных проектов " 1-го (который из 40 был в 3-4) в помошники себе и кодировать. остальные челеустремленно должны занятся ИБД

[Сабина]

В netflix/apple/e-bay/walmart.com и еше сотни компаний v San Francisco обращаться не пробовали? Мы троих oracle dba наняли за последние полгода.

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

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

[Baton-Max]

мне лучшим решением в Вашей ситуации видится использование талантов строго по назначению.
из 37 отобрать 7 самых ответственных и послушных в заград-отряд от "архитекторов, BA, меджеров моего и смежных проектов " 1-го (который из 40 был в 3-4) в помошники себе и кодировать. остальные челеустремленно должны занятся ИБД

Легко сказать... вот прямо счас разгребал - попросил одну загорелую девицу убрать все пароли и логины из пропертей в j2c и пользовать j2c алиасы. Есть тут кто-нибудь, кто понял бы это как: удалить логины и пароли из проперти файлов, удалить соотв. константы/переменные хранившие значения из кода и захардкодить алиасы в код , в тех местах где раньши дергались константы инициализированнные и пропертей
Такое чуство, что если им код побуквенно не продиктуешь, то они нормально ничего не напишут. Простое обхяснение на словах, чего хотим сделать им не хватает.
До этого, в этой же конторе, но на другом проекте, была команда из 20 девелоперов, все белые (русские, американцы). Все всё с полуслова понимали - обсуждать любые идеи было приятно, никому ненадо было лезть в дебри того, как это все написать, на верхнем уровне обсудили как должно работать, и каждый сделал свою часть и написал документацию... лепота.

[ПростоНик]

@mynameiszb А почему это должна быть ваша проблема? Ну встанет работа, ваше-то какое дело. Посоветуйте тем, кто от этого страдает обращаться за поддержкой в Бангалор. И либо они ее там получит, либо пусть Бангалор вам скажет, что они _не могут_ это сделать.
И вообще, можете всех кого не любите посылать на х в Бангалор за суппортом - будут ходить как шелковые.

Лично я говорю в таких случаях, что это отличная возможность научиться чему-то. Кто сломал, тот и ремонтирует. И нее..волнует.

[Albert_al]

@mynameiszb А почему это должна быть ваша проблема? Ну встанет работа, ваше-то какое дело. Посоветуйте тем, кто от этого страдает обращаться за поддержкой в Бангалор. И либо они ее там получит, либо пусть Бангалор вам скажет, что они _не могут_ это сделать. И вообще, можете всех кого не любите посылать на х в Бангалор за суппортом - будут ходить как шелковые.

Лично я говорю в таких случаях, что это отличная возможность научиться чему-то. Кто сломал, тот и ремонтирует. И нее..волнует.

Ага , а нам вот ето индюшиное гнездо, TCS, скоро будет EDW (укровище данных то есть) переделывать
http://www.mid-day.com/news/2013/aug/15 ... -court.htm

[ПростоНик]

@mynameiszb А почему это должна быть ваша проблема? Ну встанет работа, ваше-то какое дело. Посоветуйте тем, кто от этого страдает обращаться за поддержкой в Бангалор. И либо они ее там получит, либо пусть Бангалор вам скажет, что они _не могут_ это сделать. И вообще, можете всех кого не любите посылать на х в Бангалор за суппортом - будут ходить как шелковые.

Лично я говорю в таких случаях, что это отличная возможность научиться чему-то. Кто сломал, тот и ремонтирует. И нее..волнует.

Ага , а нам вот ето индюшиное гнездо, TCS, скоро будет EDW (укровище данных то есть) переделывать
http://www.mid-day.com/news/2013/aug/15 ... -court.htm

Ну против откатов большому начальству бороться трудно. Если и накосячат - то у них есть "золотой" парашют.

[Albert_al]

Ну против откатов большому начальству бороться трудно. Если и накосячат - то у них есть "золотой" парашют.

етто точно

[mynameiszb]

@mynameiszb А почему это должна быть ваша проблема? Ну встанет работа, ваше-то какое дело. Посоветуйте тем, кто от этого страдает обращаться за поддержкой в Бангалор. И либо они ее там получит, либо пусть Бангалор вам скажет, что они _не могут_ это сделать.
И вообще, можете всех кого не любите посылать на х в Бангалор за суппортом - будут ходить как шелковые.

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

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



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

Имеем указание "отдать разработку архитектуры базы данных" все тем же мудрецам с берегов Ганга. Задача одного модуля - хранить древовидную структуру. Пакет на запись/изменения и сама таблица. Казалось бы - что сложного? Реляционный запрос, parent id в качестве ссылки и навигации и все такое.

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

Вот и посылай

[Zorkus]

а какие особенности у теперяшнего рынка? все зажравшиеся сидят по конторам и никуда не хотят уходить?

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

Дело в том, что текущий работедатель знает настоящую цену 'зажравшимся', а для конкурентов это кот в мешке. Т.е. конкуренты может и предлагают плюс 10-20% к _среднему_ рынку, но это не достаточно. Как раз про это фаундеры Developer auction и говорят: неправильно то, что никакой девелопер получает 90, а очень хороший всего 180.

+1

[Zorkus]

к сожалению всё не так просто. работать то приходится в коллективе. примадонны влияют на коллектив обычно не очень позитивно.

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

Найти хороших людей , если работаешь не в Гуглах (обобщенно) - _очень_ трудно.

именно так. о чём я тут постоянно и ною..

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

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

Важно понимать, что если "крутой" работодатель считает, что на рынке 95% девелоперов идиоты, а из оставшихся 5% умных - 99% хотят непомерно много, то "крутой" девелопер считает, что 95% предложение на рынке - совершенно неинтересные, а из оставшихся 5% - за 99% предлогают слишком мало.

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

[Zorkus]

чем больше человек пахал тем больше умеет .

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

Ключевое слово не пахал - а менял работу. Я наблюдал это в СССР и здесь на самом деле никакой разницы. Реально рост зарплаты связан не с объемом поля а с умением продавать себя. Процесс продажи происходит в момент смены работы. . Т.е. когда идет процесс охмурения можно что то выторговать.
Просветление не наступает в результате пахания (объема пахаты), просветление наступает от чтения умных книг, работы с умными людьми. Мало того, если пахать очень очень много работая с не шибко грамотными людьми и не читать умных книг (поскольку нет ни сил ни времени) никакого просветления не будет никогда.

По зарплате можно нормально расти и не переходя в другую контору. Мой прошлогодний pay raise в моей теперишней конторе был где-то в районе 20% (+ дополнительные shares и т.п.). Но таки да - нужно идти к начальству и разговаривать, а не молчать. А то ежегодным performance review с их незначительным повышением - сыт не будешь.

Что без гринки делать как-то не очень...

[Интеррапт]

Что без гринки делать как-то не очень...

Да, на рабочей визе конечно руки связаны очень сильно.

[Zorkus]

отобрать 7 самых ответственных и послушных в заград-отряд от "архитекторов, BA, меджеров моего и смежных проектов "

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

[Ljolja]

... обычно восстанавливается из back up за неск. мин./часов...

Это тока в теории так, а на практике все гораздо сложнее.
1. Тете надо собщить менагеру о проблеме с подробностями, что уже как бы плохо.
2. Менагер будет какое-то время думать и задавать много вопросов.
3. Программу остановить нельзя, с ней много людей работает.
4. Потом ДБА восстановят старую копию на другую машину и хорошо если есть скрипт, который может скопировать тот самый один проект.
5. Если нет, то придется его кому-то написать, причем тому, кто таки в теме и знает что и как надо копировать/модифицировать.
А вы говорите несколько минут.

да не, я понимаю, все зависит от организации системы:
1. при хорошей организации, что бы какая-то тетя что-то грохнула, она должна очень постараться (продемонстрировать явную злонамерреность)
2. скрипты, работаюшие с базой, пишутся in advance (потом слегка корретируются в зависимости от ...)
3. скрипты, должны поддерживать инкрементное добавление проектов и прочая к активной базе без остановки программы
4. ну и если сделано без малейших интеллектуальных усилий, абы как лишь бы быстрее, то чего ж удивляться

[offtopic=on]
Ljolja,
скажите пожалуйста максимальный размер базы и максимальное количество одновременных пользователей у той базы с которой вы работали ?
[offtopic=off]

специально для Вас посмотрела, основная база с кот. я работаю 9TB, пользовательская нагрузка маленькая, скриптовая большая