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

129

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

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

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

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


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

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

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

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

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

BeeBand
источник
170
Дайте знать своему боссу, что с его стороны было очень приятно сохранить этот отзыв, вместо того, чтобы упоминать его, когда он заметил, что это проблема.
Blrfl
13
Программирование обслуживания требует определенного типа человека. Может это просто не твоя вещь. Точно так же, новое развитие требует еще одного человека. Вы говорите об обнаружении инструментов / подсказок / уловок. Сколько из этих инструментов вы создали для своего собственного использования? Если ответ - нет, тогда я действительно думаю, что вы не человек, занимающийся программированием технического обслуживания. Если вы были перетасованы между несколькими проектами из-за нехватки производительности, то воспринимайте это как четкое сообщение о том, что вы не подходите для занимаемой должности. Найдите что-то более подходящее для вас.
Данк
40
Если вам нужно угадать, что вас перетасовывают из-за вашей производительности, руководство делает что-то не так. Аналогичным образом, если вы впервые услышите о своей неудовлетворительной работе через 2 года, руководство делает что-то не так.
Майкл Шоу
32
@Bee: Как правило, когда кто-то получает плохой обзор, пора уходить. Они могут включить вас в «программу развития сотрудников», но я не думаю, что я когда-либо видел, чтобы кто-то приходил в себя, когда они достигли этой стадии. Самое простое время найти работу - это когда у вас уже есть работа. Так что, будь я на вашем месте, я бы очень скоро обновил свое резюме и начал бы искать в другом месте. Вы также должны быть очень осторожны с типом работы, которую вы принимаете. 7-летний опыт работы еще оставляет варианты. Как только вы достигнете 10, компании будут ожидать экспертизы в определенных областях. Выберите область, которая вам нравится и у вас хорошо получается. К сожалению, только что увидел, что вы уже достигли 10.
Данк
8
Не достаточно, чтобы быть ответом, но относительно «способа стать быстрее»: вы заявляете, что это домен, в котором вы новичок. Может быть, вы исправляете слишком много проб и ошибок, не зная, что происходит на самом деле? "в глубине души"? В таком случае тщательное изучение основ поможет вам лучше определить потенциальные проблемы.
Мацеманн

Ответы:

80

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

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

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

  2. Ты слишком худой Тот же ваш профиль SO показывает, что ваши вопросы охватывают очень широкий спектр технологий за последние 2 года (графика, веб, Python, C ++, C, Linux, встраиваемые, потоки, сокеты и т. Д.). Лично я знаю, что когда я оказался в ситуации необходимости (или желания) копаться во множестве разных потоков, я обнаружил, что плыву по течению очень быстро (или, скорее, очень медленно ). Возможно, что вам действительно нужно здесь, это ФОКУС . И, возможно, здоровая доза расстановки приоритетов . Можно ли в любом случае отложить менее важные кастрюли на задний план и включить огонь на основное блюдо?

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

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

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

kmote
источник
2
какой блестящий ответ. я думаю , что все ваши точки применимы ко мне (и о # 1, а , возможно , я буду менее умный, я слышал , что есть разные типы интеллекта -. Поэтому , возможно , что связано с # 4 может быть , я болван Embedded Linux DEV но, возможно, я лучше разбираюсь в Интернете ... и теперь я думаю об этом, это на самом деле может быть реалистичным). в любом случае - вы очень проницательны.
BeeBand
14
3 и 4 больше (для программистов), чем может себе представить большинство боссов. Если у программиста низкий моральный дух, он / она не может сосредоточиться на работе. Для программиста мораль - это импульс, а импульс - это все.
TimG
7
Отличный ответ. Отладка себя - отличная фраза, кстати. Хотел бы я во второй раз проголосовать за тебя.
Kyeotic
2
Ваше «это следовало бы» не работает в пункте 1, так как парадокс дружбы моделирует отношения между двумя людьми как простое двунаправленное ребро между двумя вершинами в графе, тогда как график того, кто «умнее», чем кто-то, должен учитывать Множество других факторов, не говоря уже о том, что правила транзитивности не применяются. Я согласен с пунктами 2,3 и 4. В случае ОП я думаю, что его босс - придурок, который страдает от эффекта Даннинга-Крюгера.
funkymushroom
1
программист, отлаживайся сам. люблю это :) хороший ответ тоже. полезно для меня не потому, что я в такой ситуации, а потому, что теперь я вижу, как этого избежать. +1
jammypeach
56

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

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

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

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

способность

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

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

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

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

Тон
источник
2
это отличный ответ. У меня есть мысли по поводу того, почему я не наслаждаюсь этой работой. В основном это файлы журналов, которые они дают нам, чтобы сопровождать ошибку, я пришел, чтобы ненавидеть их больше, чем кто-либо другой - я начинаю всегда полностью и совершенно в неведении с любой ошибкой, которую они мне дают. Я думаю, что это чувство «в темноте» я ненавижу.
BeeBand
4
Если у одного и того же проекта не возникло подобной проблемы, большинство людей начинают «в темноте», когда получают новую ошибку. Затем на основе симптомов вы выясняете, как воссоздать проблему, что должно дать представление о том, с чего начать догадываться о причине проблемы. Вы продолжаете шаг за шагом. Ничего волшебного, нечего ненавидеть. Вы говорите, что ненавидите файлы журналов. Вы создали какие-либо инструменты для автоматизации анализа этих файлов журнала? Игнорирование того факта, что файлы журналов должны быть полезными, если бы они не были полезными, прошло не много времени, прежде чем я создал инструмент, который помог бы проанализировать их для меня.
Данк
1
@ Да, я создал инструмент для анализа файлов журнала различными способами. Позже я узнал, что кто-то уже создал год или около того назад.
BeeBand
@Bee: Ваше создание инструмента показывает некоторую инициативу, необходимую. Никто не дает вам обзор среды разработки при переходе между проектами? Если инструменты существуют, то кажется, что руководитель проекта должен был сообщить вам о них.
Данк
Обзор @Dunk re - нет. Мой первый руководитель группы показал мне конкретный инструмент - но не указал, что он полезен для исправления ошибок определенного типа или что он может быть переведен в другие проекты. Когда я был переведен в этот новый проект обслуживания, никто не говорил мне через среду разработки - мне просто нужно было поспрашивать. Только после того, как я пытался создать свой собственный инструмент, я спросил коллегу, и он упомянул, как я могу использовать оригинальный инструмент. (NB это другой инструмент, чем мой предыдущий комментарий).
BeeBand
38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

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

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

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

Юридические вопросы и ответы: конструктивное увольнение

Причины требовать конструктивного увольнения

Википедия

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

Mathew Foscarini
источник
11
Это не запрещено давать отрицательные отзывы производительности, но они действительно должны быть объективными и согласовать возможные критерии для работы и поддержать вас.
pjc50
9
Я подумал, может быть, я слишком остро реагирую, когда я опубликовал этот ответ, но чтение вашего поста нашло отклик в моем собственном опыте. Исправление ошибок - это не то, что можно измерить в контексте производительности. Я потратил 3 месяца один раз, чтобы исправить одну ошибку. Обычно умные парни - те, кто получает серьезные ошибки.
Reactgular
9
Я не голосую, так как не вижу никаких доказательств того, что вы юрист и требуете дать юридическую консультацию. Кроме того, если другие сотрудники исправляют ошибки Х в среднем в месяц, а ОП исправляет Х / 10, это абсолютно объективно и разумно.
Энди
7
@ Энди, спасибо, что поделились, почему ты проголосовал. Я согласен с тем, что коэффициенты исправления ошибок являются показателем, но что является объективным, когда кто-то сообщает в пятницу, что в следующий понедельник у него отрицательный отзыв. Кроме того, чтобы тактично заставить их потеть на выходных. Разве не безопасно предположить, что желаемый результат состоял бы в том, что служащий не появляется в понедельник для обзора? Разве это не классифицируется как конструктивное увольнение? Я надеюсь, что смогу изменить вашу точку зрения, потому что конструктивное увольнение является постоянной проблемой в нашей отрасли.
Reactgular
7
Судья не может признать, что это конструктивное увольнение. Вы можете подрезать букву закона, но этот тип закона существует для случаев, когда сотрудник подвергается преследованиям или жестокому обращению, что является активно враждебной ситуацией. Основываясь на том, что говорит ОП, им сообщили, что они получают отрицательный отзыв, потому что он / она не сталкивается со сверстниками в том, что касается уровня исправления ошибок; Это сложная ситуация, но вряд ли она враждебна и, конечно, не противозаконна. Возможно, босс мог бы быть более тактичным, но обратная связь не должна ограничиваться официальными обзорами производительности
pdubs
26

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

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

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

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

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

Зан Рысь
источник
3
Это фантастический ответ. Я очень впечатлен.
Даниэль Холлинрейк,
26

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

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

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

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

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

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

zwol
источник
4
«Во-первых, отладка вдвое сложнее, чем писать код». - Брайан Керниган (отец Си, UNIX)
TimG
4
@TimG: И, как и любой другой программист, Керниган недооценивал сложность.
мю слишком коротка
Ух, я хотел бы отметить, что это действительно сложный вопрос, и я очень удивлен, увидев здесь такой хороший и проницательный ответ. Благодарю.
Максимо
12

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

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

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

JB King
источник
2
ended up getting micromanaged until I was terminated- Ну, я только что посмотрел на ваш профиль SO, и вы явно отошли от этого, поэтому я нахожу ваш ответ обнадеживающим. Я собираюсь рассказать о вашем первом замечании в понедельник - я получаю сообщения об ошибках из очень разрозненных районов.
BeeBand
10

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

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

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

chrisaycock
источник
2
да, это не мой код - это обширная встраиваемая система, впервые созданная 10 лет назад. Я думаю, что вы правы насчет шаблонов - мне нужно вернуться к основам.
BeeBand
1
@BeeBand было бы хорошо узнать, как вы поживаете. Надеюсь, все получится.
Даниэль Холлинрейк
10

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

pjc50
источник
Было бы интересно узнать, сделал ли это уже BeeBand. Прочитав комментарии и ответы, кажется, что это довольно недружелюбная среда.
Даниэль Холлинрейк
1
Ну, я могу сочувствовать этому. Я знаю, каково быть в компании, где команда разработчиков занята работой. К счастью, хотя в моем случае я работаю с некоторыми замечательными коллегами, и мы заботимся друг о друге. Есть ли кто-нибудь, с кем вы можете соединиться? Время, потраченное на обучение и помогающее вам стать более продуктивным, окупится для всех. Судя по звукам вещей, которые вам небезразличны и добросовестны, ваша фирма выиграет от того, что вас удержит
Даниэль Холлинрейк,
8

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

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

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

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

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

user2106285
источник
7

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

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

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

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

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

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

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

Kaz
источник
1
Самая большая проблема с параллелизмом заключается в том, что писать код без ошибок намного проще, чем исправлять ошибки в коде с ошибками. Особенно, если код почти правильный. И баги обычно не в одном месте, а распространяются по многим.
gnasher729
5

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

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

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

Jason Swett
источник
Я сейчас читаю это по вашей рекомендации.
BeeBand
3

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

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

m3th0dman
источник
Предположительно, это измеряется как количество закрытых вопросов / единица времени . Возможно, было бы разумно сказать: «Ну, некоторые ошибки занимают больше времени, чем другие», но если OP не работает в особенно сложной части кода, а все остальные делают легкие вещи, это, вероятно, не выдержит критики.
Калеб
3

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

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

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

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

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

Продолжайте свою страсть, так как это ключ.

dennisk1718
источник
2

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

«Но что расстраивает, так это то, что есть определенные инструменты / советы / хитрости, которые я узнал только после того, как провел там полтора года. эти «скрытые» инструменты время от времени ».

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

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

Эрик Реппен
источник
2

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

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

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

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

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

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

dcaswell
источник