разве что при работе в коллективе для понимания между коллегами. если коммуникаций никаких и не предполагается развитие специалиста через книги / лекции / конференции — тогда есть возможность не знать терминологию.
был у меня такой коллега))) слава Богу уже работаем порознь. орал зачем ему знать основы — он и так умный)
написал свой атомик на Java, потому что оракловские медленно работают… они, видите ли работают через синхронизацию…
мало того, что работало с ошибками (ни разу не запустил чтобы проверить), так еще и скорость по бенчмарку показал на ДЕВЯТЬ порядков ниже…
если вы не видите пользы в математике — это совсем не значит, что она не нужна. это просто означает, что в вашей работе будет много велосипедов.
а готовые библиотеки не панацея. как это странно не прозвучит, но надо знать внутреннюю структуру всего, что используется в критических местах, чтобы писать эффективно.
пример из жизни — когда я был маленьким и глупым — получил тестовое задание от яндекса… посчитать количество чисел на офигенно большом отрезке, в которых цифры не повторяются… решение в лоб считало на 8 ядрах около 5 часов… после некоторых манипуляций с точки зрения алгоритмов — 20 секунд...))) убитое время научило в чем разница между быдлокодером и программистом.
был я на его лекции на Jpoint17. очень странный подход. для проектов на коленке без адаптивной структуры пойдет. но никак не для серьезных продуктов. в примере, который был показан для демонстрации всей красоты этого кода, было более 20 уровней вложенности конструктор-в-конструктор.
читаемость де-факто нулевая, но зато не магия.
я правда не знаю со скольки очков можно сливать карму. но у меня пока что эта опция недоступна...) ну и ради бога)
я где-то написал о частых патчах в extJS? простите, вы с какого раза способны усвоить информацию без каких-то додумок со своей стороны? отсутствие патчей не значит, что работать с библиотекой нельзя. натыкаясь на один и тот же баг ваша команда тратит каждый раз время на полный его ресерч? я сильно сомневаюсь в этом — поднимаются готовые обертки и все работает. 1 раз разобраться в баге — пусть даже 3 дня времени. вторая встреча с такой багой -уже вопрос на минуты/часы.
я не верю в аджайл и использую его для СВОИХ проектов. и только. на работе его нет и все живут дружно) он не панацея, а просто удобный инструмент если уметь с ним работать. и вполне логично если работая в таком стиле я откажусь работать со «свободным художником», который вместо исполнительности будет рассуждать о том какое он ранимое существо и как ему нужен отдых. очередная фантазия о том, что я якобы говорил)
вы все Г и неопытные, а я талант
а это и вовсе клевета на профессию. есть такое понятие, как профессиональная этика, но вы ею банально не владеете — тыкаете коллегам, считаете свое мнение единственно верным без вникания в аргументы оппонента, врете в конце-концов (перевирание слов ни что иное как ложь). отсюда и вытекает неуважение к вам персонально. обобщать это на остальных добросовестных пользователей не нужно.
я понятия не имею что там у вас такое случилось — бросила девушка/парень, уволили, понизили или еще что — это не повод так эмоционально реагировать.
то что имхо некомпетентное -видно сразу.
нигде не требуют укладываться в срок если человек заболел. это человеческий фактор и он заложен.
все, кто не использует Аджайл, безответственные и не укладываются в сроки
если перестанете психовать и перечитаете что я написал выше — увидите, что подобной глупости там нет. просто команда НЕ способная работать в срок не сможет работать в Agile. это не то же, что написали вы.
им интересно знать, подойду ли я им под их «ритм» работы, но если я супер знаю методологию, но нихрена в программировании не шарю, то какой от меня толк?
именно для этого вводится испытательный срок. но какой смысл нанимать человека, который пропагандирует медитацию по 6 часов в день? если сотрудник не высыпается и приходит на работу без мозгов — за него должны работать остальные члены команды — ну и кому такой халявщик нужен?)
да, баги встречаются везде. но ведь находятся люди, которые при этом могут назвать срок и более того — выдержать его? это называется компетенция.
никто никогда не требует называть сроки в формате «если не будет ни одной ошибки». если требуют — можно слать их смело.
физически, какая бы команда не была бы профессиональна, выполнить в сроки не получится
если обещать сделать фичу за 20 минут и тут же идти пить кофе на час, то именно так и будет. надо знать продукт, с которым работаешь. вот и все.
ps с extjs я работал. да, есть баги. да, есть проблемы. но если с этой библиотекой плотно поработать — все эти проблемы начинают пропадать. просто в силу навыка их решения. так с любой библиотекой. так с любым языком. даже в таких гигантах как Spring баги или неочевидные моменты встречаются.
pss разработчикам-художникам место на рынке фриланса)) пару раз не заплатят за пролет по срокам — живо научатся работать или перейдут обратно в QA. в бизнес-командах, нацеленных на зарабатывание денег и обретение знаний в срок (у вас в книжках страницы не растут, нет? чтобы «я выучу эту технологию за неделю» можно было отодвигать), им делать нечего.
работал с нереальными профи, и у них бывают застои
сравнение крайне некорректное. разница между новичком и профи именно в том, что объем выполненной работы профи может превышать работу новичка на порядок. такой человек даже «тормозя» день-два по итогу месяца выдаст работу, которая превзойдет ваш полугодовой продукт. это тоже совершенно нормальная ситуация. и не надо приравнивать себя к ним. «если ему можно пить чай весь день — то и мне можно». я знаю человека. который на работу приходит в 12 и уходит в 4-5. большую часть работы он делает дома. причем большую часть работы отдела. но это же не значит, что весь офис может так ходить?))) вот если кто-то догонит его по навыкам — может быть им и разрешат халявить.
возможно тебе (раз уж на ты с другими участниками) стоило просветить свою неграмотную команду что такое Agile и как им пользоваться? книжки там почитать что ли…
согласен, что есть куча команд. где им пользуются неверно, но не видел ни одного неудачного опыта по вине методологии. порой просто команда не способна держать сроки в силу низкой квалификации или особенности продукта. и разумеется у них находится виноватая во всем методология. а в некоторых случаях такой подход просто не требуется вводить — ребята сами не осознают, что и так работают в стиле коротких спринтов. без всякой бюрократической волокиты.
Agile разработка это прежде всего сроки и ответственность. в ней невозможна ситуация, когда одну задачу мосолят полгода — любители подобного безделья не уживаются с регулярными вопросами «как продвигается работа?». возможно ты из таких — отсюда и негатив?
Интересная статья. Прежде всего тем, что автор под конкретными примерами указал только свой софт (не осуждаю, просто очень уж это бросается в глаза).
Для примера, я когда-то работал над одной из систем документооборота и было интересно заглянуть в соответствующий раздел.
И что там?
В России рынок СЭД довольно плотно поделен, более 40% рынка принадлежат одной компании. Частично элементы СЭД реализованы в крупных ERP и CRM-системах.
И все. Ни одного конкретного продукта.
Простите, но какой же это «навигатор по софту» и где тут выбор? Классификатор типов — да. Навигатор? Ни разу. Чтобы найти варианты для какого-то конкретного раздела (даже не преимущества решений, а хотя бы их названия) так и так придется пользоваться поисковиком.
проблемы и баги возникают прежде всего не от кривизны рук, а от организации процесса разработки. можно просто их игнорировать — тогда они будут копиться и заполонят продукт. а можно устраивать итерации-фиксы, в которых нет новых фич, а есть только правки. встречал я так же модель вида «баг должен быть устранен в течение N часов» (зависит от критичности).
так что их существование совсем не обязательно.
ну а если они там и есть — как показывает опыт, свежий взгляд сильно помогает в их устранении.
ну и будет достигнуто самое главное — работник получит возможность поработать с новой технологией.
предложили бы мне выбрать между «чистым» проектом на JDK5 и проблемным на JDK8 — выбор был бы очевиден)
простите, вы не до конца правы.
если бы вам платили 50 процентов оклада (немалого, к слову) просто потому что вы самый «старый» сотрудник компании, присутствовали при основании инструментария и знаете там все и вся — вы бы легко ушли на другую более интересную работу, но по окладу рынка? минимум минус треть суммы.
эта проблема когда-то сложилась в голове. это да. человек долго не находил достаточно веских причин двигаться дальше. это оправданно если легко вносятся инновации и худо-бедно можно работать в тренде современности.
а как вы определите хороший вы специалист или нет?
я довольно долго просидел на своей первой работе. вроде как «набирался опыта». а как попробовал походить по другим вариантам — такие аховые пробелы всплыли… сейчас даже смешно вспоминать)
это как раз одна из причин почему если уж не менять работу, то ходить по собеседованиям точно надо. чтение литературы «10 самых популярных вопросов собеседования» тут не поможет.
да и смена работы даст более значительный прирост оклада, нежели верность одному работодателю. не предлагаете же вы сидеть на одном месте и расти с джуниора? надо, собственно, и в семью деньги носить.
кто-то сказал «программист работает не за деньги, но его работа не бесплатна». некоторые работодатели про это любят забывать со временем.
не вижу повода для сарказма. я это все на практике регулярно вижу.
а какая разница что там внутри у этого провайдера? он вам отдаст контекст. и все.
или вы для каждого нового контекста будете вносить новые методы и пилить дополнительные интерфейсы? тогда проблема в недостаточной абстракции. это уже не ООП должно меняться, а стиль разработки.
если вы плодите миллионы лишних объектов — это проблема уже ваша. пишите более гибкий код.
и все-таки вы не ответили — чем deadline мешает лично вам написать красивый код? почему вы противопоставляете эти вещи?
а почему вы считаете, что дедлайны не дают писать красивый код?
если вы напишете быстро какую-то малочитаемую чушь — вы потратите больше сил на ее поддержку, чем могли бы. овчинка выделки не стоит.
тысячи строк чужого кода
для тысяч строк существуют метрики. если их не ввести — компания тонет и начинает срывать те же дедлайны или неоправданно раздувает штат.
они для того и нужны чтобы десятки людей писали код так, будто бы это писал один человек. в одном стиле.
я такого человека знаю по одной из бывших работ. н засиделся. каждый год пытается куда-то уйти и возвращается.
а причина проста как апельсин — основная часть его оклада идет не с навыков, а с того, что он знает структуру данного конкретного проекта. и на рынке труда ему даже аналогичную зарплату не предлагают.
это я и оспаривать не стану. скорее всего так и есть. но тут уже вопрос — почему нужно тратить время на освоение того как работает система треккинга? возьмите ту же джиру — там ребенок разберется. интерфейс должен быть не только доступным для действий. он должен быть интуитивным чтобы видящий его впервые человек думал о своих задачах, а не о том где нужная кнопка.
но это уже субъктивное отношение.
вам больше всех надо?
неудобную инфраструктуру я воспринимаю как грязь в тарелке с едой. все должно приносить радость. в мире много хорошего и интересного) если за считанные часы я могу полностью развернуть инфраструктуру отдела — почему бы этого не сделать? я это делаю не для всех, а в первую очередь для себя.
вариант использовать в своих проектах удобную мне инфраструктуру тоже бы устроил)
тыкните носом на википедию
меня чуть не сожгли когда я спросил с чего взяли, что gitlab абсолютно запрещает пуши в master… даже до документации не дошли) или хотя бы до интерфейса.
я вас понимаю и рад, что у вас все сработало. в моем случае просто нереально пройти дальше «попросил руководство». основной аргумент менеджера «это лишняя работа мне». доказывать, что этим будут заниматься разработчики, которые вполне компетентны чтобы пользоваться продуктом без каких-то доп курсов бесполезно. просто пропускается мимо ушей.
150 конфликтов при мерже? на это ответят «ничего страшного. посидишь помержишь.».
а так да. на одной из прошлых работ повнедрял подобные процессы — все были довольны.
а вы заранее нашли место или ехали в слепую? при наличии своего жилья в той же Москве можно свободно искать месяцами. вот на съемном это уже не так весело. идти в первое попавшееся место тоже ведь не хочется.
охотно верю. наблюдал на YAC2014 (кажется) как представителю mail после лекции о тестах задали вопрос «а как же вы все это храните? это же огромное количество кода»)
тут разница в другом — устраивает ли подобный процесс команду. сам могу администрировать все от Jira до Zabbix. это ни разу не сложно и найма новых специалистов не требует — просто желания и инициативы)
отдельный случай если нет мощностей. тут уже ничего не поделаешь.
на 10 человек в отделе это 10 долларов в год. сам держу в облаке для себя — лень держать работающую машину. каких-то дополнений к нынешней версии не потребуется. раньше брался greenhooper, но сейчас он идет в комплекте.
для компании с доходом в десятки миллионов в ДЕНЬ это мелочь.
может быть redmine и бесплатен, но он крайне неудобен. вчера только рассказал нашему архитектору как в нем исправить описание. он работает с ним второй год и всерьез считал, что это невозможно. (там мааааааленький карандашек в неочевидном месте).
задавать вопрос PM-у к сожалению бесполезно. инициатива снизу пресекается жестко. насколько бы полезным предложение не было — оно даже не рассматривается.
договоритесь с админами, что бы вам выделили свой профиль и запускайте тесты там
админские права у всех. сборку-то я завел и использую. но какой смысл если тесты правлю только я?
назначение дженкинса (цитирую) — отслеживать какие варники мы отдали на установку и собирать эти варники.
тесты? метрики? ни в коем разе! даже деплой в nexus с локальных машин!
Если пользователи Nexus вам приносят 2,47$ в месяц — это отличная идея
они не приносят денег вообще. он закрытый и только для отдела. но тут уже вопрос живучести и загрузки сетевого канала. да и свои артефакты тоже надо держать там. сейчас же сборка идет на локальных артефактах. то есть выполнил install на ядре — собери продукт…
с администраторами договариваться не надо. админские права раздали всем.
а не боитесь, что в один день компания разорится и вы окажетесь с навыками по факту ненужными на рынке труда? по опыту знаю, что на собеседованиях начинаешь понимать что именно сейчас в тренде. если за эти 6 лет вы поддерживаете просто какой-то интернет-магазин и профессионально не растете — могут и не взять выбрав энтузиаста с парой лет за плечами, но со знаниями новомодных фреймворков.
в этой сфере ведь опыт измеряется не годами, а проектами и навыками. вот вам пример. 6 лет назад (просто совпадение) я начал с одним из моих товарищей в одной известной компании. он там работает и по сей день. работает на пятой джаве. а теперь вопрос викторины — придет человек искать новое место и скажет, что он на восьмой джаве не писал вообще, но у него 6 лет опыта. кому нужно его доучивать? только на такой же древний проект пыль стирать.
разве что при работе в коллективе для понимания между коллегами. если коммуникаций никаких и не предполагается развитие специалиста через книги / лекции / конференции — тогда есть возможность не знать терминологию.
был у меня такой коллега))) слава Богу уже работаем порознь. орал зачем ему знать основы — он и так умный)
написал свой атомик на Java, потому что оракловские медленно работают… они, видите ли работают через синхронизацию…
мало того, что работало с ошибками (ни разу не запустил чтобы проверить), так еще и скорость по бенчмарку показал на ДЕВЯТЬ порядков ниже…
если вы не видите пользы в математике — это совсем не значит, что она не нужна. это просто означает, что в вашей работе будет много велосипедов.
а готовые библиотеки не панацея. как это странно не прозвучит, но надо знать внутреннюю структуру всего, что используется в критических местах, чтобы писать эффективно.
пример из жизни — когда я был маленьким и глупым — получил тестовое задание от яндекса… посчитать количество чисел на офигенно большом отрезке, в которых цифры не повторяются… решение в лоб считало на 8 ядрах около 5 часов… после некоторых манипуляций с точки зрения алгоритмов — 20 секунд...))) убитое время научило в чем разница между быдлокодером и программистом.
читаемость де-факто нулевая, но зато не магия.
я где-то написал о частых патчах в extJS? простите, вы с какого раза способны усвоить информацию без каких-то додумок со своей стороны? отсутствие патчей не значит, что работать с библиотекой нельзя. натыкаясь на один и тот же баг ваша команда тратит каждый раз время на полный его ресерч? я сильно сомневаюсь в этом — поднимаются готовые обертки и все работает. 1 раз разобраться в баге — пусть даже 3 дня времени. вторая встреча с такой багой -уже вопрос на минуты/часы.
я не верю в аджайл и использую его для СВОИХ проектов. и только. на работе его нет и все живут дружно) он не панацея, а просто удобный инструмент если уметь с ним работать. и вполне логично если работая в таком стиле я откажусь работать со «свободным художником», который вместо исполнительности будет рассуждать о том какое он ранимое существо и как ему нужен отдых. очередная фантазия о том, что я якобы говорил)
а это и вовсе клевета на профессию. есть такое понятие, как профессиональная этика, но вы ею банально не владеете — тыкаете коллегам, считаете свое мнение единственно верным без вникания в аргументы оппонента, врете в конце-концов (перевирание слов ни что иное как ложь). отсюда и вытекает неуважение к вам персонально. обобщать это на остальных добросовестных пользователей не нужно.
то что имхо некомпетентное -видно сразу.
нигде не требуют укладываться в срок если человек заболел. это человеческий фактор и он заложен.
если перестанете психовать и перечитаете что я написал выше — увидите, что подобной глупости там нет. просто команда НЕ способная работать в срок не сможет работать в Agile. это не то же, что написали вы.
именно для этого вводится испытательный срок. но какой смысл нанимать человека, который пропагандирует медитацию по 6 часов в день? если сотрудник не высыпается и приходит на работу без мозгов — за него должны работать остальные члены команды — ну и кому такой халявщик нужен?)
да, баги встречаются везде. но ведь находятся люди, которые при этом могут назвать срок и более того — выдержать его? это называется компетенция.
никто никогда не требует называть сроки в формате «если не будет ни одной ошибки». если требуют — можно слать их смело.
если обещать сделать фичу за 20 минут и тут же идти пить кофе на час, то именно так и будет. надо знать продукт, с которым работаешь. вот и все.
ps с extjs я работал. да, есть баги. да, есть проблемы. но если с этой библиотекой плотно поработать — все эти проблемы начинают пропадать. просто в силу навыка их решения. так с любой библиотекой. так с любым языком. даже в таких гигантах как Spring баги или неочевидные моменты встречаются.
pss разработчикам-художникам место на рынке фриланса)) пару раз не заплатят за пролет по срокам — живо научатся работать или перейдут обратно в QA. в бизнес-командах, нацеленных на зарабатывание денег и обретение знаний в срок (у вас в книжках страницы не растут, нет? чтобы «я выучу эту технологию за неделю» можно было отодвигать), им делать нечего.
сравнение крайне некорректное. разница между новичком и профи именно в том, что объем выполненной работы профи может превышать работу новичка на порядок. такой человек даже «тормозя» день-два по итогу месяца выдаст работу, которая превзойдет ваш полугодовой продукт. это тоже совершенно нормальная ситуация. и не надо приравнивать себя к ним. «если ему можно пить чай весь день — то и мне можно». я знаю человека. который на работу приходит в 12 и уходит в 4-5. большую часть работы он делает дома. причем большую часть работы отдела. но это же не значит, что весь офис может так ходить?))) вот если кто-то догонит его по навыкам — может быть им и разрешат халявить.
согласен, что есть куча команд. где им пользуются неверно, но не видел ни одного неудачного опыта по вине методологии. порой просто команда не способна держать сроки в силу низкой квалификации или особенности продукта. и разумеется у них находится виноватая во всем методология. а в некоторых случаях такой подход просто не требуется вводить — ребята сами не осознают, что и так работают в стиле коротких спринтов. без всякой бюрократической волокиты.
Agile разработка это прежде всего сроки и ответственность. в ней невозможна ситуация, когда одну задачу мосолят полгода — любители подобного безделья не уживаются с регулярными вопросами «как продвигается работа?». возможно ты из таких — отсюда и негатив?
Для примера, я когда-то работал над одной из систем документооборота и было интересно заглянуть в соответствующий раздел.
И что там?
И все. Ни одного конкретного продукта.
Простите, но какой же это «навигатор по софту» и где тут выбор? Классификатор типов — да. Навигатор? Ни разу. Чтобы найти варианты для какого-то конкретного раздела (даже не преимущества решений, а хотя бы их названия) так и так придется пользоваться поисковиком.
так что их существование совсем не обязательно.
ну а если они там и есть — как показывает опыт, свежий взгляд сильно помогает в их устранении.
ну и будет достигнуто самое главное — работник получит возможность поработать с новой технологией.
предложили бы мне выбрать между «чистым» проектом на JDK5 и проблемным на JDK8 — выбор был бы очевиден)
если бы вам платили 50 процентов оклада (немалого, к слову) просто потому что вы самый «старый» сотрудник компании, присутствовали при основании инструментария и знаете там все и вся — вы бы легко ушли на другую более интересную работу, но по окладу рынка? минимум минус треть суммы.
эта проблема когда-то сложилась в голове. это да. человек долго не находил достаточно веских причин двигаться дальше. это оправданно если легко вносятся инновации и худо-бедно можно работать в тренде современности.
я довольно долго просидел на своей первой работе. вроде как «набирался опыта». а как попробовал походить по другим вариантам — такие аховые пробелы всплыли… сейчас даже смешно вспоминать)
это как раз одна из причин почему если уж не менять работу, то ходить по собеседованиям точно надо. чтение литературы «10 самых популярных вопросов собеседования» тут не поможет.
да и смена работы даст более значительный прирост оклада, нежели верность одному работодателю. не предлагаете же вы сидеть на одном месте и расти с джуниора? надо, собственно, и в семью деньги носить.
кто-то сказал «программист работает не за деньги, но его работа не бесплатна». некоторые работодатели про это любят забывать со временем.
а какая разница что там внутри у этого провайдера? он вам отдаст контекст. и все.
или вы для каждого нового контекста будете вносить новые методы и пилить дополнительные интерфейсы? тогда проблема в недостаточной абстракции. это уже не ООП должно меняться, а стиль разработки.
если вы плодите миллионы лишних объектов — это проблема уже ваша. пишите более гибкий код.
и все-таки вы не ответили — чем deadline мешает лично вам написать красивый код? почему вы противопоставляете эти вещи?
если вы напишете быстро какую-то малочитаемую чушь — вы потратите больше сил на ее поддержку, чем могли бы. овчинка выделки не стоит.
для тысяч строк существуют метрики. если их не ввести — компания тонет и начинает срывать те же дедлайны или неоправданно раздувает штат.
они для того и нужны чтобы десятки людей писали код так, будто бы это писал один человек. в одном стиле.
а причина проста как апельсин — основная часть его оклада идет не с навыков, а с того, что он знает структуру данного конкретного проекта. и на рынке труда ему даже аналогичную зарплату не предлагают.
это я и оспаривать не стану. скорее всего так и есть. но тут уже вопрос — почему нужно тратить время на освоение того как работает система треккинга? возьмите ту же джиру — там ребенок разберется. интерфейс должен быть не только доступным для действий. он должен быть интуитивным чтобы видящий его впервые человек думал о своих задачах, а не о том где нужная кнопка.
но это уже субъктивное отношение.
неудобную инфраструктуру я воспринимаю как грязь в тарелке с едой. все должно приносить радость. в мире много хорошего и интересного) если за считанные часы я могу полностью развернуть инфраструктуру отдела — почему бы этого не сделать? я это делаю не для всех, а в первую очередь для себя.
вариант использовать в своих проектах удобную мне инфраструктуру тоже бы устроил)
меня чуть не сожгли когда я спросил с чего взяли, что gitlab абсолютно запрещает пуши в master… даже до документации не дошли) или хотя бы до интерфейса.
150 конфликтов при мерже? на это ответят «ничего страшного. посидишь помержишь.».
а так да. на одной из прошлых работ повнедрял подобные процессы — все были довольны.
тут разница в другом — устраивает ли подобный процесс команду. сам могу администрировать все от Jira до Zabbix. это ни разу не сложно и найма новых специалистов не требует — просто желания и инициативы)
отдельный случай если нет мощностей. тут уже ничего не поделаешь.
для компании с доходом в десятки миллионов в ДЕНЬ это мелочь.
может быть redmine и бесплатен, но он крайне неудобен. вчера только рассказал нашему архитектору как в нем исправить описание. он работает с ним второй год и всерьез считал, что это невозможно. (там мааааааленький карандашек в неочевидном месте).
задавать вопрос PM-у к сожалению бесполезно. инициатива снизу пресекается жестко. насколько бы полезным предложение не было — оно даже не рассматривается.
админские права у всех. сборку-то я завел и использую. но какой смысл если тесты правлю только я?
назначение дженкинса (цитирую) — отслеживать какие варники мы отдали на установку и собирать эти варники.
тесты? метрики? ни в коем разе! даже деплой в nexus с локальных машин!
они не приносят денег вообще. он закрытый и только для отдела. но тут уже вопрос живучести и загрузки сетевого канала. да и свои артефакты тоже надо держать там. сейчас же сборка идет на локальных артефактах. то есть выполнил install на ядре — собери продукт…
с администраторами договариваться не надо. админские права раздали всем.
в этой сфере ведь опыт измеряется не годами, а проектами и навыками. вот вам пример. 6 лет назад (просто совпадение) я начал с одним из моих товарищей в одной известной компании. он там работает и по сей день. работает на пятой джаве. а теперь вопрос викторины — придет человек искать новое место и скажет, что он на восьмой джаве не писал вообще, но у него 6 лет опыта. кому нужно его доучивать? только на такой же древний проект пыль стирать.