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