Так что я очень скоро начну свою работу в качестве инженера-программиста. Я никогда раньше не работал в компании. Что мне непонятно, так это то, как люди/компании, занимающиеся разработкой программного обеспечения, измеряют свою производительность или рабочее время, особенно при гибком рабочем графике.
Я имею в виду, что на других работах есть тема рабочего времени с 9 до 5, когда вы идете в офис и выполняете четкую работу. Например, как быть кассиром в супермаркете. Очень ясно, как измеряется ваша продуктивность или хорошо ли вы работаете. Если вы просто обслуживаете всех клиентов и на своем стуле, то у вас все отлично! Но как насчет работы по разработке программного обеспечения?!
В работе по разработке программного обеспечения это довольно сложно измерить. Мне действительно трудно понять атмосферу рабочего времени для разработки программного обеспечения. Я имею в виду, что вы можете работать над ошибкой, и это может занять у вас 2 дня, но кто-то другой может решить ее за пару часов или около того. Или вам может быть назначена задача по программированию, но в этот конкретный день ваш ум может быть не в лучшем виде, поэтому вы можете не написать много кода или около того. Другими словами, уделяя два рабочих часа, но разные личные режимы, за один день вы, вероятно, можете написать чертовски много кода за эти два часа, будучи очень продуктивными, но в другой день и уделив те же два часа, вы могли бы только уметь писать очень мало кода. Так как же измеряется производительность и рабочее время в нашем домене/поле?!
Я хотел бы знать это, прежде чем приступить к работе, потому что я уже беспокоюсь о том, что не смогу продуктивно работать в плохие дни или около того. Я имею в виду, что иногда вы можете немного меньше спать и быть менее продуктивным как кодер. Но кассир может выполнять свою работу, даже будучи сонным, и ему не нужно беспокоиться о том, действительно ли он заслуживает денег в конце месяца или нет, как я! Так?
Я имею в виду, что я определенно могу стараться вести хорошую/здоровую жизнь, чтобы быть как можно лучше в своей работе, но это не гарантируется!
Человек, новичок в мире труда, вот на чем я бы сосредоточился:
Знайте ожидания вашего руководителя относительно времени и посещаемости. В некоторых местах более гибкий график работы, чем в других, в некоторых местах ожидается работа 60-80 часов в неделю. Многое из этого сосредоточено на том, какой бизнес у компании. Например, есть компании, которые выставляют клиентам счет за время. Такая компания будет иметь другие ожидания, чем та, которая создает приложения и затем продает их. И у государственного учреждения могут быть другие ожидания, или у программиста в компании, которая в основном имеет объединенную рабочую силу на производственном предприятии. Это также может зависеть от того, нужна ли поддержка производства в реальном времени или нет. В то время как ожидания компании различаются, место, где можно получить эти ожидания, — ваш непосредственный руководитель.
Затем узнайте, на что похож рабочий процесс. Где вы проверяете код, каковы стандарты кодирования, какие инструменты вы должны использовать, есть ли у вас автоматизированные процессы сборки или QA, с которыми вы должны уметь работать? Какие испытания они проводят? Что ожидается от совместной работы? Они занимаются парным программированием? Делают ли они код-ревью? Они ловкие? Как назначается работа? Как определяются сроки?
Затем поговорите со своим непосредственным начальником о том, как именно он хочет, чтобы вы ускорились, и чего он ожидает от вашей работы. Скорее всего поначалу у вас будет много вопросов. Спросите его, следует ли вам прийти к нему или есть ли кто-то еще, кого он хочет научить вас. Обязательно поговорите с ним о своей первой задаче, когда она будет завершена, даже если у них нет формального обзора кода. Гораздо лучше узнать, что вы идете в направлении, которое им не нравится, сразу, чем через шесть месяцев после того, как они это заметят. Убедитесь, что вы знаете крайний срок для своей первой задачи, и сообщите, если вы видите проблемы с его выполнением.
Ожидайте, что ваш руководитель и вы не всегда будете соглашаться в подходе. Помните, однако, что, как правило, его работа заключается в принятии окончательного решения, и вы должны принимать эти решения с изяществом, даже если вы не согласны. Время влиять на решение — до того, как оно будет принято. Помните, что технические потребности или желания — не единственный и даже не самый важный фактор, влияющий на большинство решений. Постарайтесь понять, что еще влияет на решения, с которыми вы не согласны, и это поможет вам быть более убедительным в будущем. Прежде чем вы сможете оказывать большое влияние на решения, вам нужно будет завоевать репутацию специалиста по выполнению работы, так что сконцентрируйтесь на этом в первую очередь.
Также помните, что в бизнесе у нас есть сроки, которые часто означают, что вы не можете настроить последние 5% совершенства. Совершенство — враг достаточно хорошего. Мы не создаем художественное произведение, мы создаем часть программного обеспечения, которое что-то делает, и иногда лучше сделать его несовершенным, чем не сделать вообще.
Лучше задать вопрос, чем сделать неверное предположение. Лучше сообщить плохие новости (например, о проблеме, влияющей на крайний срок) раньше, чем позже. Лучше попросить о помощи (ну после попытки решить проблему самостоятельно, вампира времени тоже никто не любит), чем бороться и не иметь возможности поставить.
Убедитесь, что вы связываетесь со своим руководителем не реже одного раза в месяц (или, желательно, чаще, но это зависит от личности вашего руководителя) и смотрите, насколько хорошо вы оправдываете ожидания. По мере накопления опыта у вас будет больше суждений по этому поводу, но сейчас действительно обратите внимание на то, чтобы получить обратную связь. И когда обратная связь отрицательная, тогда внесите изменения. Ваш босс имеет контроль над вашим повышением заработной платы и премий, и даже если вы собираетесь остаться на работе. Его мнение о вашей работе значит больше, чем ваше.
Наконец, начните соблюдать корпоративную культуру. Вы узнаете, есть ли моменты, когда можно расслабиться, или сколько сверхурочных часов требуется для встречи с дилерами, или как официально люди общаются.
Так как же измеряется производительность и рабочее время в нашем домене/поле?!
На это нет простого ответа. Если вам нужна работа с легко измеряемой производительностью, умственная работа — неподходящая область.
Есть всевозможные выдуманные и в конечном счете бессмысленные метрики, строки кода, покрытие тестами, количество ошибок, количество функций. Все они имеют существенные недостатки, и вы должны подозревать любого, кто их использует. Я бы рекомендовал не использовать их (даже для себя) в качестве показателей, так как вы можете тривиально их обыграть.
Что имеет значение, так это «считает ли мой руководитель, что я оправдываю ожидания?»
Это то, что вы должны обсудить со своим руководителем, чтобы понять. На самом деле нет другого способа узнать «Я оправдываю ожидания», кроме как спросить своего руководителя. Вот хороший способ, как это сделать.
Просто примечание, ваше отношение к этому действительно осуждающее (и неправильное):
Но кассир может выполнять свою работу, даже будучи сонным, и ему не нужно беспокоиться о том, действительно ли он заслуживает денег в конце месяца или нет, как я!
Занимаясь и кассой, и разработкой программного обеспечения, это совсем не так.
Количество предметов в минуту значительно уменьшится, если вы устали. Вам потребуется больше времени для решения вопросов. Вы будете физически уставшим, что заставит вас быть медленнее. Вы будете менее дружелюбны с клиентами.
Усталость влияет на производительность вашей работы во всех областях.
Лучшее, на что вы можете здесь надеяться, это «качественно» — после небольшого опыта в отрасли вы встретите некоторых разработчиков, которые явно лучше других. Есть известный мем, что лучшие разработчики в 10 раз лучше других . О конкретных цифрах много спорят, но, безусловно, есть очень хорошие разработчики, большое количество средних разработчиков, а также несколько плохих. Проблема с выявлением «лучших» разработчиков заключается в том, что их наборы навыков различаются: один разработчик может быть превосходным, потому что он пишет код, содержащий очень мало ошибок, в то время как другой разработчик может быть превосходным, потому что он пишет код, который работает очень быстро.
Единственное, к чему я был бы очень осторожен, так это к любой компании, которая пытается измерить производительность разработчиков с помощью метрик, подобных «написанным строкам кода» или «внесенным ошибкам». Любой из них слишком прост для игры, чтобы быть полезной мерой мастерства разработчика — если взять конкретный пример, некоторые из лучших фрагментов кода, которые я написал, были фрагментами, которые удаляли строки кода, например, объединив некоторые разрозненные фрагменты кода в одну функцию, но я, очевидно, не стал бы этого делать, если бы моя производительность каким-либо образом измерялась количеством написанных строк кода.
Брандин
Натан Купер
Майлз
тиего1967
Бьярке Фройнд-Хансен