У який момент "конструктивна" критика вашого коду стає непомітною?


39

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

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

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

Тепер я можу бачити, що в деяких середовищах це було б нормою. Однак критика виглядає не однаковою мірою, саме це призводить до моєї наступної проблеми. Основа більшості цих проблем полягала в тому, що я знаходився в кодовій базі, яку написав хтось інший і намагався бути малоінвазивною. Я імітував імена змінних, які використовуються в іншому файлі. Коли я це заявив, мені прямо сказали: "Не імітуйте інших, просто робіть те, що правильно". Це, мабуть, найменш корисна річ, про яку я міг сказати. Якщо код, який уже зареєстрований, неприйнятний, то як я повинен сказати, що правильно, а що не так? Якщо основа плутанини виходила з базового коду, я не думаю, що це "

Я відчуваю себе справді виділеним і розчарованим у цій ситуації. Я набагато краще став дотримуватися стандартів, які очікуються, і я розчарований, що, наприклад, коли я переробляю фрагмент коду, щоб перевірити помилку ADD, що раніше не було, мені лише сказали, що я не зробити помилки багатослівними (і на цій основі відхилено гілку). Що робити, якщо я ніколи не додавав цього для початку? З чого це ввійшло до коду, щоб почати, якщо воно було так неправильно? Ось чому я відчуваю себе таким виділеним: я постійно стикаюся з цим існуючим проблемним кодом, що я або імітую, або рефактор. Коли я це імітую, це "неправильно", і якщо я його рефакторирую, я можу сказати, що я недостатньо зробив (і якщо я пройду весь шлях, вводячи помилки тощо). Знову ж таки, якщо це така проблема, я не розумію, як який-небудь код потрапляє в кодову базу,

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


18
Я хлопець, молодший (у цій компанії), і я відчув подібний подвійний стандарт. База даних коду часто схожа на лайно, і все ж я повинен дотримуватися набагато вищого стандарту. Що ж, виявилося, що лайно потрапило туди через "марші смерті", які були зроблені в минулому. Також, мабуть, я виглядаю на 5 років молодше, ніж я. Коли мої колеги дізналися мій реальний вік, я став набагато розумнішим за ніч. Люди - недосконалі мавпи. Це допомагає, якщо ви поділите з ними обід і посмієтеся над їх жартами, але не перестарайтеся. Хлопці трактують ВСЕ як флірт.
Робота

4
@Job: Ну, якщо база коду є лайно, то має бути краще, отже, ваші зобов'язання повинні мати вищий стандарт. Інакше він став би ще хитрішим, правда? :)
Макке

@Marcus, ти маєш рацію, але що було б дуже корисно, якби правила були чітко прописані, а однакові правила застосовувались до всіх. Крім того, є що сказати про змішування в ті ж стандарти коду, що і згаданий запитувач. Я бачив, як молодшого хлопця відпускають як козла відпущення. Керівництво поскаржилося, що інженери видали занадто багато помилок. Інженери не змогли зробити гідну роботу, оскільки керівництво дає їм встановлені строки. Тож, коли щось піде не так, завжди є молодший хлопець, у якого найбільше викручувань, і винуватити його та відпустити. en.wikipedia.org/wiki/Дедовщина
Робота

3
Одне, що мені виділилося, - це "вони звикли до хлопців, тому вони не використовують декор". Я б сказав, що вам потрібно це висмоктати, якщо явно це не проблема дискримінації. Ви б зайшли на будівельний майданчик і розраховуєте, що до нього поводяться інакше, ніж до решти резидентів? Тугіше. Якщо ви працюєте в середовищі, де переважають чоловіки, вам потрібно вміти справлятися з іншими соціальними нормами так само, як і вони. Не будьте такі "чутливі".
Ріг

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

Відповіді:


41

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

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

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

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


Відповіді Анни, як правило, дуже розумні. +1. Я думаю, що робота там, де ти працюєш, призведе до того, що я згорнеш. Невже ваше керівництво не піклується про дотримання термінів? Якщо код працює, відправте його. Почистіть його пізніше. Чорт забирай, ти можеш навіть почистити його в понеділок і просунути його в наступному випуску. Така поведінка вашого менеджера ніколи не літатиме на моє місце роботи, і я радий, що можу зосередитися на дотриманні строків замість політики. Сподіваємось, що ситуація покращиться і що ви знайдете рішення. :)
jmort253

11
@ jmort253 Дякую :) Це говорило: "якщо код працює, пересилайте його" може бути небезпечним ставленням. Робочий код не завжди є хорошим кодом (хоча це, звичайно, краще, ніж зламаний код), а якість коду є важливою в довгостроковій перспективі. Прибирання пізніше майже ніколи не відбувається, оскільки з’являються інші терміни і з’являються більш гострі речі. Для цього є термін - "технічна заборгованість".
Адам Лір

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

@ Anna / Thorbjorn - Іноді потрібно просто робити те, що хоче замовник, хоча є термін. Ваш клієнт буде не дуже розуміти, якщо він / вона втратили дохід від бізнесу на суму 15 000 доларів, тому що ви просто хотіли прибрати помилки капіталізації. На жаль, спробувати усунути 100% технічної заборгованості не завжди можливо. Це було б схоже на очікування 40 років, щоб заощадити достатню кількість грошей, щоб придбати будинок мрії, а не брати іпотеку. Звичайно, ви були б вільні і зрозумілі, але все життя провели б, займаючись тінистими поміщиками.
jmort253

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

25

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

Причини відхилення вашого реєстрації (імена змінних, якість коментарів, місце конфігурації) здаються мені досить стандартними.

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

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


2
+1 Ви зосереджуєтесь на стосунках та емоціях. Програмісти, з якими ви працюєте зі звуком, дуже сухі, але вони просто зосереджені на проблемах з кодом. Це досить часто в програмних середовищах, над якими я працював. До речі, я бачив це незалежно від статі.
Майкл Дюррант

14

Доповнення до інших відповідей:

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

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

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

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

Так ...

.. Можливо, ви отримуєте більше відгуків лише тому, що у вас є потенціал зробити щось із цього. :)


Це викликає багато хороших балів.
sevenseacat

13

Цілком можливо, що вас виділяють, бо ... ви молодший розробник.

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

Рішення просте:

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

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


1
Намагання слідувати деякому «стандарту» до «Т», коли людина має справу з заходами, як вона описує, не принесе багато користі. Це буде нескінченний аргумент щодо визначень та семантики.
MrDatabase

4
@MrDatabase Вони не дуже схожі на домівки для мене. Можливо, трохи прискіпливо, але чорт часто описується в деталях, і як тільки ви почнете підбивати свої стандарти, весь ваш додаток може швидко піти вниз.
Адам Лір

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

@ user15859: якщо ви маєте на увазі мою відповідь, це взагалі не було моїм наміром. Я вважаю, я сказала саме те саме, що сказала Анна у своїй відповіді. Жодного образи не передбачалося. Згадані вами порушення стандартів важливі для тривалого обслуговування, і будь-яка неоднозначність у застосуванні стандартів повинна вирішуватися разом із керівництвом команди. Якби ти був ледачий, ти б тут не опублікував. Якби ви були некомпетентні, ви б так не переймалися. Я не вірю, що ти один із таких.
Стівен А. Лоу

1
Я думаю, що вона посилається на те, що сказав Woot4Moot, використовуючи "лінь і некомпетентність" як фразу у своєму коментарі. Я вважаю, що ваша відповідь чудова, оскільки це дає певним чином можливість звертатися до ОП з урахуванням її тлумачення того, що відбувається насправді.
jmort253

10

Примітка автора

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

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

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

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

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

Тепер про проблеми, які ви порушили:

Ви зареєстрували код, який не відповідав встановленому ним стандарту, тому він відхилив вашу гілку. Якби я був у його взутті, я б не робив те саме так само, але я би переконався, що мої підлеглі (незвичайне слово; тому що я не вважаю лідера як «вищого» для людей, яких вони привести, але це точно (не адекватно) описує ситуацію) знайте, що правильно робити. Якщо вони не знають, що таке стандарти, я винен як лідер. Мені належить виправити це. У цьому випадку ви, можливо, помилилися, але той факт, що це сталося, означає, що ви або 1) не сказали, що правильно зробити, або 2) не були належним чином проаналізовані. Ви також не винні.

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

Якщо ваша команда написала правила кодування, дотримуйтесь їх. Якщо їх немає, то для вашої мови має існувати певна умова спільноти (для .NET і C #, Microsoft має стандарт , якого дотримуються багато компаній).

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

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

Сказати "я до цього пізніше" - це погано. Пізніше ніколи не буває. Знайдіть час, щоб зробити це правильно. Пізніше в програмуванні немає.

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


1
Я другий коментар про "я до цього пізніше". Якби у мене був нікель кожен раз, коли я це чув, ну, я б тут не набрав цього коментаря. :-)
Ерік Кінг

Для .Net є стильний коп. Увімкніть його, щоб цей код не створювався, поки StyleCop не буде задоволений. Це знімає суб'єктивність людини - це знущання робочої сили. Розумієте, технологія може допомогти вам вирішити, чи був Майкл Фелпс №1 чи №2. У фігурному катанні, однак, ... фігури . У команді не повинно бути [дис-] фаворитів. Треба бути обережним, щоб таке враження не сформувалося. Один з хороших способів зробити це - увімкнути правила, які перевіряли б код і давали вам неупереджений відповідь.
Робота

3

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

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

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

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

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


1

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

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

Зроби так, щоб зробити це правильно зробити це швидко

Отже, якщо ваш керівник прийняв рішення відхилити ваше зобов’язання, він як професіонал повинен знати, що він робить.

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

Будучи молодшим, важко знайти шлях до кодової бази компаній.

Найкраще: існують документально підтверджені стандарти кодування - і ви, сподіваємось, навчитеся їх розуміти.

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

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

І це призводить до ще однієї (останньої) поради: Дотримуйтесь правила розвідника хлопчика !

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


0

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

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

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

Вигадки особистості в офісі чи на робочому місці буквально нескінченні. Сподіваємось, ви зможете дізнатись, кого уникати та коли їх уникати. Також не будьте занадто жорсткі до себе :-) Ви завжди можете кинути і знайти іншу роботу!


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

-2

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

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

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

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

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

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


2
Це не здається "драконічним"; послідовність є важливим компонентом ремонтопридатності, ремонтопридатність є важливим компонентом якості, а якісне програмне забезпечення має набагато більший шанс доставки вчасно та з меншими витратами, ніж "компромісний код". Це може бути обнадійливим, що щось на зразок 80% програмних компаній хочуть погіршити якість та зазнати наслідків, тому, здається, не існує дефіциту "недраконічних" можливостей працевлаштування. :)
weberc2

1
Я не хотів би працювати в умовах, коли основні конвенції не виконуються. Якщо проект відмовляється від захисту своїх правил кодування, він приречений стати нездійсненним у довгостроковій перспективі. Особливо іменне змінне не є дріб'язком: незалежно від того, скільки існуючого коду називається певною матрицею A, я ніколи не приймаю комісію, яка викликає іншу матрицю Bдля узгодженості. Звичайно, я не знаю, що саме ОП малося на увазі під "імітацією [...] імен, що використовуються в інших місцях", однак, враховуючи якість якогось коду, який я бачив, це може бути таким чином.
cmaster
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.