Варіанти для провідного програміста, який віддає перевагу програмуванню перед ведучим? [зачинено]


19

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

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

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

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


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

Відповіді:


16

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

У моїй компанії мене підвищили до лідерства в команді (вони називають це «дизайн-лідерство») і через брак людей, які знають продукт і мають достатній досвід, я зголосився очолити 2 різні команди. Кілька місяців тому "допомогти в розкладі", керівництво подвоїло кількість цих 2 команд.

Я щось намагався зробити ...

  1. Дайте зрозуміти всім (у тому числі керівництву), що моя та посада всіх інших людей не є постійним завданням. Кожен бажає підійти до тарілки, поширити уявлення про проект та взяти участь у архітектурних / дизайнерських рішеннях. Я маю остаточне слово (поки що), якщо буде розбіжність без вирішення, але поки що цього не сталося.
  2. Зосередьтеся на наданні допомоги іншим людям розвиватися та рости. У мене були (майже філософські) дискусії з різними розробниками в різні часи про кодування та дизайн та різні підходи до виконання справ. Деякі з цих дискусій пов’язані з фактичною роботою, інші - чистими вправами на думку. У мене був хлопець з більш ніж 20-річним досвідом, повертайтеся до своєї книжкової полиці і піднімайте книгу C ++, тому що його цікавили деякі речі низького рівня, які я робив з мета-програмуванням шаблонів. Ці дискусії є дещо заразливими, і після того, як ви достатньо разів піднімете ці теми, люди починають замислюватися над цим матеріалом самостійно.
  3. Делегуйте якомога більше на інших людей. Хоча я переглядаю багато речей, я не беру участь у кожному огляді коду. Натомість я роблю огляди коду для наших проміжних хлопців, і я дозволяю цим хлопцям перевірити код для деяких екологічно чистих людей. Я вважаю, що огляди коду є більше інструментом передачі знань, а не "давайте переконайтеся, що ми читаємо кожен рядок і знаходимо всі можливі помилки".
  4. Після того, як інтерфейси визначені і основний дизайн буде створений, я дозволяю навіть молодшим хлопцям отримати якомога більше свободи, як можливо, кодування внутрішніх класів. Так, багато цього коду далеко не ідеально, але він перевіряється і працює. Якщо він перетинає певну суб'єктивну межу з точки зору "кодового запаху", і вони не відновили його, я б припустив, що певні класи повинні бути розбиті або переставлені. Іноді боляче, але коли я перевіряю назад кілька днів пізніше і отримую відповідь, "я ненавиджу це визнати, але цей код зараз виглядає набагато краще", що насправді викликає в мене тепле, нечітке відчуття.
  5. Киньте виклик людям. Замість того, щоб просто призначити їм функцію для додавання до продукту, попросіть їх додати ці функції, але зробіть це, не збільшуючи кількість функцій / членів даних у існуючих класах. Якщо вам доведеться поставити щось нове, вам доведеться взяти щось існуюче і витратити час, щоб зрозуміти, що це таке. Усі знають про рефакторинг, але без додаткової сили на початку здається, що людям потрібна допомога зробити цей стрибок, щоб насправді це зробити. Як мінімум, я хочу відвідати цю точку майже під час кожного огляду коду.
  6. Все стосується БАЛАНСУ. Ви не можете бути єдиною старшою особою в команді, яка переглядає всіх інших. Ви не можете провести цілий тиждень на зустрічах та переглядах. Ви не можете розраховувати, що ви згадаєте кожну помилку, яку зробить ваша команда. Зрештою, вам потрібно виділити час для того, щоб стати ведучим, але також потрібно виділити час, щоб бути розробником. Я б зійшов з розуму, якби не зміг кодувати. Навіть при всьому іншому я все-таки переконуюсь, що встигаю писати код і не просто код, а деякі справді, справді чудові речі. Я просто взяв на руки книги з програмуванням мета-програмування і почав копати всередині Boost. Хлопці, які придумали ці речі, повинні бути божевільними (в хорошому плані). Якщо ваше керівництво починає клопотати про те, чому все не переглядається або чому noob переглядає інший код ноб, вам просто потрібно пояснити всю рівновагу і те, що в команді просто немає достатньо досвідчених людей, і в кінці дня "це те, що є". Якщо у вашій команді є старші люди, тоді прийшов час розширити свої можливості та дати їм свободу робити власні розробки / огляди / допомагати іншим і не ставитися до них як до просто генераторів коду. З розширенням прав і можливостей настає свобода, і люди люблять свободу. Якщо у вас є розробники, які не піклуються про свободу / розширення прав і можливостей, це добре. Кожній команді ще потрібні чисті кодери, просто переконайтеся, що ви прагнете до рівноваги. З часом наділити повноваження і дати їм свободу робити власні розробки / огляди / допомагати іншим і не ставитися до них як до просто генераторів коду. З розширенням прав і можливостей настає свобода, і люди люблять свободу. Якщо у вас є розробники, які не піклуються про свободу / розширення прав і можливостей, це добре. Кожній команді ще потрібні чисті кодери, просто переконайтеся, що ви прагнете до рівноваги. З часом наділити повноваження і дати їм свободу робити власні розробки / огляди / допомагати іншим і не ставитися до них як до просто генераторів коду. З розширенням прав і можливостей настає свобода, і люди люблять свободу. Якщо у вас є розробники, які не піклуються про свободу / розширення прав і можливостей, це добре. Кожній команді ще потрібні чисті кодери, просто переконайтеся, що ви прагнете до рівноваги.
  7. Ваш час цінний. Тож попросіть команду надіслати електронною поштою всі найважливіші критичні питання, на які вони можуть зачекати кілька годин, перш ніж отримати відповідь. Коли питання задається, всю команду слід скопіювати на нього. Зрештою, коли у вас перерва в день, ви можете подивитися на проблему та допомогти людині, але багато разів хтось інший, можливо, вже побив вас у відповідь, і вам нічого не потрібно робити. Очевидно, що я веду за собою, я все-таки роблю себе доступним і я роблю це зрозумілим, бо я вважаю, що однією з моїх цілей є переконання, що ніхто в команді не зациклюється на тривалий час, не досягаючи прогресу.
  8. Переконайтеся, що ваша команда використовує якомога більше інструментів для підвищення ефективності спілкування. Наприклад, у нас є вікі-сайт, і коли-небудь один і той же випуск з’являється кілька разів, я прошу останнього хлопця, якого я допоміг створити сторінку вікі.

1
+1 відмінна відповідь, багато практичних порад. Делегування та балансування є надзвичайно важливими навичками, які потрібно постійно розвивати та удосконалювати.
Péter Török

Відмінна порада. +1 спеціально для №4; Я бачив, як люди витрачають занадто багато часу через те, що не думають таким чином.
DarenW

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

@Maxpm: Поза межами роботи я люблю працювати на машинах. Я також намагався займатися електронікою та обладнанням. Я приношу багато речей додому. Мій підхід до занять - це підхід, який моя дружина бере із собою: "якщо ти щось приносиш, ти повинен щось взяти". Я не кажу, що ніколи не додайте нову змінну чи метод, але настає певний поріг, вище якого ви не можете просто додати. Якщо ваш код стає великим, швидше за все, ви можете взяти великий шматок і розбити його на одне або кілька самостійних одиниць. Тоді замість великого моноліту у вас будуть будівельні блоки, і ви можете переміщатись і переставляти за потребою
DXM

@Maxpm: забув додати ... Так, ця стратегія працює надзвичайно добре, і вона лежить в основі принципів SOLID, які я рекомендував би всім ознайомитись. Минуло досить багато часу, як мені довелося мати справу з гниллю в коді.
DXM

4

Я не обговорював цього з керівництвом ні з ким

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


3

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

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

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


Так, я б. На жаль, деякі проекти є такими, моє просто не буває таким. Для управління цим достатньо технічних речей, які мені доводиться робити це 95% часу. Я спробую це змінити в майбутньому.
Вільям Фонтен

3

Перспектива роботодавців :

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

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

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

Спочатку виберіть щось просте, наприклад щотижневі оновлення статусу:

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

Потім поступово дайте їм додаткові завдання, поки ви не передасте майорці своїх додаткових обов'язків.

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

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

Я думаю, якби ти представив роботодавцю план на 6-9 місяців, який сказав

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

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

Удачі.


1

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


0

2 питання, які не очевидні з вашої публікації:

  • Ви в фірмі, яка безпосередньо заробляє гроші на написаному вами програмному забезпеченні (наприклад, Google, Microsoft чи Fog Creek), або ви перебуваєте на допоміжній функції (наприклад, у банку чи харчовій компанії)?

  • Чи є генеральний директор технологом, чи хтось, хто піднявся через ділові ролі?

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.