Які основні речі очікує програміст від старшого програміста?


41

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

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

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


19
joelonsoftware.com Прочитайте стільки його блогу, скільки у вас є час.
P.Brian.Mackey

@ P.Brian.Mackey дивовижне посилання!
Аватар

2
Те, що старший програміст має аватар, пов'язаний з Міядзакі, можливо, не обов'язково, але, безумовно, великий плюс :-)
leonbloy

1
Цікаво ... Мій бос забив 4 з 5 на цей тест ... Я повинен попередити його про хороших новинах;)
АОЕ

Відповіді:


79

Речі, які, здається, працюють добре для мене:

  • Дайте змістовну роботу та заохочуйте право власності - навіть коли виникає проблема, не вирішуйте її, розмовляйте з нею та дайте людині зрозуміти, щоб вони могли її вирішити самі.
    • редагувати - додаток - це також малося на увазі - уникнути деталей. Припустімо, що ваші люди знають достатньо, щоб виконувати завдання без мікроуправління або вимагати постійної реєстрації. Створіть набір вказівок щодо того, коли вони повинні зареєструватися - які повинні бути лише тоді, коли робота буде виконана або настільки заплутана, що серйозне втручання потрібні. Якщо можливо, тримайтеся осторонь, навіть не потребуючи участі у програмі підтримки інтерметаму.
  • Будьте чесні - це кілька наслідків:
    • Будьте чесні щодо себе - "я не встигну до вівторка", "я ніколи цього не робив, ось моя найкраща здогадка" тощо.
    • Будьте чесними щодо команди та місця, куди вони входять у компанію - якщо ви щось знаєте про діловий матеріал, скажіть, чи можете, та розкажіть, що ви знаєте, як прямі факти.
    • Будьте чесними у наданні зворотного зв’язку - не киньте слова чи м'яку педаль, якщо у вас є негативні відгуки. Це відрізняється від "жорстоко чесного" - ти все ще можеш співчувати, але якщо щось не так, скажи так.
    • Будьте чесні, коли знаєте, що робота швидше стосується редагування, ніж того, щоб зробити щось значуще. У життя кожного впаде якась безглузда робота. Не робіть вигляд, що це має сенс. Назвіть це так, щоб ви могли зосередитись на тому, щоб подолати його та перейти на щось корисне.
  • Слухай . Принаймні 50% вашої роботи слухає, а може й більше. Ви несподівано стали відповідальними не лише за технічну роботу, а за людей, які це виконують. Ви повинні слухати, щоб дізнатися не лише про проблеми, які має колектив, а й те, як ваші люди підходять до проблеми та які недоліки команди як групи.
    • Важливі наслідки - прослуховування може безпосередньо призвести до пункту №1 - даючи змістовну роботу - інженери чудово придумують способи полегшити розвиток. Ви не можете схвалити все, але там, де ідея хороша, дайте інженеру завдання, і вони по суті зробили, що ви працюєте для вас - вони створили змістовну роботу і сказали вам, що це таке.
  • Скажи «дякую» . Я знаю, це здається очевидним. Хоча ми всі любимо гроші, кращі інструменти, приємніше робоче середовище та акції - спосіб дістатися до цих речей - це ряд добрих зусиль, кожен з яких заслуговує на "спасибі". "Дякую" абсолютно безкоштовно, ви ніколи не закінчите їх, і знаючи, що ваш менеджер бачив і оцінив вашу важку працю, безумовно, є мотивуючим.
  • Приділіть час великій картині , навіть якщо це означає принести в жертву певну частину дня в день, що дало вам позицію. Напевно, правда, що ви можете кодувати краще, ніж деякі ваші люди, але якщо ви не витратите пристойний час на велику картину - команда, загальний напрямок проекту, стан вашої кодової бази, ефективність ваших процесів , оточення вашої команди - тоді ви не будете робити ту роботу, яку вам потрібно зробити.
  • Навчіться бути буфером для вашої команди . Інженерні команди найкраще працюють, коли встигають зайнятися ... інженерією. Корпоративна бюрократія - це не інженерія. Все, що ви можете зробити, щоб провести роздратовану зустріч із зовнішніми людьми на рік / місяць / тиждень. ПРИМІТКА: Це не означає спритних зустрічей із власниками акцій - це інженерія, для цього ваша команда повинна бути там. Я маю на увазі зустріч із спорудами, які хочуть поставити біля вашої команди гучний кричущий фрагмент техніки, або групу процесів, яка хоче, щоб ваша команда заповнювала документи в три примірниках, перш ніж будь-який код буде зареєстрований. Ви - система поглинання пластівців.
  • Припустимо, проблемні люди не злі , це люди, які хочуть творити добро, але ще не зрозуміли, як це зробити. Ви не зможете виправити всіх, але часто перші кілька повних викруток - це настільки ж фактор невдалого спілкування, як некомпетентність чи навмисна злоба. Якщо ви почнете з припущення, що люди не злі, ви маєте гідну надію уникнути ряду архетипів злих босів у списку вище.

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

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


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

3
Воістину Awesome .. Я б хотів, щоб StackExchange міг забезпечити підтримку наступних користувачів (коротка примітка до Джоела та Джеффа) :)
PrinceCoder

2
WAAOW !! ... це був один з кращих відповідей , які я коли - небудь зустрічав @Stackexchange
explorest

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

2
@PrinceCoder кожен користувач має власну стрічку, ви можете прослідкувати за цим у деяких RSS-читалках.
svick

12

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

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


2
Існує велика різниця між менеджером і старшим програмістом. Я ще повинен зустрітися з менеджером, як ви описуєте. Скажіть, будь ласка, де я можу їх знайти ;-)
fretje

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

+1 @James хтось відредагував назву, схоже. За запитаннями стенд про ведучих / менеджерів. Слово "начальник" виглядає люто, тому я вибираю слово старший програміст.
Аватар

6

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

Слухання важливе.

Будь ласка, і дякую вам важливо і нічого не коштує.

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

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

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

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

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

Дізнайтеся, як продавати ідеї вищим учням і навчіть цих навичок своїм дияволам.

Зрозумійте важливість бізнес-сфери та станьте експертом у цій галузі, а також програмуванні.


3

Ключові слова тут - довіра та відповідальність.

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

ІМХО, саме це творить чудеса у створенні здорової атмосфери.


2
При умови , що вони є пристойно компетентні і мотивовані. Якщо команда успадковується як є, це, на жаль, не є даною. Якщо ви обирали членів самостійно, це, звичайно, інша історія.
Péter Török

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

на жаль, я зустрічав контрприклади :-( У гіршому випадку, який я бачив, розробник не робив абсолютно нічого, коли йому дали свободу та повну відповідальність протягом двох місяців - як виявилося, він навіть не зайшов на робоче місце. деякі люди просто не тягнуть їх ваги в команді, і якщо ви дозволите їм вільно працювати без пильної уваги, ви просто зробити речі гірше , якщо ви не позбутися від цих людей під час, вони можуть пошкодити всю команду ..
Péter Török

@ Péter Török - впевнений, кожен знає декількох таких людей у ​​кожній компанії (насправді читаючи це, я думав, ти знаєш того самого хлопця, що і я :). Але з мого досвіду, більшість людей роблять фокус і намагаються зробити все можливе.
Jas

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

3

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

Головне, чого слід уникати IMO - це бути "людиною" так "вищому керівництву" і завжди погоджуватися, незалежно від того, що вони говорять (поцілунок попу, іншими словами)


+1: Правильно. І якщо ви потрапили до звіту "Так-Людина", залиште якнайшвидше.
Джим Г.

1
На жаль, є багато середовищ, де старший / ведучий / менеджер-програміст - це не що інше, як Людина Так (або як я вважаю за краще їх називати "Сміттери"), і найгірша частина - це більшість часу, про яку Ви цього не знаєте поки ви не приймете роботу.
Уейн Моліна

3

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

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

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


2

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


2

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

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