От джуна до сеньора: Как стать востребованным разработчиком - Владимир Швец
Шрифт:
Интервал:
Закладка:
Тезисы
■ Мало обсуждений – плохо.
■ Много обсуждений – тоже плохо.
Задание
Если в компании проводятся регулярные митинги, попробуйте ответить честно: насколько полезны они для вас как для разработчика? Если вы чувствуете, что они полезны и вы получаете больше опыта, – прекрасно, я могу за вас только порадоваться. Если же вам кажется, что на этих обсуждениях вы лишь теряете время, поинтересуйтесь у руководства, нельзя ли реже принимать в них участие.
История из жизни
Я настолько не любил пустые ежедневные обсуждения, что это стало для меня одной из мотиваций, чтобы развиваться как разработчик. Я хотел получить возможность сказать «нет, мне некогда», однако это сыграло со мной злую шутку. Поднимаясь вверх по карьерной лестнице, ты становишься тем самым человеком, который и инициирует подобные обсуждения, и обязан на них присутствовать. Любви к пустым обсуждениям у меня, разумеется, не появилось, поэтому я стараюсь не отвлекать разработчиков, если только для этого нет по-настоящему веских причин.
Бюрократия
Как бы печально это ни звучало, но бюрократия на сегодняшний день – неотъемлемая часть мира IT. Она проникает в нашу индустрию потому, что руководству компаний нужна четкая структура и понимание продукта (с какой скоростью и с какими перспективами идет его разработка). Это благое желание, которое часто выливается в замедление или усложнение разработки.
Возможно, я начал на печальной ноте и конкретно в вашей компании бюрократия не имеет такого размаха. Однако велика вероятность, что вы попадете в компанию, где любое взаимодействие между отделами или новая идея проходят слишком много согласований, так что под конец вы уже толком не помните, с чего, собственно, начинали.
Нельзя сказать, что бюрократия совсем бесполезна. Нередко случается, что спонтанная идея после долгого обсуждения и хождения между отделами действительно оказывается никчемной. Но бывает и так, что хорошая идея для продукта получила одобрение слишком поздно и компания уже не успевает за конкурентами, упустив время.
Вы, как разработчик, вряд ли будете напрямую влиять на рабочие процессы в компании (и скажите за это спасибо, вы НЕ хотите лезть в эту банку со змеями).
В первую очередь не следует принимать происходящее близко к сердцу. Да, возможно, именно вашу идею задвинули в угол или сочли неудачной. Да, случается, что из-за медленного взаимодействия с дизайнерами вы уже две недели не можете получить макет главной страницы приложения. Воспринимайте такие ситуации нейтрально.
Бюрократия – это неповоротливая машина, которая часто дает сбои, но, кроме этого, она может уберечь вас от потенциально провальных решений, упростить взаимодействие с коллегами или обеспечить качественный отпуск (ощутите на языке вкус бананового коктейля).
Тезисы
■ Бюрократия – неотъемлемая часть больших компаний и продуктов.
■ Редкие плюсы бюрократии теряются среди ее многочисленных минусов.
■ Не позволяйте сухим бюрократическим формальностям расстраивать вас.
Задание
Если вы работаете в компании, известной своими бюрократическими проволочками, и вас это БЕСИТ, начните тренироваться. Воспринимайте каждое вовлечение в череду ненужных (на ваш взгляд) обсуждений как прогон тестов. Да, это медленно, да, вы в это время не можете толком заняться ничем другим, но, возможно, именно на этом прогоне вы заметите какую-нибудь очень неприятную, очень опасную ошибку. Используйте время, которое теряете в бюрократической бездне, с пользой для себя: подтяните свои знания по языкам программирования, займитесь рефакторингом вашего приложения (да-да, если вам одобрили эту задачу, подписав 12 бумажек на 6 разных этажах и прислав почтового голубя с письмом-подтверждением).
История из жизни
Одна из компаний, в которых я работал, требовала тотальной отчетности по рабочему времени, разбитому на десятиминутные интервалы, так что если в течение часа вам приходилось заниматься разными делами, вы должны были составить примерно такой список:
10 минут – обсуждение с коллегой ошибки #123
20 минут – анализ требований к задаче #125
10 минут – поиск библиотек, подходящих под требования задачи #125
10 минут – общение с тестировщиком по ошибке #123
10 минут – работа по внедрению найденной библиотеки в задачу #125
Все это отнимало уйму времени, и на отслеживание и запись своих занятий нужно было тратить куда больше усилий, чем непосредственно на сами занятия.
Идеальный продукт
Людям свойственна тяга к прекрасному, а перфекционисты – люди, ставшие рабами этой тяги. Желание сделать работу как можно качественнее – важная и замечательная черта любого специалиста. Когда мы начинаем новый проект или новую работу, мы горим (мама, неси огнетушитель!). Мы мотивированны, возбуждены, ушки у нас на макушке. Мы хотим сделать все правильно. Мы хотим сделать все качественно.
Извините, но сейчас я спущу вас обратно на землю. Мир – это хаос. Мир программного обеспечения, при всей кажущейся структурированности и логичности, – еще больший хаос. И мы становимся заложниками желания привнести в этот хаос смысл и логику. Мы пытаемся написать идеальный код. Дизайнеры пытаются создать идеальный, понятный и практичный интерфейс. Тестировщики пытаются написать идеальные системы проверки продукта.
И все это разбивается о пользователя, который решил отправить форму, оставив вместо имени цифру 0. Да, я утрирую, но лишь слегка. Мы так отчаянно стараемся создать что-то незыблемое и прекрасное, что отрываемся от реальности, от хаоса, в который погрузится наш продукт, как только попадет на рынок, к пользователям. И я не хочу сказать, что в этом есть чья-то вина: наша как создателей или пользователей как потребителей. Просто так устроен мир, и мир программного обеспечения не исключение.
Для примера понаблюдайте за опытными разработчиками. Со стороны их работа может показаться достаточно небрежной. И дело не в том, что они нарушают стиль кода или вместо того, чтобы писать код, играют в пинг-понг. Нет, «небрежность» заключается в самом их отношении к своему коду. Вы редко увидите, что профессиональный разработчик корпит сутки напролет, выстраивая монструозную систему отлова всех ошибок и исключений. Вы вряд ли увидите разработчика, который тщательно напишет все возможные тесты для только что созданного им кода.
Эта кажущаяся небрежность – не более чем показатель большого опыта, полученного на множестве проектов. Каждый разработчик, приобретя достаточный опыт в IT, начинает понимать, что идеального кода не существует. Есть код, который работает и делает то, что должен делать. С одной стороны, профессиональный разработчик должен писать качественный код, с другой – может быть достаточно небрежен в работе. Но как?! Опыт и интуиция. Если за свою карьеру вы написали 10 калькуляторов, то вряд ли станете писать сотню юнит-тестов по проверке сложения (assert(2 + 2, 4), какая красота, вы только посмотрите). Вероятнее всего, вы напишете десяток тестов, но таких, которые будут включать самые нелепые, самые глупые входные данные, какие только могут быть: сложение со строкой, деление на ноль, возведение в объект. Опыт поможет вам почувствовать, в каком месте код встретится с хаосом реальности и когда он падет смертью храбрых. Но даже тогда вы не предугадаете всех вариантов, поэтому позвольте себе наслаждаться процессом. Не делайте из кода или продукта культ. Пусть работа приводит вас в восторг, а мотивация зашкаливает так, что не дает уснуть по ночам. Однако всегда помните о том, что хрустальные замки идеалов – в облаках, а внизу – хаос реальности, от которого нельзя избавиться, просто отказавшись о нем думать.
Тезисы
■ Мир программного обеспечения – хаос.
■ Старайтесь выполнять свою работу качественно, но не кладите ее на алтарь перфекционизма.
■ Идеальных решений, как и идеального кода, не существует.
Задание
Вспомните самое начало своей карьеры. (Если вы начинающий разработчик, вернитесь к этому заданию чуть позже – уверен, оно вас впечатлит.) Вспомните, с какой дотошностью вы относились к новому коду, который
