Ещё немного советов для джунов

Антон Правдин

TeamLead в Simtech Development

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

Я тоже прошел этот путь и хотел бы дать пару советов, которые я не всегда вижу в подобных статьях. Поехали!

Предсказуемость или скилл?

Это может быть неочевидно для новичка, но для бизнеса зачастую важнее ваша предсказуемость, нежели глубина ваших знаний. Это, конечно, хорошо, что вы имеете большой кругозор или можете взять и за ночь «сбацать» крутое API. Но если ваша производительность скачет из крайности в крайность — руководитель не знает, чего от вас ожидать. Компании нужно планировать как время, так и бюджет. И разработчик, то бегущий впереди паровоза, то срывающий очередной дедлайн, будет вносить, скажем так, некую неопределенность в эти планы. А это может повлечь потерю денег и времени. Короче говоря, это внесет дополнительный риск, а бизнес риски обычно считает. Выводы делайте сами.

Предупреди ближнего своего

Самое главное, что определяет предсказуемость —  ваша способность общаться с другими разработчиками и руководством. Коммуникативный навык традиционно считается «soft skills» разработчика. Но я думаю, сегодня уже многие согласятся отнести этот навык к «hard skills», особенно если компания (или команда) превышает пять человек

Без коммуникаций вы непредсказуемы. У ВСЕХ бывают ошибки и ВСЕ порой застревают на какой-то проблеме. Вопрос в том, как вы на это реагируете?

Один из плохих кейсов: вы не можете справиться с задачей и не говорите об этом. И выясниться это может уже перед дедлайном, когда нет времени, чтобы кто-то из ваших старших коллег успел подхватить задачу и сделать ее за вас.

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

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

Сначала пробуй сам, потом попроси другого

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

Один из методов — нужно ограничить время. Всегда, когда позволяет время, сначала попробуйте разобраться в проблеме самостоятельно. Но не сидите над этим весь день, установите лимит, например, в 30 минут. Если в течение получаса у вас не получилось продвинуться в решении, спросите совет у коллеги. Так вы не будете засиживаться над задачей, сопровождая это теми же срывами сроков, и проявите уважение ко времени своих коллег, не отвлекая их слишком часто.

Ну почему не работает?

Передо мной ошибка.Что мне с ней делать эти 30 минут?

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

И здесь как раз кстати «ленивый» способ поиска информации. Если у вас есть код или текст ошибки (в терминале, в логах, прямо перед вами на главной странице вашего проекта или где-то еще), попробуйте просто скопировать этот код/текст в поисковик. Вероятно, на вас тут же вывалится куча обсуждений и решений конкретно этой ошибки.

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

Этот разнообразный мир информации

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

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

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

Отдыхать не надо перегорать

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

Стоит отметить, что программирование — это деятельность, которой очень легко увлечься. Особенно в начале пути, все кажется настолько интересным, что ты можешь сидеть перед монитором с утра до ночи. У меня так и было: днем ты кодишь на работе, вечером дома и на выходных еще «чуть-чуть» (не чуть-чуть).

Может быть, каждый должен через это пройти, чтобы понять, что ничем хорошим это не кончится. Конечно, бывают «забеги», когда нужно сделать что-то грандиозное и в короткие сроки, показав весь свой героизм, но это носит разовый характер. Работая так на постоянной основе, рискуешь через пару лет потерять всякий интерес к программированию. Не потому что это не интересно, потому что настолько приелось, что уже ничего не надо.

Поэтому отдых не менее важен, чем сама работа, тем более на дистанции длинною в жизнь.

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

Уставший сотрудник совершает больше ошибок, его продуктивность обретает переменчивый характер — это может привести ко многим проблемам. Не надо так.

На этом все. Закончу выводом из одной из моих любимых книг:

Мы во всем не правы. При росте мы переходим от неправильного к несколько менее неправильному. И каждый раз наши взгляды становятся менее неправильными.

Поэтому не нужно переживать на этот счет — удачи!