Очень много людей, которые почитали книжку, приходят на собеседование джуна, мол, научите меня. Такие "джуны" никому не нужны, т.к. их учить очень дорого. Например, синьор может обучать до 5 джунов одновременно. На обучение джуна нужно 2-3 мес. Причем синьор не выполняет своих обязанностей в это время. Зп синьора 3,5к баксов. Получается, на обучение 5 человек тратятся 10к баксов, т.е. по 2к на человека. Добавьте к этой сумме зп джуна и стоимость его рабочего места, расходы на него. Получается 3-4к баксов. Причем пользы он не приносит, т.к. его код - это говнокод, который синьор постоянно перепроверяет и иногда исключает.
Вывод
Джун должен быть таким, который:
обучается сам
требует минимального контроля
знает великолепно java core
умеет искать информацию сам
задает правильные вопросы
не дергает по пустякам других программистов
знает обзорно технологии проекта
следует правилам написания кода, принятым в проекте, без отсебятины
быстро въезжает в проект
Требования к джуну на проекте:
отличное знание Java Core
самообучение
четкое формулирование проблемы
написание простых запросов SQL
распознавание в проекте ведущих технологий. Для большинства проектов:
сборка (Ant или Maven)
работа с базой данных - ORM (Hibernate, MyBatis и др.)
бизнес логика вклющая транзакционность (обычно Spring, необходимо понимание IoC)
клиент - масса фреймворков. Для веба желательно понимание основ HTML, CSS, JavaScript + часто либа JQuery.
Так что развивайтесь не только в джаве, и тогда быстрее станете программистом
Диана — в древнеримской мифологии богиня Луны и охоты. Всегда это имя завораживало :)
Но не буду отвлекаться, создательница темы безгранично права в жестокости и прагматичности текста представленной темы так же права в том, что кто предупреждён тот вооружён. Жизнь не любит слабых и тем более не любит паразитов, однако как сказал один великий полководец: лучшая тактика боя — тактика выживших.
Это говорит о том, что не стоит бояться нужно действовать, желание победить — это уже 70% победы, опыт обязательно придет более того — каждый настоящий мастер просто мечтает найти достойного ученика и передать ему свой опыт (только это секрет)!!!
Какая-то очень жесткая у вас контора/коллектив. Понятно, что от новичка будут ожидать стремление учится и разбираться самому, но у меня никогда не было проблем с тем, чтобы кто-то из коллектива не помог с вопросом/проблемой (конечно же вопрос должен быть задан корректно, но бывает, что и тупишь — никогда никто не отказывал, точно так же как и я потом не отказывал никому). Я бы даже сказал, что от новичка будут ТРЕБОВАТЬ задавать вопросы, ибо тот, кто их не задает, учиться гораздо медленнее и далает гораздо больше ошибок (хотя конечно тут тоже есть предел, правило золотой середины так сказать). А в остальном согласен с автором.
«Правильные вопросы», «Пустяки» — это звучит немного субъективно. То, что для одного пустяк, для другого может быть проблемой. Моя точка зрения заключается в том, что человек не должен бояться показаться глупым/незнающим и спокойно спрашивать (хотя бы первые 2 недели работы, а по-хорошему хотя бы месяц). Если Вы это имели ввиду, то тогда наши точки зрения совпадают.
Никакой демотивации. Я полностью согласен что для джуна нужен один единтсвенный скилл это самообучаемость. Если есть что сказать по теме я был бы не против услышать о вашем опыте. Ах да вас сразу на архитектора взяли, знаем знаем.
Моя работа пока что вообще не связана с java. Я инженер в другой области, и взяли меня не ГИПом, конечно. Но за время работы я и новых сотрудников обучал, и у студентов практикой руководил. Почему я? Потому что тоже в коллективе превалировало мнение, что мол ты, новичок, нас не трогай, а как-нибудь там сам в люди выходи. Но это, по моему мнению, выигрыш в тактике, но провал в стратегии.
Вот такие посылы я и уловил в этом топике. Задело меня немного. Надеюсь, я объяснился.
Думаю panzrnoob верно говорит. Обучаемость это хорошо, самостоятельность тоже. Но для juniora нужно понимание которое ИМХО лучше получать общаясь с более опытными сотрудниками. Команда должна поддерживать juniora, иначе он получит все что сможет и пойдет искать другую команду, у которой есть чему учиться, которая готова делится своим опытом.
Извите понимание чего именно вы имеете в виду? Если контора норм, там не точно должны, а обязаны иметь документы типа API governance, разного рода java dev guides где описаны все возможные вопросы и варианты их решения для новичков не в плане jun а новый сотрудник в компании.
У меня есть различный опыт и работа в IT среде и в около IT и там где IT вообще не пахло. Так вот опишу скажем так обобщенный случай как выглядит работа нового сотрудника, подчеркиваю не jun а просто новый сотрудник без разници есть опыт нету опыта.
Некоторое время уже довольно успешно работаешь, и тут понимаешь что есть вещи, специфические для данной фирмы. Спросишь помощи один раз, второй раз. На третий либо менеджер к вам подойдет и скажет так делать ненадо, либо на очередном appraisal ваше повышение зарплаты разделят ваши коллеги.
Если вы за подход где коллеги должны вам помогать, так вот мне нравятся компании где с коллегами работаешь в команде над общими задачами, а если нужна помощь. Идешь к менеджеру и требуешь от него оплатить Инструктора, время которого дешевле времени вашего коллеги.
Не вижу демотивации в посте. Статья — это мой субъективный опыт.
Кто предупржден, тот вооружен. Считаю, если у джуна будет реальное представление об ожидаемом от него поведении, то ему легче будет пройти испытательный срок.
Попадались мне индивидуумы «вот он я, учите меня»…
Нехило контора живет если может позволить снять сеньора с разработки. В нормальной ситуации это все выглядит по другому.
Пришел в команду скажем так неопытный разработчик. Месяц-два может три, тут как повезет, ему дают время прочитать спецификации касаемо кода, API, где что как используется, фреймворки и обще принятые практики. Паралельно устанавливает рабочию среду и все что с этим связано.
А дальше начинается самое интерестное. Допустим в фирме где придерживаются Agile методик разработки. Пусть будет Scrum к примеру. Получаем каждый разработчик имеет 1-2 must задания, 1-2 should, 1-2 could на каждый time box + фиксить баги и проводить код ревью, это не говоря о разных grooming sessions и тп. Конечно цифры могут разнится, но не суть важно. Бизнесс аналист придумал какую нить фишку, дал на нёё к примеру 2 тайм бокса. Итог получаем все разработчики по уши в работе. И кто простите будет сидеть над новичком и говорить ему что тот будет делать, когда для каждого менеджера и тим лида важно чтобы все must были сданы в срок.
Так что если планируете идти в разработку, готовтесь к тому что, никто с вами не будет сидеть, так что да Самообучение must have skill, и постоянно отрывать от работы своих коллег не очень красиво и может даже где то унизительно.
Однако не все так плохо.
Если вас взяли на работу, значит потенциал у вас есть и все будет ок. Разного рода GIT и тп, может надо учить может не надо. Любая среда разработки сегодня справляется на ура с Push, merge, commit, fetch, synchronize. То же логирование, если компания пользуется best practice, то скорее всего логирование будет на уровне анотаций, интерсепторов или еще чего.
Насчет тестирования опять же. Скоре всего ваши коллеги уже написали фреймворк для тестирования всего и вся. Останется только прочитать документацию и глянуть как ваши колеги писали код для одного или другого типа классов. Соглашусь jUnit + Mockito стоит знать хотя бы чтобы на интревью было что рассказать.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Но не буду отвлекаться, создательница темы безгранично права в жестокости и прагматичности текста представленной темы так же права в том, что кто предупреждён тот вооружён. Жизнь не любит слабых и тем более не любит паразитов, однако как сказал один великий полководец: лучшая тактика боя — тактика выживших.
Это говорит о том, что не стоит бояться нужно действовать, желание победить — это уже 70% победы, опыт обязательно придет более того — каждый настоящий мастер просто мечтает найти достойного ученика и передать ему свой опыт (только это секрет)!!!
Вот такие посылы я и уловил в этом топике. Задело меня немного. Надеюсь, я объяснился.
Думаю panzrnoob верно говорит. Обучаемость это хорошо, самостоятельность тоже. Но для juniora нужно понимание которое ИМХО лучше получать общаясь с более опытными сотрудниками. Команда должна поддерживать juniora, иначе он получит все что сможет и пойдет искать другую команду, у которой есть чему учиться, которая готова делится своим опытом.
Всего должно быть в меру.
У меня есть различный опыт и работа в IT среде и в около IT и там где IT вообще не пахло. Так вот опишу скажем так обобщенный случай как выглядит работа нового сотрудника, подчеркиваю не jun а просто новый сотрудник без разници есть опыт нету опыта.
Некоторое время уже довольно успешно работаешь, и тут понимаешь что есть вещи, специфические для данной фирмы. Спросишь помощи один раз, второй раз. На третий либо менеджер к вам подойдет и скажет так делать ненадо, либо на очередном appraisal ваше повышение зарплаты разделят ваши коллеги.
Если вы за подход где коллеги должны вам помогать, так вот мне нравятся компании где с коллегами работаешь в команде над общими задачами, а если нужна помощь. Идешь к менеджеру и требуешь от него оплатить Инструктора, время которого дешевле времени вашего коллеги.
Случайно минус поставил, другие комменты + поставил.
Да, по теме с вами согласен.
Я конечно написал то, чего хотелось бы, но трезво рассуждая — вы правы.
Кто предупржден, тот вооружен. Считаю, если у джуна будет реальное представление об ожидаемом от него поведении, то ему легче будет пройти испытательный срок.
Попадались мне индивидуумы «вот он я, учите меня»…
Пришел в команду скажем так неопытный разработчик. Месяц-два может три, тут как повезет, ему дают время прочитать спецификации касаемо кода, API, где что как используется, фреймворки и обще принятые практики. Паралельно устанавливает рабочию среду и все что с этим связано.
А дальше начинается самое интерестное. Допустим в фирме где придерживаются Agile методик разработки. Пусть будет Scrum к примеру. Получаем каждый разработчик имеет 1-2 must задания, 1-2 should, 1-2 could на каждый time box + фиксить баги и проводить код ревью, это не говоря о разных grooming sessions и тп. Конечно цифры могут разнится, но не суть важно. Бизнесс аналист придумал какую нить фишку, дал на нёё к примеру 2 тайм бокса. Итог получаем все разработчики по уши в работе. И кто простите будет сидеть над новичком и говорить ему что тот будет делать, когда для каждого менеджера и тим лида важно чтобы все must были сданы в срок.
Так что если планируете идти в разработку, готовтесь к тому что, никто с вами не будет сидеть, так что да Самообучение must have skill, и постоянно отрывать от работы своих коллег не очень красиво и может даже где то унизительно.
Однако не все так плохо.
Если вас взяли на работу, значит потенциал у вас есть и все будет ок. Разного рода GIT и тп, может надо учить может не надо. Любая среда разработки сегодня справляется на ура с Push, merge, commit, fetch, synchronize. То же логирование, если компания пользуется best practice, то скорее всего логирование будет на уровне анотаций, интерсепторов или еще чего.
Насчет тестирования опять же. Скоре всего ваши коллеги уже написали фреймворк для тестирования всего и вся. Останется только прочитать документацию и глянуть как ваши колеги писали код для одного или другого типа классов. Соглашусь jUnit + Mockito стоит знать хотя бы чтобы на интревью было что рассказать.
* логирование (Logback/Log4j)
* дебаг