Не работает разработчик работает

12 факторов, которые мешают работать программистам

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

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

Если же кто-то сомневается, стоит ли тратить на это деньги и силы, достаточно вспомнить, сколько программистам платят. Даже прирост производительности в 10% — это немало в денежном эквиваленте!

1) Совещания и прочие отвлекающие факторы

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

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

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

Как говорил Пол Грэхэм: «Одно совещание может убить полдня: время разбивается на два периода, за которые ничего серьезного сделать не успеешь».

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

2) Придирки к мелочам

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

3) Неясность

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

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

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

4) Менеджеры-чайки

Слышали когда-нибудь о таком? Бывают менеджеры, которые вообще не участвуют в рабочем процессе… за исключением тех моментов, когда вдруг решают спикировать на кого-нибудь и все обгадить. «Это никуда не годится, и это тоже, а это совсем не смотрится,» — и полетели дальше. Должен признать, сравнение мне нравится, но вот стоящее за ним явление встречается куда чаще, чем хотелось бы. Такое поведение сказывается на разработчиках очень плохо: многим приходится после этого часами вырабатывать рабочий настрой, а кто-то выпадает из потока на целые дни.

5) Кража лавров

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

6) Обстановка: шум, движение, дизайн рабочего пространства…

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

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

7) Смещение границ проекта

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

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

Возьмем для примера простую функцию:

• Первая версия (до реализации): функция определена как «Отображать карту локации»
• Вторая версия (когда первая итерация уже почти закончена): описание меняется на «Отображать 3D карту локации»
• Третья версия (когда вторая итерация уже почти закончена): описание меняется на «Отображать 3D карту локации, по которой пользователь мог бы передвигаться»

8) Процесс определения возможностей продукта

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

9) Игнорирование технического долга

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

10) Разнообразие инструментов и аппаратуры

Разработчики ежедневно используют множество инструментов для написания, пуша и слияния кода. Чем сильнее им удается автоматизировать процессы, тем лучше. Само собой разумеется, что древние инструменты будут оказывать прямое влияние на уровень производительности. Также многое решает и то, на чем ведется работа — на одном ноутбуке или еще и на дополнительном экране. Если сопоставить цены на железо с зарплатами программистов, то даже 5% роста продуктивности определенно окупит все затраты! Нужно просто предоставить команде ту аппаратуру и инструменты, которыми они предпочитают пользоваться (для аппаратуры решение должно быть индивидуальным, для инструментов — коллективным).

11) Документация в стиле «как»

В процессе обучения программированию мы все усвоили, что комментарии к коду нужно начинать добавлять как можно раньше и как можно чаще. Идея состояла в том, что лучше пусть комментариев будет слишком много, чем недостаточно. К сожалению, многие поняли это превратно и решили, что в пояснениях нуждается каждая строка. Потому-то мы имеем образчики вроде вот такого вот, из статьи Джеффа Этвуда «Код без комментариев»:

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) < r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
>

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

12) Крайне сжатые сроки

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

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

Но разве это только про разработчиков?

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

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

Источник

10 признаков того, что хороший программист из вас не получится

Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Signs You Will Suck at Programming» автора Jonathan Bluks.

Очень часто на Reddit или Quora я вижу вопросы вида «Как понять, смогу ли я стать успешным программистом?» (На самом деле, эта статья является расширенным продолжением моего недавнего ответа на Quora.) Когда кто-то задумывается о смене карьеры или интересуется разработкой и хочет знать, что для этого требуется, неизбежно возникает этот самый вопрос.

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

Будучи преподавателем на курсе «Full-stack Web-development», я работал со многими программистами-новичками. Хорошая новость в том, что мне редко встречались студенты, которые вообще не могли научиться программировать. Я считаю, что умение программировать — такой же базовый навык, как умение читать, писать и считать. Это под силу любому, так как это одна из способностей человека, но этому действительно надо учиться.

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

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

1 | Вам не хватает любознательности

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

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

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

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

2 | Вам не хватает самостоятельности и находчивости

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

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

В мире разработки всю нужную вам информацию можно найти в волшебном месте, ранее известном как Information Super Highway. У этой гигантской библиотеки есть одна большая дверь — Google. Понять, что вы можете просто вбить в поиск все, что вам захочется, и получить доступ необходимой информации — это первый барьер на вашем пути к приобретению навыков, которые потребуются вам в мире IT.

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

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

3 | Вам не хватает упорства перед лицом проблемы

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

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

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

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

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

4 | Вы не ощущаете радости от успеха в решении проблем

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

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

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

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

5 | Вам не хватает терпения в учебе

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

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

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

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

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

6 | Вы чувствуете скуку или усталость от долгих размышлений

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

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

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

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

7 | Вы не способны думать самостоятельно

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

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

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

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

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

8 | Ваше мышление негибкое, узкое и/или неорганизованное

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

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

Вторая крайность, с которой я сталкиваюсь, — неорганизованность в мыслях. Студенты сами создают себе сложности все без всякой необходимости, их код беспорядочный, в нем сложно разобраться. Они усложняют задачи и пишут по 100 строк кода там, где хватило бы 10.

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

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

Самокритика: Всегда следует сделать шаг назад, чтобы увидеть целиком всю картину того, как вы подходите к задачам. Как можно сделать это лучше? Есть ли что-то, что могло бы облегчить вашу жизнь? Чего вам не хватает и что могло бы вам помочь?

9 | Вы хотите знать один «правильный» ответ вместо признания спектра «хороших» и «плохих» ответов.

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

В начале изучения навыкам программирования студенты часто хотят знать, является ли то, что они сделали, «правильным». Ответ на этот вопрос всегда — «зависит от обстоятельств».

Computer Science — это наука оценивания компромиссов. Получив различные комбинации обстоятельств, найдете ли вы лучшее решение? Все зависит от обстоятельств и целей. Когда вы воспринимаете программирование как тест с верными и неверными ответами, вы теряете возможность видеть всю картину и отказываетесь от творческого подхода. Любое решение может быть «верным», если оно оправдано в данных обстоятельствах.

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

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

10 | Вы не уделяете достаточно внимания деталям

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

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

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

Как говорится, дьявол кроется в деталях. И в программировании это действительно так.

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

Бонус: Вы сосредоточены на бизнесе

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

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

Я также встречал студентов, которые желали начать работать сильнее, чем другие, и испытывали значительные сложности в обучении. Они часто торопились найти заказчиков, подписывались на работу, которую даже не в состоянии были выполнить самостоятельно! Они хватались за все найденные ресурсы/шаблоны чтобы только проект начал работать, или же отдавали часть работы на аутсорс кому-то еще. У них реально плохо получалось программировать, но потрясающе получалось убеждать людей платить им за это!

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

Заключение

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

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

Дисклеймер: все сказанное выше — мое собственное мнение, основанное на профессиональном опыте преподавания веб-разработки. Оно может отличаться от мнения BrainStation.

Источник