Чи означає, що більш високооплачувана технічна робота означає, що ви більше не отримуєте код? [зачинено]

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

1. Розробник на сутичку команди , яка розробляє для одного продукту і , можливо , працює з іншими командами, які тісно пов'язані з продуктом.
2. Архітектор , який є більш консультантом по декільком командам (5-6) і намагається розпізнати подібності між зусиллями команди , які можна було б абстрагуються в бібліотеки (архітектори не писати код бібліотеки, однак). Цей архітектор також відвідує багато зустрічей з керівництвом та намагається встановити технічне керівництво.

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

Мої запитання: чи працюють у більшості компаній так, що їх високооплачувані технічні працівники далеко не пишуть код? Це природна тенденція кар’єри розробника? Чи може розробник мати все це (код І встановити напрямок?)

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

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

Це природна тенденція кар’єри розробника?

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

Чи може розробник мати все це (код І встановити напрямок?)

Абсолютно. Хоча ви повинні розуміти , що кількість кодування буде йти вниз. Ви просто не можете добре виконати ці інші цінні речі, якщо ви витрачаєте 80% дня головою вниз в ІДЕ.

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

Більшість компаній не потребують такої спеціалізації. Вони просто збирають дані разом або роблять ще один веб-сайт / mobileapp.

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

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

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

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

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

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

Я думаю, що найкращі архітектори програмного забезпечення є практичними. Я побачив хорошу статтю http://www.infoq.com/articles/brown-are-you-a-software-architect Подивіться на частину 4 Проектування, розробка та тестування.

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

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

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