Хто такий «Інженер 10x»?

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

У цій статті ми розвінчаємо міф про «10-кратного інженера» та поговоримо про сумнозвісний синдром самозванця.

(Щоб дізнатися більше про «10x Engineer», перегляньте попередню статтю Codementor із засновником Moz Рендом Фішкіним тут.)

Тема Twitter

Я натрапив на a Потік Twitter днями, що мене дуже заінтригувало. У цій темі розповідалося про те, яким має бути «10x Engineer». 🤔

Ось як це почалося:

Мене ще більше зацікавило те, як багато досвідчених інженерів, експертів із розробників Google, провідних інженерів та інших професіоналів у Твіттері дуже захопилися ідеєю «10-кратного інженера», згідно з цією темою.

Давайте дізнаємось, чому, уважніше розглянемо 11 пунктів, викладених у цій темі Twitter, і обговоримо, чому ідея «10-кратного інженера» може мати шкідливі наслідки для роботодавців і працівників. У цій статті я також збираюся говорити про деякі ключові висновки.

відмова: Ця стаття висловлює лише мою точку зору щодо «10x Engineer» і ні в якому разі не має на меті зневажати будь-кого чи їхні погляди.

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

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

Я знаю, що всі ненавидять зустрічі, але це не означає, що вони непродуктивні. 👨‍💻

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

Це потенційно може дати «10x інженерам» привід не встигнути. Особисто я працюю до 2 години ночі, але я сплю 6 годин і перебуваю в офісі о 10 ранку. Крім того, я люблю працювати в оточенні інших людей. Я можу багато чому навчитися у людей, які мають більший досвід роботи, ніж я.

Як би спокусливо не було для деяких інженерів потреби в приватності під час роботи, це не означає всі інженери такі. Якщо що були у такому разі ми мали б багато порожніх офісів протягом дня. 🤷‍♂️

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

Для початку, яке відношення має фон екрана мого ноутбука? Ось як зараз виглядає головний екран на моєму ноутбуці:

Крім того, на моєму ноутбуці зношені ключі Контроль та таб, через функцію перемикання вкладок у macOS і Chrome, яку я часто використовую для пошуку відповідей у ​​Google, коли я застряг із проблемою кодування. (Я 1x Інженер. 😉)

винос: налаштуйте свої пристрої та оптимізуйте їх для ваш найвища продуктивність. Ігноруйте всі інші норми, а також «ви повинні використовувати це» і «чому ви не використовуєте це?» пропозиції. Прийміть добру пораду, але врешті-решт з’ясуйте, що найкраще підходить ви.

Більшість інженерів, яких я знаю, покладаються на свої навички вирішення проблем і навички «думати на ногах», а не на свою пам’ять. Цей твіт означає, що 10x Engineers мають неймовірну потужність пам’яті.

Коли QA робить попередити їх про проблему, інженери зазвичай вирішують проблему, використовуючи свої навички та знання кодової бази. Деякі питання можуть тривати години, інші – дні. Але не кожну проблему можна вирішити за години; це просто неможливо в реальному житті.

винос: добре знайте свою кодову базу, але не накладайте на себе надто тиску кожен рядок коду. З часом ви познайомитеся з ним ближче. Виправляти баги та помилки – це також те, у чому ви з часом станете краще.

У нас не було б жодних інженерів з переднього плану, інженерів UX чи будь-кого, хто спеціалізується на перетворенні хороших дизайнів у код інтерфейсу користувача, якби всі «10x інженерів» були повноцінними інженерами. Звичайно, повноцінні інженери — це чудово, і я знаю кількох із них, які володіють кількома навичками продукту, але вся ця ідея «10-кратного інженера», який рідко виконує будь-яку роботу з інтерфейсом користувача, не працює в жодній організації.

Робота з інтерфейсом користувача не менш важлива, і вона має свої проблеми.

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

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

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

Крім того, надмірна кількість кофеїну шкідлива для здоров’я! 🙅‍♂️

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

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

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

Цей твіт має кілька хороших моментів. це є важливо вчитися нові фреймворки та мови, але частина, де «10 інженерів» роблять це «попереду всіх у компанії», потенційно може породити негатив на робочому місці.

Натомість, якщо існує нова структура, яку деякі інженери повинні вивчити в організації, і цей нібито «Інженер 10x» уже вивчив її, обов’язком «Інженера 10x» є організувати семінар або хакатон, де він /вона допомагає навчати колег вивчати структуру.

Адже який інженер НЕ любите хакатон? 😉

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

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

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

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

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

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

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

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

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

• Їх поточна робота недостатньо складна, і вони хочуть досліджувати нові проблеми в інших організаціях, які можуть допомогти їм розвиватися як інженеру
• Вони не задоволені тим, як вони отримують винагороду за свої навички, і шукають вищу зарплату, яка відображає їхні навички
• Вони можуть вважати поточне робоче місце шкідливим, тобто у них може бути бос, який хоче, щоб вони були «10-кратним інженером» 😉

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

Але ні в якому разі не слід «тримати їх» або «відзначати їх». 🙅‍♂️

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

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

Страшний «синдром самозванця»

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

• «Я недостатньо хороший».
• «Мене взяли на роботу випадково!»
• «Як я буду таким же хорошим, як мої колеги тут?»

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

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

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

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

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

«Якщо ви найрозумніша людина в кімнаті, ви, ймовірно, не в тій кімнаті».

Джерело: https://www.codementor.io/blog/10x-Engineer-Not-Necessary-7do0ivvl3r