Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Советы сеньоров: как прокачать знания junior Java

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

Павел Желнов, Senior Java Developer, 18 лет опыта Java разработки:

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

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

Документация классов Java

Наиболее достоверный источник информации, для чего служит тот или иной класс, какие проблемы решает лучше всего. Создатели языка постарались на славу, существенно упростив нам жизнь!

Книги

Замечательное средство, откуда мы черпаем полезную информацию. Если позволяют финансы — лучше покупать бумажный вариант, его более приятно пролистывать, делать пометки. Книгу надо не просто читать, как художественный роман Стивена Кинга. С книгой требуется тщательно работать, практически экспериментируя, преодолевая все сложности и осмысливая каждый шаг.

На моем столе лежат всего четыре:

  • Effective Java (Josh Bloch);
  • Clean Code (Robert Martin);
  • Design Patterns (Head First, O’Reilly);
  • Refactoring (Kent Beck & Martin Fowler).

Для начинающих стоит пролистать Thinking in Java (Bruce Eckel)

Гуглите и найдете

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

Практика

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

Собеседование

Ищите для начала возможность поработать на небольшом проекте, где у вас будет ограниченный круг обязанностей. Для того, чтобы попасть в команду разработчиков, придется пройти сложный этап собеседования. Здесь ценится не столько ваша теоретическая подкованность, сколько умение применить эту теорию на практике.

Рекомендую также перед собеседованием просмотреть ресурсы, похожие на этот и пролистать странички, касающиеся Java, Hibernate, Spring.

Ой, мне надо знать еще один язык?

Не все упирается в мастерское овладение языком Java. Ребром становится вопрос знания английского! Кратко, как можно прокачаться в этой сфере:

  • пополняйте свой словарный запас. Хоть техническую литературу не Чарльз Диккенc писал, все же вы себя будете чувствовать комфортнее, если вы знаете 3 тысячи слов, а не 200. Для этого нужно немного: книга уровня чуть выше вашего, словарик, ручка и тетрадка;
  • каждый день слушайте болтовню ребят с TED Talks, включайте новости BBC или просто старые записи Джорджа Карлина. Тренируйте свои способности слушать и понимать речь, это очень важно;
  • преодолевайте разговорный барьер: находите носителей языка и общайтесь с ними, не бойтесь ошибаться. Важно, чтобы вас понимали.

Помните, что вам часто придется делиться своими идеями, воспринимать идеи других — и все это на чистом английском.

Становление самурая

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

Всегда ищите возможность общаться с людьми, которые знают больше вас. Идеальный вариант — поработать с этими людьми над общим проектом. Они могут вам открыть ту истину, которую ни в одной книге не напишут.

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

Смахивайте ржавчину с мозга. Мозг — это оружие. И оно должно быть всегда заряжено. Держите это оружие в форме и оно вас не подведет:
www.codewars.com
www.codingame.com

Будьте проактивными и ваше развитие будет стремительным и уверенным!

Андрей Паславский, Team Lead, 13 лет опыта Java разработки:

Как «войти в ИТ» есть уже 100500 статей с кучей рекомендаций и советов, ссылок на курсы, школы и тому подобное. К сожалению, на данный момент сформировалась такая ситуация, когда программистов не хватает, но при этом у рекрутеров лежат стопочки с резюме потенциальных кандидатов, которые хотят «войти в ИТ». Грубо говоря, их три: те, кто хорошо прошли стажировку от компании или закончили школу и получили рекомендации; те, кто просто закончил школу, курсы, стажировку; и все остальные. В первую очередь, когда открывается позиция Junior, рекрутеры листают первую папочку, могут заглянуть во вторую, но до третьей практически никогда не добираются.

Мне кажется, основной вопрос не в том, как войти в ИТ. Основной вопрос: осознаю ли я, что это за работа и как выделиться на фоне всех остальных?

Я работал со студентами и просто с ребятами, которые хотят стать программистами. Но буквально единицы представляют, что такое быть разработчиком, что значит разрабатывать софт, а не писать лабораторную работу, что значит работать в команде?

В этом плане помогут курсы стажировки, разные workshops и workgroups. Нужно уметь работать в команде. Здесь волки-одиночки никому не нужны (если только вы не Линус Торвальдс, Бьёрн Страуструп, Мартин Фаулер). Попробуйте скооперироваться с вашим соседом и написать калькулятор вместе (не надо придумывать МЕГА проект, просто калькулятор). Это окажется в разы сложнее и дольше, чем вы бы это сделали сами. Это и будет маркер: вы эффективнее один, чем в группе. Работайте над собой, над своими навыками коммуникации и кооперации. Учитесь работать в команде.

Сколько бы вы не работали в ИТ — всегда будете учиться. Не получится пройти курсы «столяра» и пойти «работать на завод». У каждого мозги работают по-разному, поэтому вы должны сами найти форму обучения, которая для вас будет максимально эффективной (я не могу сказать, что для вас будет лучше: пробовать писать свои Pet projects или проходить online курсы один за другим). Учите учиться. Навык самообучения необходим в нашей индустрии, т. к. и через 10 лет вы будете продолжать учиться.

Ходите/ездите на конференции, они нужны в первую очередь для Junior. Да, может быть дорого, но это даст понимание того, что сейчас в тренде; сможете завести полезные знакомства и окунуться в мир людей, которые занимаются ИТ уже годы/десятилетия. Может быть где-то встретите человека, который скажет, что у него есть работа для вас. И вообще это fun, нужно получать удовольствие от того, чем вы занимаетесь.

Заведите свой аккаунт на GitHub и выкладывайте туда свои Pet projects. Это важно! Работодатель сможет оценить, с какими языками работаете, какие технологии изучаете и как развиваетесь. Он сможет запостить какие-то баги, придирки, рекомендации и посмотреть, как общаетесь, как реагируете и как работаете над ошибками. Вас могут намеренно спровоцировать — учитесь работать с клиентами, они бывают «разные». Здоровый юмор тут приветствуется.

Также очень важно понимать разницу между разработчиком и программистом. Погуглите об этом, в интернете уже написано много статей на эту тему. Но отдельно я хочу выделить навык «транспонирования своего опыта». Невозможно освоить и изучить всё, но можно научиться проводить аналогии и применять свой опыт в области, где никогда не работали. Нужно научиться анализировать и видеть общие идеи. Этому научиться сложно, но попробуйте начать с patterns: Java Patterns, Design Patterns, Enterprise Patterns. Это многолетний накопленный опыт, который разложили уже по полочкам для вас. Не пренебрегайте этим!

Сделайте ИТ своим хобби, работайте над собой в этой области факультативно. Да, компания и проект, где будете работать, определят уже конкретный стек технологий и будет понятно, что нужно изучать. Но не останавливайтесь на этом. Как только станете выполнять свою работу от «забора до забора» — в какой-то момент перестанете развиваться, а ИТ-индустрия не любит этого. Через некоторое время не будете котироваться на рынке и потеряете квалификацию.

Андрей Слободяник, Tech Lead, 11 лет опыта Java разработки:

Первое, чему должен научиться даже не разработчик, а вообще любой IT-специалист — это умению печатать вслепую. Да, большую часть времени программист читает спеку/код/доки, в перерывах думает, а не барабанит по клавишам, аки хакер в фильме. Да, в современных IDE есть автоподстановка. Но, как бы там ни было, айтишник, постоянно переводящий взгляд между клавиатурой и монитором, выглядит странно и вряд ли работает эффективно. Не все тренажеры одинаково полезны, главный принцип — положить правильно руки и осваивать всю клавиатуру сразу, рекомендую KeyTo/VerseQ.

Вторым условием роста я вижу процесс Code Review. Недостаточно, чтобы код просто работал, для джуниора (и не только) необходим взгляд со стороны по поводу подходов, компоновки кода, фреймворков и т. д. Иначе есть риск быстро поймать эффект Даннинга-Крюгера. Технически опасные места также помогут отловить статические анализаторы кода — FindBugs, Sonar etc.

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

Пример из Java:

public void congrats() {
    Date today = new Date();
    if (today.getMonth() == 1 && today.getDay() == 1)
        System.out.println("Happy New Year!");
}

Тут баг, но куда бОльшая проблема в том, что непонятно, как проверить этот метод. Другая крайность — это написание слишком «открытых» классов. Найти баланс должен помочь предыдущий и следующий пункт.

Четвертое. Не копипастить! А стараться переиспользовать код. Идеи, как разбить его на части, черпаем в шаблонах проектирования.

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

Шестое. Не генерировать код с помощью IDE и аналогичных утилит. Безусловно, он нужен, но зачем же загромождать им исходники проекта? Скорее всего, эту генерацию можно включить в сборку. Например, для getters/setters и других фич подключаем Lombok.

В общем, стараемся писать поменьше, читать и думать побольше.

Андрей Белицкий, Software Architect, 7 лет опыта Java разработки:

Для начала хочу сказать, что позиция Senior Java developer имеет весьма условный характер, поскольку в разных компаниях и даже на разных проектах в одной компании люди на этой позиции могут иметь различный уровень квалификации, перечень обязанностей, зарплату и т. д. В данной заметке я хочу указать на общие направления развития и книги, которые помогут вырасти в профессиональном плане, а не получить тайтл «Senior». В связи с этим дальнейшие рекомендации будут носить общий характер.

Касательно знаний: существует матрица компетенций программиста, ее легко найти в интернете, например, здесь (1 часть, 2 часть). Эти таблицы помогут примерно понять, где вы находитесь и в каком направлении стоит работать. Список литературы по ссылке смотреть не стоит — он там, судя по всему, для примера.

Из литературы по Java я бы порекомендовал «Effective Java» Joshua Bloch — было много изданий, лучше брать последнее (вроде есть на русском) и «Java Concurrency in Practice» Brian Goetz — книга 2006 года, но, на мой взгляд, до сих пор наиболее актуальная книга по многопоточности в Java (насколько я знаю, не переводилась на русский). По OOP/OOD я бы рекомендовал почитать GoF (есть на русском) или Head First Design Patterns — поскольку считаю, что знание паттернов для Java-разработчика — это must have. А для общего развития — «The Pragmatic Programmer» Andy Hunt и Dave Thomas (есть на русском). В ней в формате небольших заметок и советов описаны принципы и типичные проблемы с решениями, которые в целом есть в индустрии (не смотря на то, что книга издана в 1999, большая часть все еще актуальна).

Кейсы и полезные советы, на мой взгляд, не очень работают, поскольку невозможно получить опыт, самостоятельно не набив шишек. Единственное, что могу посоветовать, — читайте хорошие книжки и работайте по максимуму, любите то, что вы делаете, и тогда все получится. Это может звучать банально, но я встречал разработчиков с тремя годами опыта, у которых было больше знаний, чем у специалистов с 10-15 годами опыта. Весь вопрос в желании и, соответственно, временных инвестициях, в том числе и вне работы. Удачи!

Евгений Хист, Java Tech Lead, 7 лет опыта Java разработки:

Сложность профессии разработчика заключается не только в том, что нужно знать множество библиотек и фреймворков, но и в том, что эти библиотеки и фреймворки постоянно меняются, устаревают и им на смену приходят новые. Это относится и к экосистеме Java. Но есть проекты, которые всерьез и надолго обосновались на рынке, ознакомиться с которыми я рекомендую каждому Java разработчику.

Одним из таких проектов является Docker, который за последние годы произвел революцию в сборке, тестировании и развертывании приложений. Docker позволяет «упаковать» приложение со всем окружением и зависимостями в контейнер. Этот контейнер может быть запущен на любой системе, поддерживающей Docker, в разы быстрее и потребляя намного меньше ресурсов чем системы виртуализации. Используя Docker, запуск контейнера с RabbitMQ или Redis для интеграционных тестов и его остановка после их выполнения становится тривиальной задачей. Начать знакомство с Docker и его экосистемой можно с бесплатных интерактивных браузерных курсов Katacoda. На этой площадке также можно найти интерактивные курсы по системе контроля версий Git, Continuous Integration и Continuous Delivery с использованием Jenkins и системой управления кластером контейнеров Kubernetes.

Spring Boot сегодня настолько популярен, что если вы до сих пор его не знаете, стоит ознакомиться. Официальная документация Spring Boot отлично подойдет для этого.

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

Начать я рекомендую с основ объектно ориентированного дизайна (OOD). В блоге Роберта Мартина есть отличные статьи о принципах дизайна классов SOLID и принципах свя́зности (cohesion) и зацепления (coupling) пакетов. Подробнее эти вопросы Роберт Мартин раскрывает в книге «Agile Principles, Patterns, and Practices in C#». Несмотря на наличие C# в названии книги, она будет полезна и Java разработчикам.

С выходом Java 8, помимо объектно-ориентированного подхода, распространение получил функциональный подход. Lambda выражения, java.util.Optional, java.util.Stream, java.util.concurrent.CompletableFuture и Flow API (java.util.concurrent.Flow) в JDK 9. Чтобы разобраться с этой темой рекомендую цикл статей «An Introduction to Functional Programming in Java 8». Также популярность набирает связанное с функциональным подходом реактивное программирование (Reactive Streams, RxJava, Reactor). Начать знакомство с этой темой можно с бесплатной мини-книги от InfoQ «The InfoQ eMag: Reactive Programming with Java».

Domain-driven design — это еще один набор принципов и подходов к проектированию ПО, который заслуживает внимания Java разработчиков. Начать знакомство с этой темой можно также с бесплатной книги от InfoQ «Domain Driven Design Quickly». Более подробнее об этой теме можно почитать в мини-книге Эрика Эванса «Domain-Driven Design: Tackling Complexity in the Heart of Software».

Говоря о проектировании ПО нельзя не упомянуть Мартина Фаулера и его книги. В блоге Мартина можно найти множество полезных статей о проектировании ПО. Также рекомендую к прочтению его книги «Patterns of Enterprise Application Architecture» и «NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence».

Много полезных статей можно найти на IBM developerWorks. К таким можно отнести довольно старую, но все еще актуальную серию статей о стратегиях работы с транзакциями. Также о транзакциях в Java можно прочитать в бесплатной книге от InfoQ «Java Transaction Design Strategies».

«The Data Model Resource Book» — это серия книг в 3 частях о проектировании ПО, которая заслуживает внимания. «The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises», «The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries», «The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling». Конечно, не обязательно один в один использовать модели данных, описанные в этих книгах. Знакомство с ними позволит лучше понять принципы проектирования модели данных, позаимствовать какие-то приемы и избежать ошибок.

Говоря о профессиональном развитии нельзя не упомянуть YouTube. Часто, пользуясь поиском, можно найти полезные видео с докладами и лекциями. Хочу порекомендовать 2 канала, на которых каждое видео заслуживает внимания: Devoxx Conferences и GOTO Conferences.

И, напоследок, лайфхак. Пользуйтесь шпаргалками DZone Refcardz, чтобы освежить в памяти библиотеки, фреймворки и подходы. Например, перед собеседованиями.

Евгений Годун, Senior Java Developer, 5 лет опыта Java разработки:

В карьере программиста я бы выделил три основных вектора развития, в сторону которых надо было начать работать еще вчера, так что после прочтения сразу приступай к делу!

Английский язык. Как и зачем?

Ну, во-первых, Java написана на английском языке. Если серьезней, то на stackoverflow, который будет вашим самым посещаемым сайтом на первых порах, гораздо больше ответов на английском. Плюс документация ко всем фреймворкам на английском. Плюс книги не так быстро переводятся, как хотелось бы. Плюс, если у вас распределенная команда, то ребята из Америки довольно редко общаются на русском (у меня есть такой знакомый американец, который заканчивает все митинги фразой «Dobriy vecher». Но это скорее исключение). Поэтому тут схалтурить не получится.

Во многих компаниях есть курсы английского для сотрудников (это хороший вопрос на собеседовании, когда hr-ы спрашивают, чего бы тебе хотелось узнать о нас). Из приложений я бы посоветовал Lingualeo, и так как самые лучшие инвестиции это в себя, я бы посоветовал купить премиум аккаунт, 22$ в год не такие большие деньги. Ну и после достижения определенного уровня — чтение книг в оригинале, а самый последний level — чтение профессиональных книг в оригинале. Дальше только Шекспир и Eminem в караоке.

Умение программировать. Как и зачем?

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

По поводу алгоритмов недавно прочитал хорошую и не сложную книгу, в которой описываются основные алгоритмы и структуры данных: Грокаем алгоритмы. Ну и в принципе есть много курсов по данной теме на udemy и coursera.

Что касается практики — я бы посоветовал HackerRank, там есть довольно интересные задачи на разные алгоритмы, и для продвинутых: где требуется только ответ, но для того, чтобы ваша программа работала меньше пары часов придется потрудиться.

Практика, практика и еще раз практика. Как и зачем?

Читать книжки, смотреть видео и понимать, что происходит — это одно, написать работающий код — совсем другое. Не бойтесь «испачкать руки» и разбираться в технологиях, которые есть на вашем проекте, или востребованы по рынку, на маленьких проектах. Не обязательно поднимать громоздкие системы или рисовать красивый UI, чтобы понять, как работает autowiring или написать Restful API для своей сущности. Так вы наступите на полезные грабли, запомните, почему вот так, а не по-другому, и станете меньше верить в магию. Также очень полезно разбираться во всем пути запроса в системе: от клика или отправки формы до базы данных и обратно, понимание — залог успеха.

Берете и пишете:) Подумайте, какое приложение было бы вам полезно, составьте себе ТЗ, и вперед к работающему коду!

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

  1. Подготовьтесь к сертификации и сдайте ее. Это заполнит все пробелы в вашем понимании Java core и даст вам ощутимое преимущество.
  2. Не стесняйтесь задавать вопросы старшим товарищам, от вас не будут требовать многого, но вы должны уличить правильный момент, чтобы спросить — не сразу, как только что-то не получается, но и не спустя несколько дней после дедлайна.
  3. Книги: Чистый код и Java. Эффективное программирование. Также много чего можно искать в серии Heads first, если хотите попроще, будь то Javascript или Паттерны проектирования.
  4. Смотрите видео с конференций или ходите на конференции. Мой совет — ходите на докладчиков, а не на темы. Среди моих фаворитов — Николай Алименков, Евгений Борисов, Джош Лонг. А по итогу можно сделать еще и доклад внутри компании, чтобы лучше разобраться в теме.

Не прекращайте учиться и будет вам счастье!

LinkedIn

77 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

чуваки ну реально кроме талка по поводу изучения английского ни слова по сути. А суть следующая — 2 курса программной инженерии и практика на реальных проектах. Чушь о алгоритме Дейкстры вообще не приемлема — если ты джун осваивай максимально то с чем работаешь и не забивай голову разной чепухой которая отнимает время и ресурсы. Если бы я учил АСМ нейронные сети и прочую чушь которую не использую в своей сфере, то закончил бы ВУЗ как и 98% моего факультета — не слышав в жизни слова «АПИ».

Той хто знає алгоритми працює в Гугл і Фейсбук, решта форми клепають і пишуть API. Трохи грубо, але правда. Є статистика. Тому ваше «чушь» говорить більше про вашу необізнаність.

Интереснейшая тенденция: с 18 годами опыта — сеньор, с 11 — уже техлид, с 7 — архитектор... Обратный прогресс какой-то.

разные профессии, не все хотят этого «прогресса»

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

Але насправді це все фігня.

Чому ніхто не пише «обирайте правильну роботу»? Звісно джуну особливо нема між чим обирати, куди взяли там і працюєш, проте вже через рік в нього є непогані шанси знайти достойний проект.

Потрібно якомога частіше міняти проекти на ще складніші і складніші. Бажано звичайно доживати до продакшену і дивитися як воно там їде, але це не завжди можливо.
Можна джуном просидіти на легасі проекті фіксити баги за індусами і нічому не навчитися а в сусідній кімнаті дівчата та хлопці за цей самий час вивчуть набагато більше розробляючи якийсь грінфілд проект. Це (складні проекти) є головним двигуном вашого прогресу.

Я за минулі півроку провів співбесіди з прорвою кандидатів на позицію Java розробника, так от з сумом змушений констатувати що більшість з них просто деградувала на тухлому аутсорсі і не годяться до нормальноі роботи. В тому числі і кандидати з 10+ років досвіду.

Власне ось поради Єгора щодо кар’єрного зростання значно доречніші: www.yegor256.com/...​/01/24/career-advice.html

Всі пишуть про те що терба читати джавадоки, книжки, вчити англійську і дивитися ютуб.
Але насправді це все фігня.

Не обязательно читать Javadoc, не обязательно читать книжки, не обязательно учить английский.
И YouTube не смотреть. Что тогда остается? Слушать подкасты?

Откуда как не из книг черпать знания? Теоретические знания важны для любой профессии. Чтение книг и документации является необходимым условием профессионального развития разработчика. В книгах, помимо теоретических основ, авторы, которые преуспели в своем деле, деляться опытом, что дает возможность не повторять распространенные ошибки или узнать методы решения часто встречающихся проблем и задач.

Важна ли практика разработки ПО для профессионального развития? Безусловно. Это очевидно. Практический опыт работы высоко ценится работодателями. Но вы не сказали, что ценится не просто 10+ лет опыта, а 10+ лет опыта в гемблинге или в финтехе. Человек, который знает, как с нуля в продакшн вывести онлайн казино стоит дорого. Но это уже другая тема.

Замените «Java разработчик» на «физик со специализацией аэродинамика» и поймете, как абсурдно звучит утверждение, что чтение книг и документации, прослушивание лекций и конференций — это все фигня.

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

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

Главное не просто читать книги, но и применять то что там пишут. Тогда есть эффект. Ведь многие думают, что вот сейчас прочту 2-3 книги и буду на уровне мидла, а это увы не так.

Важна ли практика разработки ПО для профессионального развития? Безусловно. Это очевидно. Практический опыт работы высоко ценится работодателями.

Те, кто думают, что имея только теоретические знания без реального опыта, станут мидлами, конечно, не правы. Хотя я не встречал людей, которые бы так думали, так как описание наверное всех middle Java developer вакансий содержит обязательное требование — коммерческий опыт работы X лет.

Ну що ж ви так з плеча відразу. Звісно що і книжки читати і на конференції ходити, просто їх роль значно нижча ніж хороший проект з нормальними технологіями і грамотними тіммейтами.
Нижче он дві людини все правильно зрозуміли.

Плюсую, саме так все у мене і складається: перша робота джуном — куди взяли, саме там зрозумів, що парцювати з фронт-ендом взагалі не подобається. Cам розбирався з ЕЕ стеком технологій (Spring, Hibernate, а також SQL і бібліотеки для тестування), все це пробував на тестовому домашньому проекті, проходив співбесіди, знову підтягував знання поки не потрапив на реально цікавий проект, який тільки стартував. Вже півтори роки працюю на ньому, восени планується продакшн і новий досвід :) Хоч у мене і не профільна освіта, але теперішня робота вже давно стала хоббі. Все частіше ловлю себе на думці, що віддав би перевагу варіанту «посидіти вдома покодити» перед «піти потусити» :) Потрібно ще заповнити деякі «академічні» прогалини в заннях (дякую за посилання на Матрица компетентности программиста), стараюсь, щоб постійно в in progress була окрім художньої також технічна література (взяв на замітку Грокаем алгоритмы).
В планах пройти сертифікацію.
Від себе ще б порадив тим, хто тільки знайомиться з unit tests книгу Practical Unit Testing with JUnit and Mockito

Но, как бы там ни было, айтишник, постоянно переводящий взгляд между клавиатурой и монитором, выглядит странно и вряд ли работает эффективно.

Це стьоб, чи автор серйозно?

Стёб — это не уметь печатать вслепую в 21 веке.

Так написание кода и рефакторинг за программиста делает IDE, программисту остается думать, что писать.

Да, в современных IDE есть автоподстановка.

Вопрос в том, над чем думать: где находится клавиша «C» или о своем коде?

То что программист смотрит на клавиатуру, не значит, что он не думает о своем коде, а судорожно ищет клавиши.

А если таки приходится думать, где находится клавиша «С», значит, клавиатура шибко нестандартная.

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

Во первых, «набирает текст не вслепую» != «ищет клавиши.» Внезапно.

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

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

Зачем же тогда человек смотрит на клавиатуру, когда набирает текст?

Например, клавиатура иногда съежает, она же к столу не приклеена.

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

То есть, человек держит в памяти расположение клавиатуры и рассчитывает свои движения относительно этого положения, вместо того, чтобы печатать на условных рефлексах. И это никак не влияет на производительность?

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

Отлично, эти люди ещё и защищают своё неумение.

Тут пытаются объяснить, что это умение повышает только почесать свое ЧСВ. От мышки (без тачпада) многие отказались из печатающих вслепую? Не выглядит странно когда разрабочик то и дело переносит руку с клавиатуры на мышку? И что занимает больше времени: взгляд или движение руки?

Не помню, когда последний раз использовал мышь как-раз по причине переключения внимания. Благо есть: trackpad, trackball, trackpoint...

ЧСВ

Просто нет. Это удобнее и мне смешно что кто-то пытается доказать обратное просто из-за лени и ЧСВ.
Проблема не во времени даже а в факте переключения внимания. Локус восприятия ограничен как по количеству объектов, так и по времени удержания оных во внимании, если вы не в курсе.

Я в курсе, спасибо. Никто не доказывает, что удобнее смотреть на клавиатуру и монитор набирая код. Дискуссия о том, что можно продуктивно разрабатывать софт без слепого набора, иначе все бы им пользовались. Сранно, что вы не смогли это понять.

Можно, конечно. Но совет все же стоящий, мне кажется.

Специально для этого на клавишах F и J есть бугорки.

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

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

Пальцы могут работать на полном автомате без задействования когнетивных ресурсов

этому учиться надо и оно того не стоит, машинисткой я работать не буду

со зрением так не прокатит, а значит ваш подход работает медленнее и мешает непосредственно решаемой задаче.

ну мешает примерно как моргание

А все таки, после прохождения Соло на клавиатуре я стал набирать вместо 200 знаков 600, статистика ошибок снизилась до 1%. Так что можете спорить, а можете и нет, а это как в притче о дровосеке, который деревья рубил тупым топором. Рубится, но долго. А на заточить — времени нет...

по-моему это сильно много знаков... учитывая что у меня ~80% кода генерируется, есть подозрение что 600 знаков это мне больше чем на один рабочий день хватит в любом случае, по-моему нет смысла ускорять набор в общей сложности от 3х минут до 1й

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

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

Кстати, я всегда думал, что печатаю не вслепую, пока несколько месяцев назад девушка не указала на обратное — даже не заметил, когда перестал смотреть на клаву. Подозреваю, давно).

То есть, вы сначала придумываете все имена методов класса, все имена свойств и все имена локальных переменных, а потом, удерживая это все в голове, пишете? И никогда в процессе написания ничего не меняете? И никогда мысль не «терялась» в процессе набора текста?

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

Термин «Бутылочное горлышко» вам знаком?

апокалиптические зарисовки про якобы огромные потраченные ресурсы звучат просто смешно.

Приведите мою цитату, пожалуйста, где я пишу об «апокалиптически» огромных потраченных ресурсах.

То есть, вы сначала придумываете все имена методов класса, все имена свойств и все имена локальных переменных, а потом, удерживая это все в голове, пишете? И никогда в процессе написания ничего не меняете? И никогда мысль не «терялась» в процессе набора текста?

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

видимо много у тебя лапши в одном классе получается что мысли теряются пока всем-всем штукам имена придумаешь

Тешьте ваше ЧСВ с другим человеком. Всего наилучшего.

То есть, вы сначала придумываете все имена методов класса, все имена свойств и все имена локальных переменных, а потом, удерживая это все в голове, пишете?

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

И никогда в процессе написания ничего не меняете? И никогда мысль не «терялась» в процессе набора текста?

«В процессе набора» не равно «по причине набора». Чаще всего она теряется, когда в голову пришла какая-то другая мысль: что можно сделать как-то иначе, или где-то может быть ошибка, или что-то пропустил etc. Совсем не обязательно, что эта мысль касается конкретной строки, которую я печатал. В этот момент я останавливаюсь, думаю и не печатаю вообще, потому что хоть вслепую, хоть не вслепую, тайпинг будет мешать думать. Могу поскроллить код, или даже полезть в другой класс, если они связаны — вариантов море.

Приведите мою цитату, пожалуйста, где я пишу об «апокалиптически» огромных потраченных ресурсах.

Идёт уже долгая дискуссия о производительности относительно слепой печати — очевидно, вы считаете эту прибавку довольно значимой. Если же не считаете, значит, всё-таки не настолько нужное умение?)

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

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

Прибавка значимая, но не катастрофичная. По моему субъективному опыту, набор текста — это то «бутылочное горлышко», которое можно расширить за счет слепой печати.

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

Чаще всего — что и как написал ранее. Это скорее интуитивный процесс, фокус не задействован. Он в момент печати занят той конструкцией, которая, собственно, и печатается, но, опять же, обдумываться она должна была до. Потому для процесса «потери мысли» это не критично, по-моему.

Специально слежу сегодя как часто смотрю на клаву когда набираю текст. Глаза изредка прыгают на клавиатуру даже когда на русском пишу (скорее по привычке — нет русских букав уже лет шесть). Дискомфорта не вызывает, на производительность не вилияет. Есть факторы, которые вляют на производительность много больше, как то незнание хоткеев, медленный билд, тесты и т.п. Так что взглядами на клавиатуру можно смело принебречь.

Вопрос в том, над чем думать: где находится клавиша «C» или о своем коде?

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

на производительность не вилияет

Это ваши субъективные ощущения. Откуда вы знаете, что, используя слепой набор текста, вы не будете работать эффективнее?

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

Да, а недостаточный сон или голод влияют еще больше. Но это же не снимает важность знания хоткеев?

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

Поинтересуйтесь когнитивистикой, вхождением в поток и т.п. Такой мелочи как «убедиться, что палец попадает в клавишу» вполне достаточно, чтобы отвлечься и выйти из потока.

«убиться, что палец попадает в клавишу» вполне достаточно, чтобы отвлечься и выйти из потока.

А посмотреть на второй экран и убедиться, что тест проходит? А заглянуть в доку или загуглить впрос? Или Вы в протоке в одну точку на 13’’ мониторе смотрите? Но даже и в таком случа клавиатура тоже перед глазами :). А перевод руки с клавиатуры на мышку не замедляет производительность? Или труъ девелоперы мышками не пользуются?

Ну, и, да, Вы девелоперов с техрайтерами не путаете?

А посмотреть на второй экран и убедиться, что тест проходит? А заглянуть в доку или загуглить впрос?

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

Или Вы в протоке в одну точку на 13’’ мониторе смотрите?

Я смотрю на код и думаю о коде.

А перевод руки с клавиатуры на мышку не замедляет производительность?

На мышку вы постоянно глаза переводите?

На мышку вы постоянно глаза переводите?

Нет, но как это относится к производительности горячих клавишь vs. мыши?

Я смотрю на код и думаю о коде.

Доу от кода не отвлекает? Из потока не выводит?

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

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

Доу от кода не отвлекает? Из потока не выводит?

О, переход на личности. Хорошего вечера :)

www.youtube.com/watch?v=lvs7VEsQzKY интересное видео о том, как парить
спаривать паровать организовывать работу в парах начинающих и продвинутых разработчиков.

На жаль , більшість рекомендація на тему «Як симулювати сіньйор розробника?» Але тут все просто — протримайтесь у ІТ 3-5 років і будь-яка аутсорсінгова компанії одарить вас лейблом «сіньйора»

Якщо ж говорити про вміння, то по суті є 3 основні рекомендації:
— хороший відпочинок і відновлення
— багато програмувати
— систематизувати знання поглядаючи у літературу

включайте новости BBC

ІМХО, не уверен хорошая ли это идея. Все-же английский английский, в придачу с лондонским акцентом может вызвать недоумения у человека который только изучает язык :)

У меня как-то были заказчики из Ирландии. Было много недоумения, недоразумения и прочего конфуза. Именно тогда пришлось ломать свой разговорный барьер.
Как я это делал? В скайпе был режим «Chat», для людей, желающих просто почирикать. Я специально искал таких индивидуумов, ограничивая поиск только тех, кто проживает в Ирландии. У ребят нереально специфичный акцент! Звонил им, задавал вопрос, написанный предварительно на бумажке. Пытался понять, что они там бормотали, ничего не получалось, клал трубку. В оффлайне прослушивал снова их речь (обязательно все записывал, как бы ни печально потом было прослушивать свою корявую речь), адаптировался к их акценту и звонил следующей жертве из списка. Спустя два-три дня я уже мог продвинуться дальше, ко второму вопросу. А потом — поехало, как по маслу, до сих пор поддерживаю связи с людьми, которыми тогда познакомился и узнал про культуру страны массу интересных деталей!

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

Лондонский акцент не должен вызывать никакого недоумения.

Работаю с товарищем из Лондона — прислушиваться ой как приходится — очень много незнакомых интонаций и выражений. При том, что с датчанами, финами и швейцарцами трудностей никаких.

Забыли упомянуть важные скиллы — уметь играть в настольный теннис и разбираться в сортах сыра

статистические анализаторы кода

ой

Все супер. Залишилось знайти тільки роботу...

Отличная статья и советы, спасибо!

пробачте, але слово «сеньор» в мене асоціюється:
Значение
1. истор. землевладелец, обладавший властью государя на своей территории
(в странах Западной Европы в эпоху Средневековья)
2. употребляется как обращение или форма вежливого упоминания
по отношению к мужчине в Испании и испаноязычных странах ;

©ru.wiktionary.org/wiki/сеньор

це дужа важлива інформація!

а може краще б запитали у гугла спочатку — senior developer?
;)

Какая прелесть! И такая сюда зашла.
Статья слабовата. Никто из уважаемых синьеров не дал каких-то дельных советов. Хотя-бы на своих примерах.
Как вариант: «Вот был я ментором у такого-то джуна. И у меня ничего не вышло его прокачать потому, что .....». Или «Вот был я ментором у такого-то джуна. И теперь он уже мидл .....»
А так пустой набор стандартных советов.
Как говорил Михаил Жванецкий «Тщательнеееее надо»

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

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

Ну ваше мнение о здоровье тут не в тему.

а это очень глупо и опрометчиво — в работе программистом это капец как важно

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

Добавляйтесь в скайп, спишемся!

теж було б цікаво/корисно почитати, поділіться, будь ласка, і зі мною недемоверсією тексту

Краще окремою статтею тут, ну або дуже великим коментарем під цією темою)

Если там было восемь страниц — создавайте топик «Восемь страниц советов от бывалого джависта». Про пять книг от мистера Х топики создают же и нормально. Тут должно быть интереснее.

кинул заявку

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

Фиксить баги — это дурной совет. Многие баги нетривиальные, раз прожили достаточно долго, что бы превратится в отдельную задачу. Часто вместо нахождения источника беды, будет сделан кривой костыль. Джуниорам нужно просто учиться, и не говнохибернайтам и прочим реактам, а базовым вещам.

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

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

Несколько сложно дать дельные советы в статье, рассчитаной на общую аудиторию. Я могу сказать на своём примере «Вот я был ментором у таких-то товарищей. И теперь они мидлы/синьоры». И объяснить как это произошло — пару лет ревьюил их код. Только вряд ли этот комментарий чем-то тщательнее статьи.

И испанский тоже круто было бы выучить. Все таки один из самый востребованных наряду с китайским и английским ;)

Подписаться на комментарии