Почему программирование — это так сложно?

Некоторые тонкости работы в IT-индустрии можно понять только на собственном опыте. Разработчик программного обеспечения Тим Бейкер поделился несколькими советами, которые могут помочь начинающим программистам освоиться в профессии. Мы перевели их для вас.

Для программистов важны навыки работы с людьми

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

Всё это довольно неплохо описывает большинство программистов. И до поры описывало меня. Если это про вас, то придётся довольно долго приспосабливаться к работе в индустрии.

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

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

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

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

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

Экспертиза без полномочий

Зачастую ваши идеи будут расходиться с идеями тех кто принимает окончательные решения. Придётся смириться с этим и научиться работать над утомительными проектами и принимать все «шишки», как взрослый человек. Фред Брукс в книге «Мифический человеко-месяц» назвал это «экспертизой без полномочий».

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

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

Обязательное условие — любовь к экспериментам

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

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

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

Компиляция требует абсолютного совершенства

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

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

Идеи просты, но компьютерные программы — сложные

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

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

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

Не каждая ошибка является ошибкой

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

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

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

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

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

Подводя итог: красный, волнистый и раздражающий автоматически не переводится в «‎важный».

Отсутствие ошибок — это НЕ отсутствие багов

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

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

Существует два основных типа ошибок: ошибки компиляции (красные, волнистые) и ошибки времени выполнения или логические ошибки. О последнем мы сейчас и говорим.

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

Идеальный пример — деление на ноль. Это математическое выражение не определено, и проблема не очевидна, если просто делить Х на Y. Обе переменные могут быть какими угодно, и значение Y имеет только тогда, когда программа запущена.

Решайте первопроблемы

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

Чтобы стать лучшим программистом, нужно уметь быстро определять первопричину и исправлять именно её. Это я называю «решением первопроблем».

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

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

Таким образом, запомните эти простые правила устранения неполадок и отладки:

1. Всегда тестируйте код;
2. Проверяйте и перепроверяйте всё, особенно то, что считаете неважным;
3. Старайтесь не делать слишком резких изменений, чтобы исправить ошибки — это может создать больше проблем;
4. Перепроверьте всё ещё раз.

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

Фундаментальная проблема разработки программного обеспечения

Неважно, насколько хороша ваша программа, кто-нибудь обязательно найдёт способ использовать её не так, как задумывалось. И будет полностью уверен в том, что делал всё верно. Не верите? Разработайте любое ПО, выложите и затем почитайте комментарии и письма, которые вскоре получите.

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

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

Технология — это непредсказуемая, движущаяся цель

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

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

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

Оценка сроков — это сложно

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

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

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

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

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

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