Categories: Разработка

experience-part-1/

Будучи молодым и наивным, я хотел перепробовать на практике все новомодные NoSQL-решения, знать все необычные языки программирования и писать код, покрытый тестами не менее, чем на 98%. Я считал, что при желании смогу одинаково хорошо разбираться как в веб-разработке, так и в написании драйверов для FreeBSD. Теперь, состарившись и помудрев, я начинаю осознавать всю глубину этих, а также других заблуждений. В данной серии заметок я хочу перечислить совершенно очевидные вещи, понимание которых, тем не менее, почему-то приходит только со временем.

Программирование — это не только написание кода

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

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

Клиент не знает, чего он хочет, и это нормально

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

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

Программисты не знают всего, и это нормально

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

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

Однако всему нужно знать меру. Если в каком-то вопросе можно разобраться без помощи коллег, например, путем поиска в Google или чтения документации, попробуйте сначала этот вариант. Не напрягайте коллег понапрасну, в конце концов у них и без вас забот хватает. Соответственно, вы также должны быть готовы предоставить помощь тому, кто в ней нуждается. Даже если вопрос кажется вам глупым и/или вы сильно загружены, никогда не посылайте человека дефолтным маршрутом, даже не попытавшись разобраться в его проблеме.

Это все личное

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

Запомните — это все личное ! Любые ваши неуместные шутки, любая критика, любой слегка повышенный тон или косой взгляд, частые болезни, поздний приход на работу или ранний уход, а также многие другие вещи — все это замечают и запоминают окружающие вас люди. Любые ваши слова вырываются из контекста, коверкаются и затем понимаются неправильно. Так уж работает человеческое восприятие. Классический пример: слова «деньги» или «зарплата», сказанные в присутствии вашего босса, всегда интерпретируются как недовольство вашей текущей зарплатой . И не забудьте добавить сюда эффект сломанного телефона. Все это незаметно копиться, как снежный ком, и совершенно неожиданно выливается на вас через годик-другой.

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

Это все бизнес

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

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

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

Продолжение следует

admin

Share
Published by
admin

Recent Posts

Консоль удаленного рабочего стола(rdp console)

Клиент удаленного рабочего стола (rdp) предоставляет нам возможность войти на сервер терминалов через консоль. Что…

1 месяц ago

Настройка сети в VMware Workstation

В VMware Workstation есть несколько способов настройки сети гостевой машины: 1) Bridged networking 2) Network…

1 месяц ago

Логи брандмауэра Windows

Встроенный брандмауэр Windows может не только остановить нежелательный трафик на вашем пороге, но и может…

1 месяц ago

Правильный способ отключения IPv6

Вопреки распространенному мнению, отключить IPv6 в Windows Vista и Server 2008 это не просто снять…

1 месяц ago

Ключи реестра Windows, отвечающие за параметры экранной заставки

Параметры экранной заставки для текущего пользователя можно править из системного реестра, для чего: Запустите редактор…

1 месяц ago

Как управлять журналами событий из командной строки

В этой статье расскажу про возможность просмотра журналов событий из командной строки. Эти возможности можно…

1 месяц ago