В каждой приличной IT-компании уделяется достаточно много внимания развитию сотрудников. Проводятся разного рода митапы, тренинги и хакатоны для прокачки хард-скиллов, встречи на тему развития софт-скиллов (на которых сотрудникам объясняют почему панибратство и общение строго матерными выражениями - очень плохая идея), и прочие увеселительные мероприятия. Но мое внимание обратила на себя тема, которая находится на стыке этих двух навыков - хард и софт. С некоторой регулярностью мне приходится видеть перспективных ребят, которые явно засиделись в джунах. Это удручает и разочаровывает - ведь я знаком со многими из них, и отлично знаю, что у них есть все необходимое для быстрого роста. И часто причина не в чем-то одном, а в сочетании некоторых, возможно неочевидных, недостатков. Я постарался собрать здесь весь список подобных минусов, которые приходится наблюдать довольно регулярно.
Итак, что обычно мешает условному джуну подтянуться до условного мидла:
Нет обработки ошибок
Классика - не изучаешь тему обработки ошибок в целом и способ это делать в данном конкретном проекте. Автоматически записан в джуны.
Касаемо конкретно языка
Dart- абьюзbang-оператора. Этот оператор доступен к использованию только когдаnullне прилетит гарантированно. Другой случай непроверки наnull- выдавать сообщение об ошибке вtoString(). Прилетитnull- покажешь пользователю сообщение “null”. За такое желательно сразу расстреливать, но, так как в большинстве стран мира смертная казнь не применяется, приходится ограничиваться подобной статьей.Вообще, во внимании джуна код всегда имеет более высокий приоритет, чем то, что видит пользователь. У мидла наоборот - приоритет у UI. Потому что заказчик видит только UI и оценивает приложение в первую очередь по пользовательскому опыту.
Пассивное отношение к взаимодействию с бэком
Прилетает ошибка с кодом 200 - не просишь поправить. Как маленький, ей-Богу. Поле с сообщением об ошибке возвращается в рандомных объектах с рандомным названием этого поля - пилишь у себя поиск таких сообщений во всех возможных случаях, вместо того чтобы призвать бэк к порядку. В следующий раз сообщение прилетает в очередном неожиданном месте - снова ломается. Я утрирую, но мысль понятна. Прилетают одни и те же данные разрозненном виде - не просишь бэк привести их одному и тому же виду. Например, принимать и возвращать один тот же объект. В будущем это приводит к проблемам, которые нарастают, как снежный ком.
Отсутствие тестирования собственного кода
Вместо проверки работоспособности кода в разных условиях, ты приносишь жертвы темным силам в надежде, что всё работает как надо. Или того хуже - не думаешь о том, что нужно тестировать что ты там понаписал. Не перекладывай свою работу на тестировщика - его задача искать крайние кейсы и замечать то, что пропустил ты. Он работает вместе с тобой, а не вместо тебя.
Злоупотребление Google
Гуглишь и вставляешь найденный код, иногда не разбираясь, как он работает. Так называемый «Google-программист» на парт-тайме. Ты не учишься.
Недостаточная вера в себя
Когда сталкиваешься с более или менее сложной задачей, сразу сдаешься с формулировкой «есть люди поопытнее, надо спросить». По моим наблюдениям, больше половины вопросов джунов связаны с простой логикой, и не требуют никакого опыта. То есть он бы и сам справился, если бы верил в себя. Подход должен быть - «если не я, то кто?». Разбираешься с задачей самостоятельно, пока не заходишь в полный тупик. Тогда идешь спрашивать у опытных коллег, да и то только чтобы время сэкономить. "Разобрался бы и сам, да только времезатраты не адекватны задаче".
Пассивное отношение к макету
В макете указано поле ввода, хотя очевидно, что должен быть выпадающий список - ты не обращаешь на это внимание дизайнера и/или ПМа. «Там уже все решили». Этот пункт перекликается с предыдущим.У программиста всего два инструмента для решения задачи - логика и опыт
и Google. Отсутствие опыта — это не повод выбрасывать в окно еще и здравый смысл. В макете не указана кнопка повтора последнего действия при ошибке (там, где это уместно) - ты молча выводишь только сообщение об ошибке. Если не забудешь. В дизайне не указан способ обновления данных на экране - ты так и делаешь, хотя очевидно что тут нужно обновление свайпом, к примеру. И такая задача неизбежно прилетает из QA, либо от заказчика. Ты мог сделать сразу логично - но дождался пока укажут пальцем. В дизайне не указана индикация загрузки при пагинации - ты так и делаешь. А ведь достаточно посмотреть взглядом пользователя — прокрутил список до конца, ничего не происходит. Потом внезапно в конце появляются новые элементы. Отсюда вытекает следующий пункт.Удивляешь пользователя
Удивлять нужно девушку на 8 марта. А приложение должно обладать предсказуемым поведением, настолько, насколько это возможно. Это касается всего приложения в целом и отдельных элементов в частности. Никто не будет вести тебя за ручку и указывать на каждую мелочь. Это будет делать заказчик. После чего тебя отшлепают. Из чего станет очевидно, что на тебя нельзя положиться.
Общий настрой - «моя хата с краю»
Текущая задача тебя интересует только с точки зрения взаимодействия с ПМом и/или тимлидом, в отрыве от всего проекта - формально сделал, остальное меня не касается. Отсюда вытекают такие странности, как например отображение информации для пользователя с помощью всплывающего сообщения снизу на одном экране, и сверху - на другом. Ты не смотрел как там у других. “Зачем, мне и так хорошо, а то того и гляди придется поучиться чему то новому”. Ты должен смотреть на задачу как часть проекта в целом. Насколько твоя работа соответствует логике всего приложения?
Отношение к любой текущей задаче, как к копанию огорода
Просто объем земли, который нужно перелопатить. Копаешь от забора и до обеда. Любая задача это мини-проект, у которого есть начало и конец. К реализации нужно подходить творчески - сначала обдумать, как это сделать эффективнее, чем делалось раньше. Как сократить себе время на похожую задачу в будущем. Как это уже сделано твоим коллегой и почему именно так. Не бояться экспериментировать. Каждая задача - это материал для прокачки своих скиллов.
Отсутствие стремления писать читаемый код
Читаемый всеми, а не только тобой. Привык вариться в своем соку - у тебя свои приколы и привычки в коде, понятные только себе. Также ты не смотришь как написаны другие модули приложения, а пилишь очередную вариацию.
Пассивная позиция в компании
Ты не активный член коллектива, стремишься не высовываться, чтобы не дали каких нибудь задач. Никогда не вызываешься добровольцем. Если нет текущих задач, то молча занимаешься своими делами. Ведь молоток всегда бьет по тому гвоздю, что торчит выше других.
Гиперактивная позиция в компании
Противоположная крайность - ты неугомонный член коллектива, берешься за тучу задач в куче проектов. Отсюда вечная спешка. Нет времени вникать, разбираться, исправлять. Гонишься за объемом в ущерб качеству.
Не придаешь значения «мелочам»
У тебя вечно куча опечаток. Куча подсказок от анализатора, которые ты игнорируешь. Ну не ошибки же. А предупреждения - это для слабых духом. Твоя консоль замусорена бесполезными сообщениями на всякий случай.
Не делишься опытом с другими
Избегаешь роли лидера - например, работы со стажерами, где нужно подсказывать менее опытным коллегам. Мидл часто является тимлидом, навык лидерства жизненно необходим. Это не значит, что ты, будучи интровертом, должен выступать перед стадионом и рвать рубаху на груди. Достаточно базовых навыков распределения задач и работы с людьми.
Ты не понимаешь, что твоя работа - не только писать код
Твоя работа - учиться. Учиться каждый день и при любой возможности. Это твой стандартный подход к решению задач. Отныне и до самой пенсии.
Надеюсь, эта информация поможет вам быстрее продвигаться на пути разработчика. Happy coding.
