[Из песочницы] Что я хотел знать в начале своей карьеры разработчика. Часть 1
Когда вы начинаете карьеру где бы то ни было, вы, вероятно, надеетесь на многое, но не знаете, чего ожидать. Стоит ли не высовываться и делать, что сказано или нацелиться только на амбициозные проекты? Вот чему я научился за время работы как разработчик ПО.
Позвольте мне высказать несколько предположений, основанных на моих опыте и наблюдениях. Этот список не полный — потому что не может им быть. Ваш опыт будет уникальным.Это перевод статьи-ответа на ресурсе Quora.com, иллюстрация с сайта LifeHacker.com.
1. Не бойтесь учиться на работе. К сожалению, книжные полки большинства рабочих мест стоят там для вида. Вы редко видите кого-либо, читающего книгу, тем более во время основных рабочих часов. Всё же, вы можете читать документации и большинство книг с компьютера или электронной книги. Так что займитесь этим. Вряд ли вы научитесь многому, если будете делать только назначенное. Вы так же не продвинетесь, если потребуете больше работы и получите рутину. Останавливайтесь и делайте вещи правильно и учите основы. Как люди становятся экспертами в областях вроде машинного обучения? Каждый день понемногу.
2. Управляйте своей карьерой агрессивно. Берите ответственность за ваше обучение и прогресс. Один из десяти (в лучшем случае) находит наставника, который показывает проторённые дорожки и дёргает за ниточки, чтобы их ученик получил повышение и хороший проект. Если вы среди девяти других (а вы будете там большую часть времени), смиритесь с тем, что о вас не заботятся. Так что позаботьтесь о себе сами. Не просите больше работы, пока не будете уверены, что вы доверяете этому человеку и он даст вам лучшую работу, чем та, которую вы получите иначе. Когда это возможно, делайте как можно меньше работы, не продвигающей вас по карьерной лестнице или учит вас чему-либо; если эта работа не имеет значения для вашей карьеры, то скорее всего людей не заботит то, что вы делаете работу еле-еле, пока вы никому не мешаете. После трёх лет, если вам не дают задач больше или труднее, чем в начале, «внешнее повышение» (читайте: смена работы) обычно является хорошим выходом.
3. Научитесь распознавать недоработку и переработку, а так же избегать их. Есть множество ленивых разработчиков, работающих годами. Это неплохая стратегия, если вы устроились, но я бы не стал так падать. К слову сказать, за недоработку обычно увольняют людей, которые делают так мало работы, что создают работу для остальных. Недоработчики, которые не высовываются, обычно не наживают врагов. В то же время остерегайтесь переработки. Это не вуз, в котором можно получить пятёрку за то, что вы аргументированно переспорили вашего профессора. Переработчики часто создают работу для их коллег и начальников и привлекают ненужное внимание (Читай: МакНалти из «Прослушки»), а так же имеют больше шансов быть уволенными по пункту «производительность», чем недоработчики. Я не имею ввиду, что вы не должны стараться, делать хорошую работу и учиться насколько возможно — просто это не переработка. По моему опыту переработка — возможно, повышенная амбициозность — гораздо опаснее недоработки, потому что приведёт вас к увольнению гораздо быстрее. Если вам придётся выбирать из двух зол, склоняйтесь к недоработке.
4. Никогда не спрашивайте разрешения, если только не спрашивать опасно. Хотите потратить неделю на исследование по собственной инициативе? Не спрашивайте разрешения. Вы его не получите. Вполне вероятно, что вы не окажете услугу начальству, спрашивая разрешения; с их точки зрения, вы бросаете на них ответственность, если у вас что-либо не получится. К тому же, в любом случае он может отказаться от вашей ответственности потом, потому что он выше вас. Как видите, нет хороших сторон в этих просьбах. Конечно, если вы рискуете нанести серьёзный ущерб бизнесу, или от вас просто требуется спросить разрешение, тогда вы должны это сделать. Если потери малы, а риски соответствуют вашему уровню в компании (а на вакансию программиста, на которой вам не доверяют через недели вашего собственного времени, не стоит устраиваться) — тогда не спрашивайте разрешения. Просто сделайте это, и сделайте это хорошо.
5. Никогда не извиняйтесь за самостоятельность или использование собственного времени. Вы можете признать, что ваш проект или ваше расследование не получились, как задумано. хотя лучше представить это как попытку исследования, но вы не должны извиняться за проваленный сторонний проект. Это создаёт прецедент, касающийся вас, как подчинённого, над которым необходимо больше наблюдения. После описания чего-либо, сделанного по вашей инициативе, не говорите начальнику: «Не беспокойтесь, я сделал это вне рабочего времени». Если ваша компания не позволяет работать вам над своими проектами в часы вашей работы, то не стоит ради них стараться ни по какой причине. Уважайте своё время — иначе никто не будет.
6. Выучите CS666 (так я называю политику разработки ПО). Выучите его и можете про него забыть. Не учите его, и он будет сопровождать вас всегда. Когда мы взрослеем, мы начинаем видеть ценность в переносимых и общих способностях: функциональное программирование вместо Spring/Hibernate, алгоритмы вместо причуд Java 1.4 legacy. Да, CS666 не из приятных, но он применим в индустрии гораздо лучше любого языка программирования. Я не говорю, что вы должны стать политическим животным или стать одержимым ею, потому что это хорошо не закончится, но вы должны быть политически сознательным, потому что политика есть во всём, чем мы занимаемся. Хорошо начать изучать людей и их поступки как можно раньше, даже если вы не собираетесь играть (а в молодости вы не должны часто играть). Хоть вам дают кластер Hadoop вовремя для решения ваших задач, или вы получаете ту самую возможность «заморозки фич» (feature freeze, когда в проекте фиксят баги и не добавляют фичи — прим. переводчика), чтобы вы смогли почистить свои долги, или за какие проекты вы ответственны — это всё политика. Хорошо это или плохо, но это — ваш главный инструмент, и в настоящей жизни вам лучше использовать его, а не попадать под его действие. Если вы выучите CS666, вы получите время отдышаться, забыть о нём и просто делать хорошую работу. Если вы его не выучите, то ваша карьера будет формироваться теми, кто лучше этим пользуется.
7. Не будьте идеалистом и не пытайтесь доказать, что ваше начальство не право. Когда молодые инженеры чувствуют, что их идеи лучше, чем те, которые предложены начальником, но не находят поддержки, как правило они резко повышают ставку и риски и тратят множество часов. «Давайте докажем, что начальник не прав… путём жертвования собственного времени на то, чем будут владеть они!» Извини, но если тебе пришлось выкинуть пару выходных (не считая редких случаев вроде «последнего рывка»), чтобы выполнить проект, значит твоё начальство не сильно о нём заботится. Иначе у тебя было бы время и ресурсы, а так же не было терпения для идеализма. Вместо того, чтобы делать хет-трик сломанной клюшкой, просто позволь этой игре случиться. Начальник не любит, когда из него делают дурака люди, которые в нём сомневались. Вы не получите повышения или премии. Начальство найдёт способ доказать их плохое впечатление (и ваше искреннее сопереживание успеху «плохого» проекта наложит на вас след) и, даже если вы преуспеете, вы провалитесь. Всегда останется место для: «Он сделал неплохую работу, но отвлёкся от назначенной работы и я не могу ему доверять/мы не можем позволить ему создать прецедент/это была моя идея».
UPD: CS666 не существует — автор оригинальной статьи обозвал так общение в сфере разработки ПО с коллегами, начальством и заказчиками.
