Comments 9
Находите смелость обращаться за помощью в любой момент, когда не получается найти решение. Вы — часть очень открытого сообщества, в котором четкий, детализированный вопрос, как правило, поможет найти правильный ответ.Вот только не надо этими вопросами докучать тиммейтам, если сами перед этим не пытались решить проблему. Я уверен, многие согласятся, что не стоит отвлекать человека за, хм, творческим процессом. Это относится не только к программистам. Попробуйте решить проблему самостоятельно, а уж если не получится, то обращайтесь за помощью к команде.
Я уже встречал людей, который при возникновении проблем сразу задают вопросы, отвлекают тиммейтов от текущих задач и т.п. Не надо так.
Без плана даже самый маленький проект может превратиться в неуправляемого монстра. Перед тем, как перейти к разработке в зомби-режиме, вам нужно подумать о возможных затратах, планировании спринтов, вопросах архитектуры и проектировании таких элементов как перемещение пользователя по элементам интерфейса.
Легко потерять цель, ради которой разрабатывается приложение, когда вы весь день пялитесь на куски кода.
Реальность такова, что задумываться о цели ты начинаешь только в своих проектах или же проектах, которые тебе интересны. Но правда в том, что, как правило, этот момент настанет только через пару лет (в лучшем случае), когда вы наберётесь опыта и т.п. А до тех пор вы, вероятно, будете работать на проектах, где вам нет дела до цели.
Можете кидаться тапками, но на прошлых местах работы все эти «цели», «планирование» и т.п. я оставлял на других, хотя проекты были вполне интересны (местами), так как единственной целью было набраться опыта, чтоб заниматься уже собственными интересными проектами. Теперь, я занимаюсь только свои проектами и думаю о цели, планировании, команде и т.п., так как я часть проекта и заинтересован в его успехе.
Делиться возникшими проблемами с другими ребятами в команде.
Да — вся эта коммуникация идёт в лес, когда сверхкоммуникативный разработчик каждый поднимает вопрос, который легко гуглится. Надо развивать техническую экспертизу, а не софтскилл «взять и спросить». А то хочется подчас взять черенок от лопаты и…
Негодование не касается концептуальных, в том числе организационных и архитектурных вопросов, но я верю, что разработчики уровнем повыше — не целевая аудитория сей статьи.
В принципе это статья не только для программиста, просто её писал програмист. Если подставить другую профессию, то тоже хорошо пойдётю
Коммуникабельность важна, поскольку бывает полно ситуаций, когда разработчики друг друга не слышат. Например, пытаются доказать свою правоту до конца, вместо того чтобы сосредоточиться на решении задачи. Или ситуации, когда боятся сказать реальные оценки сроков задач, или вовремя сообщить о какой-то проблеме команде/менеджеру (проект не нравится, стул не удобный, коллеги достали и т.п.). Но, если ты интроверт, это не значит что с коммуникацией проблемы. Можно общаться мало, но уметь это делать так, чтобы команда тебя понимала и получать желаемый результат.
Насчет предпринимательского мышления — скорее разработчик с таким мышлением начнет оценивать бизнес-процессы изнутри: сколько стоит написать аналогичный проект, какие роли и кто за что отвечает, кому поручить задачи за меньшие деньги (актуально для фрилансеров) и скорее всего так или иначе будет прокачиваться в сторону бизнеса, чем в сторону специалиста. Для одних компаний это хорошо, можно его назначить на управляющую должность или сделать партнером, для других не очень, так как боятся потерять хорошего специалиста.
Насчет предпринимательского мышления — скорее разработчик с таким мышлением начнет оценивать бизнес-процессы изнутри: сколько стоит написать аналогичный проект, какие роли и кто за что отвечает, кому поручить задачи за меньшие деньги (актуально для фрилансеров) и скорее всего так или иначе будет прокачиваться в сторону бизнеса, чем в сторону специалиста. Для одних компаний это хорошо, можно его назначить на управляющую должность или сделать партнером, для других не очень, так как боятся потерять хорошего специалиста.
На эту тему есть очень хорошая книга: Путь программиста, автор Джон Сонмез.
Сделайте шаг назад и подумайте о целях, лежащих в основе бизнеса. Вы можете далеко пойти, если не ограничите себя дедлайнами и будете думать не только о коде, но также будете предлагать свои решения.
Проблема в том, что работая на проекте не всегда понимаешь за что заказчик платит деньги, особенно если проект уже в продакшене не один релиз. Отсюда потеря мотивации и отсутствие предпринимательского мышления.
Единственное то что меня напрягает в моей работе так это как раз — общение. Говорить с коллегами и тем более с начальством составляет большой труд. Так или иначе я хороший разработчик и берут меня на работу без проблем, платят достойно и хорошо относиться. Как можно уже догадаться большую часть времени вообще почти не разговариваю ни с кем и считаю что описанные в посте рекомендации не предоставляют весомой пользы если ты знаешь своё дело хорошо
Личностные.
Sign up to leave a comment.
Какие личностные качества нужны разработчику?