Як стати хорошим гравцем команди? [зачинено]

Я програю (нав'язливо) з 12 років. Я досить добре обізнаний у мовах, що знаходяться там, від складання, до C ++, до Javascript, до Haskell, Lisp та Qi. Але всі мої проекти були власноруч.

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

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

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

І останнє, що мені потрібно багато часу, щоб зрозуміти код інших людей. Конвенції про іменування змінних (які змінюються в залежності від кожної нової мови) є складними (__mzkwpSomRidicAbbrev), і я вважаю, що розв'язання зв'язаного каналу складно. Це не означає, що я не злегка парую речі - я думаю, що я досить добре в цьому можу власну роботу, але коли я завантажую щось на зразок ядра Linux або вихідного коду Chromium, щоб переглянути це, я витрачаю години на пробування щоб зрозуміти, як з’єднуються всі ці дивно названі каталоги та файли. Гріх програмування - винаходити колесо, але я часто вважаю, що просто швидше написати функціонал сам, ніж витрачати години на розбирання якоїсь бібліотеки.

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

Питання: Які кроки я можу зробити, щоб почати "інтегруватися" з усіма іншими?

Спасибі!

Я думаю, що ти стаєш трохи тривожним і схвильованим, працюючи над групою.

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

Ми просто вчимося працювати з групами, працюючи в групах IN.

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

Для мене суть є

Станьте частиною команди.

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

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

...

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

...

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

Я думаю, що найбільше, що вам потрібно буде вивчити, це:

Для даного стандарту можливостей розробника команда nрозробників робить менше, ніж nразів, роботу, яку один із розробників міг зробити сам - але вони все одно виконують більше, ніж могла б одна людина .

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

Інша важлива річ:

Деякі ваші колеги будуть менш здатні, ніж ви, безумовно, у деяких навичках; деякі навіть менше можливостей , ніж ви в усіх навичок

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

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

Найефективніший спосіб - стати частиною команди.

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

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

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

Shameless вилка: ви дуже вітаємо тут !

Я не повторюю те, про що вже говорили всі "just do it", але додам додатковий момент, про який я не бачив: хороший менеджер дійсно допоможе вам інтегруватися в команду.

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

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

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

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

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

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

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

Бути хорошим членом команди означає безстрашно спілкуватися, довіряти колегам та долати перешкоди в проекті як команді таdeliver project as a team.

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

Було б корисно виділити деяких персонажів хорошого члена команди .

а) Хороший член команди - це людина, орієнтована на ціль, а не орієнтована на себе.

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

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

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

Ви знедолені тим, що не маєте освіти в галузі створення програмного забезпечення. У цій освіті є кілька предметів, які навчаються (не тільки як програмувати), що для CS-програм та досвідчених розробників програмного забезпечення буде другою природою. Не те, що він часто виникає на робочому місці (хоча це колись було для мене), але NP-hard є прикладом терміна, який вони можуть зрозуміти, а ви цього не можете. Вам, мабуть, не вистачає будь-якої основи формальної теорії, яка лежить позаду обчислень, але це нормально, доки ви готові дізнатися про це. Може бути, магістр з CS у вашому майбутньому? Здається, що ваш код може бути ідіоматичним, в тому сенсі, що у вас є стиль програмування, який вам здається зрозумілим, а не іншим. Зверніть увагу на огляди коду та будьте готові приймати критику та вчитися. Це займе роботу, і ви можете розчаруватися,

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