Есть ли способ быстрее освоиться с ошибками? У меня только что было предупреждение от моего босса [закрыто]

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

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

Я на самом деле был программистом около 10 лет. Но это моя первая многопоточная встроенная Linux-работа - я здесь уже 2 года, и всем очевидно, что я все еще боюсь. И я думаю, что я стал настолько деморализованным и чувствовал себя настолько маргинализованным, что потерял много огня, который у меня был в начале работы.

Кто-нибудь когда-либо был в подобной ситуации и как вы собираетесь увеличивать скорость исправления ошибок?


Обновление: У меня был обзор. Я был переведен на 3-месячную программу развития сотрудников (типа, упомянутого Dunk). Не уверен, смогу ли я это обойти. Но даже если мне придется двигаться дальше, я многое узнал из этого опыта.

Другое обновление

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

Еще одно обновление

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

129 голосов | спросил 5 revs, 2 users 100%
BeeBand
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

16 ответов


80

Многие ответы поставили под сомнение методы /тактику /метрики вашего босса /и т. д. Но это не относится к делу. Возможно, вы медленно. У каждой комнаты разработчиков есть ОДИН, который медленнее остальных, не так ли? (Это просто прямая теория множеств.) Итак, давайте предположим, что это вы. Ответ: ПОЧЕМУ вы медленно? (Ясно, что это вопрос, на который вы должны ответить, прежде чем вы сможете решить свой заявленный вопрос о том, как быстрее.)

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

  1. Вы менее умны, чем . Возможно, да? (Исследования показали, что мы ВСЕ менее популярные , менее интересный , и (он будет следовать) меньше умный, чем наши друзья.) Так что, может быть, вы просто медленно. Опять же, в вашем случае я думаю, что это маловероятно. Быстрый просмотр вашего профиля StackOverflow показывает, что у вас есть история, задающая интеллектуальные вопросы по широкому кругу тем. Таким образом, вы, очевидно, мыслитель и, вероятно, хороший.

  2. Вы слишком тонкие. . Тот же самый профиль SO показывает, что ваши вопросы охватывают очень широкую гамму технологий за последние 2 года (графика, веб, python, c ++ , c, linux, встроенные, потоки, сокеты и т. д.). Лично я знаю, что когда я был поставлен в ситуации, когда (или желаю) вникать в множество разных потоков, я нахожусь в плавном режиме очень быстро (или, вернее, действительно slow ). Возможно, вам действительно нужно FOCUS . И, возможно, здоровая доза приоритизации . Есть ли в любом случае вы можете отнести менее важные горшки к заднему контуру и включить огонь на основное блюдо?

  3. Вы не развлекаетесь. Когда огонь падает, паровому двигателю суждено замедляться. Вы признались в своем посту, что ваш боевой дух в последнее время сильно пострадал. К сожалению, вы попали в сосательный вихрь самоукрепляющих отрицательных гармоник - силы, которая может уничтожить мосты . Это слишком знакомая спираль: сложная задача -> стресс -> пропущенный срок -> больше стресса -> плохой механизм преодоления -> больше стресса -> промедление -> больше пропущенных сроков -> критика /сплетня (реальная или воображаемая) -> но еще больше стресса. Вы получите картину. Это редко приводит к полезности. Примите урок из моих дней в рафтинг на белой воде: когда вы будете всасываться под водой с помощью циркулирующего тока на задней стороне ускорения класса 4, ваш спасательный жилет НЕ будет буем вас назад к поверхности. Лучшая стратегия (хотя и неинтуитивная) состоит в том, чтобы найти дно дна , и выйти из riptide. Поэтому мой совет для вас: найдите какую-нибудь землю , чувак (друзей, церковь, здоровые новые привычки и т. Д.) И используйте ее, чтобы вытащить себя из водоворота.

  4. Ты не в своей зоне. Майкл Джордан сделал довольно хромого бейсболиста. (ОК, он был еще лучше меня, но определенно миноритарный.) Возможно, «многопоточное встроенное linux» просто не ваш концерт. Но разработка программного обеспечения - чрезвычайно обширная область (как вы хорошо знаете, cf # 2 выше). Является ли ваша компания достаточно широкой, чтобы вы могли найти другую нишу? В моей последней работе я был нанят как встроенный SW dev. (У меня не было опыта в этой области, но я сказал им, что я «быстрый ученик»). Я быстро опустился, как камень. Но я продолжал работать упорно и постоянно искал проблемы, которые я сделал знает, как решить их. Как оказалось, я постепенно мог перейти на новые обязанности, при которых ямог сиять, и для которого я в конце концов получил значительную оценку. Так что, возможно, вам нужно снова заклеймить себя.

Дело в том, что если вы медленны, есть причина. Но, эй - ты инженер-программист, чувак! Отлаживайте себя!

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
56

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

Давайте рассмотрим несколько причин, по которым ваш босс может сейчас это сделать:

Культура и политика

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

Способность

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

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
38

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

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

Вы упомянули, что есть люди, которые делают подобные задания для ваших, которые, я полагаю, не испытывают трудности, но у вас есть 5+ лет опыта для вашего 2. Как вы себя чувствуете по сравнению с вашими сверстниками? Являются ли они рок-звездами, которые полностью превосходят вас (в этом отношении), или они такие же, как вы? Возможно, они просто познакомились с системой, когда она была более простой ... Вы упомянули о том, что у вас есть опыт программирования на 8 лет перед этой работой. Как вы там поступили? Если вы сделали большой, то это должно вам что-то сказать.

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

Для того, чтобы вы сделали это, насколько это возможно, вы сделали что-то правильно и что-то для вас.

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

Лучше двигаться дальше, чем иметь работу, разрушающую вашу жизнь.

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
31

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

Это может быть случай Конструктивное увольнение , и это незаконно.

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

  

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

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

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

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

  

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

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

  

Я на самом деле был программистом около 10 лет. Но это моя первая многопоточная встроенная работа linux - я здесь уже 2 года, и всем очевидно, что я все еще боюсь.

Вот почему я думаю, что вы оказались в центре конструктивного увольнения. Они вас не устраивают, поэтому они наваливают на вас дерьмо, пока вы не уйдете.

  

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

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

Ссылки

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

Соответствующие факты соблюдают:

  • Неправильная поддержка сотрудника во время трудных условий работы
  • Чрезмерное дисциплинарное взыскание сотрудника. Наложение изменений в рабочем месте работника в короткие сроки.
  • Наложение сокращения заработной платы или заработной платы

Юридическое Q & A: Конструктивное увольнение

Причины претензийдля конструктивного увольнения

Википедия

элементы конструктивного увольнения

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
26

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

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

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

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

Решение этих проблем с низким уровнем нитей может быть очень сложным, и у меня есть много симпатий к вам. Мне пришлось анализировать несколько гигабайт файлов журналов, прежде чем обнаруживать проблему с двумя строками. И знаешь, что? Я смотрел на это несколько дней, прежде чем я попросил о помощи у младшего инженера, который был стажером год назад, и он придумал новый подход и обнаружил проблему через час. Итак, после того, как вы положили некоторое время на ошибку, взгляните на нее новыми глазами. Это может многое помочь!

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
26

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

Что вы можете сделать с этим?

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

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
12

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
10

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

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

Если вы понимаете, насколько важны критические разделы, условия гонки и тупик, тогда вы сможете лучше понять то, что неожиданно. Если вы видите «связь» между двумя потоками без переменных условия или если ресурсы мьютексируются без определенного порядка или если локальная переменная объявлена ​​static без видимых причин, то у вас есть потенциал ошибка! Поэтому изучите лучшие практики своего домена, и вы будете в лучшем положении, чтобы судить, когда что-то необычно.

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
10

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
8
  

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

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

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
7

Во-первых, повышение уверенности:

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

Во всяком случае, невозможно установить ограничение времени на поиск ошибки. Безупречная охота - это умение, несомненно, и эффективность в нем очень ценна.

Возможно, вам не хватает базового трюка, о котором знают другие, что делает вас медленнее.

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
5

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

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
3

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

Это своего рода метрика, на самом деле не метрика; если бы это было так, это было бы еще более ненадежным, чем LOC (хотя и измеряло разные вещи). И без надлежащего измерения нет оснований обвинять вас в чем-либо.

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
3

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

Вы профессионал, который много инвестировал в ваш малый бизнес, а именно себя.

Вы готовы работать, пока есть Союз интересов, который выталкивает вас из стойки каждый день.

Если это движение не существует в течение некоторого времени, тогда двигайтесь дальше.

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

Сохраняйте свою страсть, поскольку это ключ.

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
2

Я был в подобных ситуациях, потому что боялся просить о помощи. Судя по тому, что вы сказали в этом комментарии ...

  

«Но что расстраивает то, что есть определенные инструменты /советы /трюки я   узнал только после полутора лет. Меня перевели   раунд от команды к команде (я думаю, что я был неэффективен), и я   открывая эти «скрытые» инструменты так часто ».

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

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12
2

Что не хватает в OP - это упоминание о повторяющемся процессе или методе, который используется для устранения ошибок.

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

Вы можете описать процесс как имеющий такие задачи:

  1. Убедитесь, что вы точно понимаете, что такое проблема.
  2. Попробуйте воспроизвести проблему.
  3. Начните разбивать проблему на более мелкие части.
  4. Подумайте о возможных причинах проблемы.
  5. Проверьте эти гипотезы

Было бы полезно узнать, существуют ли ошибки в течение длительного времени или вводятся с недавними изменениями. Если ошибки были введены с недавними изменениями, которые делают обзоры кода и /или просто чтение кода, создаваемого людьми, могут помочь.

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

ответил sdenham 14 Jpm1000000pmWed, 14 Jan 2015 19:53:12 +030015 2015, 19:53:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132