Никогда не представляйте проблему

Я быстро просмотрел ваш профиль и заметил, что вы уже некоторое время присутствуете в сообществе StackExchange. Вы, несомненно, заметили здесь, что вопросы, которые получают здесь лучшие ответы, — это те, которые представляют проблему и рассуждения, которые они уже использовали в попытке ответить на вопрос.

Трудовая жизнь такова. Если вы задаете вопрос, вы также должны сообщить им, что вы уже сделали, чтобы попытаться ответить на него самостоятельно. Это дает вам несколько преимуществ:

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

Здесь есть пара моментов, которые нужно распаковать.

Я полагал, что всем остальным в технологической компании нравится говорить о технологиях...

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

Я думаю, вы можете запутаться между этим и:

Меня также ругали за то, что я «иду по ложному пути» при попытке решить проблему, с которой я не знаком, вместо того, чтобы спросить кого-то, кто знал.

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

Я почти всегда пытаюсь разобраться в проблемах самостоятельно хотя бы час. Это слишком коротко?

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

Сложите все это вместе, и я вижу молодого программиста, у которого есть некоторые проблемы с суждением, о чем вам сказал ваш HR-менеджер. Это не непреодолимо, но есть некоторые вещи, о которых вам нужно подумать.

• Приберегите гипотетические технические вопросы для обеденной комнаты. Неуместно, если вы хорошо не знаете людей, тратить свое и чужое время на неуместные вопросы.
• Узнайте, как применять лучшие условия веб-поиска. Если вам говорят, что вы задаете слишком много вопросов и тратите на них слишком много времени, то очевидно, что вы задаете неправильные вопросы.
• Задавая вопрос, покажите, что вы пробовали. Классический менталитет переполнения стека. Если у вас нет ничего, что можно было бы продемонстрировать как согласованные усилия по решению проблемы, значит, вы недостаточно старались. На самом деле, не бойтесь использовать такие ресурсы , как Stack Overflow, если есть что-то реальное, что может быть общедоступным. И наконец;
• Сохраняйте вопросы для бизнес-специфических вопросов. Не спрашивайте о том, как управлять своим инструментом программирования, но спрашивайте о проблемах, связанных с предметной областью или окружающей средой, которые не будут в открытом доступе.

Здесь есть много вещей, которые вы можете улучшить. Вы можете обнаружить, что PIP может быть очень ценным инструментом, который поможет вам стать лучшим разработчиком :)

Проблема в том, что когда вы прерываете чью-то работу, они не только теряют 5-15 минут, которые им нужны, чтобы ответить. Они теряют намного больше времени, так как им нужно восстановить концентрацию. И это может быть весьма неприятно.

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

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

Другой вариант — назначить встречу, на которой все выясняется.

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

Слишком много вопросов

Большая часть вашего замешательства, по-видимому, связана с тем, что вы не понимали, что задавать вопросы — опасная игра. Это!!!

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

Теперь сложная часть здесь заключается в том, что иногда это именно так, и вы должны задавать вопросы. Просто важно помнить, что, несмотря ни на что, в этих вопросах есть и негативная сторона.

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

Не тратите достаточно времени на себя

Это великан!!! Когда вы просите члена команды о помощи, вы также снижаете продуктивность этого человека. Вы одновременно влияете на их процесс и оскорбляете их (см. выше). Вы не сможете победить, если вам придется просить о помощи. Думайте о каждом вопросе, как о проигранной битве. Вы все еще можете выиграть войну, но вы проиграли эту битву.

Есть некоторые вещи, которые вы можете сделать, чтобы смягчить проблему:

1. Спросите по электронной почте, никогда лично или в чате. Чат может быть предпочтительным способом сделать это «официально», но электронная почта удобнее, потому что получатель может справиться с этим в свое время.
2. Подойдите к нему с «нижней» позиции. Вы проситель здесь. Займитесь унижением. Ничего страшного. Немного не повредит вам и покажет получателю, что вы заботитесь об их времени, например: «Я знаю, что вы очень заняты, но я не могу понять, как интегрироваться с вашим API. Когда вы получите Через несколько минут вы можете показать мне, что мне не хватает?" Это показывает, что вы не правы, а не они. Это важно.
3. Перечислите шаги, которые вы предприняли самостоятельно. «В документе API сказано передать строку, представляющую идентификатор пользователя. Я пытался передать свойство user.id и имя пользователя, но ничего не получилось». Это показывает, что вы хоть что-то пробовали, и что в целом продукт у вас начинает «доходить».

Лучшее суждение, задавая вопросы

Для меня это звучит так, как будто вы кому-то «ныли», и у них не было хорошего способа сказать: «Вы всех раздражаете своими глупыми вопросами. Прекратите!» Другими словами, я думаю, что это не проблема. Как только вы исправите другие проблемы, это исчезнет.

Плохая документация

Кхм! Это еще одно личное оскорбление. Никогда не говори так. КОГДА-ЛИБО!!!! Вы опять говорите, что качество их кода настолько низкое, что вы не можете в нем разобраться. Их ответ всегда будет таким: «Сработает для всех остальных, так что ты, должно быть, идиот, а не я!»

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

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

Я скажу это, хотя. Какой бы дрянной ни была документация, с исходным кодом прямо перед вами она вам не понадобится. Это очень приятно иметь, не поймите меня неправильно, но вы можете работать и без него.

Опоздать

Очевидно, не опаздывать. Это не ежу понятно. На самом деле в вашей ситуации прямо сейчас, быть 30 минут. рано!! Никаких оправданий. Вы разрушаете любую надежду найти свою следующую работу с этим. Если бы я позвонил в отдел кадров и спросил о вашей посещаемости, а мне сказали бы: «Он часто опаздывал» или «Его выписали за опоздание», — это мгновенный красный флаг. Я упоминаю об этом, потому что, сохраните ли вы эту работу или получите новую, это больше, чем что-либо другое, помешает вам получить следующую работу.

Код низкого качества

Вероятно, это правда. Учитывая проблему вопроса, вы, вероятно, не пишете хороший код. Ты новичок, и этого следовало ожидать. Я обнаружил, что колледжи ни черта не учат программированию в реальном мире. Я никогда не нанимал кого-то сразу после колледжа и не получал «хорошего разработчика». Это не значит, что они не стали хорошими разработчиками. Они просто не начинают таким образом. Писать хороший код означает быть в курсе последних тенденций и технологий. Вы постоянно учитесь. В тот момент, когда вы остановитесь, вы начнете сосать.

В заключение

Этот пост был грубым, но я хотел ясно показать, какой может быть позиция компании. Часто они (компании) оборачивают свои комментарии таким количеством «менеджерской речи», что это может быть трудно понять. Я пытался максимально сократить слова менеджера в этом посте, но это означает, что он получился немного грубым.

Ваши самые важные шаги, чтобы исправить неудачную карьеру:

1. ПРИХОДИТЕ НА РАБОТУ ЗАРАНЕЕ!!!! (Я не могу подчеркнуть это достаточно)
2. Задавайте вопросы, думая, что вы уже оскорбляете человека, которого задаете.
3. Показать свою работу. Задавая вопрос, четко укажите, что вы уже сделали.
4. Уделяйте больше времени самостоятельному обучению. Важно тратить больше времени на изучение вещей, чем на вопросы. Честно говоря, 3-4 дня поиска чего-то самостоятельно будут более уважаемы, чем 30-секундный вопрос.

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

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

Могут возникнуть проблемы, когда кто-то задает вопрос:

1. Мне нужно кое-что сделать, поэтому сейчас не время. В идеале люди сказали бы вам, когда самое подходящее время.
2. Это то, что вы должны исследовать самостоятельно. К сожалению, Google легче скрыть решения проблем с помощью устаревших технологий, чем найти политики и процедуры для вашей собственной компании. Люди не документируют. Это грустно, но верно.
3. Вы продолжаете задавать один и тот же вопрос снова и снова.
4. Ваши вопросы кажутся чрезмерно критическими, и люди устают объяснять/защищать, почему они делают что-то определенным образом. Это еще сложнее, когда имеешь дело с новыми людьми. «Почему мы используем COBOL?» Потому что это была лучшая технология в то время, и она работала с тех пор, как вы были в подгузниках. Теперь иди делай свою работу.

Судя по тому, что вы говорите, вы не получали много отзывов, пока вас не отправили на испытательный срок. Это позор. Во многих местах не предусмотрены ресурсы и практики для обучения и наставничества новых людей. Если бы кто-то действительно заботился о том, чтобы помочь вам добиться успеха, он бы сказал вам что-нибудь.

Был точно в такой же ситуации.

Проблема

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

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

Я думаю, вы задаете вопросы, потому что,

• Вы чувствуете, что на выполнение задачи уходит больше разумного времени, так как вы не понимаете какую-то часть системы.

• Вам просто интересно понять систему полностью

• Ваша компания не предоставила вам надлежащее обучение

Решение

Если мои предположения верны, тогда перестаньте задавать вопросы, если в этом нет необходимости (полная остановка - прямо сейчас)

• Начните тратить больше времени на понимание системы (не только 8 часов)

• Вместо этого используйте SO или другие связанные сайты (после выполнения исследовательской части)

• Попросите свою компанию обучить вас должным образом @областям, в которых вам нужна помощь.

Я последовал вышеизложенному и теперь работаю в той же компании через 5 лет, и я могу утверждать, что знаю больше, чем кто-либо здесь.

Я хотел попробовать это с точки зрения управления.

PIP — это комплексная вещь

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

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

Каждый час на счету

Новый выпускник колледжа — это инвестиция в командное время. Любой менеджер, который говорит вам обратное, либо никогда не нанимал нового выпускника колледжа, либо лжет, либо на него/нее работают действительно выдающиеся тимлиды. Любой новый сотрудник требует определенных вложений, но выпускники колледжей требуют БОЛЬШЕГО времени. Однако обычно компромисс того стоит, но имейте в виду, что выпускники колледжей задают больше вопросов, чем более опытные разработчики.

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

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

Я был бы уверен, что ЛЮБОЕ переключение контекста стоит 1 час, поэтому, даже если у вас есть 5-минутный вопрос, вы будете стоить команде часа, когда кто-то остановится, чтобы ответить на ваш вопрос. Это означает, что потратить 1 час и не получить его, а затем обратиться за помощью на самом деле стоит больше времени, чем потратить 2-4 часа.

Нет такой вещи, как «другому парню понадобится всего 5 минут, чтобы сэкономить мне час». Учитывая показатель не менее часа на одно прерывание, другому парню лучше сэкономить вам 2-4 часа.

Советы, как правильно задавать вопросы:

• Понимайте и задавайте вопросы в соответствии со срочностью — если вы абсолютно ДОЛЖНЫ решить проблему в течение часа, то прерывание почти любого, кто может вам помочь, — хорошая идея. Если вам дали крайний срок в 3 недели, то лучше меньше прерывать и больше решать собственные проблемы. Это означает, что в чрезвычайной ситуации люди часто задают множество вопросов, которые в противном случае они исследовали бы самостоятельно. Потому что абсолютно необходимо получить ответ как можно быстрее.
• Используйте форумы вопросов для их определенной цели или интуитивно определите цель из существующих вопросов/ответов. Обмены стека, например, имеют довольно обширный набор основных правил, которые довольно хорошо задокументированы, и особое ожидание, что пользователи ищут предыдущие ответы, прежде чем спрашивать. Другой форум может ожидать повторных вопросов, но только по очень узкой области.
• Исследуйте свой вопрос. Ожидайте, что на написание хорошего вопроса может уйти столько же времени, сколько и на ответ — во многих случаях вы описываете (кратко!) шаги, которые привели вас к невозможности ответить на проблему. Также вы, вероятно, будете документировать все симптомы проблемы.
• Нацеливайте свои вопросы — выясните, кто на самом деле может ответить на вопросы, когда это возможно, а не спрашивайте всех. Не каждый вопрос стоит обсуждения.
• Соберите большую кучу вопросов — особенно если вы новичок, потратьте день на рассмотрение проблемы и кода. Объедините свои вопросы в маркированный список с объединенными темами. Затем спросите наставника или друга, куда можно обратиться за помощью. Вполне вероятно, что на большинство вопросов, заданных в часе №1, ответят в часе №6. Вопросы, которые пришли в течение 1-2 часов и на которые не удалось ответить к 8 часу, вероятно, находятся в верхней части вашего списка, поскольку вы знаете, что за 8 часов вы не сможете их решить.
• Код не является «самодокументируемым», но, прочитав его, можно узнать много информации. Я изучил множество недокументированных систем, сидя с блокнотом и рисуя свою версию проекта по ходу дела. Если вы не читали несколько уровней выше и несколько уровней ниже области, в которой вы работаете, и вы не читали документы внешних API, которые вы используете, вы недостаточно хорошо изучили.
• Когда вы пытаетесь найти ответ, очень важно, если вы можете предложить варианты, а не спрашивать ответ. "Это будет правильный способ сделать это?" лучше, чем "Как мне это сделать?" - даже если ответ "вы делаете это совершенно неправильно" - вы все равно можете спросить "почему мой путь неправильный?" и тем более мета "как бы мне научиться делать это правильно неоднократно"? Это подход «научить человека ловить рыбу» — научитесь ловить рыбу, не задавайте вопросов, которые принесут вам только 1 рыбу.
• Избегайте вопросов, которые являются просто вежливым способом несогласия. Существует грань между «работоспособен ли мой способ сделать это?» vs. «Я не понимаю (т.е. не согласен), почему ты поступил по-своему?» Это прекрасные разговоры, но их лучше вести в неформальной обстановке после того, как вы познакомитесь с людьми.
• Умерьте свои общие вопросы — обычно это вопросы «почему». Новые люди имеют полное право задавать множество вопросов «где» и «кто» (где документы, где процесс для этого, где место в коде, на которое я мог бы взглянуть? кто может ответить на это? кто Приглашаю на обзор?) и ряд вопросов "как" - так ли мне к этому подходить? как я могу получить ваше согласие? Но «почему», например, «почему мы сделали это таким образом?», «почему мы не документируем больше кода?», «почему это не является приоритетом?» - они законны, но пока у вас не будет больше опыта работы и бизнеса, это не самые необходимые вопросы. Они могут быть ОТЛИЧНЫМИ для встречи один на один с вашим боссом, когда у вас нет других неотложных вопросов,

Здесь уже есть много ответов, но я хочу затронуть несколько конкретных частей вашего вопроса.

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

Это слишком коротко? Сколько времени разумно потратить на решение проблемы, прежде чем спросить коллегу, который знает ответ?

Акцент добавлен мой.

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

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

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

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

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

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

Тем не менее, задавать вопросы, связанные с работой, — это хорошо, так как это показывает, что вы заинтересованы в своей работе и хотите совершенствоваться.

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

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

Я бы сказал, что вы узнали о том, чего ожидает эта компания, через школу тяжелых ударов. Вопросы в этом месте - нет-нет.

Я думаю, что ваша главная проблема заключается в видимости . Задавать вопросы в slack — это то, что видят многие; даже если они не чувствуют себя обязанными отвечать, это все равно может повлиять на их мнение о вас. Между тем, если вы потратите день на изучение одной функции за своим столом, никто не увидит, как крутится колесо. Похоже , вы делаете что-то не так, а не просто стучите по клавишам за столом, что выглядит как работа. Конечно, возможно, в еженедельных, ежемесячных или годовых обзорах ваша продуктивность будет плохо отражаться. Но ваши незанятые вопросы просматриваются несколько раз в день, в то время как ваша реальная продуктивность измеряется гораздо реже.

Я был в таком же положении, как и вы. Меня наняли исправлять ошибки в приличной CMS, в то время как ведущий разработчик (только для чтения) изо всех сил пытался добавить функции для клиентов. Мы сильно отстали. Кодовая база не находилась под контролем версий, и у каждой стороны была своя собственная версия. Это был полный беспорядок.

По наивности, я думал, что лучше потратить 10, 20 или 30 минут моего и лида времени на болтовню, чтобы он мог мне что-то объяснить, чем тратить полдня, целый день или даже несколько дней на реверс-инжиниринг. функция, чтобы узнать 1. что он должен был делать, 2. как он должен был работать и 3. как исправить ошибку.

Оказывается, когда мой босс (один из двух партнеров) узнал об этом, он, хотя и плохо показал мне, что я не могу самостоятельно устранять неполадки в коде и что я отнимаю у нашего драгоценного ведущего разработчика время. (Ведущий разработчик, похоже, любил говорить о том, как работает его кодовая база — во всяком случае, он не жаловался на это моему боссу, как он сказал мне.) Итак, я перестал задавать вопросы, и моя продуктивность упала, наверное, до 10% от того, что было. Меня отпустили примерно через месяц.

В любом случае, эта компания говорит вам в плохой манере, что они не ценят эту экономию времени и побочный эффект документации. Так что не делай этого.

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

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

Так чем закончилась моя история? После периода безработицы я устроился на новую работу. Помимо того, что кодовая база намного лучше (мы используем стандартную CMS, у нас есть контроль версий, у нас есть среды разработки, подготовки и производства и т. д.), мои коллеги выдающиеся, и моя компания поощряет обучение. У нас есть вики, где мы делимся информацией и избегаем изобретения велосипедов. Мы болтаем весь день в slack, говорим о работе, задаем вопросы, проводим мозговые штурмы, делимся новостями, информацией и открытиями. Мы запускаем проекты по улучшению наших процессов, таких как agile, vagrant и внедрение непрерывной интеграции. Мы учим друг друга и учимся друг у друга. Мы действуем как коллеги и сотрудники; не конкуренты. У нас есть адаптация и ориентация для новых сотрудников и подрядчиков, чего мы не смогли бы иметь без этой культуры. Что'

Наша компания отправляет нас на тренинги, конференции и поощряет уделять время веб-классам и кастингам. За это время здесь я узнал больше, чем за любой другой период моей карьеры, особенно. по предметам, в которых я конкретно не работаю. Это замечательно; Я здесь уже 4,5 года и не вижу особых причин уходить, кроме изучения новой технологии. Культура на моем новом месте действительно направлена ​​на изучение, понимание и внедрение лучших практик, что ведет к повышению производительности. Это беспроигрышный вариант.

Серьезно, есть места получше. Это не место для вас, и вы не тот человек для них.

Типы рабочих вопросов:

1. Как мне сделать то, что мне нужно научиться делать работу.

2. Как мне сделать что-то Мне нужно научиться делать работу, но мне уже сказали.

3. Как мне сделать то, что я уже должен знать.

4. Как мне сделать что-то, что не соответствует заданию, и я знаю, что это не соответствует цели.

5. Как мне сделать что-то, что не соответствует заданию, и я не знаю, что это не так.

6. Смешные вопросы и светская беседа.

Так...

Вы можете запросить столько #1, сколько захотите. Они могут подумать, что вы раздражаете, но это хорошее/умное раздражение. Вас бы за это не записали.

Если вы спрашиваете № 2, они думают, что у вас проблемы с пониманием. Или вы просто любите задавать вопросы, но не слушать. Это терпится до определенной степени и быстро надоедает.

В зависимости от вашего положения и того, какие необычные вещи вы привносите в команду № 3, может быть все в порядке — вы хорошо знаете конкретную область, вы дешевы, что угодно. Однако вам лучше не спрашивать № 2 после того, как вы спросите № 3.

Нет сомнения, что #4s не хороши. Вы можете уйти, спрашивая некоторые из них, но не как новый сотрудник. Коллеги ожидают, что вы спросите № 1 (и некоторые № 2) задолго до того, как подумаете о № 4. Если вы задаете много вопросов №4, они думают, что вы повсюду.

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

Хммм... #6 зависят от человека. Многие люди могут задать множество вопросов №6, если они интересны или забавны. С другой стороны, если вы не № 6, это может быть очень плохо, особенно если вы спрашиваете № 2-5.

Если вы думаете про себя, почему они не могут просто быть добрыми ко мне и помочь мне, если у меня возникают проблемы и я постоянно задаю вопросы со 2 по 5. Потому что они могут нанять кого-то другого, кто знает больше и не задает глупых вопросов. Если бы я был на вашем месте, я бы стал уделять больше внимания, может быть, даже носить с собой блокнот, и когда кто-то что-то отвечает, вы должны быть на 100% уверены, что вы это поняли, или попросить разъяснений на месте.

Этот ответ о том, как получать отзывы (другие ответы уже очень хорошо рассказывают, как задавать вопросы).

Хотя меня также ругали за то, что я «иду по ложному пути» при попытке решить проблему, с которой я не знаком, вместо того, чтобы спросить кого-то, кто был знаком. Когда я спросил о противоречии, мой менеджер и отдел кадров сказали, что мне просто нужно лучше понять, когда задавать вопросы. Никогда не думал, что задавать вопросы может быть так опасно.

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

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

Это потому, что если вы не напортачили преднамеренно, вы и ваш босс расходитесь во мнениях относительно того, напортачили ли вы. Либо ваш босс неправ, либо вы (или вы оба). Вы должны принять во внимание возможность того, что это можете быть вы, потому что очень маловероятно, что ваш босс полностью неправ, а вы полностью правы, и даже если вы правы, вы можете убедить своего босса в том, что он не прав, только показав ему, где он находится . неправильно, и это тоже требует его слушания.

Вы также можете попросить совета о том, как вы могли бы добиться большего успеха.

Например, услышав, что вы задаете слишком много и слишком мало вопросов, вы могли бы спросить:

Таким образом, я задавал как ненужные вопросы, так и не задавал нужных вопросов. Как определить, какие вопросы необходимы? То есть, каких вопросов мне следует задавать больше, а каких меньше?

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

Это обычно? Разве новый человек в компании не должен быть любопытным или задавать вопросы, которые непосредственно не связаны с его работой?

В какой степени ожидается или желательно задавать вопросы, различается в зависимости от рабочего места. Возможно, вы захотите адаптироваться к культуре своего рабочего места, которую вы можете обнаружить, наблюдая за своими коллегами, обращая внимание на то, как люди реагируют на ваши действия (их раздражают ваши вопросы или в восторге от них?), или спрашивая их отзывы. («Можно ли было спросить об этом?»).

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

Что касается неприятностей из-за того, что я задаю вопросы, я стараюсь использовать объяснение: я хочу увидеть, как это должно быть сделано, или действовать в соответствии со стандартами компании. Опять же, я заметил, что в старшем поколении это почему-то раздражает. Я думаю, что пожилые люди склонны думать, что я решил это сам, и мне не помогли, поэтому они менее готовы помочь. Они также чувствуют себя прерванными. Как и кто-то из упомянутых выше, постарайтесь найти подходящее время, чтобы попросить о помощи, поглаживая при этом свое эго: «Я слышал, что вы были тем парнем, к которому можно было обратиться по этому поводу…» «Кто-то сказал, что вы эксперт по…. «Надеюсь, это заставит их не обращать внимания на прерывание, и они будут более охотно помогать, так как вы дали им что-то, чтобы доказать. Будьте осторожны с последним советом, так как я уверен, что в некоторых случаях он может иметь неприятные последствия.

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

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

Это скорее предложение для вашего работодателя, но, возможно, вы могли бы заставить его работать на вас.

Они назначили вам наставника, когда вы начинали? Хорошая идея — дать новому сотруднику назначенного наставника, к которому он может обратиться со своими вопросами. Это дает им кого-то, кто уже имеет опыт работы в компании, и не дает новому парню постоянно беспокоить всех остальных. :-)

Наставник также будет знать, у кого можно спросить и где искать такие вещи, как документация. Например, в одних проектах могут быть документы Google Doc, в других — на внутреннем файловом сервере, а в третьих — в исходном репозитории. В то время как другие проекты вообще не имеют никаких документов.

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

Следует помнить одну вещь: код подобен грамматике. Люди могут знать, что у них отстой, но не любят, когда им об этом говорят. Например, если я укажу, что вы постоянно пишете с ошибкой слово «суждение», вы можете быть раздражены, потому что на самом деле я не добавляю ничего конструктивного. Ну я как раз так и сделал :)

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

Я согласен с другими, кто упомянул, что это не похоже на хороший инкубатор для начинающих разработчиков. Однако это обычное дело. Требуется время и опыт, чтобы определить свою нишу, найти работодателя, который вам подходит, и определить, что для вас важнее всего. Так что платите свои взносы, берите свои куски, планируйте свою карьеру и уходите после нескольких лет упорной работы. А пока просто прислушайтесь к совету, не беспокойтесь о PIP и продолжайте напоминать себе, что ваша текущая ситуация — это просто средство для достижения цели. Ваши начальники ожидают, что вы будете приходить и уходить вовремя, как если бы вы работали в Wendy's. Это не так, как должно быть, даже для неопытных новых разработчиков, так что впереди может быть гораздо более светлое будущее в другом месте.