Чи можете ви одночасно бути менеджером і програмістом? [зачинено]

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

Це дуже поширена схема, принаймні в компаніях, в яких я працював.

Чи можете ви бути хорошим програмістом чи хорошим менеджером, якщо ви робите обидва одночасно?

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

ОНОВЛЕННЯ : моє запитання включає управління компанією (що є моїм випадком), а не конкретно управління командою. Але мене цікавить обоє, звичайно.

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

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

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

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

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

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

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

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

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

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

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

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

Я впродовж багатьох років був менеджером проекту програмування з різними компаніями, проектами та командами.

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

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

Я бачив обидва сценарії. Менеджери розробників роблять {деякий відсоток свого часу} кодування, а менеджер розробників взагалі не робить кодування.

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

(Звичайно, є компанії, де ви можете просуватися через Dev, Dev Lead - відрізняється від менеджера Dev звичайно - на такі посади, як архітектор тощо)

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

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

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

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

Для тих, хто розглядає цей шлях, кілька порад:

• Виконайте вихід із ролі архітектури та визначте потенційні результати у вашій групі.

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

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

• Допоможіть вашій команді рости: станьте більш незалежною, самоорганізованою, технічною майстерністю, більш високим рівнем обізнаності.

• Багато в чому ви є мостом між командою та зовнішнім світом. Значна частина вашої уваги повинна бути поза командою.

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

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

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

Вкрай часто (як ви сказали) бачити це в запускаються компаніях.

Я думаю, що ні.

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

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

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

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

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

Спольський у своїй статті про рівень абстракції розробника написав таке:

"Для програмної компанії першочерговим завданням управління повинно бути створення цієї абстракції для програмістів".

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

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

Він все ще один з найкращих розробників, яких я знаю.

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

Кращий менеджер, який я коли-небудь мав (я був у бізнесі ~ 25 років), був активним розробником, моїм менеджером і напіввласником компанії (близько 40 емп). Він був особливим, але він явно досяг успіху в цьому питанні.

ДЛЯ ВЗАЄМНО НІ !!

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

Хоча менеджер технологічної компанії ПОТРІБНО .. ні ... ПОВИНЕН знати, як кодувати. Ви просто не зможете оцінити або зрозуміти проблеми клієнта. Кодування та управління - це два типи людей. Один бік - вундеркінд і незручний з людьми (зіткнетесь, вун, ви знаєте, про що я говорю), а інший - добрий з людьми. Ви повинні вибрати сторону. Ви нікуди не потрапите з кодуванням, якщо зробите і те, і інше. Якщо ви любите кодування і можете це робити цілодобово, якщо ваша дружина не перешкоджала вам, БУДІТЬСЯ ВІД ВІД ВПРАВЛІННЯ. Навіть зніміть зарплату, якщо вам доведеться. Я збираюся це зробити, але я не думаю, що начальству це сподобається, бо я полегшую їм життя, роблячи частину управління. Мені доведеться повернутися до фрілансу, якщо вони не згодні, тому що щастя і те, що ти любиш, важливіше, ніж гроші та ілюзії, які він купує.

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

Прочитайте розділ "Відсутність орієнтованого на програмування шляху до кар'єри" на цьому веб-сайті. Дуже хороший матеріал і дуже актуальний: http://c2.com/cgi/wiki?ProgrammingIsNotFun

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

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

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

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

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

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

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

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

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