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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

способность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Википедия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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