Чи є спосіб швидше вирішувати помилки? У мене щойно було попередження від мого начальника [закрито]

Мені щойно сказав мій начальник, що я отримаю негативний огляд результативності в понеділок. Він хоче поговорити зі мною про те, чому я так повільно і чому мій рівень виправлення помилок такий низький.

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

Я фактично був програмістом близько 10 років. Але це моя перша багатопотокова робота з вбудованим Linux - я тут вже 2 роки, і всім очевидно, що я все ще борюся. І я думаю, що я став настільки деморалізованим і відчуваю себе настільки маргіналізованим, що втратив багато вогню, який мав на початку роботи.

Хтось коли-небудь потрапляв у подібну ситуацію і як ви ставитеся до підвищення рівня виправлення помилок?

Оновлення: у мене був огляд. Мене поклали на тримісячну програму розвитку співробітників (такого типу, який згадував Данк). Не впевнений, чи можу я це перевернути. Але навіть якщо мені доведеться рухатись далі, я багато чого навчився з цього досвіду.

Ще одне оновлення

Зараз минуло 6 тижнів з моменту першого огляду. Моя порада всім, хто стикається з тією ж ситуацією, - бути досить покірним, щоб критикувати та вчитися на своїх помилках. І не боятися виглядати німим. Задайте питання та вантажі запитання. Повідомте людям, що ви намагаєтеся навчитися, і продовжуйте запитувати, поки не зрозумієте. Але будьте готові, щоб це не вийшло. Я будую портфоліо коду ... а також даю найкраще.

Ще одне оновлення

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

Багато відповідей ставлять під сумнів методи / тактику / метрику вашого начальника / тощо. Але це поруч. Можливо, ви повільні. Кожна кімната розробників повинна мати ОДНО, що повільніше, ніж решта, правда? (Це просто пряма теорія множин.) Тож припустимо, що це ти. Відповідь: ЧОМУ ви повільні? (Очевидно, що це питання, на яке ви повинні відповісти, перш ніж ви зможете вирішити заявлене питання про те, як швидше.)

Причини можуть бути всілякі, але ось кілька можливих пояснень:

1. Ви менш розумні, ніж вони . Це можливо, правда? (Дослідження показали, що ми ВСІ є менш популярними , менш цікавими та (з цього випливаємо) менш розумними, ніж наші друзі.) Тож, можливо, ви просто повільні. Потім, знову ж таки, у вашому випадку я думаю, що це малоймовірно. Швидкий огляд вашого профілю StackOverflow показує, що у вас є історія запитань інтелектуальних питань на широкий спектр тем. Тож ти, очевидно, мислитель і, мабуть, хороший у цьому.

2. Ти занадто худий. Той самий ваш профіль SO показує, що ваші запитання охоплюють дуже широку гаму технологій за останні 2 роки (графіка, веб, python, c ++, c, linux, вбудовані, нитки, розетки тощо). Особисто я знаю, що коли я потрапив у ситуацію, коли я маю (або бажаю) заглибитися у безліч різних потоків, я виявляю, що плаваючий струм дуже швидко (або, вірніше, дуже повільно ). Можливо, тут вам дійсно потрібно Фокус . І може бути здоровою дозою пріоритетності . Чи все-таки ви можете віднести менш важливі горщики до задньої конфорки і підняти тепло на основній посуді?

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

4. Ви не у своїй зоні. Майкл Джордан зробив досить кульгавого бейсболіста. (Гаразд, він все ще був кращий за мене, але, безумовно, мінор.) Можливо, "багатопотоковий вбудований Linux" просто не ваш концерт. Але розробка програмного забезпечення - надзвичайно широке поле (як ви добре знаєте; див. №2 вище). Чи достатньо широка ваша компанія, щоб ви могли знайти іншу нішу? На моїй останній роботі мене найняли як вбудовану розробнику SW. (У мене не було досвіду в цій царині, але я сказав їм, що я "швидкий вчитель".) Я швидко затонув, як камінь. Але я продовжував працювати наполегливо і постійно шукав проблеми , які я зробивзнати, як їх вирішити. Як виявилося, я поступово зміг перейти до нових обов'язків, на яких я міг сяяти, і за що я зрештою отримав значну похвалу. Тож, можливо, вам доведеться ребрендувати себе.

Справа в тому, що якщо ви повільні, є причина. Але, ей - ти програмний інженер, чувак! Налагоджуйте себе!

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

Давайте подивимось на кілька причин, через які ваш начальник може зараз це виховувати:

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

Можливо, сили, що не перебувають під вашим контролем, вимагають від вашого начальника висловити свою стурбованість. Важливо розуміти систему, в якій ви працюєте. Ваша робота - зробити так, щоб ваш начальник виглядав добре. Єдиний спосіб зробити це - зрозуміти тиск, під яким він перебуває.

Здатність

Цілком можливо, що здібності не дорівнюють, як ви кажете, він відкрито заявив. Ось що я зробив би в цій ситуації:

Отримайте конкретні відгуки від свого начальника про те, як він вимірює результативність. Ви не закриваєте стільки помилок, як людина X? Чи існує набір помилок, які ви повинні вирішити? Якщо ви працюєте поодинці, то вам потрібно переконатися, що люди, які вимірюють вашу ефективність, оцінюють це справедливо, а не базуються на заздалегідь задуманій ідеї.

Якщо ваша ефективність повільна і базується на реальній прогалині, визначте цю прогалину та складіть детальний план разом із вашим начальником з метою його усунення.

Цей огляд також є гарною можливістю підказати той факт, що ви не задоволені. Добре, що ви визначили, що не любите цю роботу. Але з’ясуємо, чому. Яка частина вашої роботи вам подобається, а що ні? Можливо, ця робота не для вас ...

Деякі робочі середовища непрацездатні. Я бачив умови, в яких ніхто не міг вижити (окрім тих, хто був на початку), тому що стільки було недокументовано, а питання настільки жорстоко відлякували.

Вам справді потрібно бути чесним щодо себе щодо очікувань та наданих ресурсів, які допоможуть вам їх задовольнити. Проблема може бути не ти.

Ви згадуєте, що є люди, які виконують подібну роботу з вашими, які, я вважаю, не мають труднощів, але які мають 5+ років досвіду для ваших 2. Як ви себе почуваєте порівняно зі своїми однолітками? Це рок-зірки, які цілком переважають вас (у цьому відношенні), чи вони просто такі, як ви? Можливо, вони просто познайомилися з системою, коли вона була простішою ... Ви згадали, що до цього напряму роботи працювали 8 років досвіду програмування. Як ви там зробили? Якщо ви зробили чудово, то це повинно вам щось сказати.

Частина, яка мене вразила, - це те, що ти описуєш себе як у темряві стосовно всіх помилок, які надходять на твій шлях. Можливо, база коду настільки обширна і незрозуміла, що очікування може не бути розумним.

Для вас це зробило так далеко, як у вас є, означає, що ви зробили щось правильно і щось для вас вийшло.

Підсумок, я думаю, полягає в тому, що вам потрібно добре себе почувати і про те, що ви робите. А якщо це означає рухатися далі, то так і буде.

Краще рухатися далі, ніж працювати, що руйнує ваше життя.

По-перше, зауважте: ця відповідь може застосовуватися лише до певних регіонів, де звільнення працівника без виправдання незаконно. Це сказало ...

Це може бути випадок конструктивного звільнення, а це незаконно.

Тактика полягає в деморалізації та зниженні самооцінки працівника до тих пір, поки вони не відмовляться від роботи. Це спосіб компанії заощадити гроші, не виплачуючи виплат, або вирішити проблему, що доведеться протистояти працівникові та звільняти їх.

Він хоче поговорити зі мною про те, чому я так повільно і чому мій рівень виправлення помилок такий низький.

Ця вина дуже неоднозначна. Жодна сторона партії не може стверджувати, що інша є неправильною. Вам знадобився місяць, щоб виправити одну помилку. І що! Це ставить вас в оборонну позицію, викладаючи факти, які підтверджують ваше твердження, що потрібен місяць. Враховуючи вашу чинну майстерність, досвід та знання як фактори. Як роботодавець це робота роботодавця керувати часом та зусиллями своїх працівників. Роботодавцем має бути особа, яка бере участь у ризику, пов’язаному із виправленням помилок. Не працівник. У нього завжди був вибір призначити помилку комусь іншому.

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

Чи неправильно роботодавець скаржитися на те, що ви забираєте занадто довго? Абсолютно ні, але він не може притягнути вас до відповідальності за це, і він не може звільнити вас за це. Він може сказати вам "У нас немає більше помилок, які вимагають ваших навичок, і вас відправляють у відпустку", але вони повинні повідомити вам, коли з'явиться нова проблема, яку ви можете виправити. В іншому випадку вони повинні припинитися з відстороненням. Що він не може зробити, це дати вам роботу, яку ви не можете впоратися, а потім скаржитися на це. Я думаю, що це незаконно.

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

Існує велика різниця між прийняттям роботи, яку вам важко, і роботодавцем, який дає вам занадто важку роботу. Якщо ви вважаєте, що покладені на вас завдання були зроблені, щоб відмовити вам від кар'єри в компанії, це може бути незаконним.

Я фактично був програмістом близько 10 років. Але це моя перша багатопотокова робота з вбудованим Linux - я тут вже 2 роки, і всім очевидно, що я все ще борюся.

Тому я думаю, що ви опинилися в середині конструктивного звільнення. Вони із вами не задоволені, тому вони накидають на вас лайно, поки ви не підете.

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

Роботодавець несе відповідальність за забезпечення безпечного та позитивного робочого середовища. Без додаткової інформації (швидше за все особистої) стороннім людям складно сказати, що тут насправді відбувається. Попросіть адвоката з працевлаштування на безкоштовну консультацію. Вони зможуть сказати вам, чи граєте ви.

Список літератури

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

Відповідні факти слідкуйте за:

• Недостатня підтримка працівника під час складних умов праці
• Надмірна дисциплінованість працівника Накладення зміни місця роботи працівників за короткий термін
• Накладення зменшення зарплати чи заробітної плати

Юридичні питання та відповіді: конструктивне звільнення

Причини вимагати конструктивного звільнення

Вікіпедія

елементи конструктивного звільнення

Можливо, вас порівнюють з одним із оригінальних програмістів проекту. Я знаю, що як оригінальний розробник одного з проектів, над якими я працюю, я маю величезну перевагу при виправленні в ньому помилок. Я не думаю, що це через брак документації, я просто можу інтуїтивно перестрибувати до потенційних проблем, оскільки мій мозок знає весь код.

Якщо вас порівнюють з цим, то ви просто не збираєтесь вимірювати. Завжди буде потрібно більше часу, щоб прискорити проект, і ви не знатимете, де знаходяться всі потенційні точки взаємодії.

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

Ви можете використовувати зошит або дошку, щоб намітити графіки шляхів, потоків і блокувати час життя, а також позначити, де ви спостерігаєте різні поведінки і де можна вставити нові зонди.

Вирішення подібних проблем із ниткою на низькому рівні може бути дуже важким, і я маю дуже симпатію до вас. Мені довелося проаналізувати кілька гігабайт файлів журналів, перш ніж виявити дво рядкову проблему. А ви знаєте що? Я дивився на це днями, перш ніж я звернувся за допомогою до молодшого інженера, який був стажистом рік тому, і він придумав новий підхід і виявив проблему через годину. Отже, після того, як ви помістите деякий час у помилку, погляньте на це нові очі. Це може дуже допомогти!

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

Що ви можете з цим зробити?

• Робіть замітки під час налагодження. Просто завжди відкрийте вікно редактора і запишіть свій потік свідомості. Це не має сенсу для когось, крім вас. Ви можете виявити, що це допомагає швидше налагоджувати, але це також означає, що вам потрібно щось конкретно вказати, щоб продемонструвати, що ви не грали в Nethack цілий тиждень.

• Порівняйте замітки з усіма своїми колегами. Скільки часу потрібно, щоб виправити помилки? Чи залишаються виправлені помилки? Як часто вони змінюють одну дрібницю і опиняються похованими під купою каскадних наслідків? Відповіді на ці запитання дадуть вам певне розуміння того, чи справді ви боретеся щодо інших відділів.

• Подружитися з QA людьми та підтримкою клієнтів. Саме вони мають найкраще уявлення про те, наскільки важливі помилки. Часто це має мало або взагалі ніякої кореляції з тим, наскільки важкі помилки, тому ви можете трохи пограти в систему і спробувати призначити всі помилки, що мають велику важливість, з невеликою складністю. (Це насправді не обман. Добре організована команда завжди йде за першими помилками.)

• Якщо ваш начальник протягом двох років не надає вам належних відгуків про вашу ефективність, це проблема спочатку піднести цей огляд результатів роботи, а потім, коли вам дадуть змогу на нього, піднятись з начальником свого начальника. Будьте ввічливі, і особливо не дозволяйте їм бачити, як ви гніваєтесь, але пишіть конкретну критику в письмовій формі.

Хоча ви, можливо, любите програмування та вирішення проблем, може виникнути питання про те, наскільки добре ви застосовуєте те, що вивчаєте, в інших сферах. Чи є хтось із останніх десятків помилок, які ви виправили, досить подібними, що те, що допомогло вам виправити одну, було корисним для іншого? Це частина огляду тому, що ви робили, і скільки часу знадобилося, щоб це зробити. Просто ідея для розгляду.

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

У мене були деякі робочі місця, які кажуть мені, що їм не сподобалося, як довго мені потрібно було виконати деякі мої роботи. Звичайно, це були ті місця, де, якби я зробив одну річ, 5 нових речей відпали б у мене на колінах, і, таким чином, було легко перемогти. Хоча я, можливо, більше не працюю там, у мене не було хорошого рішення, як привернути увагу до кількох речей, так що я не відчуваю, що намагаюся засвоїти 1000 речей все одночасно. Якщо я можу знати кілька ключових речей, які потрібно виконати, і як оцінюватимуть мою роботу, то я набагато кращий, ніж якби у мене був список "завдань", який довгий за милю, і, здається, ніхто не піклується про те, якщо я отримаю частини цього зроблено. Таким чином, може статися, що в цьому є культурний компонент, хоча я б з обережністю попросив змінитись тут.

Після двох років роботи, це повинно бути очевидним для всіх (ви, ваш начальник, ваші колеги), де ви стоїте. Тобто ніколи не слід дізнаватися, що ти робиш себе погано лише раз на рік; ідеальне робоче середовище забезпечить постійний зворотний зв'язок.

У будь-якому разі, щодо налагодження багатопотокового коду: ви не згадали, чи це ваш код, чи чужий код. Існують нові відладчики та статичні аналізатори, які здатні впоратися з одночасністю. Але на самому справі, знаючи модель буде вашим кращим вибором , так як ви будете знати , що шукати.

Якщо ви розумієте, як працюють критичні секції, умови перегонів та тупикові місця, тоді ви зможете помітити несподівані речі. Якщо ви бачите "комунікацію" між двома потоками без змінних умов, або якщо ресурси змінено без конкретного порядку, або якщо локальна змінна оголошена staticбез видимих ​​причин, то у вас є потенційна помилка! Тож вивчіть кращі практики вашого домену, і ви зможете судити про те, що щось не є звичайним.

Не боройтеся самі, якщо вам не доведеться. Набір колег. Запропонуйте їм допомогти у полюванні на помилок. Запитайте їх про їхній розумовий процес та інструменти. Можливо, згадайте це у своєму огляді як частину свого плану покращення. Якщо всі навколо вас в цій системі краще , можливо, вони знають щось конкретне?

Мені щойно сказав мій начальник, що я отримаю негативний огляд результативності в понеділок. Він хоче поговорити зі мною про те, чому я так повільно і чому мій рівень виправлення помилок такий низький.

Майте на увазі, що в будь-якій нефункціональній компанії речі не відбуваються в цьому порядку. Якщо ваш начальник стурбований вашою роботою, він повинен встановити короткострокові цілі та поговорити про ваші результати, щоб дізнатися, де проблема полягає.

Натомість він вирішує дати вам негативний відгук, а потім з’ясує, чому. Здається, що він не бажає брати участь у проблемі, і він просто хоче результатів у таблиці.

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

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

По-перше, підвищення довіри:

Навіщо страждати? Ви можете легко знайти роботу, де вони вважатимуть вас "богом" лише тому, що ви можете зробити Linux, вбудований у будь-що, незалежно від рівня виправлення помилок.

У будь-якому випадку встановити обмеження на час полювання на клопа неможливо. Полювання на помилок - це безперечно вміння, а ефективність в ньому дуже цінна.

Можливо, вам не вистачить основної хитрості, про яку знають інші, яка робить вас повільнішою.

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

Крім того, як ваше розуміння одночасності ? Якщо ви розробляли десять років, але більша частина цього досвіду не була з багатопотоковим кодом, це може бути проблемою.

Ви повинні детально вивчити багатопотоковість: більше, ніж просто знати, як користуватися API, але насправді "отримати" це на глибокому рівні. Якщо ви займаєтеся багатопотоковим програмуванням, ви повинні бути тим розробником, який може дивитися на кодову базу з милі та визначати сценарії перегонів, тупиків, інверсій пріоритетів, голодування ...

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

Якщо код, з яким ви працюєте, що-небудь менш ніж ідеальний, я думаю, що ця книга допомогла б. Я виявив, що дуже багато часу, щоб виправити помилку, мені потрібно спочатку перефактувати навколишній код, щоб навіть зрозуміти його, а потім, коли я зрозумію код, і, сподіваюся, зробить код перевіряючим, відстежуючи і виправлення проблеми - менший випробування. (Іноді я навіть переписую код просто для того, щоб зрозуміти його, але потім повертаю свої зміни, щоб зменшити ризик введення нових помилок. Потім я вставляю виправлення помилок. Ця методика заснована на хитрість із книги.)

Я думаю, що моя пропозиція стосується лише частини вашої проблеми, і дещо опосередковано, але книгу варто читати незважаючи ні на що, оскільки робота зі застарілим кодом неминуча для будь-якого розробника.

Запитайте свого начальника, яка ваша швидкість виправлення помилок і яка середня швидкість виправлення помилок у команді. Що важливіше, запитайте його, як вимірюється швидкість виправлення помилок ...

Цей вид метрики насправді не є показником; якби це було, це було б навіть ненадійніше, ніж LOC (хоча вимірювати різні речі). І без належного вимірювання немає причин звинувачувати вас у чому-небудь.

Визнайте, що ви працюєте з роботодавцями та / або замовником НЕ для них. Не соромтесь зазначити, що в інтерв'ю, просто встановити рекорд прямо з самого початку.

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

Ви готові працювати, поки є Союз інтересів, що виганяє вас зі стійки кожного дня.

Якщо цього рушія немає протягом тривалого часу, тоді рухайтеся далі.

Ви витрачаєте свій час та енергію на роботодавця, який не продовжує цікавитись / покращувати навички / завдання завдання та / або цікаво вам працювати. Це робота управління. Крім того, що вони чисті накладні .....

Тримайте свою пристрасть, адже це і є ключовим.

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

"Але що засмучує, що є певні інструменти / підказки / підказки, про які я дізнався лише після того, як там був півтора року. Мене перемістили з команди в команду (я думаю, тому що я був недостатньо ефективним) і я виявляю ці «приховані» засоби так часто ».

... ви, можливо, мали таку ж проблему, що і я. Налагодження - це настільки ж ремесло, як і написання коду, який не вимагає стільки налагодження. Спостерігати, як інші розробники працюють через проблему налагодження, може бути дуже навчальним. Попросіть їх допомогти, коли у вас виникають проблеми з розсортуванням чогось. Особливо, якщо ти покриваєш землю, якої раніше не робив. І зробіть це в ідеалі, перш ніж настане час панікувати, тому що ви нічого не зробите.

Однак, я згоден із зауваженнями, що керівництво робило щось не так. Якщо хтось бореться з чимось, він повинен отримати допомогу в цьому, перш ніж розпочнеться негативний розгляд. Чорт, якщо хтось із команди бореться і ніколи не отримує допомоги, я б сказав, що кожен член цієї команди робить щось не так (хоча це може бути прямим результатом, коли люди спостерігають за їхніми виправленнями помилок надто близько).

Чого не вистачає в ОП - це будь-яка згадка про повторюваний процес або метод, який застосовується для усунення помилок.

Отже, спочатку документуйте процес, який ви слідуєте. Не забудьте задокументувати, що має на меті досягти кожного кроку в процесі.

Ви можете окреслити процес таким завданням:

1. Будьте впевнені, що ви точно розумієте, про що йдеться у повідомленні.
2. Спробуйте відтворити проблему.
3. Почніть розбивати проблему на більш дрібні шматочки
4. Подумайте про можливі причини проблеми.
5. Перевірте ці гіпотези

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

Я думаю, що якщо ви зможете чітко визначити проблему, наприклад, "У мене проблеми з роздумом гіпотез, щоб перевірити, коли намагаються вирішити помилки", тоді ви можете отримати більш цілеспрямовану пораду.