Як залишатись мотивованим, коли відчуваєш, що високопоставлені колеги - ні

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

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

Моє питання полягає в тому, як працювати з такими колегами, особливо коли я старший.?

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

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

PS: Хоча я ціную всі відповіді, я здивований тому, що стільки людей виступає за нестандартну роботу, якщо ви це робите ". Це те, що від мене чекають.

Також, Я не хотів, щоб це було обговорення найкращих способів написання коду які деякі з них перетворили.

4 відповіді

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

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

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

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

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

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

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

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

Мені погано (і також сумно), коли щось робиться так, що я знаю, що є кращий спосіб зробити те саме.

Ваші колеги можуть бути на вищій посаді, ніж ви, оскільки вони можуть робити все швидко і ефективно.

Коли ви говорите, що існує «кращий спосіб», ви маєте на увазі, що те, як це було зроблено, було не елегантним, не «приємним» і що у вас був слабший спосіб робити те саме? Або ви кажете, що ваші колеги ставлять код небезпечним, небезпечним або кодом, який буде дуже важко підтримувати та масштабувати?

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

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

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

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

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

Задоволеність споживачів також є надзвичайно важливим фактором. Якщо вибір між кращим кодом та кращим користувацьким досвідом, UX завжди виграє і повинен. Знову ж таки, найбільший фактор відхилення - це коли кращий код призводить до кращого UX в майбутньому - чи буде достатньо кращого впливу коду, щоб зрештою зробити його дешевшим? Хороший код - це часто інвестиція, а не щось нестандартне; ви рідко знайдете можливість, коли хороший код забезпечує кращу ефективність оригінального завдання (пам’ятайте, що я говорю про «поганий» код, створений хорошими програмістами - якщо ваші програмісти просто погані та необережні, вам «пощастить»; повернення зазвичай йде далі по дорозі, якщо взагалі.

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

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

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

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

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